Alert Triage

general

Définition

L'Alert Triage (tri des alertes) est le processus par lequel les analystes SOC évaluent chaque alerte de sécurité pour déterminer rapidement si elle représente une menace réelle (True Positive), une fausse alarme (False Positive), ou un incident qui mérite une investigation approfondie. C'est la première et la plus critique des étapes dans la chaîne de réponse aux incidents. L'enjeu du triage est fondamental : un SOC enterprise reçoit en moyenne 10 000 à 100 000 alertes par jour selon la taille de l'organisation et la sensibilité des règles. Les équipes ne peuvent physiquement investiguer chaque alerte en profondeur. Le triage permet de prioriser : traiter en priorité les alertes critiques qui représentent des menaces immédiates, et filtrer les faux positifs qui consomment inutilement du temps analyste. Le processus de triage standard comprend plusieurs étapes. L'enrichissement initial : dès qu'une alerte est reçue, enrichir automatiquement (via SOAR) les indicateurs présents — vérifier les IPs sur VirusTotal, AbuseIPDB, et Shodan ; vérifier les hashes sur VirusTotal et MISP ; interroger la TIP pour context CTI ; vérifier si l'asset cible est critique (via le CMDB/ITAM). La classification de sévérité : attribuer une priorité P1/P2/P3/P4 basée sur la criticité de l'asset impacté, la nature de la menace, et le contexte (heure, utilisateur, localisation). La décision : True Positive (escalade Tier 2) / False Positive (clôture documentée avec raison) / Informationnel (logguer sans action immédiate) / En attente de contexte supplémentaire (attendre des événements corrélés). La fatigue d'alerte est le principal ennemi du triage efficace. Quand le taux de faux positifs dépasse 90% (ce qui est courant dans les SIEM mal tunés), les analystes développent des biais de confirmation et commencent à "rubber stamp" les alertes sans investigation réelle — risquant de passer à côté d'un vrai incident critique masqué dans le volume. La réduction du taux de faux positifs via le tuning des règles SIEM et l'implémentation de l'automatisation SOAR est donc aussi critique que la détection elle-même.

SOAR et automatisation du triage

Les plateformes SOAR automatisent le triage de nombreux types d'alertes standardisées, permettant aux analystes de se concentrer sur les cas complexes. Workflow SOAR typique pour une alerte "connexion depuis une IP malveillante" : (1) Enrichissement automatique : vérification VirusTotal, AbuseIPDB, Greynoise — si l'IP est dans les top feeds de menace → escalade prioritaire automatique ; si c'est un scanner de base du Greynoise → clôture automatique comme bruit de fond réseau. (2) Vérification du contexte utilisateur : l'utilisateur est-il en déplacement à l'étranger ? A-t-il eu d'autres alertes récentes ? (3) Vérification de l'asset : est-ce un serveur exposé en DMZ (attendu pour du scan) ou un poste administrateur interne (suspect) ? Ce workflow réduit le temps de triage d'une alerte de 15-30 minutes à quelques secondes pour les cas standards, libérant les analystes pour les investigations profondes.

True Positive vs False Positive — métriques qualité

Les métriques True Positive (TP) et False Positive (FP) mesurent la qualité du système de détection. Taux de vrais positifs (detection rate) = TP / (TP + FN) — quelle proportion des vraies menaces sont détectées ? Taux de faux positifs = FP / (FP + TN) — quelle proportion des alertes déclenchées sont des fausses alarmes ? Précision = TP / (TP + FP) — quelle proportion des alertes déclenchées sont réelles ? Un SIEM bien tuné vise une précision > 30% (moins de 70% de faux positifs) — en dessous, la fatigue d'alerte menace la qualité du monitoring. Les False Negatives (menaces manquées) sont difficiles à mesurer mais essentiels pour évaluer la couverture : le purple team et les red team exercises permettent de mesurer ce taux en testant si les détections fonctionnent contre des TTP réels simulés.

Priorisation contextuelle — asset criticality

La criticité de l'asset impacté est le facteur le plus important dans la priorisation du triage. La même alerte (connexion RDP inhabituelle) aura une priorité différente selon qu'elle concerne un poste administrateur du domaine (P1 critique) ou un poste utilisateur standard (P3 modéré). L'ITAM/CMDB doit fournir au SIEM un "asset criticality score" pour chaque système : les serveurs qui gèrent la paie, les bases de données clients, les contrôleurs de domaine, et les systèmes OT critiques doivent avoir des scores élevés qui augmentent automatiquement la priorité des alertes associées. Microsoft Sentinel, Splunk ES, et IBM QRadar supportent nativement l'enrichissement des alertes avec le score de criticité des assets depuis un fichier de référence ou une API CMDB, permettant une priorisation automatique plus intelligente que les seuils fixes.

Articles liés

Expert en cybersécurité offensive et intelligence artificielle. Pentest, audit et développement IA sur-mesure.

Services

Ressources

Projets & Outils

Contact

Nous contacter

Mentions légales Confidentialité Politique éditoriale Plan du site ⭐ Source préférée

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis