Detection-as-Code : Pipeline CI/CD pour Règles SIEM et Détection Automatisée

1. Introduction : pourquoi la détection doit devenir du code

Dans la majorité des SOC (Security Operations Centers), les règles de détection sont encore gérées de manière artisanale : un analyste crée une alerte directement dans l'interface du SIEM, un autre la modifie sans documenter le changement, une troisième version existe sur un wiki obsolète. Cette approche ad hoc est incompatible avec les exigences de fiabilité, de traçabilité et de scalabilité d'un programme de détection mature. Le Detection-as-Code (DaC) propose une réponse structurelle à ce problème en appliquant les principes du génie logiciel -- versioning, testing, CI/CD, revue par les pairs -- au développement des règles de détection.

Le constat est alarmant : selon le rapport MITRE ATT&CK Evaluations 2025, moins de 40 % des techniques d'attaque documentées sont couvertes par des règles de détection dans le SOC moyen. Pire, parmi les règles existantes, une proportion significative génère des faux positifs non traités ou ne fonctionne tout simplement plus en raison de changements dans les sources de logs. Le DaC ne résout pas magiquement ces problèmes de couverture, mais il fournit le cadre méthodologique pour les identifier, les mesurer et les corriger de manière systématique.

Cet article propose un guide complet pour implémenter une approche Detection-as-Code, depuis les fondements conceptuels jusqu'au pipeline CI/CD opérationnel, en passant par les frameworks de test et les métriques de qualité. Que vous opériez avec Splunk, Elastic Security, Microsoft Sentinel ou un autre SIEM, les principes présentés sont universels et adaptables à votre environnement. Pour compléter cette lecture, notre guide complet sur les Sigma Rules détaille la syntaxe et les techniques d'écriture de règles portables.

2. Les fondements du Detection-as-Code

2.1 De l'Infrastructure-as-Code au Detection-as-Code

Le Detection-as-Code s'inscrit dans la lignée de l'Infrastructure-as-Code (IaC) et du Policy-as-Code. L'idée fondamentale est identique : tout artefact opérationnel critique doit être versionné, testé et déployé de manière automatisée. Là où Terraform gère l'infrastructure cloud et Open Policy Agent gère les politiques de sécurité, le DaC gère les règles de détection du SIEM.

Les principes directeurs du DaC sont les suivants :

• Single Source of Truth (SSoT) : le dépôt Git est la source de vérité unique pour toutes les règles de détection. Toute modification passe par un commit, toute règle active en production existe dans le dépôt.
• Revue par les pairs : chaque nouvelle règle ou modification fait l'objet d'une Pull Request (PR) revue par au moins un autre detection engineer. La PR documente le contexte, la logique de détection, les tests effectués et les risques de faux positifs.
• Tests automatisés : avant le déploiement, chaque règle est validée syntaxiquement, testée contre des données de référence (true positives et true negatives), et vérifiée pour les régressions.
• Déploiement automatisé : le merge d'une PR dans la branche principale déclenche automatiquement le déploiement de la règle vers le SIEM de production, éliminant les erreurs manuelles et les dérives de configuration.
• Traçabilité complète : l'historique Git offre un audit trail complet de qui a modifié quelle règle, quand et pourquoi. C'est un atout considérable pour la conformité ISO 27001 et les audits réglementaires.

2.2 Anatomie d'une règle Detection-as-Code

Dans une approche DaC, chaque règle de détection est un fichier structuré (YAML, TOML ou JSON) qui contient non seulement la logique de détection, mais aussi l'ensemble des métadonnées nécessaires à son cycle de vie. Voici la structure type d'une règle DaC :

# detection-rules/credential-access/mimikatz-lsass-access.yml
rule:
  id: "CR-2026-0142"
  name: "Mimikatz LSASS Memory Access Detection"
  description: |
    Détecte l'accès au processus LSASS par des outils de type Mimikatz
    via les event IDs Sysmon 10 (ProcessAccess) avec des droits
    PROCESS_VM_READ sur lsass.exe.
  
  # Métadonnées de gouvernance
  author: "a.nedjimi@ayinedjimi-consultants.fr"
  created: "2026-02-15"
  modified: "2026-02-28"
  version: "1.2.0"
  status: "production"          # draft | testing | production | deprecated
  severity: "high"
  confidence: "high"
  
  # Mapping MITRE ATT&CK
  mitre:
    tactic: "Credential Access"
    technique: "T1003.001"      # OS Credential Dumping: LSASS Memory
    subtechnique: "LSASS Memory"
  
  # Logique de détection (format Sigma)
  sigma:
    logsource:
      category: process_access
      product: windows
    detection:
      selection:
        TargetImage|endswith: '\lsass.exe'
        GrantedAccess|contains:
          - '0x1010'
          - '0x1410'
          - '0x1438'
          - '0x143a'
      filter_legitimate:
        SourceImage|endswith:
          - '\wmiprvse.exe'
          - '\taskmgr.exe'
          - '\MsMpEng.exe'
      condition: selection and not filter_legitimate
  
  # Métadonnées opérationnelles
  operations:
    sla_response: "15min"
    runbook: "runbooks/credential-access/lsass-dump.md"
    escalation: "tier2-incident-response"
    false_positive_rate: "low"
    known_fps:
      - "Antivirus legitimate scanning LSASS"
      - "Windows Defender periodic checks"
  
  # Tests associés
  tests:
    atomic_red_team: "T1003.001"
    unit_tests:
      - "tests/credential-access/test_mimikatz_lsass.yml"
  
  # Cibles de déploiement
  targets:
    - siem: "splunk"
      index: "windows_sysmon"
      sourcetype: "XmlWinEventLog:Microsoft-Windows-Sysmon/Operational"
    - siem: "elastic"
      index: "winlogbeat-*"
    - siem: "sentinel"
      table: "SecurityEvent"

Cette structure offre plusieurs avantages décisifs. D'abord, la portabilité : la logique Sigma est indépendante du SIEM cible et peut être compilée automatiquement pour chaque plateforme. Ensuite, la gouvernance : les métadonnées de version, d'auteur et de statut permettent un suivi rigoureux du cycle de vie. Enfin, la testabilité : les références aux tests Atomic Red Team et aux tests unitaires permettent une validation automatisée dans le pipeline CI/CD.

2.3 Organisation du dépôt Git

L'organisation du dépôt de détection doit refléter la taxonomie MITRE ATT&CK pour faciliter l'analyse de couverture. Voici la structure recommandée :

detection-repository/
├── .github/
│   └── workflows/
│       ├── ci-lint-test.yml          # Pipeline CI (PR)
│       ├── cd-deploy-production.yml  # Pipeline CD (merge main)
│       └── coverage-report.yml       # Rapport couverture hebdo
├── rules/
│   ├── initial-access/
│   │   ├── phishing-attachment.yml
│   │   └── drive-by-compromise.yml
│   ├── execution/
│   │   ├── powershell-encoded-command.yml
│   │   └── mshta-execution.yml
│   ├── persistence/
│   │   ├── registry-run-keys.yml
│   │   └── scheduled-task-creation.yml
│   ├── privilege-escalation/
│   ├── defense-evasion/
│   ├── credential-access/
│   │   ├── mimikatz-lsass-access.yml
│   │   └── dcsync-detection.yml
│   ├── discovery/
│   ├── lateral-movement/
│   │   ├── psexec-execution.yml
│   │   └── wmi-lateral-movement.yml
│   ├── collection/
│   ├── exfiltration/
│   └── command-and-control/
│       ├── dns-tunneling.yml
│       └── cobalt-strike-beacon.yml
├── tests/
│   ├── unit/                         # Tests unitaires par règle
│   ├── integration/                  # Tests d'intégration SIEM
│   └── fixtures/                     # Données de test (logs)
│       ├── true-positives/
│       └── true-negatives/
├── backends/
│   ├── splunk/                       # Config spécifique Splunk
│   ├── elastic/                      # Config spécifique Elastic
│   └── sentinel/                     # Config spécifique Sentinel
├── runbooks/                         # Procédures de réponse
├── scripts/
│   ├── sigma-compile.py              # Compilation Sigma multi-SIEM
│   ├── deploy-splunk.py              # Déploiement Splunk API
│   ├── deploy-elastic.py             # Déploiement Elastic API
│   ├── coverage-matrix.py            # Génération matrice couverture
│   └── validate-rule.py              # Validation schéma YAML
├── sigma-config/                     # Configs pySigma (mappings)
├── docs/
│   ├── CONTRIBUTING.md               # Guide contribution
│   ├── STYLE_GUIDE.md                # Convention nommage
│   └── REVIEW_CHECKLIST.md           # Checklist revue PR
├── coverage/
│   └── mitre-coverage.json           # Matrice de couverture ATT&CK
└── README.md

3. Le pipeline CI/CD de détection

3.1 Architecture du pipeline

Le pipeline CI/CD de détection se décompose en deux phases distinctes : la Continuous Integration (CI) déclenchée à chaque Pull Request, et la Continuous Deployment (CD) déclenchée au merge dans la branche principale. Chaque phase comprend plusieurs étapes de validation qui garantissent la qualité et la fiabilité des règles déployées.

3.2 Phase CI : validation automatisée

La phase CI se déclenche automatiquement à chaque Pull Request et comprend quatre étapes de validation :

Étape 1 : Lint et validation de schéma

La première étape vérifie la syntaxe YAML et la conformité au schéma JSON de la règle. Un fichier de règle mal formé ne doit jamais atteindre la revue humaine -- c'est un gaspillage du temps de l'analyste. Le pipeline utilise yamllint pour la syntaxe et jsonschema pour valider que tous les champs obligatoires sont présents et correctement typés :

# .github/workflows/ci-lint-test.yml
name: Detection Rules CI
on:
  pull_request:
    paths:
      - 'rules/**/*.yml'

jobs:
  lint-and-validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: YAML Lint
        run: |
          pip install yamllint
          yamllint -c .yamllint.yml rules/
      
      - name: Schema Validation
        run: |
          pip install jsonschema pyyaml
          python scripts/validate-rule.py \
            --schema schemas/detection-rule.json \
            --rules rules/
      
      - name: Check Rule IDs Uniqueness
        run: python scripts/check-unique-ids.py rules/
      
      - name: Verify MITRE ATT&CK References
        run: python scripts/check-mitre-refs.py rules/

Étape 2 : Compilation Sigma multi-SIEM

Chaque règle contenant une section Sigma est compilée vers tous les backends configurés (Splunk SPL, Elastic ES|QL/KQL, Microsoft Sentinel KQL). Cette étape vérifie que la compilation réussit sans erreurs et que la syntaxe générée est valide pour chaque plateforme. L'utilisation de pySigma et ses backends permet une compilation déterministe et reproductible :

# scripts/sigma-compile.py (extrait)
from sigma.collection import SigmaCollection
from sigma.backends.splunk import SplunkBackend
from sigma.backends.elasticsearch import LuceneBackend
from sigma.backends.microsoft365defender import Microsoft365DefenderBackend
from sigma.pipelines.splunk import splunk_windows_pipeline
from sigma.pipelines.elasticsearch import ecs_windows_pipeline

def compile_rule(rule_path, backends_config):
    """Compile une règle Sigma vers tous les backends configurés."""
    collection = SigmaCollection.from_yaml(open(rule_path))
    results = {}
    
    for backend_name, config in backends_config.items():
        backend = config['backend_class']()
        pipeline = config['pipeline']()
        backend.set_pipeline(pipeline)
        
        try:
            output = backend.convert(collection)
            results[backend_name] = {
                'status': 'success',
                'query': output
            }
        except Exception as e:
            results[backend_name] = {
                'status': 'error',
                'message': str(e)
            }
    
    return results

Étape 3 : Tests unitaires

Les tests unitaires vérifient que la règle détecte correctement les comportements malveillants (true positives) tout en ne générant pas d'alertes sur des activités légitimes (true negatives). Chaque règle doit être accompagnée d'au moins un fichier de test contenant des échantillons de logs :

# tests/unit/credential-access/test_mimikatz_lsass.yml
test:
  rule: "rules/credential-access/mimikatz-lsass-access.yml"
  
  true_positives:
    - name: "Mimikatz sekurlsa::logonpasswords"
      log:
        EventID: 10
        SourceImage: 'C:\Users\attacker\mimikatz.exe'
        TargetImage: 'C:\Windows\System32\lsass.exe'
        GrantedAccess: '0x1010'
      expected: match
    
    - name: "procdump LSASS dump"
      log:
        EventID: 10
        SourceImage: 'C:\Tools\procdump64.exe'
        TargetImage: 'C:\Windows\System32\lsass.exe'
        GrantedAccess: '0x1438'
      expected: match
  
  true_negatives:
    - name: "Windows Defender scanning LSASS"
      log:
        EventID: 10
        SourceImage: 'C:\ProgramData\Microsoft\Windows Defender\Platform\MsMpEng.exe'
        TargetImage: 'C:\Windows\System32\lsass.exe'
        GrantedAccess: '0x1010'
      expected: no_match
    
    - name: "Task Manager viewing processes"
      log:
        EventID: 10
        SourceImage: 'C:\Windows\System32\taskmgr.exe'
        TargetImage: 'C:\Windows\System32\lsass.exe'
        GrantedAccess: '0x1410'
      expected: no_match

Étape 4 : Analyse de couverture et détection de doublons

La dernière étape CI met à jour la matrice de couverture MITRE ATT&CK et vérifie l'absence de règles dupliquées. Le script coverage-matrix.py génère un fichier JSON qui alimente un dashboard de couverture, permettant aux detection engineers de visualiser les tactiques et techniques couvertes et celles qui restent à traiter. Ce mapping est essentiel pour structurer un programme de détection aligné sur MITRE ATT&CK.

3.3 Phase CD : déploiement automatisé

Une fois la PR approuvée et mergée dans main, la phase CD prend le relais avec quatre étapes :

Compilation finale : les règles modifiées sont recompilées pour chaque backend cible. Le pipeline détecte automatiquement quelles règles ont changé (via git diff) et ne recompile que les fichiers modifiés pour optimiser le temps de build.

Déploiement via API : les requêtes compilées sont déployées vers chaque SIEM via leurs APIs respectives. Pour Splunk, le script utilise l'API REST pour créer ou mettre à jour les saved searches. Pour Elastic Security, l'API Detection Engine permet de pousser les règles au format TOML/JSON. Pour Microsoft Sentinel, les Analytics Rules sont déployées via l'API ARM ou l'Azure CLI.

# scripts/deploy-splunk.py (extrait)
import requests
import json

def deploy_to_splunk(rule_name, spl_query, config):
    """Déploie une saved search dans Splunk via REST API."""
    url = f"{config['base_url']}/servicesNS/{config['owner']}/{config['app']}/saved/searches"
    
    payload = {
        'name': rule_name,
        'search': spl_query,
        'is_scheduled': '1',
        'cron_schedule': '*/5 * * * *',
        'dispatch.earliest_time': '-5m@m',
        'dispatch.latest_time': 'now',
        'alert_type': 'number of events',
        'alert_comparator': 'greater than',
        'alert_threshold': '0',
        'actions': 'notable',
        'action.notable.param.severity': 'high',
        'action.notable.param.rule_title': rule_name,
    }
    
    # Vérifier si la règle existe déjà
    check = requests.get(
        f"{url}/{rule_name}",
        auth=(config['user'], config['password']),
        verify=config['verify_ssl']
    )
    
    if check.status_code == 200:
        # Update
        response = requests.post(
            f"{url}/{rule_name}",
            data=payload,
            auth=(config['user'], config['password']),
            verify=config['verify_ssl']
        )
    else:
        # Create
        response = requests.post(
            url,
            data=payload,
            auth=(config['user'], config['password']),
            verify=config['verify_ssl']
        )
    
    return response.status_code in [200, 201]

Smoke tests : après le déploiement, le pipeline exécute des smoke tests pour vérifier que les règles sont effectivement actives et fonctionnelles dans chaque SIEM. Un smoke test typique interroge l'API du SIEM pour confirmer que la saved search existe, est activée, et que sa requête compile sans erreur.

Notification et métriques : en cas de succès, un message est envoyé sur le canal Slack/Teams du SOC avec le résumé des modifications. En cas d'échec, le pipeline déclenche un rollback automatique (revert du commit + redéploiement de la version précédente) et une alerte de priorité haute.

4. Testing framework : valider la détection

4.1 Atomic Red Team : les tests unitaires de la détection

Atomic Red Team est un framework open-source maintenu par Red Canary qui fournit des tests atomiques -- des procédures de simulation d'attaque minimales et ciblées -- pour chaque technique MITRE ATT&CK. Chaque test atomique reproduit un comportement d'attaque spécifique dans un environnement contrôlé, permettant de valider que la règle de détection correspondante se déclenche correctement.

L'intégration d'Atomic Red Team dans le pipeline DaC se fait à deux niveaux. Au niveau développement, le detection engineer exécute manuellement les tests atomiques correspondants à sa règle pour valider la détection avant de soumettre la PR. Au niveau CI/CD, les tests sont exécutés automatiquement dans un environnement de lab (VM Windows instrumentée avec Sysmon, WEF et l'agent SIEM) à chaque merge dans la branche staging.

# Exécution d'un test Atomic Red Team pour T1003.001
# (OS Credential Dumping: LSASS Memory)
Invoke-AtomicTest T1003.001 -TestNumbers 1,2,3

# Test 1: Dump LSASS via mimikatz
# Test 2: Dump LSASS via procdump
# Test 3: Dump LSASS via comsvcs.dll MiniDump

# Vérification post-test : la règle a-t-elle généré une alerte ?
$alerts = Search-SplunkAlerts -Query "mimikatz_lsass_access" -TimeRange "-5m"
if ($alerts.Count -eq 0) {
    Write-Error "FAIL: Rule did not trigger on Atomic Test T1003.001"
    exit 1
}

# Nettoyage post-test
Invoke-AtomicTest T1003.001 -Cleanup

4.2 Tests de régression et tests de performance

Au-delà des tests fonctionnels, deux catégories de tests sont essentielles pour un pipeline DaC mature :

Tests de régression : chaque modification d'une règle existante doit être accompagnée de la ré-exécution de tous les tests associés. Le risque principal est qu'une modification destinée à réduire les faux positifs (ajout d'un filtre) supprime également la détection d'un vrai positif. Le pipeline doit maintenir un corpus de true positives historiques et les rejouer systématiquement. C'est l'équivalent des tests de régression en développement logiciel, appliqué aux patterns d'attaque connus.

Tests de performance : une règle de détection qui fonctionne parfaitement en lab peut devenir problématique en production si elle génère des requêtes trop coûteuses. Le pipeline doit mesurer le temps d'exécution des requêtes compilées et alerter si une règle dépasse un seuil configurable. Pour Splunk, cela signifie estimer le scan count et le temps de recherche via l'API Jobs. Pour Elastic, il s'agit de monitorer le temps de requête et la consommation mémoire des rules.

Type de test	Objectif	Fréquence	Automatisable
Lint / Schema	Syntaxe YAML et conformité schéma	Chaque PR	Oui (100%)
Compilation Sigma	Compilation multi-backend sans erreur	Chaque PR	Oui (100%)
Tests unitaires	True positive / True negative	Chaque PR	Oui (100%)
Tests Atomic RT	Validation en environnement réel	Merge staging	Oui (lab requis)
Tests régression	Non-régression des true positives	Chaque modification	Oui (100%)
Tests performance	Temps exécution requête	Déploiement prod	Oui (API SIEM)
Smoke tests	Règle active et fonctionnelle	Post-déploiement	Oui (100%)

4.3 Environnement de test : le lab SOC

Un pipeline DaC efficace nécessite un environnement de lab dédié qui reproduit la stack de production. Ce lab comprend au minimum : une VM Windows Server 2022 avec Active Directory, une VM Windows 11 workstation, Sysmon configuré avec une config modulaire (type SwiftOnSecurity ou Olaf Hartong), le forwarding d'événements vers une instance SIEM de staging, et les outils d'émulation d'attaque (Atomic Red Team, Caldera, MITRE ATT&CK Navigator).

L'infrastructure de lab peut être provisionnée via IaC (Terraform + Ansible) pour garantir la reproductibilité et permettre la reconstruction rapide après des tests destructifs. Certaines organisations utilisent des conteneurs Docker pour les composants SIEM (Elastic Stack en particulier) afin de réduire les coûts et accélérer le provisioning, une approche similaire aux environnements Kubernetes éphémères.

5. Compilation Sigma et intégration multi-SIEM

5.1 Le pipeline de compilation Sigma

Le format Sigma est la pierre angulaire de la portabilité des règles dans une approche DaC. Sigma agit comme un langage intermédiaire -- un "YAML de détection" -- qui est ensuite compilé vers la syntaxe native de chaque SIEM. Cette compilation est assurée par pySigma, le successeur de sigmac, qui offre une architecture modulaire basée sur des backends et des pipelines de processing.

5.2 Configuration des processing pipelines

Le point le plus critique de la compilation Sigma est la configuration des processing pipelines. Chaque SIEM utilise des noms de champs différents pour les mêmes données. Par exemple, le chemin de l'exécutable source est SourceImage dans Sysmon, process.executable dans ECS (Elastic Common Schema), et InitiatingProcessFileName dans Microsoft Defender. Le processing pipeline assure cette traduction.

# sigma-config/custom-pipeline.yml
# Pipeline de processing personnalisé pour notre environnement
name: "Custom SOC Pipeline"
priority: 20

transformations:
  # Ajout d'un index pattern Splunk personnalisé
  - id: splunk_index
    type: add_condition
    conditions:
      - type: logsource
        category: process_creation
        product: windows
    detection_items:
      - field: index
        value: "idx_windows_sysmon"
  
  # Mapping de champs spécifiques à notre environnement
  - id: custom_field_mapping
    type: field_name_mapping
    mapping:
      SourceImage: "process.executable"
      TargetImage: "target.process.executable"
      CommandLine: "process.command_line"
      ParentCommandLine: "process.parent.command_line"
      User: "user.name"
      LogonId: "winlog.logon.id"

La gestion des pipelines personnalisés est souvent le point de friction principal lors de l'adoption du DaC. Chaque organisation a ses propres conventions de nommage, ses propres index patterns, et ses propres enrichissements. Le conseil : commencez par les pipelines officiels pySigma (qui couvrent les cas standards) et ajoutez des surcouches de personnalisation de manière incrémentale, en documentant chaque mapping dans un fichier dédié.

5.3 Spécificités par plateforme SIEM

Chaque SIEM a ses particularités qui impactent le déploiement :

Splunk : le déploiement se fait via les saved searches (alertes) ou les correlation searches (Enterprise Security). L'API REST est mature et bien documentée. Le point d'attention principal est la gestion des macros et des lookups qui peuvent être référencés dans les requêtes. Le pipeline DaC doit les déployer en amont des règles qui les utilisent.

Elastic Security : les règles sont déployées via l'API Detection Engine au format JSON. Elastic offre un avantage natif pour le DaC avec son dossier detection-rules dans le dépôt GitHub d'Elastic, qui sert de référence d'implémentation. Le support d'ES|QL (le nouveau langage de requête) offre des capacités de corrélation temporelle particulièrement intéressantes pour les règles avancées.

Microsoft Sentinel : les Analytics Rules peuvent être déployées via les templates ARM, l'Azure CLI, ou l'API REST. Sentinel offre une intégration native avec les logs Entra ID et Defender for Endpoint, simplifiant le mapping des sources de logs pour les règles axées identité et endpoint. Le format KQL est puissant mais certaines fonctionnalités Sigma avancées (near correlation) nécessitent des adaptations manuelles.

6. Git workflows et gouvernance des règles

6.1 Le workflow Git pour la détection

Le workflow Git pour un dépôt de détection doit équilibrer rigueur et agilité. En situation d'incident, un detection engineer doit pouvoir créer et déployer une nouvelle règle en quelques minutes -- sans pour autant court-circuiter les contrôles qualité essentiels. Voici le workflow recommandé :

Workflow standard (nouvelles règles et modifications) : le detection engineer crée une branche feature/RULE-XXX-description, développe la règle avec ses tests, soumet une PR avec le template dédié (contexte de la menace, logique de détection, tests effectués, risques de faux positifs), et attend la revue d'au moins un pair. Le pipeline CI valide automatiquement la PR. Après approbation, le merge dans main déclenche le déploiement.

Workflow d'urgence (incident en cours) : pour les situations où une nouvelle règle doit être déployée immédiatement (exploit zero-day, TTP observé en cours d'incident), un workflow fast-track permet le merge direct dans main par un Detection Lead, avec un tag [HOTFIX]. La revue se fait a posteriori dans les 24h. Ce workflow doit rester exceptionnel et chaque utilisation doit être documentée dans le post-mortem de l'incident.

# Template de Pull Request pour nouvelle règle
## Contexte
- **Menace ciblée** : [Description de la menace/TTP]
- **Technique MITRE** : [TXXXx.xxx - Nom]
- **Source** : [Rapport threat intel, incident, SigmaHQ, etc.]

## Logique de détection
- **Source de logs** : [Sysmon, Windows Security, etc.]
- **Événements clés** : [Event IDs, champs, valeurs]
- **Filtres appliqués** : [Exclusions pour faux positifs connus]

## Tests effectués
- [ ] Tests unitaires (true positives + true negatives)
- [ ] Atomic Red Team test exécuté (si applicable)
- [ ] Compilation Sigma réussie (Splunk + Elastic + Sentinel)
- [ ] Pas de régression sur les règles existantes

## Estimation des faux positifs
- **Niveau estimé** : [Bas / Moyen / Haut]
- **FP connus** : [Liste des cas légitimes pouvant déclencher l'alerte]
- **Période de tuning recommandée** : [7/14/30 jours]

## Checklist revue
- [ ] ID unique et conforme à la convention
- [ ] Description claire et actionnable
- [ ] Mapping MITRE ATT&CK correct
- [ ] Runbook de réponse associé
- [ ] Severity et confidence cohérents

6.2 Versioning sémantique des règles

L'application du versioning sémantique (SemVer) aux règles de détection offre une traçabilité précieuse. Le principe : MAJOR.MINOR.PATCH où :

• MAJOR : changement fondamental de la logique de détection (nouvelle approche, refonte complète). Exemple : passage d'une détection par nom de processus à une détection par comportement.
• MINOR : ajout ou modification de fonctionnalité. Exemple : ajout d'un nouveau pattern de détection, extension des sources de logs couvertes.
• PATCH : correction ou tuning. Exemple : ajout d'un filtre pour un faux positif identifié, correction d'une typo dans un champ.

Le versioning permet de générer automatiquement un changelog des modifications de détection, un atout précieux pour les rapports de conformité et les revues trimestrielles du programme de détection. Il permet aussi de corréler l'évolution des métriques de qualité (taux de faux positifs, couverture) avec les changements spécifiques apportés aux règles.

6.3 Gestion du cycle de vie des règles

Chaque règle de détection traverse un cycle de vie en quatre étapes, matérialisé par le champ status dans le fichier YAML :

• draft : la règle est en cours de développement. Elle n'est pas déployée et ne génère aucune alerte.
• testing : la règle est déployée en mode silencieux (alerte loguée mais non notifiée). Le detection engineer surveille les résultats pendant 7 à 14 jours pour calibrer les filtres.
• production : la règle est active et génère des alertes traitées par les analystes SOC. Elle fait l'objet d'un monitoring continu des métriques.
• deprecated : la règle est désactivée, soit parce que la menace n'est plus pertinente, soit parce qu'une règle plus efficace la remplace. Le fichier reste dans le dépôt pour l'historique.

Un processus de revue trimestrielle doit évaluer chaque règle en production : taux de faux positifs, nombre de vrais positifs détectés, pertinence de la menace ciblée, et performance de la requête. Les règles à haut taux de faux positifs sans vrais positifs confirmés depuis plus de 6 mois sont candidates au statut deprecated. Cette hygiène est comparable à la revue régulière des GPO Active Directory : une règle non maintenue est une dette technique qui dégrade l'efficacité globale du SOC.

7. Métriques de qualité et tableaux de bord

7.1 Les métriques essentielles du programme de détection

Un programme Detection-as-Code sans métriques est un programme qui vole à l'aveugle. Les métriques permettent de répondre aux questions fondamentales : notre détection s'améliore-t-elle ? Nos investissements en detection engineering produisent-ils des résultats mesurables ? Voici les métriques clés à suivre :

Métrique	Description	Cible	Fréquence
Couverture MITRE ATT&CK	% de techniques avec au moins une règle active	> 60%	Hebdomadaire
Taux de faux positifs	% d'alertes clôturées comme FP	< 20%	Quotidien
Mean Time to Detect (MTTD)	Temps entre l'activité et l'alerte	< 5 min	Par alerte
Règles en production	Nombre total de règles actives	Croissance	Mensuel
Règles testées	% de règles avec tests Atomic RT	> 80%	Mensuel
Vélocité	Nombre de règles déployées/mois	> 10	Mensuel
Temps moyen PR	Délai entre soumission et merge	< 48h	Mensuel
Rollbacks	Nombre de rollbacks déclenchés	< 5%	Mensuel

7.2 Dashboard de couverture MITRE ATT&CK

Le dashboard de couverture est l'artefact le plus visible du programme DaC. Il visualise, sous forme de heatmap, quelles tactiques et techniques MITRE ATT&CK sont couvertes par au moins une règle de détection, et avec quel niveau de confiance. Ce dashboard est généré automatiquement par le pipeline CI à partir des métadonnées des règles :

# scripts/coverage-matrix.py (extrait)
import json
from pathlib import Path
import yaml

def generate_coverage_matrix(rules_dir):
    """Génère la matrice de couverture MITRE ATT&CK."""
    coverage = {}
    
    for rule_file in Path(rules_dir).rglob('*.yml'):
        with open(rule_file) as f:
            rule = yaml.safe_load(f)
        
        if rule.get('rule', {}).get('status') != 'production':
            continue
        
        mitre = rule.get('rule', {}).get('mitre', {})
        technique = mitre.get('technique', '')
        tactic = mitre.get('tactic', '')
        
        if technique not in coverage:
            coverage[technique] = {
                'tactic': tactic,
                'rules': [],
                'max_confidence': 'low'
            }
        
        coverage[technique]['rules'].append({
            'id': rule['rule']['id'],
            'name': rule['rule']['name'],
            'confidence': rule['rule'].get('confidence', 'medium')
        })
        
        # Mettre à jour la confiance maximale
        conf_order = {'low': 0, 'medium': 1, 'high': 2}
        current_conf = rule['rule'].get('confidence', 'medium')
        if conf_order.get(current_conf, 0) > conf_order.get(coverage[technique]['max_confidence'], 0):
            coverage[technique]['max_confidence'] = current_conf
    
    # Calculer les statistiques
    total_techniques = 201  # Total techniques ATT&CK Enterprise
    covered = len(coverage)
    
    stats = {
        'total_techniques': total_techniques,
        'covered': covered,
        'coverage_percent': round(covered / total_techniques * 100, 1),
        'high_confidence': sum(1 for t in coverage.values() if t['max_confidence'] == 'high'),
        'medium_confidence': sum(1 for t in coverage.values() if t['max_confidence'] == 'medium'),
        'low_confidence': sum(1 for t in coverage.values() if t['max_confidence'] == 'low'),
    }
    
    return {'stats': stats, 'coverage': coverage}

Le dashboard MITRE ATT&CK Navigator est le format de visualisation standard. Il peut être généré automatiquement au format JSON compatible ATT&CK Navigator à partir de la matrice de couverture, avec un code couleur indiquant le niveau de confiance : vert (high), orange (medium), rouge (low), gris (non couvert).

7.3 Métriques de qualité des règles individuelles

Au-delà des métriques agrégées, chaque règle doit être évaluée individuellement. Un script de monitoring post-déploiement collecte les statistiques suivantes sur une fenêtre glissante de 30 jours :

• Volume d'alertes : nombre d'alertes générées par jour/semaine. Un volume anormalement élevé indique un problème de faux positifs. Un volume à zéro pendant 30 jours peut indiquer une source de logs manquante.
• Ratio VP/FP : proportion de vrais positifs confirmés par rapport aux faux positifs. Objectif : > 80% de vrais positifs ou > 50% pour les règles de détection comportementale.
• Temps de triage moyen : temps passé par les analystes pour qualifier chaque alerte. Un temps élevé suggère que la règle manque de contexte ou de documentation.
• Performance de la requête : temps d'exécution moyen et peak. Les requêtes dépassant 30 secondes en peak doivent être optimisées.

8. Checklist d'implémentation Detection-as-Code

L'adoption du Detection-as-Code est un programme progressif, pas un big bang. Voici une checklist en 20 points organisée en trois phases pour guider votre implémentation :

Phase 1 : Fondations (Semaines 1-4)

• Créer le dépôt Git avec la structure de répertoires alignée sur MITRE ATT&CK
• Définir le schéma YAML des règles avec les champs obligatoires (id, name, mitre, sigma, status, tests)
• Documenter les conventions de nommage, le guide de contribution et la checklist de revue
• Importer les règles existantes depuis le SIEM vers le dépôt Git (migration initiale)
• Configurer les pipelines pySigma pour chaque backend SIEM utilisé
• Mettre en place le pipeline CI avec lint, validation de schéma et compilation Sigma

Phase 2 : Automatisation (Semaines 5-8)

• Implémenter le déploiement automatisé via les APIs SIEM (Splunk REST, Elastic Detection, Sentinel ARM)
• Configurer les smoke tests post-déploiement et le mécanisme de rollback automatique
• Mettre en place le lab SOC avec Atomic Red Team pour les tests de validation
• Créer les premiers tests unitaires pour les 20 règles les plus critiques
• Implémenter les notifications (Slack/Teams) pour chaque déploiement et rollback
• Configurer le Git workflow avec le template PR et le processus de revue

Phase 3 : Maturité (Semaines 9-12+)

• Générer la matrice de couverture MITRE ATT&CK automatiquement et le dashboard associé
• Implémenter le monitoring des métriques (taux FP, MTTD, vélocité, performance)
• Établir le processus de revue trimestrielle des règles (deprecated, tuning, nouvelles menaces)
• Intégrer les feeds Threat Intel pour la création automatique de stubs de règles
• Former les analystes SOC au workflow Git et à la contribution de règles
• Documenter les runbooks associés à chaque règle de détection
• Créer le rapport mensuel de performance du programme de détection pour le RSSI
• Partager les règles pertinentes avec la communauté SigmaHQ pour contribuer à l'écosystème

9. Conclusion : la détection comme produit d'ingénierie

Le Detection-as-Code représente un changement de paradigme fondamental pour les SOC : la détection n'est plus un artisanat ponctuel mais un produit d'ingénierie avec son cycle de développement, ses tests, ses métriques et son amélioration continue. Ce changement est inévitable pour plusieurs raisons : la croissance exponentielle du volume de données et du nombre de techniques d'attaque rend l'approche manuelle insoutenable, les exigences de conformité (ISO 27001, SOC 2, NIS2) imposent une traçabilité que seul le versioning peut fournir, et la pénurie de talents en cybersécurité oblige à automatiser tout ce qui peut l'être.

Les organisations qui adoptent le DaC constatent des améliorations mesurables : réduction du taux de faux positifs de 30 à 50%, augmentation de la couverture MITRE ATT&CK de 20 à 40 points de pourcentage en un an, et division par deux du temps de déploiement d'une nouvelle règle (de jours à heures). Mais au-delà des métriques, le bénéfice le plus profond est culturel : les detection engineers développent un sentiment de propriété sur leur code, les analystes SOC gagnent en confiance dans les alertes qu'ils traitent, et le RSSI dispose d'une visibilité objective sur la posture de détection de l'organisation.

Le chemin vers un programme DaC mature est progressif -- il ne se parcourt pas en un sprint. Mais chaque étape apporte une valeur immédiate. Commencez par versionner vos règles dans Git, ajoutez le linting automatique, puis la compilation Sigma, puis les tests, puis le déploiement automatisé. Chaque couche renforce la précédente. Et n'oubliez pas : le meilleur pipeline DaC est celui qui est effectivement utilisé par votre équipe, pas celui qui est le plus sophistiqué sur le papier.