Écrire, tester et déployer une règle Sigma, de l'hypothèse à l'alerte

Une alerte utile n’apparaît pas par hasard : elle est le résultat d’une hypothèse, d’une règle écrite avec soin, d’un test et de plusieurs ajustements. Sigma, un format ouvert de règles de détection, permet de décrire cette logique une seule fois et de la convertir pour plusieurs outils (Splunk, Elastic, etc.).

Cet article suit le cycle complet sur un exemple concret : détecter un document Office qui lance PowerShell avec une commande encodée.

Pourquoi Sigma

Chaque SIEM a son langage de requête. Écrire une détection en SPL, puis en KQL, puis en Lucene, c’est la maintenir trois fois. Sigma sépare la logique (ce que l’on cherche) du moteur (comment on le cherche) : on écrit en YAML, et un convertisseur produit la requête pour la cible choisie. C’est aussi un langage commun pour partager des détections avec la communauté.

1. Partir d’une hypothèse ATT&CK

Une bonne règle commence par une question précise. Ici :

Un attaquant qui obtient l’exécution de code via un document piégé lance souvent un interpréteur de commandes depuis l’application Office.

On la rattache à des techniques MITRE ATT&CK : T1204.002 (exécution d’un fichier malveillant par l’utilisateur) et T1059.001 (PowerShell). Cette étape fixe le périmètre : on ne cherche pas « tout PowerShell » (bien trop bruyant), on cherche un enchaînement précis.

2. Vérifier que le journal existe

Une règle ne détecte que ce qui est journalisé. Pour la création de processus, deux sources courantes :

Sysmon, événement 1 (création de processus) ;
Journal Security, événement 4688, à condition d’avoir activé l’audit de la création de processus et l’inclusion de la ligne de commande dans les événements (stratégie de groupe « Inclure la ligne de commande dans les événements de création du processus »).

Sans ligne de commande, impossible de voir -enc. Cette vérification évite de passer des heures sur une règle qui ne pourra jamais se déclencher. Sigma décrit cela dans le bloc logsource, et le convertisseur adapte les noms de champs à la source cible.

3. Écrire la règle

title: Office lance PowerShell avec une commande encodée
id: 8d3b1c8e-7a4f-4c2b-9f0e-3b2a6d5c1e47
status: experimental
description: >
  Détecte Word, Excel ou PowerPoint qui lancent PowerShell avec un paramètre
  de commande encodée, comportement typique d'une macro malveillante.
references:
  - https://attack.mitre.org/techniques/T1059/001/
author: Jeovany NGUEDJIO
date: 2026-10-13
tags:
  - attack.execution
  - attack.t1204.002
  - attack.t1059.001
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith:
      - '\winword.exe'
      - '\excel.exe'
      - '\powerpnt.exe'
  selection_child:
    Image|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
    CommandLine|windash|contains:
      - '-enc'
      - '-encodedcommand'
  condition: selection_parent and selection_child
falsepositives:
  - Macros d'automatisation métier légitimes, rares. À documenter et à exclure par liste blanche.
level: high

Quelques points qui font la différence :

id : un UUID unique (uuidgen), qui identifie la règle même si son titre change.
status : experimental au départ. On ne promeut une règle qu’après test.
Modificateurs : |endswith évite de dépendre du chemin complet. |windash couvre à la fois -enc et /enc, deux écritures acceptées par PowerShell.
condition : combine des blocs nommés. Une règle lisible se lit comme une phrase.
falsepositives : on anticipe les cas légitimes, c’est ce qui permettra de régler la règle plus tard.

Limite à connaître : PowerShell accepte des abréviations du paramètre (-e, -ec, -en…). Une règle trop stricte les manque ; une règle trop large génère du bruit. C’est un équilibre à mesurer, pas à deviner.

4. Valider et convertir

Avec l’outil officiel sigma-cli :

pip install sigma-cli
sigma plugin install splunk
sigma check office_powershell_encoded.yml
sigma convert -t splunk -p splunk_windows office_powershell_encoded.yml

sigma check vérifie la syntaxe et les bonnes pratiques de la règle ;
sigma convert produit la requête pour la cible (-t) avec un pipeline (-p) qui traduit les champs génériques vers ceux du SIEM.

Relisez toujours la requête générée : c’est elle qui tournera en production, et c’est là que l’on repère un champ mal traduit. D’autres cibles existent (par exemple Elasticsearch) via d’autres plugins.

5. Tester avec une vraie attaque simulée

Une règle qui n’a jamais déclenché n’est pas une détection, c’est une hypothèse. On la confronte à un comportement réel, en environnement de test, avec Atomic Red Team :

Invoke-AtomicTest T1059.001 -ShowDetails
Invoke-AtomicTest T1059.001 -TestNumbers <numéro choisi>

On vérifie ensuite trois choses :

L’événement est bien journalisé (Sysmon 1 ou 4688 avec ligne de commande) ;
La requête convertie le trouve dans le SIEM ;
L’alerte contient l’information utile : machine, utilisateur, processus parent, ligne de commande.

Si l’un des trois échoue, la règle est à corriger, même si elle est syntaxiquement correcte.

6. Réduire les faux positifs

Une règle trop bruyante finit ignorée, ce qui est pire qu’une absence de règle. Après le déploiement en mode observation (alerte à faible priorité) pendant une ou deux semaines :

listez les déclenchements et classez-les en vrais et faux positifs ;
pour un faux positif récurrent, ajoutez un bloc filter et modifiez la condition :

  filter_legit:
    ParentImage|endswith: '\excel.exe'
    CommandLine|contains: 'script-compta-approuve'
  condition: selection_parent and selection_child and not filter_legit

documentez chaque exclusion : pourquoi elle existe, qui l’a validée ;
ajustez le niveau (level) selon la confiance obtenue.

Évitez les exclusions trop larges : une liste blanche qui exclut un chemin entier est une porte dérobée pour l’attaquant.

7. Gérer ses règles comme du code

Une règle de détection est du code : elle se versionne, se relit et se teste.

Un dépôt Git avec une règle par fichier, classées par source de journaux ou par tactique ;
Une intégration continue qui lance sigma check à chaque modification et, idéalement, rejoue des événements de test pour vérifier que la règle détecte toujours ce qu’elle doit détecter ;
Un cycle de vie dans le champ status : experimental, puis test, puis stable, et deprecated quand la règle est remplacée ;
Une revue par un pair avant la mise en production.

C’est la démarche dite de Détection-as-Code, que j’ai inscrite dans ma feuille de route de projets.

Erreurs fréquentes

Écrire une règle sans vérifier que le journal est collecté et complet.
Chercher une chaîne trop générique (powershell) au lieu d’un comportement.
Dépendre de la casse, des chemins complets ou d’une écriture unique d’un paramètre.
Déployer sans test ni période d’observation.
Ajouter des exclusions sans les documenter.
Ne jamais relire ni retirer les règles devenues obsolètes.

En résumé

Une bonne détection suit un cycle : hypothèse, journal, règle, test, réglage, suivi. Sigma n’en est que le support : sa valeur vient de la rigueur avec laquelle on l’utilise. Le prochain pas logique est d’automatiser les tests, pour qu’une règle modifiée soit validée avant d’atteindre la production.