Detection Engineering : Construire des Règles de : Guide

# 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 détection 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". Guide complet Detection Engineering : pyramide de la douleur, MITRE ATT&CK mapping, lifecycle des règles SIEM, types de détection, testing, métriques.

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*"

# 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

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

Figure 3 -- Pipeline Detection Engineering avec métriques et boucle de feedback

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

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 détection 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

Pour approfondir ce sujet, consultez notre outil open-source siem-correlation-rules qui facilite l'optimisation des règles de corrélation SIEM.

Questions frequentes

Sources et références : MITRE ATT&CK · MITRE CAR

Cycle de vie d'une règle de détection : création, test, déploiement, retraite

Une règle de détection suit un cycle de vie structuré. La phase de création part d'une hypothèse de menace basée sur des TTPs documentés dans MITRE ATT&CK. La phase de test valide la règle sur des données historiques et simule des faux positifs. Le déploiement inclut un monitoring initial renforcé pour affiner les seuils. La retraite intervient quand la technique d'attaque devient obsolète ou quand de meilleures règles la remplacent.

Gestion des faux positifs : la métrique clé du SOC

Le taux de faux positifs est la métrique principale de qualité d'une règle de détection. Une règle qui génère des centaines d'alertes par jour dont 99% sont des comportements légitimes fatigue les analystes et masque les vraies menaces. Le tuning continu via des exclusions ciblées (liste blanche d'IPs internes, exclusion de processus légitimes connus) est une activité permanente du SOC. L'objectif est une règle générant des alertes actionnables, pas du bruit.

Mapping MITRE ATT&CK pour une couverture structurée

MITRE ATT&CK fournit un référentiel de 14 tactiques et plusieurs centaines de techniques d'attaque documentées. Mapper ses règles de détection sur ATT&CK permet de mesurer la couverture et d'identifier les angles morts. Des outils comme MITRE ATT&CK Navigator visualisent cette couverture et facilitent la communication avec la direction sur l'état de la posture de détection.

GitOps pour le detection engineering : règles comme code

Les équipes matures gèrent leurs règles comme du code : versionning Git, revue par les pairs (pull requests), tests automatisés avant déploiement (CI/CD), et déploiement automatisé vers le SIEM de production. Cette approche garantit la traçabilité des modifications et permet un rollback rapide en cas de règle défectueuse. Sigma, le format SIEM-agnostique, est le standard recommandé pour cette approche GitOps appliquée au detection engineering.

Conclusion

Cet article a couvert les aspects essentiels de 1. Introduction : du SOC réactif au SOC engineering, 2. La pyramide de la douleur, 3. MITRE ATT&CK : le framework de référence. La mise en oeuvre de ces recommandations permet de renforcer significativement votre posture de sécurité et de repondre aux exigences des referentiels en vigueur.

Analyse des impacts et recommandations

L'analyse des risques associés à cette problématique révèle des impacts potentiels significatifs sur la confidentialité, l'intégrité et la disponibilité des systèmes d'information. Les recommandations présentées s'appuient sur les référentiels de l'ANSSI et du NIST pour garantir une approche structurée de la remédiation.

Mise en œuvre opérationnelle

La mise en œuvre des mesures de sécurité décrites dans cet article nécessite une approche progressive, en commençant par les actions à gain rapide avant de déployer les contrôles plus complexes. Un plan d'action priorisé permet de maximiser la réduction du risque tout en respectant les contraintes opérationnelles de l'organisation.

Optimisez votre détection des menaces

Audit SOC, règles de détection, threat hunting, SIEM — par un expert offensif et défensif.

Améliorer ma détection [email protected]