Pourquoi vos alertes ne sont pas des incidents

Un tableau de bord annonce 12 000 alertes ce mois-ci. Il annonce aussi, plus bas, 4 incidents. Entre les deux, il s’est passé quelque chose que peu d’organisations formalisent — et c’est là que se joue l’efficacité réelle du dispositif.

Trois niveaux, trois métiers

L’événement : une observation. Une authentification, une connexion, un fichier créé. Volume massif, valeur unitaire nulle.

L’alerte : un événement, ou une combinaison, qui correspond à un motif jugé suspect. Elle ne dit pas qu’il se passe quelque chose ; elle dit qu’il faut regarder.

L’incident : une alerte qualifiée, dont l’analyse a confirmé un impact réel ou potentiel sur la sécurité. C’est le seul niveau qui déclenche une réponse, et éventuellement une obligation de notification.

Confondre alerte et incident produit deux erreurs symétriques : déclencher une cellule de crise pour un faux positif, ou traiter une compromission réelle comme une ligne parmi douze mille.

Pourquoi le volume d’alertes explose

Les règles s’ajoutent et ne se retirent jamais. Chaque incident produit une nouvelle règle. Personne ne supprime les anciennes, y compris celles qui couvrent des systèmes décommissionnés.

On alerte sur ce qui est facile à détecter plutôt que sur ce qui compte. Une règle sur les échecs d’authentification est simple à écrire et produit un volume énorme pour une valeur faible.

Le contexte manque. Sans savoir qu’une machine est un serveur de recette, toute anomalie s’y produisant paraît grave.

Le paradoxe du taux de base. Quand les événements malveillants sont extrêmement rares rapportés au volume, même un excellent taux d’erreur noie le signal — voir IA et analyse de journaux.

Ce que produit la saturation

Un phénomène bien documenté : au-delà d’un certain volume, les analystes cessent d’examiner sérieusement chaque alerte. Ils traitent en lot, ferment par habitude, et développent une confiance excessive dans le fait que « celles-là sont toujours fausses ».

Le jour où la vraie alerte arrive, elle ressemble aux précédentes. Elle est fermée en trente secondes.

Ce n’est pas un problème de sérieux : c’est une conséquence mécanique du volume. La seule correction est de réduire le volume, pas de demander plus d’attention.

Construire une chaîne de qualification

Étape 1 — Filtrer à la source. Ne pas collecter ce qui ne répond à aucune question d’enquête. Voir ce qu’il faut collecter.

Étape 2 — Enrichir avant d’alerter. Rattacher l’actif, son propriétaire, sa criticité, son exposition. Une alerte sans contexte n’est pas qualifiable.

Étape 3 — Définir des critères de qualification écrits. Qu’est-ce qui fait qu’une alerte devient un incident ? Sans critères, la qualification dépend de l’analyste de garde.

Étape 4 — Mesurer et retirer. Chaque règle doit avoir un taux de vrais positifs suivi. Une règle qui n’a jamais produit un seul incident en six mois doit être retirée ou réécrite, pas conservée « au cas où ».

Les indicateurs qui comptent

Le nombre d’alertes n’est pas un indicateur de performance. Trois mesures ont du sens :

• Le délai de détection — entre l’événement initial et l’alerte.
• Le délai de qualification — entre l’alerte et la décision.
• Le taux de vrais positifs par règle — qui pilote le nettoyage.

Une baisse du nombre d’alertes accompagnée d’une stabilité du nombre d’incidents détectés est un excellent résultat. C’est rarement présenté comme tel.

Ce que la norme attend

ISO/IEC 27002:2022 traite le sujet par les mesures 5.24 à 5.28 : planification et préparation, appréciation et prise de décision, réponse, tirer des enseignements, collecte de preuves.

La mesure 5.25 porte précisément sur l’appréciation des événements et la prise de décision — c’est-à-dire la qualification. Un auditeur demandera vos critères écrits.

Sources

• ISO/IEC 27002:2022, mesures 5.24 à 5.28 et 8.16
• Directive (UE) 2022/2555 (NIS 2), article 23
• MITRE ATT&CK

Aller plus loin

La construction de cette chaîne est au cœur de notre infogérance SOC. Voir aussi ce que la détection ne fera jamais à votre place.