Détection-as-code — Sigma

Page concept

Cette page explique les grands principes de la détection-as-code — de quoi parler avant d’écrire une règle Sigma. La mise en œuvre pas à pas est dans le TP — Détection Sigma → LogQL. Les ressources en fin de page sont votre point de départ pour aller plus loin par vous-même.

Le concept en une phrase

La détection-as-code, c’est écrire ses détections comme du code — des règles Sigma versionnées, testables et portables, compilées vers le langage de requête de son stockage.

Une règle de détection n’est pas une case cochée dans une interface propriétaire : c’est un fichier YAML qu’on relit, qu’on teste, qu’on partage, qu’on fait évoluer en git. Dans TAAF, ce fichier s’écrit une fois en Sigma et se compile en LogQL, le langage de requête de Loki.

---

Les grands principes

1. Pourquoi du code et pas des clics

Une règle cliquée dans une UI propriétaire vit dans cette UI : personne d’autre ne peut la relire facilement, l’historique de ses modifications se perd, et elle ne survit pas à un changement d’outil. Une règle écrite est un fichier : elle se versionne (git log montre qui a changé quoi et pourquoi), se relit en revue de code, se partage entre équipes ou entre bases. C’est la même logique que l’infrastructure-as-code appliquée à la détection.

2. Anatomie d’une règle Sigma

Une règle Sigma a une structure fixe, indépendante du moteur qui l’exécutera :

title: Auth VPN hors plage horaire connue
logsource:
  category: authentication
  product: vpn
detection:
  selection:
    event_status: success
    src_ip|not_in_cidr: '10.60.0.0/16'
  condition: selection
tags:
  - attack.initial_access
  - attack.t1078

• logsource — où chercher : quelle catégorie de log, quel produit.
• detection — quoi chercher : un ou plusieurs blocs de sélection (champs et valeurs), combinés par une condition (selection, selection1 and not selection2, etc.).
• tags ATT&CK — la technique décrite par la règle (attack.t1078 = Valid Accounts). C’est ce tag qui alimente la couverture — voir MITRE ATT&CK & la kill chain.

3. La compilation Sigma → LogQL — une règle, N backends

Sigma est un format pivot : on écrit la règle une seule fois, et un compilateur (pySigma, backend Loki) la traduit vers le langage de requête réellement exécuté. Dans TAAF, cette traduction produit du LogQL :

flowchart LR
    S[Règle Sigma\nYAML, portable] -->|pySigma backend Loki| Q["LogQL\n{job=\"auth\"} |= ..."]
    Q --> G[Grafana Alerting]

L’intérêt : la même règle Sigma pourrait, sur un autre projet, se compiler vers Splunk ou Elastic sans être réécrite. On investit dans la logique de détection, pas dans la syntaxe d’un moteur en particulier.

4. Le cycle de vie d’une règle — hypothèse, test, tuning

Une règle ne naît jamais parfaite :

1. Hypothèse — « un compte de service qui exécute pg_dump sur une table classifiée hors procédure, c’est suspect ».
2. Test — on la fait tourner sur des logs connus (le jeu de données du fil rouge, par exemple) : détecte-t-elle l’événement attendu ?
3. Faux positifs — la règle matche-t-elle aussi des sauvegardes légitimes ? Il faut resserrer la condition (ex. exclure les fenêtres de sauvegarde planifiée).
4. Tuning — on ajuste, on retest, jusqu’à un point d’équilibre acceptable entre bruit et silence — voir le principe 5 de C’est quoi un SIEM.

5. Ce qu’une règle ne voit pas — l’angle mort

Une règle Sigma détecte ce qu’on a pensé à écrire. Un attaquant qui varie sa technique, passe par un chemin non instrumenté, ou reste sous le seuil d’une condition trop précise, ne déclenche rien — la couverture ATT&CK peut afficher une case verte sans qu’aucune vraie attaque n’ait jamais été testée contre elle. C’est l’angle mort structurel de toute détection basée sur des règles écrites à l’avance : elle suppose qu’on connaît déjà la forme de l’attaque. Vérifier qu’une règle marche vraiment — et pas seulement qu’elle existe — est le rôle du purple team.

---

Où ça sert dans TAAF

• TP — Détection Sigma → LogQL — écrire les règles du fil rouge (phishing, auth VPN hors plage, exfiltration genetic_samples) et les compiler.
• TP — Couverture & Corrélation — tagger les règles ATT&CK, générer un layer Navigator, et écrire une règle de corrélation qui relie plusieurs événements isolés en une chaîne.

---

Ressources associées

Ces liens sont des points de départ pour vos propres recherches — voir la bibliothèque complète sur la page Ressources, section Détection & SIEM.

À chercher par vous-même : « Sigma rule specification », « pySigma backend loki », « detection as code », « detection engineering false positive tuning ».