Écrire une règle Sigma pour une CVE ou une technique : du comportement à la détection qui ne noie pas le SOC

Un rapport décrit une nouvelle technique : l'exploitation d'une CVE, l'abus d'un binaire système légitime, un comportement post-exploitation. Vous voulez savoir si cela se produit chez vous. Sigma est le format pivot pour ça : un YAML lisible, indépendant du SIEM, que vous écrivez une fois et convertissez vers Splunk, Elastic ou Sentinel. Mais écrire la règle est une chose ; écrire une règle qui se déclenche sur le vrai comportement sans ensevelir le SOC sous les faux positifs en est une autre.

Point important d'emblée : Sigma détecte un comportement dans les logs, pas une vulnérabilité sur le réseau. Pour une CVE, cela veut dire détecter l'exploitation (ce que l'attaque fait sur l'hôte (un processus lancé, une clé de registre modifiée, une commande caractéristique)) pas la faille elle-même. Cet article montre comment passer d'un comportement décrit à une règle qui tient en production, et comment le prouver.

L'anatomie d'une règle Sigma

Une règle Sigma tient en quelques blocs :

title: Exécution suspecte de MSHTA depuis un répertoire temporaire
id: 7c9d2e10-4a3b-4f8e-9c1a-000000000000
status: experimental
description: Détecte mshta.exe lançant un script depuis un chemin temporaire, technique d'exécution observée après exploitation.
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        Image|endswith: '\mshta.exe'
        CommandLine|contains:
            - '\Temp\'
            - '\AppData\Local\Temp\'
    filter_legit:
        ParentImage|endswith: '\msiexec.exe'
    condition: selection and not filter_legit
falsepositives:
    - Déploiements logiciels légitimes via MSI
level: high
tags:
    - attack.execution
    - attack.t1218.005

Le logsource dit où chercher (ici, les événements de création de processus Windows). Le bloc detection combine une selection (les critères qui caractérisent la technique) et, souvent, un filter (ce qu'il faut exclure). La condition assemble le tout. Les champs falsepositives, level et tags ne sont pas décoratifs : ils rendent la règle triable et exploitable par le SOC.

Le logsource, c'est la moitié du travail

Une règle Sigma ne vaut que si la donnée qu'elle interroge existe. Deux pièges avant même d'écrire la detection :

• La bonne catégorie. process_creation, registry_event, network_connection… choisir la mauvaise, c'est écrire une règle qui ne s'appliquera jamais aux bons événements.
• Votre télémétrie réelle. Si votre configuration Sysmon ne journalise pas les lignes de commande, aucune règle basée sur CommandLine ne se déclenchera, aussi juste soit-elle. La détection commence par la collecte : vérifiez que vos logs contiennent le champ dont vous dépendez.

Partir du comportement, pas d'une règle recopiée

Comme pour toute détection, le point de départ est le fait, pas l'expression d'autrui. Un rapport d'analyse décrit l'observable : le processus lancé, le parent, l'argument caractéristique, la clé écrite. Ce fait n'appartient à personne, la règle que vous en tirez est votre œuvre. Recopier une règle publiée sous licence copyleft ou sans licence dans un jeu fermé ou revendu, en revanche, en contaminerait les droits.

Concrètement : lisez le rapport, isolez l'action minimale et fiable qui prouve la technique, et construisez la selection autour d'elle, pas autour de tout ce que l'attaquant a fait, seulement du signe le plus discriminant.

La discipline du faux positif

C'est ici que la plupart des règles échouent en production. Une selection trop large (CommandLine|contains: 'powershell') se déclenche des milliers de fois par jour sur de l'activité légitime. Trois réflexes :

• Resserrez la sélection. Combinez plusieurs champs (Image et CommandLine et ParentImage) plutôt qu'un seul motif vague.
• Filtrez le légitime connu. Le bloc filter retire les usages sains qui matcheraient malgré tout (un outil d'administration, un déploiement MSI). Le champ falsepositives documente ce qui reste.
• Méfiez-vous des jetons courants. Un mot isolé qui apparaît dans des événements d'authentification ou des noms de service banals produit une tempête d'alertes. Préférez toujours une combinaison spécifique à un jeton unique.

Cartographier ATT&CK

Renseignez les tags avec la tactique et la technique MITRE ATT&CK (attack.execution, attack.t1218.005). Ce n'est pas cosmétique : c'est ce qui permet au SOC de trier, de mesurer sa couverture et de corréler la règle avec le reste de sa détection. Une règle sans tag ATT&CK est une règle orpheline.

Valider ne suffit pas : il faut prouver

L'outillage pySigma vérifie la syntaxe et la cohérence :

sigma check regle.yml

Mais « valide » ne veut pas dire « se déclenche au bon moment ». La preuve est empirique, en deux temps :

1. La règle tire-t-elle sur la vraie technique ? Convertissez-la vers votre SIEM (via le backend pySigma), déclenchez la technique dans un environnement de test (un projet comme Atomic Red Team rejoue des centaines de techniques ATT&CK de façon contrôlée) puis vérifiez que l'alerte apparaît. Si rien ne se déclenche, la règle est inutile.
2. Combien de bruit sur du trafic normal ? Passez la règle convertie sur une journée de logs réels et bénins. Le nombre de déclenchements vous dit si elle est déployable ou si elle noiera l'analyste.

Une règle qui tire sur la technique et reste calme sur le quotidien vaut infiniment plus qu'une règle simplement « valide ». C'est la différence entre « ça compile » et « ça détecte, prouvé ».

Les pièges qui coûtent cher

• Le jeton isolé sur événement courant. La première cause de tempêtes de faux positifs. Combinez, ne vous fiez jamais à un mot seul.
• Le mauvais logsource. Une règle rangée dans la mauvaise catégorie ne s'applique à rien, un faux négatif silencieux.
• Les noms de champ. Après conversion, Image devient process.executable en ECS, autre chose ailleurs. Vérifiez que le mapping colle à votre schéma, sinon la requête ne matche rien.
• La sélection trop large. Un seul contains vague déployé en production, et le SOC vous rappelle dans l'heure.

En résumé

Écrire une bonne règle Sigma pour une CVE ou une technique, c'est une méthode : détecter l'exploitation (le comportement dans les logs, pas la faille), partir du fait décrit dans le rapport, resserrer la sélection et filtrer le légitime, cartographier ATT&CK, et prouver empiriquement que la règle tire sur la technique sans noyer le quotidien. Le reste (validation syntaxique, tags, niveau) est de l'hygiène.

C'est exactement la discipline que nous appliquons à l'échelle dans le feed Sigma de ThreatClaw : chaque règle est testée sur son déclenchement réel, cartographiée sur ATT&CK, et livrée prête à convertir vers votre SIEM. Vous récupérez la détection, pas un YAML qu'il faut encore éprouver.