SIEM : Correlations Avancees pour Threat Hunting en 2026

Les siem corrélations avancées threat hunting 2026 ne ressemblent plus à ce qu'elles étaient il y a trois ans. Les environnements hybrides — Active Directory on-premise, workloads Azure, endpoints EDR, flux réseau NetFlow — génèrent des volumes de logs que les moteurs de corrélation traditionnels peinent à traiter avec pertinence. Face à des adversaires qui utilisent des binaires légitimes Windows (LOLBins), des comptes de service compromis et des connexions chiffrées pour se déplacer latéralement, les équipes SOC doivent construire des hypothèses de chasse précises, les traduire en requêtes KQL, SPL ou Elasticsearch DSL, et automatiser la validation via des règles Sigma standardisées. Ce guide technique couvre l'intégralité du pipeline : depuis l'écriture d'une règle Sigma taggée MITRE ATT&CK jusqu'à sa conversion vers les trois grands SIEM du marché, en passant par l'établissement de baselines comportementales Z-score, l'analyse UEBA (impossible travel, data staging, off-hours access), et l'application du PEAK Framework pour structurer vos campagnes de threat hunting. Les exemples de code sont fonctionnels et issus d'environnements de production 2025-2026.

Pourquoi les corrélations SIEM classiques ne suffisent-elles plus ?

Les règles de corrélation SIEM de première génération reposent sur un modèle simple : si l'événement A suivi de l'événement B dans une fenêtre temporelle X → alerte. Ce modèle échoue face aux TTPs modernes pour trois raisons structurelles.

Le bruit de fond dépasse le signal. Un SOC de taille moyenne ingest entre 50 000 et 500 000 événements par seconde. Les règles à seuil fixe génèrent une proportion très élevée de faux positifs. Les analystes passent une grande part de leur temps à triager des alertes non actionnables, au détriment de l'investigation des incidents réels.

Les adversaires opèrent sous les seuils. Les campagnes APT modernes utilisent des techniques "slow and low" : une tentative d'authentification toutes les 4 heures sur 200 comptes différents passe sous le radar d'une règle de brute force classique (seuil habituel : 5 échecs en 5 minutes). Les corrélations temporelles étendues sur 24 à 72 heures sont nécessaires pour détecter ces patterns.

La fragmentation des sources casse les chaînes d'attaque. Un mouvement latéral typique génère des événements dans Windows Event Log (EventID 4648, 4624), l'EDR (process hollowing détecté), le proxy (connexion C2 sortante) et les logs Azure AD (Conditional Access bypass). Sans normalisation vers un schéma commun (ECS ou OCSF), la corrélation multi-source est impossible à automatiser fiablement.

La solution passe par trois piliers : Sigma pour l'abstraction des règles de détection, les baselines comportementales pour contextualiser les anomalies, et le PEAK Framework pour structurer la démarche de hunting. Ces trois approches, combinées aux capacités des SIEM modernes, permettent de détecter des attaques que les règles statiques laissent passer systématiquement.

Sigma : La Grammaire Universelle des Règles de Détection

Sigma est un format YAML open-source développé par Florian Roth et Thomas Patzke qui permet d'écrire une règle de détection une seule fois et de la convertir vers n'importe quel SIEM. La règle décrit ce qu'on cherche (champs, valeurs, logique booléenne) indépendamment du langage de requête de la plateforme cible. La communauté SigmaHQ maintient plus de 2 800 règles dans le dépôt officiel, toutes taggées avec les techniques MITRE ATT&CK correspondantes.

Règle Sigma — Détection d'accès LSASS par Mimikatz (T1003.001) :

title: Mimikatz LSASS Memory Access
id: 61d0c0a5-e001-4e8e-b9b1-b1a1a1e1c1d1
status: stable
description: Detects Mimikatz attempting to access LSASS process memory for credential dumping
references:
  - https://attack.mitre.org/techniques/T1003/001/
author: SOC Team
date: 2024/01/15
modified: 2026/01/10
tags:
  - attack.credential_access
  - attack.t1003.001
  - attack.defense_evasion
logsource:
  category: process_access
  product: windows
detection:
  selection:
    TargetImage|endswith: '\lsass.exe'
    GrantedAccess|contains:
      - '0x1010'
      - '0x1038'
      - '0x40'
      - '0x1400'
  filter_legitimate:
    SourceImage|startswith:
      - 'C:\Windows\System32\'
      - 'C:\Windows\SysWOW64\'
      - 'C:\Program Files\Windows Defender\'
  condition: selection and not filter_legitimate
falsepositives:
  - Security scanners (CrowdStrike, Carbon Black)
  - AV products performing in-memory scanning
level: critical

Règle Sigma — PowerShell Encoded Command (T1059.001) :

title: PowerShell Encoded Command Execution
id: 9d4a2d05-2b1a-4c3e-8f5b-2c4e6a8b0d2e
status: experimental
description: >
  Detects PowerShell execution with Base64 encoded commands,
  commonly used to evade detection and bypass script block logging.
tags:
  - attack.execution
  - attack.t1059.001
  - attack.defense_evasion
  - attack.t1027
logsource:
  category: process_creation
  product: windows
detection:
  selection_powershell:
    Image|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
  selection_encoded:
    CommandLine|contains:
      - ' -enc '
      - ' -EncodedCommand '
      - ' -ec '
  selection_suspicious:
    CommandLine|contains:
      - 'JAB'       # $ en base64 (debut de variable PowerShell)
      - 'SUVYR'     # IEX en base64
      - 'aWV4'      # iex en base64
      - 'SQBFAFgA'  # IEX en unicode base64
  condition: selection_powershell and (selection_encoded or selection_suspicious)
fields:
  - CommandLine
  - ParentCommandLine
  - User
  - ComputerName
level: high

Règle Sigma — Mouvement Latéral via Credentials Explicites (Event 4648) :

title: Lateral Movement via Explicit Credentials (Event 4648)
id: 7a3f1b2c-8d4e-4f5a-9b6c-3e7d2f1a4b8c
status: stable
description: >
  Detects use of explicit credentials for lateral movement via Event 4648.
  Legitimate use includes scheduled tasks and services — filter accordingly.
tags:
  - attack.lateral_movement
  - attack.t1021
  - attack.credential_access
  - attack.t1550.002
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4648
    LogonType: 3
  filter_system:
    SubjectUserName|endswith: '$'
    TargetUserName: 'ANONYMOUS LOGON'
  filter_scheduled_tasks:
    ProcessName: 'C:\Windows\System32\taskhost.exe'
  condition: selection and not (filter_system or filter_scheduled_tasks)
falsepositives:
  - Administrator using RunAs for legitimate remote management
  - Scheduled tasks configured with explicit credentials
level: medium

Conversion avec sigma-cli vers les trois SIEM principaux :

# Installation
pip install sigma-cli

# Conversion vers KQL (Microsoft Sentinel / M365 Defender)
sigma convert -t microsoft365defender rules/mimikatz_lsass.yml

# Conversion vers SPL (Splunk Enterprise Security)
sigma convert -t splunk rules/mimikatz_lsass.yml

# Conversion vers Lucene/ECS (Elastic SIEM)
sigma convert -t lucene --backend-config ecs_windows rules/mimikatz_lsass.yml

# Conversion en lot — repertoire complet
sigma convert -t microsoft365defender rules/windows/ --output kql_rules.txt

# Verification de la couverture ATT&CK
sigma check rules/windows/

KQL (Kusto Query Language) : Chasse aux Menaces dans Microsoft Sentinel

KQL est le langage de requête natif de Microsoft Sentinel. Sa force réside dans les jointures temporelles et les fenêtres d'analyse glissantes qui permettent de corréler des événements séquentiels typiques d'une chaîne d'attaque. La documentation officielle Microsoft Sentinel couvre l'ensemble des opérateurs analytiques KQL disponibles.

Corrélation KQL — Credential Dumping suivi de Mouvement Latéral :

// Detecte un dumping credentials suivi d'un mouvement lateral dans les 2 heures
let CredentialDumping = SecurityEvent
    | where TimeGenerated > ago(24h)
    | where EventID == 4656
    | where ObjectName endswith "lsass.exe"
    | where AccessMask in ("0x1010", "0x1038", "0x40")
    | project DumpTime=TimeGenerated, DumpHost=Computer, DumpUser=SubjectUserName;

let LateralMovement = SecurityEvent
    | where TimeGenerated > ago(24h)
    | where EventID == 4648
    | where LogonType == 3
    | where not (SubjectUserName endswith "$")
    | project LMTime=TimeGenerated, LMHost=Computer, LMUser=SubjectUserName,
              TargetHost=TargetServerName, TargetUser=TargetUserName;

CredentialDumping
| join kind=inner (LateralMovement) on $left.DumpHost == $right.LMHost
| where LMTime between (DumpTime .. DumpTime + 2h)
| extend TimeDelta = LMTime - DumpTime
| project DumpTime, DumpHost, DumpUser, LMTime, TargetHost, TargetUser, TimeDelta
| order by DumpTime desc

Baseline comportementale KQL — Z-score sur connexions RDP :

// Calcul du Z-score pour detecter les anomalies de connexions RDP par compte
let Lookback = 30d;
let ZThreshold = 3.0;

let BaselineStats = SecurityEvent
    | where TimeGenerated between (ago(Lookback) .. ago(1d))
    | where EventID == 4624
    | where LogonType == 10  // Remote Interactive (RDP)
    | summarize DailyCount=count() by bin(TimeGenerated, 1d), Account=TargetUserName
    | summarize AvgCount=avg(DailyCount), StdDev=stdev(DailyCount) by Account;

let TodayActivity = SecurityEvent
    | where TimeGenerated > ago(1d)
    | where EventID == 4624
    | where LogonType == 10
    | summarize TodayCount=count() by Account=TargetUserName;

TodayActivity
| join kind=inner (BaselineStats) on Account
| extend ZScore = (TodayCount - AvgCount) / (StdDev + 0.001)
| where ZScore > ZThreshold
| project Account, TodayCount, AvgCount=round(AvgCount, 1),
          StdDev=round(StdDev, 1), ZScore=round(ZScore, 2)
| sort by ZScore desc

Hunting KQL — PowerShell Beacon over DNS (T1071.004) :

// Hypothese : C2 PowerShell via requetes DNS a haute frequence vers domaine inconnu
DnsEvents
| where TimeGenerated > ago(48h)
| where SubType == "LookupQuery"
| summarize
    QueryCount=count(),
    UniqueSubdomains=dcount(Name)
    by Computer, bin(TimeGenerated, 1h),
       ParentDomain = strcat(
           tostring(split(Name, ".")[-2]), ".",
           tostring(split(Name, ".")[-1])
       )
| where QueryCount > 50 and UniqueSubdomains > 20
| join kind=inner (
    SecurityEvent
    | where EventID == 4688
    | where NewProcessName endswith "powershell.exe"
    | summarize PSCount=count() by Computer, bin(TimeGenerated, 1h)
) on Computer, TimeGenerated
| project Computer, TimeGenerated, ParentDomain, QueryCount, UniqueSubdomains, PSCount
| sort by QueryCount desc

SPL Splunk : Corrélations Avancées et Sessions Multi-Events

Le Splunk Processing Language (SPL) excelle dans la création de transactions (séquences d'événements liées) et dans les calculs statistiques avancés avec eventstats et streamstats. Son approche pipeline permet de chaîner les transformations sans limite de complexité, ce qui le rend particulièrement adapté aux corrélations comportementales longues.

SPL — Détection de Data Staging avant Exfiltration :

index=windows EventCode=4663 Object_Type=File Access_Mask=0x2
| eval hour=strftime(_time, "%H")
| eventstats avg(count) as avg_files, stdev(count) as stdev_files
  by host, Account_Name, hour
| transaction Account_Name maxspan=1h maxpause=10m
| eval z_score=(count-avg_files)/(stdev_files+0.001)
| where z_score > 3 AND count > 100
| eval risk_score=case(
    z_score > 5, "CRITICAL",
    z_score > 4, "HIGH",
    z_score > 3, "MEDIUM",
    true(), "LOW"
  )
| table _time, host, Account_Name, count, z_score, risk_score
| sort -z_score

SPL — Détection de Password Spray avec statistiques avancées :

index=windows EventCode=4625
| bucket span=15m _time
| stats
    count as failed_attempts,
    dc(WorkstationName) as source_hosts,
    dc(TargetUserName) as targeted_accounts,
    values(TargetUserName) as account_list
  by _time, IpAddress
| where failed_attempts > 20 AND targeted_accounts > 5
| eval attack_pattern=case(
    targeted_accounts > 50, "Password Spray",
    failed_attempts/targeted_accounts > 10, "Brute Force",
    true(), "Credential Stuffing"
  )
| eventstats max(failed_attempts) as peak_attempts by IpAddress
| where failed_attempts == peak_attempts
| table _time, IpAddress, failed_attempts, targeted_accounts, attack_pattern

SPL — Hunting Living off the Land Binaries (LOLBins) :

index=windows EventCode=4688
| rex field=New_Process_Name "\\(?<process_name>[^\\]+)$"
| where process_name IN (
    "certutil.exe", "bitsadmin.exe", "regsvr32.exe",
    "mshta.exe", "wscript.exe", "cscript.exe",
    "rundll32.exe", "msiexec.exe", "installutil.exe",
    "regasm.exe", "regsvcs.exe", "odbcconf.exe"
  )
| eval is_suspicious=if(match(Process_Command_Line,
    "(?i)(http|ftp|\.ps1|base64|download|encode|urlcache)"), 1, 0)
| where is_suspicious=1
| stats
    count,
    values(Process_Command_Line) as commands,
    dc(ComputerName) as affected_hosts
  by process_name, Account_Name
| sort -count
| eval lolbin_risk=if(count > 10 AND affected_hosts > 3, "HIGH", "MEDIUM")

Elasticsearch DSL : Agrégations et Détections Comportementales

L'Elastic SIEM utilise un DSL JSON basé sur Lucene avec des agrégations pipeline pour les détections comportementales, et EQL (Event Query Language) pour les séquences d'attaque. Le guide Elasticsearch DSL couvre l'ensemble des agrégations disponibles.

Requête DSL — Détection d'Impossible Travel (UEBA) :

{
  "query": {
    "bool": {
      "must": [
        { "term": { "event.category": "authentication" } },
        { "term": { "event.outcome": "success" } }
      ],
      "filter": [
        { "range": { "@timestamp": { "gte": "now-1h" } } }
      ]
    }
  },
  "aggs": {
    "by_user": {
      "terms": { "field": "user.name", "size": 1000 },
      "aggs": {
        "sessions": {
          "top_hits": {
            "size": 10,
            "_source": [
              "@timestamp",
              "source.ip",
              "source.geo.country_name",
              "source.geo.location"
            ],
            "sort": [{ "@timestamp": { "order": "asc" } }]
          }
        }
      }
    }
  }
}

EQL (Event Query Language) — Séquence d'attaque PowerShell → Network :

sequence by host.name with maxspan=30m
  [process where event.type == "start"
   and process.name == "powershell.exe"
   and process.command_line regex~ ".*(-enc|-EncodedCommand|-ec).*"]
  [process where event.type == "start"
   and process.parent.name == "powershell.exe"
   and process.name in ("cmd.exe", "net.exe", "whoami.exe", "ipconfig.exe")]
  [network where event.type == "connection"
   and process.name in ("powershell.exe", "cmd.exe")
   and not destination.ip in ("10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16")]

L'avantage d'EQL sur une requête DSL classique est la garantie d'ordre temporel des événements dans la séquence. La clause with maxspan=30m définit la fenêtre temporelle maximale entre le premier et le dernier événement de la chaîne, évitant les faux positifs liés à des coïncidences sur de longues périodes.

Le PEAK Framework : Méthodologie de Threat Hunting Hypothesis-Driven

Le PEAK Framework (Prepare, Execute, Act with Knowledge) est la méthodologie de référence pour les équipes de threat hunting matures. Contrairement au hunting réactif basé sur des alertes SIEM, PEAK part d'une hypothèse formulée à partir d'intelligence sur les menaces (CTI), de la topologie réseau et du profil de risque de l'organisation. Son adoption par des équipes comme celles de Microsoft DART et de Mandiant IR en fait le standard de facto en 2026.

Phase 1 — Prepare (Préparer l'hypothèse et les données)

• Formuler l'hypothèse : "Un attaquant ayant compromis un compte de service AD utilise PowerShell pour établir une communication C2 via des requêtes DNS vers un domaine enregistré dans les 30 derniers jours."
• Identifier les sources de données : DNS resolver logs, Sysmon Event 1 (process creation), Event 3 (network connection), Zeek DNS logs, MDE network telemetry.
• Définir les indicateurs attendus : domaines avec TTL inférieur à 60 secondes, sous-domaines alphanumériques longs (plus de 20 caractères), fréquence supérieure à 50 requêtes par heure depuis un même hôte.
• Vérifier la disponibilité des données : Sysmon est-il déployé sur 100% des endpoints ? Les logs DNS sont-ils centralisés avec une latence inférieure à 5 minutes ?

Phase 2 — Execute (Chasse active)

• Exécuter les requêtes de hunting (KQL, SPL ou DSL selon le SIEM en place)
• Itérer sur les résultats : affiner les filtres, éliminer les faux positifs connus (résolveurs internes, CDN légitimes)
• Pivoter sur les indicateurs découverts : hash de processus, adresse IP, domaine DNS, compte utilisateur impliqué
• Documenter chaque pivot dans un ticket de hunting avec timestamp, raisonnement et conclusion partielle

Phase 3 — Act with Knowledge (Agir avec la Connaissance)

• Si compromission confirmée : déclencher le playbook IR, isoler les systèmes, notifier les parties prenantes selon la matrice d'escalade
• Si hunting négatif : documenter les lacunes de visibilité (sources de logs manquantes, rétention insuffisante, agents non déployés)
• Dans tous les cas : convertir la logique de hunting en règle Sigma permanente, l'intégrer dans le SIEM avec un seuil d'alerte calibré sur les données de la chasse
• Mesurer l'impact : Mean Time to Detect (MTTD) avant et après la nouvelle règle, évolution du taux de faux positifs

Exemples d'hypothèses de hunting 2026 par TTP :

• PowerShell beacon over DNS — T1071.004 : canal C2 DNS via dnstunnel ou iodine, détectable par fréquence et longueur des sous-domaines
• Credential dumping sequence — T1003.001 : accès LSASS → net use → PsExec → mouvement latéral SMB
• Living off the land via WMI — T1047 : souscriptions WMI persistantes déclenchant des payloads encodés
• Azure AD token theft — T1528 : vol de refresh token OAuth pour accès à M365 sans credentials réutilisés

Pour une approche complémentaire combinant IA et threat hunting, consultez notre article sur les Agents IA pour la Cyber-Défense et le Threat Hunting.

Comment construire des Baselines Comportementales efficaces ?

Une baseline comportementale est la modélisation statistique du comportement normal d'un utilisateur, d'un compte de service ou d'un actif réseau sur une période de référence. Sans baseline, il est impossible de distinguer une anomalie d'une variation saisonnière ou d'un pic d'activité légitime. La méthode recommandée en 2026 combine Z-score pour les métriques volumétriques et analyse de fréquence temporelle pour les patterns d'accès horaires.

Implémentation Python — Z-score comportemental sur connexions réseau :

import pandas as pd
import numpy as np
from datetime import datetime

def compute_behavioral_baseline(events_df, entity_col, metric_col, window_days=30):
    # Calcule un Z-score pour la detection d'anomalies comportementales.
    # Args:
    #   events_df: DataFrame avec colonnes [timestamp, entity_col, metric_col]
    #   entity_col: Colonne de regroupement (ex: 'username', 'hostname')
    #   metric_col: Metrique a baseliner (ex: 'connection_count', 'bytes_out')
    #   window_days: Periode de reference pour le calcul de baseline
    # Returns:
    #   DataFrame avec z_score et severity pour les anomalies detectees

    # Agregation en totaux journaliers
    daily = events_df.groupby([
        events_df['timestamp'].dt.date,
        entity_col
    ])[metric_col].sum().reset_index()
    daily.columns = ['date', entity_col, 'daily_value']

    # Statistiques de baseline — exclure les dernieres 24h (activite en cours)
    baseline_window = daily[daily['date'] < datetime.now().date()]
    stats = baseline_window.groupby(entity_col)['daily_value'].agg(
        mean_val='mean',
        std_val='std'
    ).reset_index()

    # Valeurs du jour courant
    today = daily[daily['date'] == datetime.now().date()]

    # Fusion et calcul du Z-score
    result = today.merge(stats, on=entity_col, how='left')
    result['z_score'] = (
        (result['daily_value'] - result['mean_val']) /
        (result['std_val'] + 1e-6)  # evite division par zero
    )

    # Categorisation de la severite
    result['severity'] = np.select(
        [result['z_score'] > 5, result['z_score'] > 4, result['z_score'] > 3],
        ['CRITICAL', 'HIGH', 'MEDIUM'],
        default='NORMAL'
    )

    return (
        result[result['z_score'] > 3.0]
        .sort_values('z_score', ascending=False)
        [[entity_col, 'daily_value', 'mean_val', 'std_val', 'z_score', 'severity']]
    )

Les pièges à éviter : les baselines calculées sur des périodes incluant des incidents passés sont contaminées par les valeurs aberrantes de l'attaque. Il faut exclure les périodes d'alerte connues du calcul. De même, les comptes de service ont des patterns radicalement différents des comptes utilisateurs — construire des baselines par type d'entité, pas globalement. Un compte de service qui se connecte à 03h00 toutes les nuits pour des sauvegardes ne doit pas déclencher une alerte off-hours.

Pour aller plus loin sur la détection comportementale dans les SIEM, consultez notre guide sur la Détection de Menaces par IA : SIEM Augmenté et UEBA.

UEBA : Détection d'Anomalies Utilisateur et Entité

L'UEBA (User and Entity Behavior Analytics) étend les baselines comportementales à l'ensemble des entités du SI : utilisateurs, comptes de service, hôtes, applications et ressources cloud. Les trois cas d'usage UEBA les plus efficaces pour détecter les comptes compromis avant l'exfiltration sont les suivants.

1. Impossible Travel

Un utilisateur s'authentifie depuis Paris à 09h00 et depuis São Paulo à 09h45. La vitesse de déplacement impliquée (environ 9 000 km/h) est physiquement impossible. L'algorithme calcule la distance géodésique entre deux authentifications successives réussies et la divise par le delta temporel. Si la vitesse calculée dépasse 900 km/h (vitesse maximale d'un avion commercial), une alerte "impossible travel" est déclenchée avec un score de risque proportionnel à la distance et à l'écart temporel.

2. Off-Hours Privileged Access

Un compte admin Active Directory qui s'authentifie à 03h17 un dimanche matin sur un serveur de fichiers RH est statistiquement anormal — sauf si ce compte dispose d'un historique documenté d'accès nocturnes pour des maintenances planifiées. L'UEBA calcule une distribution horaire d'activité par compte sur 90 jours. L'accès hors de la plage P5-P95 déclenche une alerte contextuelle ("premier accès nocturne de ce compte en 90 jours"), enrichie du nom de la ressource accédée et de la criticité de l'actif.

3. Data Staging avant Exfiltration

Avant une exfiltration, un attaquant agrège typiquement les fichiers dans un répertoire temporaire (C:\Temp, %APPDATA%, dossiers partagés réseau). La signature comportementale : augmentation soudaine des opérations de lecture de fichiers (Event 4663) combinée à des écritures dans des répertoires temporaires, dans une fenêtre de 15 à 60 minutes. La corrélation avec un accès réseau sortant vers un volume supérieur à 50 MB dans l'heure suivante confirme le staging avec un niveau de confiance élevé.

Pour approfondir le threat hunting spécifiquement sur les plateformes Microsoft, consultez notre guide Threat Hunting Microsoft 365 Sentinel.

Comment intégrer MITRE ATT&CK dans vos règles Sigma ?

Le framework MITRE ATT&CK classe les techniques d'attaque par tactique (TA) et technique (T). L'intégration des tags ATT&CK dans vos règles Sigma permet de mesurer automatiquement la couverture de détection : quel pourcentage des techniques ATT&CK pertinentes pour votre secteur sont couvertes par des règles actives dans votre SIEM ?

La convention de tagging Sigma suit le format attack.tXXXX.YYY pour les sous-techniques. Les techniques les plus courantes à couvrir en priorité pour un SOC entreprise :

• attack.t1059.001 — PowerShell (Execution) : présent dans la grande majorité des intrusions Windows avancées
• attack.t1003.001 — OS Credential Dumping: LSASS Memory (Mimikatz, ProcDump, Comsvcs.dll)
• attack.t1021.002 — Remote Services: SMB/Windows Admin Shares (mouvement latéral PsExec)
• attack.t1071.004 — Application Layer Protocol: DNS (canal C2 furtif via DNS tunneling)
• attack.t1078.002 — Valid Accounts: Domain Accounts (comptes légitimes compromis)
• attack.t1486 — Data Encrypted for Impact (Ransomware — chiffrement de masse détecté trop tard)

Pour mesurer votre couverture ATT&CK, exportez la liste des tags de toutes vos règles Sigma actives et importez-les dans ATT&CK Navigator. Un SOC mature vise une couverture supérieure à 60% des sous-techniques ATT&CK Enterprise les plus courantes dans son secteur. Les lacunes de couverture identifiées via ATT&CK Navigator deviennent les priorités de la prochaine campagne de hunting PEAK.

Cette approche systématique alimente directement les exercices de Purple Team : l'équipe rouge simule les techniques non couvertes, l'équipe bleue crée les règles Sigma manquantes, et le cycle vertueux améliore la posture de détection de façon mesurable et traçable. Le lien avec notre article sur le Top 10 des Attaques Active Directory illustre les techniques ATT&CK les plus fréquentes dans les compromissions AD, qui doivent figurer en tête de liste des règles Sigma prioritaires.

Corrélations Multi-Sources : Windows + EDR + Network + Cloud

La chaîne d'attaque moderne traverse systématiquement plusieurs domaines de télémétrie. Une règle de corrélation efficace joint des événements provenant d'au moins trois sources distinctes. La normalisation vers un schéma commun est le prérequis indispensable pour automatiser cette corrélation à l'échelle.

Pipeline de normalisation ECS vers schéma commun :

# Mapping ECS pour normalisation multi-source
# Windows Security Event 4624 vers champs ECS
windows_event_4624:
  "@timestamp": "TimeCreated.SystemTime"
  "event.category": ["authentication"]
  "event.type": ["start"]
  "event.outcome": "success"
  "user.name": "TargetUserName"
  "user.domain": "TargetDomainName"
  "source.ip": "IpAddress"
  "host.name": "Computer"
  "winlog.logon.type": "LogonType"

# CrowdStrike Falcon Process vers champs ECS
cs_falcon_process:
  "@timestamp": "timestamp"
  "event.category": ["process"]
  "event.type": ["start"]
  "process.name": "FileName"
  "process.command_line": "CommandLine"
  "process.parent.name": "ParentBaseFileName"
  "process.pid": "TargetProcessId"
  "user.name": "UserName"
  "host.name": "ComputerName"

# Zeek DNS log vers champs ECS
zeek_dns:
  "@timestamp": "ts"
  "event.category": ["network"]
  "dns.question.name": "query"
  "dns.response_code": "rcode_name"
  "dns.answers": "answers"
  "network.protocol": "proto"
  "source.ip": "id.orig_h"
  "destination.ip": "id.resp_h"

Une fois normalisés en ECS, ces événements se corrèlent sans transformation supplémentaire dans Elastic SIEM, ou s'exportent vers Sentinel via l'Azure Monitor Agent avec le mapping ECS vers ASIM (Azure Sentinel Information Model). L'OCSF (Open Cybersecurity Schema Framework), soutenu par AWS, Splunk et IBM, émerge comme standard alternatif pour les architectures multi-cloud où plusieurs SIEM coexistent.

Tableau Comparatif SIEM 2026

Questions fréquentes

Quelle est la différence entre une règle Sigma et une règle YARA ?

YARA détecte des patterns dans des fichiers (binaires, documents, mémoire) — c'est un outil de forensics et d'analyse de malware statique ou en mémoire. Sigma détecte des événements dans des logs structurés (Windows Event Log, Sysmon, logs réseau). Les deux sont complémentaires : YARA à la couche endpoint pour identifier les payloads malveillants, Sigma à la couche SIEM pour détecter les comportements et les TTPs. Un flux de threat hunting mature combine les deux, avec les TTPs décrits en Sigma et les IOCs techniques en YARA.

Comment calibrer le seuil d'un Z-score pour éviter la fatigue d'alerte ?

Le Z-score de 3,0 correspond théoriquement à 99,7% de la distribution normale. En pratique, commencez à Z=4,0 les deux premières semaines pour observer le volume d'alertes, puis descendez progressivement. Associez systématiquement le Z-score à un contexte supplémentaire (heure de la journée, type de compte, criticité de l'actif cible) pour enrichir l'alerte et réduire le temps de triage de l'analyste SOC. L'objectif est de ne pas dépasser une dizaine d'alertes comportementales par analyste et par jour.

Le PEAK Framework remplace-t-il les alertes SIEM classiques ?

Non — PEAK est complémentaire aux règles de détection automatiques. Les alertes SIEM couvrent les TTPs connus avec des règles permanentes déclenchées en temps réel. PEAK couvre les TTPs inconnus ou émergents via des campagnes de hunting proactives, typiquement déclenchées par un nouveau rapport CTI, une alerte CISA, ou une anomalie dans les métriques SOC (augmentation du MTTD). Les résultats d'une campagne PEAK positive alimentent directement de nouvelles règles SIEM permanentes.

Quelle rétention de logs est nécessaire pour les corrélations temporelles longues ?

Pour détecter les techniques "slow and low" (password spray sur 72h, beaconing toutes les 4h), une rétention de 90 jours de logs hot est le minimum opérationnel. Les corrélations ATT&CK pour la persistance (T1053 scheduled tasks, T1547 run keys) nécessitent parfois 180 jours pour détecter des backdoors dormants activés après une longue période. Architecturez avec un tier chaud (30 jours, indexé, requêtable en secondes) et un tier froid (90 à 365 jours, compressé, requêtable en quelques heures) pour optimiser les coûts de stockage SIEM sans sacrifier la capacité d'investigation.

Comment mesurer l'efficacité d'un programme de threat hunting ?

Quatre métriques clés permettent de piloter un programme de hunting : (1) le Hunt Hit Rate — pourcentage de campagnes ayant trouvé au moins une anomalie réelle (cible : 15 à 25%) ; (2) la réduction du Dwell Time — temps moyen de présence d'un attaquant avant détection, avant et après l'activation du programme ; (3) le Rule Conversion Rate — pourcentage de chasses converties en règles Sigma permanentes dans le SIEM ; (4) le delta de couverture ATT&CK — progression de la couverture des techniques sur 6 mois. Un programme mature améliore le dwell time de 30% en 12 mois d'opération continue.