Trier une alerte : de la notification à la décision
La méthode pour qualifier une alerte de sécurité : vrai ou faux positif, contexte, enrichissement, périmètre, et quand escalader.
Elouan
Série Détection et supervision · article 2 sur 4
- SIEM, EDR, XDR, NDR, SOAR : qui fait quoi
- Trier une alerte : de la notification à la décision
- IOC, IOA, TTP et la pyramide de la douleur
- La chasse aux menaces (threat hunting)
Une alerte n’est qu’une hypothèse : « quelque chose ressemble à une attaque ». Le travail de l’analyste est de la transformer en certitude, dans un sens ou dans l’autre, le plus vite possible et sans se tromper. C’est le cœur du métier en supervision, et il repose plus sur une méthode que sur un outil.
Les quatre issues possibles
| L’activité est malveillante | L’activité est légitime | |
|---|---|---|
| Une alerte se déclenche | Vrai positif | Faux positif |
| Aucune alerte | Faux négatif | Vrai négatif |
On ajoute souvent une cinquième case : le vrai positif bénin. La détection est exacte (un outil d’attaque a bien été lancé), mais l’activité est autorisée : un test d’intrusion, un exercice, un administrateur qui utilise un outil légitime.
Le pire, c’est ce qu’on ne voit pas
Les faux positifs coûtent du temps. Les faux négatifs coûtent des incidents, et par définition on ne les voit pas. Mais trop de faux positifs mènent à la fatigue d’alerte : les analystes finissent par clôturer sans regarder, et le vrai positif passe dans le lot.
La méthode de tri
1. Comprendre ce que dit l’alerte
Avant tout : quelle règle s’est déclenchée, sur quoi elle se fonde, et ce qu’elle est censée détecter. Une alerte « exécution PowerShell encodée » ne raconte pas la même histoire qu’une alerte « accès à la mémoire de lsass.exe ».
2. Rassembler le contexte
Les questions de base, souvent appelées les 5 W :
| Question | Ce qu’on cherche |
|---|---|
| Quoi ? | Quel processus, quel fichier, quelle connexion, quelle ligne de commande |
| Qui ? | Quel compte, avec quels droits, quel rôle dans l’entreprise |
| Où ? | Quelle machine, quel type (poste, serveur, contrôleur de domaine), où dans le réseau |
| Quand ? | Heure exacte, horaires habituels, pendant une intervention prévue ? |
| Comment / pourquoi ? | Qu’est-ce qui a précédé, qu’est-ce qui a suivi, quel enchaînement |
3. Enrichir
On ajoute des informations extérieures :
- réputation des IP, domaines, URL et hash (bases de threat intelligence, VirusTotal, plateformes de partage comme MISP) ;
- âge d’un domaine et informations d’enregistrement ;
- informations internes : inventaire de la machine, service de l’utilisateur, tickets de changement en cours ;
- historique : cette alerte s’est-elle déjà produite sur cette machine ? Comment a-t-elle été qualifiée ?
Attention à ce qu’on envoie dehors
Soumettre un fichier interne à un service public d’analyse peut divulguer des informations confidentielles, et prévenir l’attaquant que son outil a été repéré. On préfère rechercher le hash d’abord, et utiliser un bac à sable interne ou contractuel pour les fichiers sensibles.
4. Regarder autour : avant, après, ailleurs
Une alerte isolée est souvent trompeuse. On élargit :
- dans le temps : que s’est-il passé sur cette machine dans les minutes ou les heures avant et après ?
- dans l’espace : le même hash, le même domaine, la même IP, le même compte apparaissent-ils sur d’autres machines ? C’est le scoping, indispensable avant de conclure.
Une alerte, deux histoires
Alerte : powershell.exe -enc … sur un poste. Histoire A : le parent est l’outil de gestion de parc de l’entreprise, la commande décodée installe une mise à jour, le même script tourne sur 300 postes à la même heure : vrai positif bénin, on affine la règle. Histoire B : le parent est winword.exe, la commande télécharge un fichier depuis un domaine enregistré la veille, puis une connexion part toutes les 60 secondes vers une IP inconnue : vrai positif, on isole et on escalade.
5. Décider et documenter
La décision tombe dans l’une de ces cases :
- faux positif : on clôture, et on propose une amélioration de la règle ;
- vrai positif bénin : on clôture, et on documente pourquoi c’est autorisé ;
- vrai positif : on escalade selon la procédure, on lance les premières mesures de confinement prévues, on ouvre un incident.
Dans tous les cas, on documente : ce qu’on a vérifié, comment, les éléments trouvés et la conclusion. Une alerte clôturée « RAS » sans justification ne sert à rien le jour où l’on découvre, trois mois plus tard, qu’elle était le premier signe d’une intrusion.
Réduire le bruit sans devenir aveugle
Améliorer les détections fait partie du travail. Les bonnes pratiques :
- affiner plutôt que supprimer : une exclusion précise (un compte, un chemin, une machine, un hash) plutôt que la désactivation d’une règle ;
- combiner les signaux : une règle qui exige deux comportements suspects est plus fiable qu’une règle sur un seul ;
- mesurer : taux de faux positifs par règle, temps de traitement ;
- tester les règles sur des simulations d’attaque pour vérifier qu’elles détectent toujours ce qu’elles doivent détecter.
Les formats comme Sigma permettent de partager et de versionner des règles indépendamment du SIEM utilisé.
Partager l’information
Pendant et après un incident, on partage des informations avec d’autres équipes, d’autres organisations, des autorités. Le TLP (Traffic Light Protocol) précise avec qui une information peut être diffusée :
| Code | Diffusion |
|---|---|
| TLP:RED | Uniquement les destinataires nommés |
| TLP:AMBER+STRICT | Uniquement l’organisation du destinataire |
| TLP:AMBER | L’organisation du destinataire et ses clients ou partenaires qui en ont besoin |
| TLP:GREEN | La communauté (sans publication publique) |
| TLP:CLEAR | Aucune restriction |
L’article suivant explique comment exploiter les indicateurs : IOC, IOA, TTP et la pyramide de la douleur.
L'essentiel
- Vrai positif : l'alerte signale une vraie activité malveillante. Faux positif : l'alerte se déclenche sur une activité légitime. Vrai positif bénin : la détection est juste, mais l'activité est autorisée (un test, un outil d'administration). Faux négatif : une attaque qui n'a déclenché aucune alerte.
- Les faux négatifs sont les plus dangereux, parce qu'on ne les voit pas. Trop de faux positifs mènent à la fatigue d'alerte, qui fait rater les vrais.
- Trier, c'est répondre à : que s'est-il passé, sur quelle machine, avec quel compte, quand, est-ce normal pour cet environnement, et y a-t-il d'autres machines concernées ?
- Enrichir : réputation d'une IP, d'un domaine ou d'un hash, informations sur l'utilisateur et la machine, historique de l'alerte, activité avant et après.
- Le périmètre (scoping) : chercher le même indicateur (hash, domaine, IP, compte) sur l'ensemble du parc avant de conclure.
- Tout noter : ce qu'on a vérifié, comment, ce qu'on a trouvé, ce qu'on a décidé. Une alerte close sans justification est inutilisable plus tard.
Idées reçues
Une alerte se déclenche sur un outil d'administration utilisé par l'équipe informatique. Faux positif ?
L'erreur courante. La clôturer immédiatement comme faux positif.
En réalité. D'abord vérifier : qui l'a lancé, depuis quel poste, à quelle heure, sur quelles cibles, et est-ce cohérent avec une intervention prévue ? Les attaquants utilisent justement les outils d'administration légitimes. Si tout est confirmé, c'est un vrai positif bénin ; on peut alors affiner la règle (exclusion précise), sans désactiver toute la détection.
Comment réduire les faux positifs sans augmenter les faux négatifs ?
L'erreur courante. Répondre « en supprimant les règles qui sonnent trop ».
En réalité. En affinant plutôt qu'en supprimant : exclusions précises (un compte, un chemin, un hash, une machine), ajout de contexte (seuils, combinaison de plusieurs signaux), enrichissement automatique pour aider la décision. Et en testant la règle sur des données réelles ou des simulations d'attaque pour vérifier qu'elle détecte toujours ce qu'elle doit détecter.
Un hash de fichier n'est connu d'aucun moteur sur VirusTotal. Le fichier est-il sain ?
L'erreur courante. Répondre oui.
En réalité. Non. Un fichier inconnu peut être un malware récent ou spécifiquement compilé pour la cible. L'absence de détection n'est pas une preuve d'innocuité. On regarde le comportement (exécution, connexions, persistance), la signature numérique, la provenance, et on peut l'analyser dans un bac à sable. Attention aussi : envoyer un fichier interne sur un service public peut divulguer des informations confidentielles.
Tester ses connaissances
Références
- Blue Team Handbook : SOC, SIEM, and Threat HuntingDon Murdoch · Autoédition
- Crafting the InfoSec PlaybookJeff Bollinger, Brandon Enright, Matthew Valites · O'Reilly
- Applied Network Security MonitoringChris Sanders, Jason Smith · Syngress