Face à une éventuelle menace cyber, il est essentiel de pouvoir réagir rapidement. Le recours à un orchestrateur au niveau du SOC, grâce aux possibilités d’automatisation qu’offre l’outil, permet de faciliter le suivi des alertes et d’accélérer la prise de décision face à un éventuel risque cyber.
Soutenant la sécurisation des systèmes informatiques, un Security Operations Center (SOC) opère une analyse continue de l’activité au cœur d’un environnement informatique. Celle-ci permet de détecter en temps réel toute anomalie, de générer des alertes et de les traiter. Le recours à une telle solution permet aux utilisateurs d’être plus sereins, dans la mesure où quelqu’un veille en permanence sur les actifs numériques de l'organisation et leur sécurité.
La gestion de chaque alerte implique de mener des investigations, afin de pouvoir la qualifier. En effet, une alerte ne correspond pas forcément à une menace et n’implique pas systématiquement de procéder à une intervention au niveau des systèmes.
Les équipes du SOC, à la suite d’une anomalie, ont pour mission première de récupérer un maximum d’informations afin de pouvoir déterminer si l’entreprise est victime d’une attaque, s’expose à une éventuelle fuite ou perte de données ou, au contraire, si l’alerte correspond à un faux positif. Dans ce dernier cas, l’alerte sera classée.
Ces informations, il faut aller les récupérer sur des bases de threat intelligence (par exemple des données sur une adresse IP publique, le hash d’un fichier, etc.) ou bien directement au niveau des logs (pour vérifier quelles ont été les actions réalisées avant ou après l’alerte).
Les vérifications à mener à la suite d’une alerte, consommatrices en ressources humaines, peuvent prendre du temps. Souvent, les opérateurs doivent les réaliser manuellement. Or, face à un risque, la capacité à réagir rapidement est un élément crucial.
Afin de réduire le temps de réaction, il est dès lors utile de recourir à un orchestrateur.
Cet outil permet avant tout d’automatiser les recherches et certaines tâches effectuées manuellement par l’opérateur à la suite d’une alerte. L’orchestrateur permet notamment l’enrichissement des alertes, en récupérant automatiquement les informations pour ensuite les restituer dans un e-mail, une notification Teams, ou tout autre cannal de communication que nous aurions défini, afin de rendre ces informations directement disponible à la personne chargée de qualifier le danger.
De cette manière, on peut gagner un temps précieux et éviter de prendre des décisions qui pourraient perturber les opérations de l’organisation, comme le fait de bloquer une machine ou le terminal d’un utilisateur en raison d’une potentielle menace qui s’avérerait être au final un faux positif.
Un « playbook », est un ensemble d’actions executé dans un ordre précis, qui peuvent être defini dans un arbre de décisions.
A l’aide de ces « playbooks », il est possible d’automatiser directement certaines tâches à travers l’orchestrateur, qu’il s’agisse de la recherche d’information en fonction d’un contexte donné ou d’autres opérations, comme l’agrégation des données ou même la qualification de l’alerte en faux positif si cela s’y prête. On peut en effet pousser très loin le niveau d’automatisation.
En interfaçant l’orchestrateur avec les outils de ticketing, il est possible d’automatiser la création de ticket et d’assigner celui-ci, avec toutes les information necessaires, directement à l’equipe la plus à même de traiter l’alerte. L’ingénieur peut alors beaucoup plus rapidement fermer le ticket s’il s’avère qu’il s’agit d’un faux positif au regard des données disponibles transmises, ou prendre les mesures nécessaires dans le cas contraire.
Si les facteurs amenant à la classification en faux positif sont connus, ceux-ci peuvent être defini dans l’orchestraur afin qu’il ferme automatiquement le ticket s’ils sont détéctés.
Les tâches déléguées à l’orchestrateur, réel soutien aux opérateurs du SOC, seront progressivement enrichies en fonction des cas de figure rencontrés et qui se prêtent à une automatisation. Cela permet une amélioration continue du service en liberant du temps aux opérateurs sur les taches redondantes pour effectuer des taches plus spécifique, comme du « threat hunting » ou de la veille technologique.
L’orchestrateur, suite à une analyse automatique des données, peut aussi lancer des actions de blocage d’un utilisateur, d’une machine ou de tout autre objet constitutif de l’environnement système, si la procédure le requiert, et ce afin d’éviter toute contamination des systèmes.
Toutefois, pousser l’automatisation jusqu’à ce niveau requiert de bien maîtriser les éléments d’analyse et de s’assurer que le blocage automatique fait effectivement suite à des menaces réelles.
Un blocage consécutif à une mauvaise catégorisation de l’alerte par l’orchestrateur peut en effet entrainer un risque de perturbation de la production à l’échelle de l’organisation.
Pour éviter ce genre de déconvenues, on peut envisager un blocage semi-automatique. Dans ce cas de figure, l’orchestrateur rassemble les informations et les envoie à la personne habilitée à prendre une décision, par e-mail par exemple. Dans le courrier électronique, le destinataire se voit inviter à enclencher ou non le blocage par simple validation. L’orchestrateur, une fois la décision validée, déclenche le processus permettant de contenir la menace.
Rédigé par
Thomas Profeta