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

# 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

# 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

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

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

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 securite 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.