1. Introduction : du SOC réactif au SOC engineering

Le Security Operations Center (SOC) traditionnel souffre d'un paradoxe structurel : il est noyé sous les alertes mais aveugle aux menaces réelles. Les études du secteur sont unanimes -- le SOC moyen gère entre 10 000 et 50 000 alertes par jour, dont plus de 60 % sont des faux positifs. Les analystes passent leur temps à trier du bruit plutôt qu'à investiguer de vraies menaces. Le résultat : un MTTD (Mean Time To Detect) qui se compte en jours, voire en semaines, pour les attaques sophistiquées.

Le Detection Engineering est la réponse à cette impasse. Inspiré des pratiques du software engineering (version control, testing, CI/CD, code review), il applique une discipline d'ingénierie rigoureuse à la création et à la maintenance des règles de détection. Ce n'est pas simplement "écrire de meilleures règles SIEM" -- c'est repenser fondamentalement comment un SOC construit sa capacité de détection.

Les principes fondamentaux du Detection Engineering :

• Threat-informed defense : les règles sont dérivées de la threat intelligence et des techniques d'attaque réelles, pas de patterns arbitraires
• Detection-as-Code : les règles sont du code, versionné dans Git, avec des tests unitaires, du CI/CD et des code reviews
• Coverage-driven : la couverture de détection est mesurée objectivement contre le framework MITRE ATT&CK et les gaps sont comblés méthodiquement
• Data-driven optimization : chaque règle est évaluée par des métriques quantitatives (precision, recall, MTTD) et ajustée en continu
• Collaborative : le detection engineering est un effort d'équipe impliquant les analystes SOC, les threat hunters, les red teamers et les ingénieurs sécurité

Cette approche est complémentaire des disciplines connexes comme le forensics numérique et le threat research. Un bon detection engineer comprend comment les attaquants opèrent, ce qui nécessite une connaissance des techniques offensives que nous documentons dans nos articles sur les attaques par mots de passe et le phishing avancé.

2. La pyramide de la douleur

2.1 Concept et niveaux

La Pyramid of Pain (pyramide de la douleur), conceptualisée par David J. Bianco en 2013, est le modèle mental fondamental du detection engineering. Elle classe les indicateurs de compromission (IOC) par le niveau de difficulté que leur détection impose à l'attaquant pour s'adapter. L'idée est simple mais profonde : plus vous détectez haut dans la pyramide, plus vous infligez de douleur à l'adversaire.

2.2 Implications pour le Detection Engineering

La pyramide de la douleur a des implications directes sur la manière dont un SOC devrait investir ses ressources de détection :

Niveau	Exemple de détection	Durée de vie	Priorité
Hash	Blocage du hash SHA-256 d'un malware connu	Minutes (recompilation)	Basse
IP	Blocage de l'IP du C2 server	Heures (nouveau VPS)	Basse
Domaine	Blocage du domaine de phishing	Jours (nouveau domaine)	Moyenne
Artefacts	Détection d'un User-Agent spécifique, mutex, registry key	Semaines	Moyenne
Outils	Détection de Mimikatz, Cobalt Strike, Impacket	Mois (temps de développement)	Haute
TTPs	Détection de LSASS dump (quelle que soit la méthode)	Années (changement de tactique)	Critique

Règle d'or : pour chaque heure investie dans la détection de hash/IP (bas de la pyramide), investissez dix heures dans la détection de TTPs (haut de la pyramide). Les détections TTP survivent au changement d'outillage de l'attaquant.

Un exemple concret : plutôt que de bloquer le hash de Mimikatz (qui change à chaque recompilation), construisez une détection du comportement "accès en lecture à la mémoire du processus LSASS" (technique T1003.001 de MITRE ATT&CK). Cette détection capturera Mimikatz, mais aussi pypykatz, comsvcs.dll MiniDump, procdump, nanodump, et tout futur outil qui tente d'extraire les credentials de LSASS.

3. MITRE ATT&CK : le framework de référence

3.1 ATT&CK comme langage commun

Le framework MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) est devenu le standard de facto pour structurer les capacités de détection d'un SOC. Avec ses 14 tactiques, 201 techniques et 424 sous-techniques (version 15.1, octobre 2025), ATT&CK fournit un vocabulaire commun pour décrire le comportement des attaquants à chaque étape de l'intrusion.

Pour le detection engineering, ATT&CK remplit trois fonctions essentielles :

• Coverage Gap Analysis : mapper les détections existantes sur la matrice ATT&CK pour identifier les techniques non couvertes. Un heatmap ATT&CK visualise instantanément les angles morts du SOC
• Priorisation threat-informed : utiliser les rapports de CTI (Cyber Threat Intelligence) pour identifier les techniques les plus utilisées par les groupes d'attaquants ciblant votre secteur, et prioriser les détections en conséquence
• Communication : fournir un langage commun entre les équipes SOC, CTI, Red Team et management. "Nous couvrons 73 % des techniques de Persistence" est plus actionnable que "nous avons 500 règles SIEM"

3.2 Mapping des détections sur ATT&CK

Chaque règle de détection doit être mappée sur une ou plusieurs techniques ATT&CK. Ce mapping doit inclure :

# Exemple de metadata ATT&CK pour une règle de détection
# Format YAML (utilisé dans Sigma et les systèmes de gestion de règles)

detection_rule:
  name: "LSASS Memory Access via Suspicious Process"
  id: "DET-2026-0142"
  status: production
  severity: high
  
  mitre_attack:
    tactics:
      - credential-access
    techniques:
      - T1003           # OS Credential Dumping
    sub_techniques:
      - T1003.001       # LSASS Memory
    
  data_sources:
    - "Process: Process Access"          # Sysmon EventID 10
    - "Process: Process Creation"        # Sysmon EventID 1
    
  platforms:
    - Windows
    
  detection_type: behavioral
  
  references:
    - https://attack.mitre.org/techniques/T1003/001/
    - https://www.elastic.co/guide/en/security/current/credential-access.html

3.3 Coverage Gap Analysis en pratique

L'analyse de couverture est un exercice critique qui doit être réalisé régulièrement (au minimum trimestriellement). Le processus recommandé :

1. Inventaire des détections : exporter toutes les règles SIEM actives avec leur mapping ATT&CK
2. Scoring par technique : attribuer un score de couverture pour chaque technique (0 = non couverte, 1 = couverture partielle, 2 = couverture complète, 3 = couverture testée et validée)
3. Overlay threat intelligence : superposer les techniques les plus utilisées par les groupes APT pertinents pour votre secteur (via ATT&CK Navigator)
4. Identifier les gaps critiques : les techniques fortement utilisées par vos adversaires mais non couvertes sont la priorité absolue
5. Plan de remédiation : créer des tickets/stories pour développer les détections manquantes, avec un calendrier réaliste

4. Le lifecycle d'une règle de détection

4.1 Les phases du cycle de vie

Une règle de détection n'est pas un artéfact statique. Elle naît d'une hypothèse, est développée, testée, déployée, optimisée et éventuellement retirée. Ce cycle de vie doit être formalisé et suivi rigoureusement :

4.2 Phase d'hypothèse : d'où viennent les détections ?

Les meilleures détections naissent de sources diversifiées :

• Threat Intelligence : rapports CTI sur les groupes APT, analyse de malware, bulletins CERT-FR. Notre veille CERT est une source précieuse pour identifier les menaces émergentes
• Retour d'expérience d'incidents : chaque incident géré par le SOC doit générer une question : "comment aurions-nous pu détecter cela plus tôt ?" Les post-mortem sont une mine d'or pour les hypothèses de détection
• Red Team / Purple Team : les exercices offensifs révèlent les angles morts. Un Red Team report qui mentionne "non détecté" est une invitation directe à créer une nouvelle règle
• Coverage Gap Analysis : l'analyse ATT&CK identifie les techniques non couvertes qui sont pertinentes pour l'organisation
• Communauté : les règles Sigma de la communauté, les blogs de threat hunters, les conférences (BlackHat, SANS, BSides) fournissent des idées de détection testées par d'autres équipes

4.3 Phase de recherche : data sources et feasibility

Avant d'écrire une seule ligne de règle, le detection engineer doit répondre à trois questions critiques :

1. Ai-je les données nécessaires ? -- Vérifier que les sources de logs requises sont collectées, parsées et indexées dans le SIEM. Par exemple, détecter T1003.001 (LSASS dump) nécessite les événements Sysmon EventID 10 (ProcessAccess). Si Sysmon n'est pas déployé, la détection est impossible
2. Quel est le volume de données ? -- Estimer le volume de logs concerné et le coût de recherche. Une règle qui scanne 100 millions d'événements par exécution impactera les performances du SIEM
3. Quel est le taux de base (base rate) ? -- Évaluer la fréquence du comportement normal qui pourrait déclencher la détection. Si 10 000 processus légitimes accèdent à LSASS chaque jour, la règle doit être assez spécifique pour filtrer le bruit

# Exemple : vérifier la disponibilité des données dans Splunk
# Recherche de validation des sources de logs nécessaires

index=windows sourcetype=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational
  EventCode=10
| stats count by TargetImage
| where TargetImage LIKE "%lsass.exe%"
| stats count
# Résultat attendu : confirme que Sysmon EventID 10 est collecté
# et que les accès à LSASS sont visibles

5. Types de détection : signature, anomalie, comportementale

5.1 Détection par signature (Signature-based)

La détection par signature est la forme la plus ancienne et la plus simple : elle recherche un motif (pattern) connu et statique dans les données. Exemples : un hash de fichier malveillant, une chaîne de caractères dans un log, un User-Agent spécifique.

Avantages : précision très élevée (quasi zéro faux positifs quand la signature est spécifique), performance excellente, facile à comprendre et à maintenir.

Limites : ne détecte que les menaces connues, facilement contournable (obfuscation, polymorphisme), se situe en bas de la pyramide de la douleur.

# Exemple de détection par signature dans Splunk SPL
# Détection de l'utilisation de Mimikatz par nom de processus
index=windows sourcetype=WinEventLog:Security EventCode=4688
  (New_Process_Name="*mimikatz*" OR New_Process_Name="*sekurlsa*")
| table _time, ComputerName, Account_Name, New_Process_Name, Creator_Process_Name

5.2 Détection par anomalie (Anomaly-based)

La détection par anomalie établit un baseline du comportement normal et alerte lorsqu'un écart significatif est observé. Elle ne nécessite pas de connaissance préalable de la menace, ce qui lui permet de détecter des attaques zero-day.

Avantages : peut détecter des menaces inconnues, adaptative au contexte de l'organisation.

Limites : génère potentiellement beaucoup de faux positifs, nécessite une période d'apprentissage, vulnérable au concept drift (le baseline évolue) et à l'adversarial evasion (l'attaquant adapte lentement son comportement pour normaliser la baseline).

# Exemple de détection par anomalie dans Splunk SPL
# Détection de connexions RDP inhabituelles (baseline sur 30 jours)
index=windows sourcetype=WinEventLog:Security EventCode=4624 Logon_Type=10
| stats count as daily_rdp_count by src_ip, dest, _time
| eventstats avg(daily_rdp_count) as avg_count, stdev(daily_rdp_count) as stdev_count by dest
| where daily_rdp_count > (avg_count + 3 * stdev_count)
| table _time, src_ip, dest, daily_rdp_count, avg_count

5.3 Détection comportementale (Behavioral)

La détection comportementale est le sweet spot du detection engineering. Elle se situe au sommet de la pyramide de la douleur en détectant les TTPs plutôt que les indicateurs éphémères. Elle modélise le comportement de l'attaquant : "un processus non système accède à la mémoire de LSASS", "un script PowerShell télécharge et exécute du code en mémoire", "un compte de service se connecte depuis un poste utilisateur".

Avantages : résistante au changement d'outils de l'attaquant, se concentre sur l'intention, longue durée de vie.

Limites : plus complexe à écrire, nécessite une bonne compréhension du contexte normal, peut nécessiter une corrélation de plusieurs événements. La corrélation de logs est un sujet que nous approfondissons dans notre article sur l'audit avancé Microsoft 365.

# Exemple de détection comportementale dans Elastic KQL
# Détection : processus non standard accédant à LSASS memory
# MITRE ATT&CK: T1003.001 - OS Credential Dumping: LSASS Memory

process where event.action == "access" and
  process.Ext.target.name == "lsass.exe" and
  not process.executable : (
    "C:\\Windows\\System32\\*.exe",
    "C:\\Windows\\SysWOW64\\*.exe",
    "C:\\Program Files\\*\\*.exe",
    "C:\\Program Files (x86)\\*\\*.exe"
  ) and
  process.Ext.call_trace_summary : "*UNKNOWN*"

Critère	Signature	Anomalie	Comportementale
Menaces zero-day	Non	Oui	Oui
Faux positifs	Très bas	Élevé	Moyen
Complexité	Faible	Élevée	Élevée
Durée de vie	Courte	Variable	Longue
Pyramide de la douleur	Base (Hash/IP)	Milieu	Sommet (TTPs)
Recommandation	Complémentaire	UBA/UEBA	Prioritaire

6. Création de règles SIEM

6.1 Sigma : le standard universel

Sigma est un format de description de règles de détection générique, indépendant de tout SIEM. Créé par Florian Roth et Thomas Patzke, Sigma est au SIEM ce que YARA est aux fichiers malveillants ou Snort aux paquets réseau. L'avantage fondamental : une règle Sigma peut être convertie automatiquement en SPL (Splunk), KQL (Elastic/Azure Sentinel), Lucene, QRadar AQL, et des dizaines d'autres langages SIEM via le compilateur sigma-cli ou pySigma.

# Exemple de règle Sigma complète
# Fichier: rules/windows/process_access/proc_access_lsass_dump.yml

title: LSASS Memory Dump via Suspicious Process
id: 5ef8bda5-8093-4c92-a7da-080c7d4c5f4c
status: production
level: high
description: |
    Detects access to LSASS process memory by a suspicious process,
    indicating potential credential dumping (Mimikatz, pypykatz, etc.)

author: Ayi NEDJIMI
date: 2026/03/01
modified: 2026/03/01

tags:
    - attack.credential_access
    - attack.t1003.001

logsource:
    category: process_access
    product: windows
    
detection:
    selection:
        TargetImage|endswith: '\lsass.exe'
        GrantedAccess|contains:
            - '0x1010'     # PROCESS_QUERY_LIMITED_INFORMATION + PROCESS_VM_READ
            - '0x1410'     # + PROCESS_QUERY_INFORMATION
            - '0x1438'     # Full dump access
            - '0x1fffff'   # PROCESS_ALL_ACCESS
    filter_known_good:
        SourceImage|startswith:
            - 'C:\Windows\System32\'
            - 'C:\Windows\SysWOW64\'
            - 'C:\Program Files\Windows Defender\'
            - 'C:\ProgramData\Microsoft\Windows Defender\'
    filter_sysmon:
        SourceImage|endswith: '\Sysmon64.exe'
    condition: selection and not 1 of filter_*

falsepositives:
    - Legitimate security tools performing memory scans
    - EDR agents accessing LSASS for monitoring
    - System Center Configuration Manager

fields:
    - SourceImage
    - TargetImage
    - GrantedAccess
    - CallTrace

6.2 Conversion Sigma vers Splunk SPL

# Installation de sigma-cli
pip install sigma-cli pySigma-backend-splunk pySigma-pipelines-sysmon

# Conversion d'une règle Sigma en Splunk SPL
sigma convert -t splunk -p sysmon rules/windows/process_access/proc_access_lsass_dump.yml

# Résultat SPL généré :
index=windows sourcetype=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational EventCode=10
  TargetImage="*\\lsass.exe"
  (GrantedAccess="*0x1010*" OR GrantedAccess="*0x1410*" OR GrantedAccess="*0x1438*" OR GrantedAccess="*0x1fffff*")
  NOT (SourceImage="C:\\Windows\\System32\\*" OR SourceImage="C:\\Windows\\SysWOW64\\*"
       OR SourceImage="C:\\Program Files\\Windows Defender\\*"
       OR SourceImage="C:\\ProgramData\\Microsoft\\Windows Defender\\*")
  NOT SourceImage="*\\Sysmon64.exe"
| table _time, Computer, SourceImage, TargetImage, GrantedAccess, CallTrace

6.3 Règle Splunk SPL avancée : corrélation multi-événements

Les détections les plus puissantes corrèlent plusieurs événements pour construire une chaîne d'attaque. Voici un exemple de détection de lateral movement via PsExec qui corrèle la création de service à distance avec l'exécution de processus :

# Détection avancée : Lateral Movement via PsExec/Remote Service
# Corrélation entre la création de service (Event 7045) et l'exécution (Event 4688)
# MITRE ATT&CK: T1021.002 (SMB/Windows Admin Shares) + T1569.002 (Service Execution)

index=windows sourcetype=WinEventLog:System EventCode=7045
  Service_File_Name="*PSEXESVC*" OR Service_File_Name="*\\cmd.exe*" OR Service_File_Name="*\\powershell*"
| rename Computer as dest_host
| join type=inner dest_host 
  [search index=windows sourcetype=WinEventLog:Security EventCode=4624 Logon_Type=3
   | rename Computer as dest_host
   | where src_ip != "127.0.0.1" AND src_ip != "::1"
   | stats earliest(_time) as logon_time, values(src_ip) as src_ip by dest_host, Account_Name]
| eval time_diff = _time - logon_time
| where time_diff > 0 AND time_diff < 300
| table _time, dest_host, Account_Name, src_ip, Service_File_Name, Service_Name, time_diff
| sort -_time

6.4 Règle Elastic KQL : détection de Living-off-the-Land

Les attaques Living-off-the-Land (LOLBins) utilisent des binaires légitimes du système pour exécuter des actions malveillantes. Ces techniques sont particulièrement difficiles à détecter car les outils utilisés sont légitimes. Voici une détection de l'utilisation suspecte de certutil.exe pour télécharger des fichiers :

# Elastic Security Rule (KQL)
# Détection : certutil.exe utilisé pour télécharger un fichier
# MITRE ATT&CK: T1105 (Ingress Tool Transfer) + T1140 (Deobfuscate/Decode Files)

process where event.type == "start" and
  process.name : "certutil.exe" and
  process.args : ("-urlcache", "-split", "-decode", "-encode", "-decodehex") and
  not process.parent.executable : (
    "C:\\Windows\\System32\\svchost.exe",
    "C:\\Windows\\System32\\mmc.exe"
  )

# Version ESQL (Elasticsearch Query Language)
FROM logs-endpoint.events.process-*
| WHERE process.name == "certutil.exe"
  AND (process.args LIKE "*-urlcache*" OR process.args LIKE "*-decode*")
| STATS count = COUNT(*) BY host.name, user.name, process.command_line
| WHERE count > 0
| SORT count DESC

6.5 Bonnes pratiques d'écriture de règles

L'écriture de règles de détection de qualité repose sur plusieurs principes fondamentaux :

• Documenter l'intention : chaque règle doit expliquer pourquoi elle existe, pas seulement ce qu'elle fait. Le titre et la description doivent permettre à un analyste SOC de comprendre l'alerte en 5 secondes
• Minimiser les faux positifs dès la conception : inclure des filtres d'exclusion pour les processus légitimes connus. Documenter les faux positifs attendus
• Mapper sur ATT&CK : chaque règle doit référencer au moins une technique ATT&CK. C'est non négociable
• Fournir un runbook : chaque règle doit être accompagnée d'un runbook qui guide l'analyste SOC dans l'investigation. Questions à poser, logs complémentaires à consulter, actions de remédiation
• Tester avant le déploiement : jamais de règle en production sans test. Utiliser Atomic Red Team ou un dataset de logs pour valider
• Limiter la complexité : une règle trop complexe est difficile à maintenir et à débugger. Préférer plusieurs règles simples corrélées par le SOAR

7. Testing et validation

7.1 Pourquoi le testing est non négociable

Une règle de détection non testée est un danger. Elle peut être inefficace (ne détecte pas ce qu'elle prétend détecter), génératrice de bruit (faux positifs en cascade), ou pire, consommatrice de ressources SIEM sans aucune valeur. Le testing est l'étape qui transforme une hypothèse de détection en une capacité validée.

Le testing d'une règle de détection couvre trois dimensions :

• True Positive Testing : vérifier que la règle déclenche bien une alerte lorsque le comportement malveillant se produit. Utiliser Atomic Red Team, MITRE Caldera ou un Purple Team pour simuler l'attaque
• False Positive Testing : vérifier que la règle ne déclenche pas d'alerte sur le comportement normal. Exécuter la règle sur un historique de logs (30 jours minimum) et analyser les résultats
• Performance Testing : vérifier que la règle n'impacte pas les performances du SIEM. Mesurer le temps d'exécution, la consommation de ressources

7.2 Atomic Red Team : tests unitaires pour les détections

Atomic Red Team est une bibliothèque de tests atomiques mappés sur MITRE ATT&CK. Chaque test est une procédure minimale qui simule une technique d'attaque spécifique, permettant de valider qu'une règle de détection fonctionne correctement. C'est l'équivalent des tests unitaires en développement logiciel.

# Installation d'Atomic Red Team (PowerShell)
IEX (IWR 'https://raw.githubusercontent.com/redcanaryco/invoke-atomicredteam/master/install-atomicredteam.ps1' -UseBasicParsing)
Install-AtomicRedTeam -getAtomics

# Exécuter le test pour T1003.001 (LSASS Dump)
Invoke-AtomicTest T1003.001

# Tests disponibles pour T1003.001 :
# 1. Dump LSASS with Mimikatz
# 2. Dump LSASS with comsvcs.dll
# 3. Dump LSASS with procdump
# 4. Dump LSASS with Windows Task Manager
# 5. Dump LSASS via rundll32/MiniDumpWriteDump

# Exécuter un test spécifique (test #2 : comsvcs.dll)
Invoke-AtomicTest T1003.001 -TestNumbers 2

# Vérifier dans le SIEM que l'alerte a bien été déclenchée
# Si l'alerte ne se déclenche pas : la règle est déficiente
# Si l'alerte se déclenche : True Positive confirmé

7.3 MITRE Caldera et simulation d'adversaire

Pour des scénarios de test plus complexes impliquant des chaînes d'attaque multi-étapes, MITRE Caldera est un framework de simulation d'adversaire qui exécute automatiquement des séquences de techniques ATT&CK. Il permet de tester la capacité du SOC à détecter non pas une technique isolée, mais un parcours d'attaque complet.

D'autres outils de validation sont également précieux :

• Sigma Test Utility (sigma-test) : teste les règles Sigma contre des jeux de données JSON, vérifie que la logique de détection est correcte sans nécessiter un SIEM
• DetectionLab : un environnement de lab automatisé avec Windows AD, Sysmon, Splunk pré-configuré pour le testing des détections
• Vectr : plateforme de Purple Team qui suit les résultats de test et le coverage ATT&CK au fil du temps
• Log replay : rejouer des logs d'incidents passés (anonymisés) pour vérifier que les nouvelles règles auraient détecté l'attaque

8. Métriques de performance

8.1 Les métriques essentielles du Detection Engineering

Ce qui ne se mesure pas ne s'améliore pas. Le Detection Engineering exige des métriques quantitatives pour évaluer la performance des règles et du programme de détection dans son ensemble. Les métriques clés sont :

Métrique	Définition	Objectif	Comment mesurer
Precision	TP / (TP + FP) -- proportion d'alertes qui sont de vraies menaces	> 80 %	Feedback des analystes sur chaque alerte
Recall	TP / (TP + FN) -- proportion de menaces réelles détectées	> 90 % pour les techniques critiques	Purple Team, Atomic Red Team
MTTD	Mean Time To Detect -- temps moyen entre le début de l'attaque et la détection	< 1h pour les techniques critiques	Timestamp alerte - timestamp premier événement
FP Rate par règle	Nombre de faux positifs par jour pour chaque règle	< 5 FP/jour par règle	Compteur automatique + feedback analyste
ATT&CK Coverage	% de techniques ATT&CK pertinentes couvertes par au moins une règle testée	> 70 % des techniques prioritaires	Mapping automatique + ATT&CK Navigator
Rule Health	% de règles en état "production" avec tests valides	> 90 %	Dashboard de suivi des états de règles

8.2 Le problème du faux positif

Le faux positif est l'ennemi numéro un de l'analyste SOC. Chaque faux positif consomme du temps d'investigation (5-15 minutes en moyenne), génère de la fatigue d'alerte (alert fatigue), et augmente le risque que de vraies menaces soient ignorées ou traitées en retard. La gestion des faux positifs est un processus continu :

1. Identification : l'analyste SOC marque l'alerte comme "faux positif" avec une justification (quel processus légitime a déclenché l'alerte)
2. Analyse de pattern : le detection engineer agrège les FP de la même règle et identifie les patterns récurrents
3. Tuning : ajout de filtres d'exclusion spécifiques dans la règle, sans réduire la couverture de détection légitime
4. Validation : vérification que le tuning ne crée pas de blind spots (angles morts) exploitables par un attaquant
5. Déploiement : la règle mise à jour passe par le cycle complet (review, test, deploy)

8.3 Dashboards de suivi

Le Detection Engineering doit disposer de dashboards dédiés pour piloter la performance du programme. Les tableaux de bord essentiels sont :

• Rule Health Dashboard : état de chaque règle (production/testing/deprecated), nombre de TP/FP sur les 30 derniers jours, dernière date de test, dernier tuning
• ATT&CK Coverage Heatmap : visualisation de la matrice ATT&CK avec un code couleur par niveau de couverture (rouge = non couvert, jaune = partiel, vert = couvert et testé)
• SOC Performance : MTTD, MTTR, volume d'alertes par catégorie, taux de faux positifs global, tendances sur 90 jours
• Detection Backlog : nombre de règles en développement, en attente de review, en testing. Velocity de production de nouvelles détections

9. Automatisation et CI/CD pour la détection

9.1 Detection-as-Code : principes fondamentaux

Le paradigme Detection-as-Code applique les pratiques du développement logiciel à la création et à la gestion des règles de détection. Chaque règle est versionnée dans un dépôt Git, revue par des pairs, testée automatiquement et déployée via un pipeline CI/CD. Cette approche apporte plusieurs avantages majeurs :

• Traçabilité complète : chaque modification est liée à un commit, un auteur et une justification. L'historique complet est consultable
• Reproductibilité : l'état de la détection à un instant T peut être reconstitué à partir du dépôt Git
• Collaboration : les pull requests permettent la revue par les pairs avant déploiement. Les commentaires documentent les décisions
• Qualité : les tests automatiques détectent les erreurs de syntaxe, les régressions et les problèmes de performance avant la mise en production
• Vélocité : le pipeline automatise les étapes de validation et de déploiement, réduisant le time-to-detect pour les nouvelles menaces

Pour approfondir cette approche, consultez notre article dédié sur le pipeline CI/CD pour la détection SIEM.

9.2 Structure d'un dépôt de détection

Un dépôt de détection bien organisé suit une arborescence claire, alignée sur le framework MITRE ATT&CK :

detection-rules/
├── rules/
│   ├── sigma/                    # Règles Sigma universelles
│   │   ├── credential_access/
│   │   │   ├── mimikatz_execution.yml
│   │   │   ├── lsass_memory_dump.yml
│   │   │   └── kerberoasting.yml
│   │   ├── lateral_movement/
│   │   │   ├── psexec_execution.yml
│   │   │   └── wmi_remote_execution.yml
│   │   ├── persistence/
│   │   │   ├── registry_run_keys.yml
│   │   │   └── scheduled_task_creation.yml
│   │   └── defense_evasion/
│   │       ├── process_injection.yml
│   │       └── amsi_bypass.yml
│   └── platform-specific/       # Règles natives SIEM
│       ├── splunk/
│       ├── elastic/
│       └── sentinel/
├── tests/
│   ├── unit/                    # Tests unitaires par règle
│   ├── integration/             # Tests avec données réelles
│   └── fixtures/                # Données de test (logs simulés)
├── pipelines/
│   ├── sigma-to-splunk.yml      # Configuration pySigma
│   └── sigma-to-elastic.yml
├── docs/
│   ├── CONTRIBUTING.md          # Guide de contribution
│   ├── STYLE_GUIDE.md           # Conventions d'écriture
│   └── REVIEW_CHECKLIST.md      # Checklist de revue
├── .github/workflows/
│   └── detection-pipeline.yml   # Pipeline CI/CD
└── README.md

9.3 Pipeline CI/CD : les étapes clés

Un pipeline CI/CD de détection se compose de plusieurs étapes exécutées automatiquement à chaque pull request :

# .github/workflows/detection-pipeline.yml
name: Detection Rules Pipeline

on:
  pull_request:
    paths: ['rules/**', 'tests/**']
  push:
    branches: [main]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # Étape 1 : Validation syntaxique
      - name: Validate YAML syntax
        run: |
          pip install yamllint
          yamllint -c .yamllint.yml rules/

      # Étape 2 : Validation Sigma
      - name: Validate Sigma rules
        run: |
          pip install pySigma
          sigma check rules/sigma/

      # Étape 3 : Compilation multi-SIEM
      - name: Compile to target SIEMs
        run: |
          sigma convert -t splunk -p sysmon rules/sigma/ -o compiled/splunk/
          sigma convert -t elastic -p ecs_windows rules/sigma/ -o compiled/elastic/

      # Étape 4 : Tests unitaires
      - name: Run detection tests
        run: pytest tests/ -v --tb=short

      # Étape 5 : Analyse de couverture
      - name: ATT&CK coverage report
        run: python scripts/coverage_report.py --output coverage.json

  deploy:
    needs: validate
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      # Déploiement automatique vers le SIEM
      - name: Deploy to Splunk
        run: python scripts/deploy_splunk.py --env production
        env:
          SPLUNK_TOKEN: ${{ secrets.SPLUNK_TOKEN }}

      - name: Deploy to Elastic
        run: python scripts/deploy_elastic.py --env production
        env:
          ELASTIC_API_KEY: ${{ secrets.ELASTIC_API_KEY }}

9.4 Tests automatisés pour les règles de détection

Chaque règle doit être accompagnée de tests qui valident son comportement attendu. Les tests vérifient deux aspects : les true positives (la règle détecte bien ce qu'elle doit détecter) et les true negatives (la règle ne déclenche pas sur l'activité légitime) :

# tests/test_mimikatz_detection.py
import pytest
from sigma.rule import SigmaRule
from sigma.backends.splunk import SplunkBackend

class TestMimikatzDetection:
    @pytest.fixture
    def rule(self):
        return SigmaRule.from_yaml(open('rules/sigma/credential_access/mimikatz_execution.yml'))

    def test_rule_compiles_splunk(self, rule):
        """Vérifie que la règle se compile correctement pour Splunk"""
        backend = SplunkBackend()
        result = backend.convert_rule(rule)
        assert len(result) > 0
        assert 'mimikatz' in result[0].lower() or 'sekurlsa' in result[0].lower()

    def test_true_positive_process_name(self, rule):
        """Vérifie la détection par nom de processus"""
        test_event = {
            'Image': 'C:\\Users\\attacker\\mimikatz.exe',
            'CommandLine': 'mimikatz.exe "privilege::debug" "sekurlsa::logonpasswords"',
            'User': 'CORP\\admin'
        }
        assert rule.matches(test_event)

    def test_true_negative_legitimate(self, rule):
        """Vérifie l'absence de faux positif sur activité légitime"""
        test_event = {
            'Image': 'C:\\Windows\\System32\\lsass.exe',
            'CommandLine': 'lsass.exe',
            'User': 'NT AUTHORITY\\SYSTEM'
        }
        assert not rule.matches(test_event)

10. Checklist Detection Engineering

Cette checklist synthétise les bonnes pratiques présentées dans cet article. Utilisez-la comme référence pour chaque nouvelle règle de détection et comme guide d'audit pour votre programme existant :

10.1 Avant d'écrire une règle

• Identifier la technique ATT&CK ciblée et son data source
• Vérifier que les logs nécessaires sont effectivement collectés dans le SIEM
• Rechercher les règles existantes (SigmaHQ, Elastic Detection Rules) avant de créer une règle from scratch
• Définir l'hypothèse de détection : quel comportement attaquant spécifique vise-t-on ?
• Évaluer le niveau dans la Pyramide de la Douleur : privilégier les TTP aux IoC
• Estimer le volume d'alertes attendu en requêtant les logs historiques

10.2 Pendant l'écriture

• Utiliser le format Sigma pour garantir la portabilité multi-SIEM. Voir notre guide d'écriture Sigma
• Nommer la règle de manière descriptive (verbe + objet + contexte)
• Documenter les champs description, falsepositives, level, tags
• Ajouter des filtres d'exclusion pour les processus légitimes connus
• Préférer la détection comportementale (TTP) à la détection par signature (hash, IP)
• Tester la règle sur un jeu de données contenant des TP et des TN

10.3 Avant le déploiement

• Faire une revue par un pair (pull request avec commentaires)
• Exécuter le pipeline CI/CD : validation syntaxique, compilation, tests
• Déployer en mode shadow/silent pendant 1-2 semaines pour mesurer le bruit
• Vérifier que la règle ne génère pas plus de 50 alertes/jour (seuil ajustable selon le contexte)
• Valider avec un test Atomic Red Team que la technique est effectivement détectée
• Documenter le runbook d'investigation pour les analystes SOC

10.4 Après le déploiement

• Surveiller le ratio TP/FP pendant les 30 premiers jours
• Itérer sur les filtres d'exclusion en fonction des retours analystes
• Mettre à jour la couverture ATT&CK dans le dashboard
• Planifier des re-tests trimestriels pour vérifier que la règle fonctionne toujours
• Intégrer les retours d'incidents (retex) pour enrichir la détection
• Déprécier les règles obsolètes avec une justification documentée