Vvanakor
Retour aux écrits
Detection3 min de lecture

Detection engineering : des règles qu'on déplace, des règles qu'on retire

Detection EngineeringSigmaMITRE ATT&CKThreat Hunting

Deux formats, délibérément

Sigma sert aux détections qui doivent se déplacer. Les langages natifs des plateformes servent aux détections qui doivent s'exécuter vite sur un backend donné. Ces objectifs sont réellement en conflit, et choisir l'un coûte quelque chose.

Je garde les deux. Sigma est la source de vérité et ce qui survit à une migration de plateforme ; la règle native est l'artefact compilé, ajusté là où le volume l'exige. Dans ARGOS, cela prend la forme d'un jeu de règles Sigma allant du Kerberoasting au DCShadow, aux côtés d'une bibliothèque SPL pour la partie Splunk.

L'échec classique consiste à ne garder que la version native. Cela fonctionne très bien jusqu'à une migration, où l'on découvre que la logique de détection n'a jamais été écrite quelque part de lisible.

Les détections sont du code, et personne ne les teste

Une règle qui n'a jamais été déclenchée contre un événement vrai connu est une hypothèse, pas une détection.

Chaque règle a besoin d'un cas de test qui doit la déclencher et d'un cas qui ne doit pas. Exécutez-les en CI. C'est une pratique d'ingénierie banale dont le contenu de détection est systématiquement dispensé, et le résultat est un jeu de règles auquel personne ne fait assez confiance pour l'ajuster.

Le retrait est la moitié négligée

Les détections s'accumulent. Une règle qui n'a pas tiré depuis quatre-vingt-dix jours vous dit quelque chose : soit la menace ne vous concerne plus, soit la règle est cassée et personne ne l'a vu. Les deux appellent une action. Aucune ne l'obtient, parce que supprimer une détection donne l'impression de réduire la couverture.

Ce n'est généralement pas le cas. Une règle incapable de tirer n'a aucune couverture à réduire. Elle a un coût d'entretien, un coût de requête, et une ligne dans un rapport qui vous rassure.

Signalez les silencieuses. Demandez à quelqu'un de justifier qu'on les garde.

Sur les chiffres de couverture

Vous verrez des affirmations sur le pourcentage de techniques ATT&CK détecté par l'organisation moyenne. Maniez-les avec prudence : la couverture dépend des techniques réellement atteignables dans votre parc, et une technique qui ne s'applique pas à vous n'est pas une lacune.

Servez-vous d'ATT&CK comme vocabulaire commun, pour que votre détection, votre renseignement et votre rapport décrivent le même comportement. Servez-vous-en comme tableau de bord et vous finirez par écrire des règles pour faire monter un chiffre.

Là où un modèle aide

Pas à écrire des règles. À expliquer des anomalies.

Une ligne de base comportementale peut vous dire que ce compte de service n'a jamais touché cet hôte. C'est utile et ce n'est pas nouveau. Ce qu'un modèle ajoute, c'est la phrase suivante — que faudrait-il pour que ceci soit bénin — qui est la question qu'un bon analyste pose et qu'un analyste fatigué saute.

C'est une amélioration réelle, et bien moins spectaculaire qu'elle n'en a l'air dans une présentation commerciale.

Retour aux écrits