Ingénierie de détection avec Sigma : par où commencer

Un RSSI ou un analyste qui veut structurer une détection maison se heurte presque toujours au même mur : il sait qu'il faut « écrire des règles », mais il ne sait ni par où commencer, ni comment savoir si ce qu'il a écrit couvre quoi que ce soit de réel. Le résultat classique est un dossier de règles éparses, copiées ici et là, jamais testées contre un moteur réel, qui donnent un faux sentiment de couverture. L'ingénierie de détection (detection engineering) est justement la discipline qui comble ce vide : elle traite la détection comme un cycle de vie, pas comme un fichier texte qu'on écrit une fois et qu'on oublie.

Pourquoi Sigma est le format pivot

Avant Sigma, chaque SIEM avait son propre langage de règles : SPL pour Splunk, KQL pour Sentinel ou Elastic, EQL pour Elastic Security. Écrire une détection signifiait l'écrire une fois par plateforme, sans réutilisation possible d'un environnement à l'autre. Sigma a réglé ce problème en devenant un format pivot déclaratif : on décrit une fois la logique de détection (quelle source de logs, quels champs, quelle condition), et un backend se charge de la traduire vers le langage natif du moteur cible.

Ce découplage change la nature du travail. L'analyste raisonne sur l'intention de détection (« un processus enfant suspect d'un lecteur de courrier ») plutôt que sur la syntaxe d'un SIEM particulier. C'est ce qui a fait de Sigma le format de référence pour le partage de règles dans la communauté, au même titre que YARA pour les fichiers ou Suricata pour le réseau.

Anatomie commentée d'une règle Sigma

Une règle Sigma est un fichier YAML structuré en quelques blocs. Voici un exemple annoté, construit sur un cas classique : un processus enfant anormal lancé depuis winword.exe.

title: Suspicious Child Process from Office Application
id: 3d8f2b4a-1e29-4c7a-9a4e-8f6b2c1d0a11
status: test
description: >
  Detects a command interpreter or scripting engine spawned as a
  direct child of a Microsoft Office application, a common pattern
  in macro-based initial access.
references:
  - https://attack.mitre.org/techniques/T1204/002/
author: detection-team
date: 2026-06-10
tags:
  - attack.execution
  - attack.t1204.002
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith:
      - '\winword.exe'
      - '\excel.exe'
      - '\powerpnt.exe'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\wscript.exe'
      - '\mshta.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Legitimate add-ins that shell out for automation (rare)
level: high

Trois blocs portent l'essentiel de la logique. Le logsource indique quelle télémétrie interroger : ici une création de processus Windows, indépendamment du produit qui la collecte (Sysmon, EDR, journal natif). Le bloc detection définit les motifs à rechercher sous forme de sélections nommées, chacune une liste de conditions sur des champs. La condition combine ces sélections avec une logique booléenne, ici un simple and entre un parent Office et un enfant interpréteur.

Le champ tags avec la référence attack.t1204.002 relie la règle à la matrice MITRE ATT&CK. Ce mapping n'est pas cosmétique : il permet de raisonner en couverture (quelles techniques sont détectées, lesquelles ne le sont pas) plutôt qu'en nombre brut de règles, et de prioriser l'écriture en fonction des techniques réellement pertinentes pour la menace visée.

Outillage minimal pour démarrer

Trois briques suffisent pour une pratique sérieuse, toutes open source :

• pySigma : la bibliothèque Python qui interprète le format Sigma et porte les backends de traduction (Splunk, Elastic, Microsoft Sentinel, QRadar, et une dizaine d'autres).
• sigma-cli : l'interface en ligne de commande construite sur pySigma, pour convertir et valider des règles sans écrire de code.
• Un accès au moteur réel visé (une instance Splunk, un cluster Elastic, ou au minimum ses données d'exemple) : sans cela, la conversion reste théorique.

L'usage courant tient en une commande :

pip install sigma-cli
sigma convert -t splunk -p sysmon ma_regle.yml

Le paramètre -t désigne le backend cible, -p un pipeline de traduction qui adapte les noms de champs génériques Sigma (Image, ParentImage) vers les noms réels du produit de collecte choisi (ici Sysmon). C'est ce pipeline qui fait la différence entre une règle qui se convertit proprement et une règle qui produit une requête syntaxiquement valide mais vide de résultats, faute de mapping de champs correct.

La boucle d'ingénierie de détection

Écrire une règle isolée n'est pas de l'ingénierie de détection. La discipline repose sur une boucle répétée :

1. Hypothèse : formuler ce qu'on cherche à détecter, idéalement rattaché à une technique ATT&CK et à une source de log disponible.
2. Règle : écrire la Sigma correspondante, avec un logsource précis et une condition qui reflète l'hypothèse sans la déborder.
3. Test contre Atomic Red Team : rejouer la technique en environnement contrôlé avec un test Atomic Red Team correspondant, et vérifier que la règle convertie se déclenche réellement sur le moteur cible.
4. Mode silencieux (shadow mode) : déployer la règle en simple journalisation, sans alerte active, pendant une période d'observation sur le trafic de production, pour mesurer son taux de déclenchement réel.
5. Promotion : si le volume d'alertes reste gérable et les faux positifs identifiés et filtrés, faire passer la règle en alerte active.

Cette boucle transforme la détection d'un acte d'écriture en un acte de validation. Une règle qui n'a jamais traversé les étapes 3 et 4 n'est qu'une hypothèse non vérifiée, quelle que soit la qualité de sa syntaxe YAML.

Prioriser par la télémétrie disponible, pas par le mode d'attaque

L'erreur de débutant la plus fréquente consiste à partir d'une liste de techniques d'attaque séduisantes et à essayer d'écrire une règle pour chacune, sans vérifier au préalable si la source de log nécessaire existe réellement dans l'environnement. Une règle qui dépend d'un champ Sysmon EventID 1 avec CommandLine enrichi ne sert à rien si seul le journal Windows natif 4688, sans ligne de commande, est collecté.

L'ordre de priorité qui fonctionne en pratique part de l'inventaire réel des sources :

• Sysmon, quand il est déployé, offre la granularité la plus riche (création de processus avec ligne de commande, connexions réseau, accès registre).
• L'EDR en place, quand il expose ses événements bruts au SIEM et non seulement ses propres alertes, couvre souvent un périmètre équivalent ou supérieur à Sysmon.
• Le journal Windows natif (4688, 4624, 4104 pour PowerShell) reste la base minimale, plus pauvre mais universellement présente.
• Le pare-feu et les journaux réseau couvrent un axe complémentaire : trafic sortant, balises, exfiltration.

Écrire d'abord pour la source réellement collectée, quitte à couvrir une technique moins spectaculaire, produit davantage de valeur qu'une règle parfaite sur le papier mais qui ne se déclenchera jamais faute de données.

Les pièges à faux positifs du débutant

Trois erreurs reviennent systématiquement dans les premières règles :

• Le bare-token : rechercher un simple mot-clé (powershell) sans contexte de champ ni de position, ce qui capture toute occurrence de la chaîne, y compris dans des chemins de fichiers ou des arguments légitimes sans rapport.
• Les conditions trop larges : un contains sans ancrage (endswith, startswith) ou une sélection unique sans corrélation avec un second signal, qui transforme une règle en détecteur de bruit.
• L'absence de filtres d'exclusion : ne pas prévoir de bloc de filtrage (filter) pour les cas légitimes connus (outils d'administration, scripts de déploiement internes), ce qui oblige à retraiter la règle après le premier lot d'alertes au lieu de l'anticiper dès l'écriture.

Le mode silencieux de la boucle précédente est justement l'endroit où ces trois pièges se révèlent avant de saturer une file d'alertes réelle.

Pourquoi un pack curé bat un clone GitHub figé

La tentation la plus répandue est de cloner un dépôt communautaire de règles Sigma et de le brancher tel quel sur le SIEM. Le problème n'est pas la qualité initiale de ces règles, souvent correcte, mais leur dérive dans le temps : le dépôt évolue, votre clone non. Les règles cassées par un changement de schéma de log ne sont jamais corrigées côté client. Les nouvelles techniques documentées après le clone ne sont jamais ajoutées. Le résultat est un faux sentiment de couverture : le dossier de règles donne l'impression d'une détection active, alors qu'une partie ne se déclenche plus depuis des mois sans que personne ne le sache.

Un pack curé et testé répond à ce problème par construction : chaque règle a traversé la boucle hypothèse-test-shadow mode-promotion décrite plus haut, sur un moteur réel, avec un suivi de dérive dans le temps plutôt qu'un instantané figé au jour du clone.

Pour démarrer une pratique de détection sans repartir de zéro sur chaque règle, le pack Sigma ThreatClaw fournit cette base déjà validée, priorisée par télémétrie réellement disponible et maintenue dans la durée.