Cas d'usage de détection et faux positifs
Concevoir des cas d'usage de détection SIEM/EDR robustes et réduire le bruit des faux positifs.
À retenir
- Un cas d'usage de détection combine source de données, logique de corrélation et action de réponse.
- Le contexte métier (horaire, rôle, localisation) réduit les faux positifs plus efficacement que les seuils bruts.
- Un taux élevé de faux positifs provoque une fatigue d'alerte qui peut masquer de vrais incidents.
- Réduire le bruit sans discernement augmente le risque de faux négatifs.
Du journal brut au cas d'usage de détection
Un cas d'usage de détection formalise une hypothèse d'attaque en une règle exploitable : quelle donnée, quel seuil, quel contexte, quelle action déclenchée.
Anatomie d'un cas d'usage
- Objectif : quelle technique d'attaque le cas d'usage vise-t-il à repérer (par exemple, tentative de connexion par force brute) ?
- Sources de données requises : journaux d'authentification, EDR, proxy.
- Logique de détection : seuil, corrélation temporelle, comparaison à une base de référence (baseline).
- Sévérité et action de réponse associée : notification, ticket automatique, endiguement automatisé.
Point clé
un cas d'usage sans logique de contexte (heure habituelle, localisation géographique, rôle du compte) génère mécaniquement beaucoup de faux positifs ; ajouter du contexte métier est souvent plus efficace qu'ajuster uniquement les seuils numériques.
Le problème central : les faux positifs
Un taux élevé de faux positifs entraîne la fatigue d'alerte (alert fatigue) : les analystes finissent par traiter les alertes superficiellement, ou pire, par les ignorer, ce qui peut masquer un vrai incident au milieu du bruit.
| Type de résultat | Définition | Conséquence si mal géré |
|---|---|---|
| Vrai positif | Alerte correcte sur une activité réellement malveillante | Traitement approprié |
| Faux positif | Alerte sur une activité légitime | Fatigue d'alerte, perte de temps |
| Faux négatif | Activité malveillante non détectée | Incident non détecté, impact non maîtrisé |
| Vrai négatif | Absence d'alerte sur une activité légitime | Fonctionnement normal |
Attention
réduire les faux positifs en élevant simplement les seuils de détection augmente presque toujours les faux négatifs ; l'objectif n'est pas de supprimer le bruit à tout prix, mais d'affiner le contexte et d'enrichir les règles (listes blanches justifiées, heuristiques comportementales).
Tuning continu
Le réglage d'un cas d'usage est un processus continu, pas une action ponctuelle : chaque alerte close doit être annotée (vrai positif, faux positif, indéterminé) pour alimenter l'amélioration de la règle. Un cas d'usage jamais révisé après son déploiement dérive presque toujours vers un taux de faux positifs élevé, à mesure que l'environnement change (nouveaux outils métier, nouveaux usages légitimes).
Sur le terrain
dans un data center exploitant des astreintes de nuit, une règle de détection de connexion « hors horaires habituels » génère souvent une avalanche de faux positifs lors des campagnes de maintenance planifiées ; documenter les fenêtres de changement dans le SIEM permet de suspendre temporairement la règle plutôt que de la désactiver définitivement.
Astuce
tenez un registre des cas d'usage avec leur taux de faux positifs mesuré sur trente jours glissants ; tout cas d'usage dépassant un seuil convenu (par exemple 90 % de faux positifs) doit être retravaillé ou temporairement désactivé plutôt que laissé actif sans revue.