Et maintenant, qu'est-ce qu'on fait ?
Recevez votre première alerte de sécurité
Acceptez votre mission
Votre SOAR reçoit en permanence des alertes, et même dans un SOC très mature, il y a toujours de fausses alertes. Il est essentiel de faire un tri pour éviter de mobiliser le SOC… pour rien. En revanche, dans ces alertes il y en a qui concernent des incidents graves, qu’il faut traiter d’urgence. Vous n’avez donc pas le temps d’investiguer sur chaque alerte !
Votre première mission, si vous l’acceptez, sera de décider le plus rapidement possible si l’alerte doit passer à l’étape d’après, ou s’il s’agit d’une fausse alerte qui doit être filtrée. C’est le principe de la qualification. Cette étape ne devrait pas vous prendre plus d’une dizaine de minutes.
Utilisez le SOAR
Alors cette alerte, à quoi elle ressemble ?
Sur le SI de Méditronique, ce sont le SIEM et l’EDR qui déclenchent les alertes, mais ces alertes sont envoyées dans le SOAR. Et c’est depuis le SOAR que vous allez échanger avec votre SOC pour trier les alertes et organiser la réponse aux incidents correspondants.
L’alerte vient avec des informations :
la règle qui a été déclenchée ;
le système sur lequel l’événement a été identifié ;
l’utilisateur qui a effectué l’action détectée (quand c’est possible) ;
l’heure de l’événement ;
etc.
Dans la capture d’écran présentée ci-dessus, on voit que chaque alerte possède un niveau de sévérité et un statut.
La sévérité est évaluée automatiquement par le système (SIEM ou EDR) qui a déclenché l’alerte, à partir de caractéristiques de l’événement ou de la règle de détection. Mais il faut la prendre avec beaucoup de recul ! Ces systèmes appliquent automatiquement des règles de détection, et peuvent passer complètement à côté d’éléments de contexte qui seraient évidents pour l’intelligence humaine.
En fait, cette sévérité ne sert qu’à prioriser l’ordre dans lequel vous devez qualifier les différentes alertes. Il faut plutôt l’interpréter comme une priorité.
À côté de la sévérité, vous pouvez voir le statut de l’alerte, qui indique qu’il s’agit d’une nouvelle alerte.
Le but de la qualification, c’est de lui attribuer un nouveau statut qui indique la suite du traitement à faire pour cette alerte.
Identifiez rapidement les faux positifs
Déjà, est-ce qu’on est bien certain qu’il s’agit vraiment d’une cyberattaque ?
Excellente question. Il arrive fréquemment qu’un événement qui n’est pas malveillant déclenche tout de même une alerte. On parle de faux positif.
Cela arrive lorsqu’une alerte n’arrive pas à différencier un comportement malveillant d’un comportement légitime (par exemple une connexion privilégiée), ou bien lorsqu’un comportement malveillant est arrivé par erreur ou de façon bénigne (par exemple un crash d’application).
Il est essentiel d’identifier les faux positifs dès que possible pour éviter de mobiliser le SOC… pour rien.
Et comment on fait pour les identifier ?
De manière générale, le principe est de prioriser ce qui pourra indiquer au plus vite un faux positif, et de conclure dès que vous êtes en mesure de le prouver.
Comprenez l’alerte
Tout d’abord, demandez-vous ce que signifie cette alerte.
Telle qu’elle est transmise au SOAR, elle contient des informations sur le contexte de l’événement : la date, le système concerné, et éventuellement l’utilisateur concerné ou le fichier suspect.
Ça a l’air simple une fois qu’on a de l’expérience. Mais comment un nouvel arrivant au SOC peut savoir comment réagir ?
Commencez par étudier ce contexte, il peut être suffisant pour conclure à un faux positif. Par exemple, si vous savez que l’événement déclencheur est le résultat d’une action qui était prévue, comme une maintenance. Ou bien si cet événement arrive souvent à cette heure-là, sur ce système, ou venant de cet utilisateur donné.
À l’inverse, le caractère malveillant peut être flagrant sur l’alerte. Si vous pouvez la lier avec certitude à une technique de la matrice MITRE ATT&CK, par exemple si vous reconnaissez l’usage d’un logiciel malveillant que vous connaissez, vous pouvez privilégier la réaction rapide et transmettre l’alerte. Vous pouvez être d’autant plus enclin à transmettre l’alerte tout de suite que la technique est à droite de la matrice, ce qui indique que l’attaquant potentiel est plus proche d’infliger des dégâts à l’organisation.
Il peut aussi s’agir d’une alerte qui revient souvent. Ici aussi, avec l’expérience, vous allez vite reconnaître ces alertes. Par exemple, un script qui effectue une connexion suspecte peut régulièrement lever la même alerte, que vous allez vite reconnaître, car elle concerne toujours le même serveur et le même utilisateur.
Identifiez si une investigation est en cours ou a déjà eu lieu
C’est toute la puissance du SOAR en tant qu’outil d’orchestration. Comme il contient tous les incidents, il constitue une formidable base de connaissance. Si vous n’avez pas encore l’expérience ou la maîtrise du contexte, votre SOAR, lui, l’a !
Cherchez les attributs que contient l’alerte : le nom du serveur, le nom de l’utilisateur, du fichier… Dans le SOAR de Méditronique, on appelle ça des observables.
Ces observables vont vous permettre de trouver des alertes ou des investigations. Est-ce qu’elles sont liées à votre alerte ?
Il y a plusieurs cas possibles :
Vous trouvez une investigation qui a déjà eu lieu sur l’observable. Elle explique la cause de l’alerte. Cela vous permet de conclure directement s’il faut traiter l’alerte ou non.
Il y a une investigation en cours sur un observable. Vous estimez que cette alerte est liée à l’investigation. Vous pouvez alors ajouter cette alerte à l’investigation.
Il y a déjà eu des alertes similaires, mais pas d’investigations. Pour quelle raison n’y a-t-il pas eu d’investigations ? Si la raison vous apparaît clairement, vous pouvez marquer cette alerte comme duplicata ou faux positif. Sinon, c’est peut-être le moment de creuser cette alerte !
Si vous n’identifiez aucune alerte similaire ni aucune investigation qui pourrait être liée, il faut chercher plus loin.
Approfondissez votre compréhension de l’alerte
À ce stade de vos recherches, vous n’avez rien identifié qui vous permette de filtrer l’alerte.
Quelles sont les questions à me poser pour pouvoir conclure en 5 minutes à un faux positif ?
En général, toutes ces questions sont guidées par des directives internes, et donc des procédures opérationnelles.
Voici quelques exemples :
Est-ce que vous pouvez contacter directement la personne ou l’équipe qui est responsable de l’alerte ? Si l’alerte a été déclenchée par un programme, il y a bien une équipe responsable de ce système (application, data, poste de travail, middleware…). Vous pouvez aussi contacter l’équipe métier qui utilise ce système et le connaît bien. Un appel rapide est encore le plus efficace !
Est-ce que vous pouvez identifier des événements qui expliquent cette alerte ? Ici aussi, un simple coup d'œil à l’agenda de l’utilisateur ou au planning de la DSI peut rapidement vous éclairer.
Est-ce que l’état du système explique l’alerte ? Cherchez dans le SIEM et l’EDR des informations concernant le moment où l’événement a eu lieu. Il ne s’agit pas de faire une analyse approfondie, mais simplement de vérifier en moins de 5 minutes s’il n’y a pas d’informations évidentes qui indiquent un faux positif (par exemple, un système en maintenance ou un mot de passe expiré).
Documentez votre conclusion et déclenchez l’étape suivante
Si vous avez effectué tout cela, vous devez arriver à l’une de ces 3 grandes conclusions :
soit l’alerte est un faux positif : il faut le noter dans le SOAR en lui donnant le statut “faux positif” ! En effet, même les faux positifs sont intéressants, parce qu’ils vont permettre d’améliorer le SOC ;
il y a une investigation déjà en cours : vous ajoutez cette alerte à l’investigation dans le SOAR. Cela peut être utile pour faire avancer l’investigation ;
aucune des réponses précédentes. Dans ce cas, vous devez en savoir plus sur l’alerte. Il faut donc créer une nouvelle investigation dans le SOAR à partir de l’alerte.
De manière générale, on essaie de filtrer un maximum les alertes pour ne se lancer que dans les investigation pertinentes. Mais mieux vaut faire une investigation pour conclure plus tard à un faux positif.
Vous pouvez voir ce processus comme un entonnoir, où à chaque étape les faux positifs sont écartés.
Vous devez donc créer une nouvelle investigation dans le SOAR. Pour cela, il faut la décrire, lui assigner une criticité et éventuellement l’assigner à quelqu’un.
Estimez la criticité de l’investigation
Comment estimer la criticité d’un incident ?
À partir du travail que vous avez fait pour trier les faux positifs, vous avez déjà une vision partielle sur la gravité de l’incident.
Pour estimer sa gravité, vous devez vous poser plusieurs questions.
Tout d’abord, à partir de caractéristiques intrinsèques de l’alerte :
À quelle technique de la matrice MITRE ATT&CK cette alerte fait-elle référence ?
Dans quelle colonne de la matrice (tactique) cette technique est-elle située ?
Plus la tactique est avancée à droite de la matrice, plus cela indique que l’attaquant est avancé dans son attaque, et plus l’alerte sera critique. En observant la technique correspondante, vous pouvez identifier les impacts potentiels.
Mais cela n’est pas suffisant ! Il faut prendre aussi en compte tout ce qui est autour de l’alerte, le contexte de l'événement dans l’organisation. Ce sont les caractéristiques extrinsèques : quels sont les actifs concernés : ordinateurs, comptes ?
Plus l’actif est sensible, plus l’alerte sera critique. Une alerte qui concerne un site web ou l’ordinateur portable d’un collaborateur lambda est moins préoccupante qu’une alerte sur un serveur, qui est elle-même moins critique qu’une alerte sur le poste de travail d’un administrateur.
En particulier, il existe un ensemble d’actifs qui sont le cœur de la sécurité de l’organisation : le Tier 0. Chaque alerte sur ces actifs est à la criticité maximale par défaut, car un attaquant qui les a compromis peut faire absolument tout ce qu’il veut dans l’organisation.
Enrichissez l’investigation
En plus de ces éléments, vous devez ajouter tout ce qui vous a été utile dans votre recherche de faux positif.
On appelle ce procédé l’enrichissement. Ici, il est très rapide, pour laisser la priorité à l’investigation. Mais tout au long du cycle de vie de l’incident, il sera enrichi de nouvelles informations pertinentes.
En parlant d'enrichissement, prenez le temps de visionner cette vidéo de Binetou qui va vous parler de la qualification des alertes au quotidien.
À vous de jouer !
Vous devez qualifier les trois alertes suivantes qui arrivent dans le SOAR de l’entreprise Méditronique :
L’utilisateur charlie.dupont@méditronique.com a effectué 5 tentatives de mot de passe erronées à la suite à 08:39. La technique associée est la compromission d’un compte via une attaque bruteforce par un attaquant sur le réseau.
L'utilisatrice alice.martin@méditronique.com s’est connectée depuis une adresse IP au Maroc à 09:21. Puis elle s’est connectée à sa boîte mail depuis une adresse en France à 10:02. La technique associée est la récupération d’un compte valide par un attaquant externe.
L’EDR a identifié un programme malveillant appelé
somekatz.exesur un serveur de sauvegarde. Ce serveur est critique, car il réalise les sauvegardes d’applications critiques pour l’activité de Méditronique. La technique identifiée par l’EDR est une tentative de récupération des identifiants d’autres utilisateurs connectés dans la mémoire du serveur.
Pour chaque alerte, proposez 3 questions pour qualifier rapidement ces alertes. Quand ce sera fait, comparez vos propositions à celles de la correction.
En résumé
La qualification est la première action menée sur réception d’une alerte.
L’objectif est de déterminer si l’alerte est un faux positif ou un incident de sécurité avéré qu’il faut investiguer, ou si elle est liée à un incident qui est déjà en cours de traitement.
L’outil central dans cette étape est le SOAR ; c’est ici que l’on reçoit les alertes, qu’on les trie, et si besoin qu’on crée les investigations.
Le SOAR permet aussi de partager les informations sur les investigations en cours et les incidents passés.
Pour trier les incidents, on cherche à répondre aux questions suivantes :
Est-ce que cette alerte est une alerte connue ou un faux positif évident ?
Est-ce que cette alerte est liée à une investigation, un incident en cours de traitement ou qui a déjà été traité ?
Est-ce que je peux vérifier en 5 minutes s’il s’agit d’un faux positif ?
Est-ce que j’ai besoin d’en savoir plus sur cette alerte ?
À l’issue de ce processus, il y a 3 possibilités de conclusion :
l’alerte est un faux positif : on le consigne dans le SOAR et on passe à la suite ;
il faut en savoir plus : on crée une investigation, on ajoute les informations nécessaires à l’alerte, et on estime la criticité de l’incident ;
l’incident indique un danger majeur et immédiat pour l'organisation : c’est la crise.
La prochaine étape est d’investiguer pour identifier la cause de l’incident. C’est le sujet du chapitre suivant !
