Décrivez-moi le cycle de vie d'une détection, de l'idée à la règle maintenue.
Réponse courte
L'ingénierie de détection traite les détections comme un produit logiciel doté d'un cycle de vie : identifier une menace ou technique à couvrir, étudier la télémétrie et le comportement, développer la règle, la tester face à des données de vrais positifs et bénignes, la déployer (souvent par étapes), la valider par émulation d'adversaire, puis l'ajuster en continu pour les faux positifs et retirer les règles qui ne se justifient plus. Chaque étape est documentée et versionnée, et la couverture est suivie par rapport à un cadre comme ATT&CK.
Une détection n'est pas un livrable unique ; c'est un produit qui doit être construit, validé, exploité et finalement retiré. Le cycle de vie de l'ingénierie de détection emprunte directement à la discipline du génie logiciel.
Les étapes
- Identifier — choisir ce qu'il faut détecter. Pilotez-le par la threat intel, une technique ATT&CK sans couverture, un incident récent ou un constat de chasse. Priorisez selon la pertinence pour votre environnement et votre modèle de menace.
- Étudier — comprendre le comportement et quelle télémétrie le révèle réellement. Une technique invisible dans vos journaux n'est pas encore détectable.
- Développer — écrire la logique (p. ex. une règle Sigma), avec métadonnées, sévérité et étiquettes ATT&CK.
- Tester — l'exécuter face à des données de vrais positifs connues (reproduction en labo ou sortie d'émulation) et à un échantillon de données bénignes proches de la production pour jauger le bruit.
- Déployer — la livrer, idéalement par étapes : surveillance seule d'abord, puis alerte une fois le taux de faux positifs acceptable.
- Valider — confirmer qu'elle se déclenche réellement via l'émulation d'adversaire (Atomic Red Team, exercices purple-team), pas seulement l'espérer.
- Ajuster et maintenir — suivre les faux positifs, affiner, et retirer les règles redondantes, perpétuellement bruyantes, ou couvrant une technique qui ne s'applique plus.
Les détections comme code
Stockez les règles dans un gestionnaire de versions, examinez-les en pull requests, et passez-les dans une CI qui vérifie syntaxe et schéma. La couverture est mappée sur ATT&CK pour que les lacunes et les chevauchements soient visibles.
Pourquoi c'est important
Les recruteurs seniors sondent la pensée orientée cycle de vie et la volonté de retirer et de valider, pas seulement d'écrire. Quiconque déploie une règle et s'en va finira par noyer le SOC sous le bruit et les angles morts.
Questions de suivi probables
- Comment testez-vous une détection avant qu'elle n'atteigne la production ?
- Quand et pourquoi retireriez-vous une détection ?
- Comment l'émulation d'adversaire s'intègre-t-elle à la validation ?