Détection d'intrusion : les bases 2025 (IDS, EDR, SIEM)

La détection d'intrusion est la capacité d'une organisation à identifier une activité malveillante (exploitation, mouvement latéral, exfiltration, C2, abus d'identité) sur ses systèmes et réseaux, suffisamment tôt pour permettre containment avant impact métier significatif. Elle repose en 2025 sur 4 familles d'outils complémentaires : NIDS (Network IDS : Suricata, Snort, Zeek) au niveau réseau, HIDS / EDR (Host IDS / Endpoint Detection & Response : CrowdStrike Falcon, SentinelOne, Microsoft Defender for Endpoint, Wazuh) au niveau endpoint, SIEM / XDR (Splunk, Microsoft Sentinel, Elastic Security, Datadog Cloud SIEM) pour corrélation cross-source, UEBA / NDR (User & Entity Behavior Analytics / Network Detection & Response) pour anomalies comportementales. Les 3 approches de détection sont : signature-based (patterns connus, efficace pour exploits CVE et malware catalogué), anomaly-based (déviation d'une baseline statistique, efficace pour 0-day), behavioral (chaînes de TTPs MITRE ATT&CK, efficace pour APT sophistiqués). Les KPIs structurants sont MTTD (Mean Time To Detect, objectif < 24h critique), MTTR (Mean Time To Respond, < 1-4h), FP rate par règle (< 5 % matures), couverture MITRE ATT&CK (50-70 % mature). Cet article détaille les 4 familles d'outils avec positionnement technique et exemples concrets, les 3 approches de détection, le placement réseau (choke points, mirror/SPAN, TAP), l'écriture de règles Sigma et ATT&CK-mappées, les anti-patterns (alert fatigue, règles copiées-collées, logs sans rétention, pas de tuning), et le pattern stack de référence 2025 pour une ETI française.

1. Qu'est-ce que la détection d'intrusion

La détection d'intrusion répond à une question simple mais difficile : « sait-on repérer une compromission en cours ? ». Les rapports d'incident 2023-2024 (Mandiant M-Trends 2024, Verizon DBIR 2024, CrowdStrike Global Threat Report 2024) convergent sur trois constats :

• Dwell time médian global : ~10 jours en 2024 (en baisse depuis 205 jours en 2014), mais queue longue à 100-300+ jours sur les campagnes APT ciblées.
• 67 % des attaques 2024 incluent une phase de mouvement latéral interne — invisible sans détection inter-segments.
• 75 % des attaques 2024 n'utilisent pas de malware traditionnel (CrowdStrike 2024) — reliance sur LOLBins (Living-Off-the-Land Binaries), identity-based attacks, cloud abuse.

Un programme de détection mature couvre les 5 phases du Cyber Kill Chain Lockheed Martin ou des 14 tactiques MITRE ATT&CK : Reconnaissance, Resource Development, Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, C2, Exfiltration, Impact.

2. Les 4 familles d'outils de détection

2.1 NIDS / NDR (Network Intrusion Detection / Network Detection & Response)

Observation passive ou semi-passive du traffic réseau. Suricata est le leader open-source 2025 :

# Installation Suricata (Ubuntu 22.04+)
sudo add-apt-repository ppa:oisf/suricata-stable
sudo apt update && sudo apt install suricata suricata-update
 
# Mise à jour des règles (Emerging Threats Open + ruleset gratuit)
sudo suricata-update
 
# Run en mode IDS sur interface eth1 (mirror port)
sudo suricata -i eth1 --init-errors-fatal
 
# Output EVE JSON pipeline ELK
# /etc/suricata/suricata.yaml : outputs → eve-log → types : alert, http, tls, dns, flow
tail -f /var/log/suricata/eve.json | jq 'select(.event_type == "alert")'

Zeek joue un rôle distinct : au lieu de matching signatures, il produit des logs protocolaires enrichis (conn.log, http.log, ssl.log, files.log) qui alimentent les SIEM avec du contexte structuré. Souvent déployé en complément de Suricata.

2.2 EDR / HIDS (Endpoint Detection & Response)

Agent installé sur chaque endpoint, collecte télémétrie riche (processus, arguments, DLL loaded, fichiers modifiés, connexions réseau, clés registry Windows) et applique :

• Détection via règles comportementales (ex: lsass.exe accédé par un process non-autorisé → T1003.001).
• Response : quarantaine de fichier, tuer un process, isoler la machine du réseau.

2.3 SIEM / XDR (Security Information & Event Management)

Centralisation des logs multi-sources avec corrélation inter-événements et détection cross-layer. Exemple de détection impossible sans SIEM : connexion VPN depuis pays X + accès à RH depuis ce compte + export CSV massif dans les 30 minutes = probable exfiltration.

2.4 UEBA / NDR — couche 4 (émergente)

User & Entity Behavior Analytics et Network Detection & Response sont les surcouches ML/IA sur les logs SIEM + traffic NIDS. Détectent des anomalies impossibles à exprimer en règles déterministes (ex: user qui se connecte aux heures inhabituelles à une ressource jamais accédée avant).

3. Les 3 approches de détection

3.1 Signature-based

Match de patterns connus sur le traffic ou les logs. Efficace sur exploits CVE catalogués, malware fingerprintable, C2 default profiles.

# Règle Suricata exemple — détection exploit CVE-2021-44228 Log4Shell
alert http any any -> $HOME_NET any (
    msg:"ET EXPLOIT Log4Shell Exploitation Attempt CVE-2021-44228";
    content:"${jndi:";
    http.uri;
    flow:established,to_server;
    reference:cve,2021-44228;
    classtype:web-application-attack;
    sid:2034647;
    rev:3;
)

Limite : totalement aveugle aux 0-days et aux variantes qui échappent aux regex.

3.2 Anomaly-based

Baseline statistique du comportement « normal », alerte sur déviation. Efficace sur 0-days et comportements nouveaux, mais taux de faux positifs élevé (5-25 % typique avant tuning).

Exemple : utilisateur qui télécharge typiquement 50 MB/jour depuis Google Drive, soudain 2 GB. L'algo lève une alerte, mais il peut s'agir d'une migration légitime.

3.3 Behavioral / TTP-based (ATT&CK mapping)

Détection de chaînes de TTPs MITRE ATT&CK plutôt que de signatures individuelles. Efficace sur APT sophistiqués, hautement résistant aux tentatives d'évasion.

Exemple de chaîne détectée : user qui exécute whoami + net user /domain + net group "Domain Admins" + nltest /dclist: en moins de 10 minutes = reconnaissance AD interne typique.

4. Placement réseau : choke points, mirror, TAP

4.1 Choke points stratégiques

Un NIDS n'est utile que s'il voit le traffic pertinent. Positionnement :

4.2 Mirror / SPAN vs TAP

• SPAN / Mirror port (Switched Port Analyzer) — configuration logicielle sur switch/router qui duplique le traffic d'un port vers un autre. Simple à configurer, mais sujet à congestion : si le SPAN port sature, le switch drop silencieusement les paquets mirroir.
• Network TAP (Test Access Point) — appareil physique dédié inserted inline. Aucune perte, mais coût hardware (500-5 000 $/TAP selon débit) et maintenance physique.

Règle pratique 2025 : SPAN pour volumes < 5 Gbps sustained, TAP pour production critique ou débits élevés.

5. Outils open-source dominants 2025

5.1 Suricata + Zeek combo

Pattern classique : Suricata pour alerte signature, Zeek pour logs protocolaires enrichis. Tous deux envoient vers un SIEM.

Architecture typique NIDS open-source 2025
───────────────────────────────────────────
Traffic réseau
      │  (SPAN ou TAP)
      ▼
Suricata (signature + lua scripts)   ─► alertes (EVE JSON)
      │
      ▼
Zeek (protocol analysis)             ─► logs enrichis (conn/http/ssl/dns)
      │
      ▼
Filebeat / Vector / Fluent Bit       ─► shipper vers SIEM
      │
      ▼
SIEM (Elastic / Splunk / Sentinel)   ─► corrélation + alerting
      │
      ▼
SOAR (TheHive / Cortex / Tines)      ─► réponse automatisée

5.2 Wazuh — HIDS/SIEM open-source intégré

Wazuh combine agent HIDS (Linux, Windows, macOS) + serveur de centralisation + stack ELK intégrée. Point fort : déploiement rapide pour un SOC de démarrage.

# ossec.conf exemple Wazuh agent Linux — File Integrity Monitoring
<syscheck>
  <frequency>43200</frequency>  <!-- toutes les 12h -->
  <directories realtime="yes">/etc</directories>
  <directories realtime="yes">/bin,/sbin,/usr/bin,/usr/sbin</directories>
  <directories check_all="yes" report_changes="yes">/var/log</directories>
  <ignore>/etc/mtab</ignore>
  <ignore>/var/log/wazuh/</ignore>
  <nodiff>/etc/ssl/private</nodiff>  <!-- détecte modif mais n'exfiltre pas le contenu -->
</syscheck>
 
<!-- Détection attaques réseau -->
<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>5710,5711,5712,5760</rules_id>  <!-- SSH brute force, authentication failures -->
  <timeout>600</timeout>
</active-response>

5.3 Falco — détection runtime pour Kubernetes / Linux

Falco (CNCF project, ~7 000 stars GitHub 2024) utilise eBPF pour monitorer les syscalls Linux et Kubernetes, détecte les comportements anormaux (container escape, privilege escalation, cryptomining, etc.).

# Règle Falco — détection exécution de shell dans un container
- rule: Launch Shell in Container
  desc: Detect when an interactive shell starts inside a container
  condition: >
    spawned_process and
    container and
    shell_procs and
    proc.tty != 0 and
    container_entrypoint
  output: >
    Shell spawned in container (user=%user.name container_id=%container.id
    shell=%proc.name parent=%proc.pname cmdline=%proc.cmdline)
  priority: NOTICE
  tags: [container, shell, mitre_execution]

Cross-reference avec Sécurité serverless pour la détection runtime sur fonctions Lambda et avec Secrets management cloud pour la corrélation accès secrets.

6. Detection engineering : écrire une bonne règle

6.1 Format Sigma — règles portables

Sigma (github.com/SigmaHQ/sigma, licence DRL 1.1) est le format standard pour écrire des règles de détection portables, convertibles vers SPL Splunk, KQL Sentinel, Elastic EQL, Panther, Chronicle, etc.

# Exemple Sigma — détection dump LSASS via procdump
title: Procdump Execution against LSASS
id: 5afee48e-67dd-4e03-a783-f74259dcf998
status: stable
description: Detects execution of procdump against lsass.exe
references:
  - https://attack.mitre.org/techniques/T1003/001/
author: Florian Roth
date: 2019/12/11
tags:
  - attack.credential_access
  - attack.t1003.001
logsource:
  category: process_creation
  product: windows
detection:
  selection_procdump:
    Image|endswith:
      - '\procdump.exe'
      - '\procdump64.exe'
  selection_lsass:
    CommandLine|contains:
      - 'lsass'
  condition: selection_procdump and selection_lsass
falsepositives:
  - Legitimate system administration
  - Some security products using procdump for forensics
level: high

6.2 Démarche ATT&CK-driven

Processus de création d'une règle :

1. Sélectionner la technique ATT&CK à couvrir (ex: T1053.005 Scheduled Task/Job: Scheduled Task).
2. Identifier les data sources (Process Creation, Scheduled Task, Windows Event 4698, Sysmon Event 13).
3. Rechercher les Atomic Red Team tests correspondants (github.com/redcanaryco/atomic-red-team) pour tests reproductibles.
4. Écrire la règle Sigma ou SIEM-native.
5. Tester — exécuter l'Atomic test, vérifier l'alerte.
6. Tuner — exécuter en environnement prod pendant 7-14 jours, identifier et whitelister les faux positifs.
7. Mapper — documenter la règle dans la matrice ATT&CK de l'organisation.

7. KPIs et métriques du programme détection

7.1 Les 6 KPIs structurants

7.2 Outils de mesure

• DeTT&CT (github.com/rabobank-cdc/DeTT&CT) — cartographie coverage ATT&CK vs règles déployées.
• Atomic Red Team (redcanaryco/atomic-red-team) — tests adversariaux pour valider chaque règle.
• Mordor (hunters-forge/mordor) — datasets labélisés pour tester sans exécuter en prod.
• Caldera (mitre/caldera) — automation de tests ATT&CK pour coverage continue.

8. Les 8 anti-patterns à éviter

1. Alert fatigue — des centaines d'alertes/jour non-actionnables. Analyste ignore, manque la vraie.
2. Règles copiées sans tuning — import des 3 000 règles Sigma sans validation = coverage nominale, efficacité réelle faible.
3. Logs sans rétention adequate — investigation post-incident impossible. Cible : 90 jours minimum pour logs critiques, 1 an recommandé.
4. Pas de test des règles — Atomic Red Team / Caldera non utilisés. Personne ne sait quelles règles fonctionnent vraiment.
5. Couverture centrée sur endpoints — EDR partout, rien au réseau interne. Mouvement latéral inter-segments invisible.
6. Pas de corrélation identity — login Azure AD + action AWS + action on-prem traités en silos, pas de détection de compromission d'identité cross-environnement.
7. SOC en mode réactif seul — ticket puis tickets, jamais de threat hunting proactif. 40-50 % des compromissions détectées via chasse proactive vs alerting (Mandiant 2024).
8. Metrics qui masquent les problèmes — MTTD excellent mais seulement parce que les vraies attaques ne sont pas détectées (hors numerateur). Traquer aussi le dwell time sur incidents confirmés post-mortem.

9. Stack de référence détection 2025 — ETI française 500-2000 personnes

Stack détection ETI 500-2000 pers, budget 300-600 k€/an
──────────────────────────────────────────────────────────
 
Endpoint     ─► EDR commercial (CrowdStrike / SentinelOne / MDE)
                 - tous postes bureautique + serveurs
                 - remediation automatique L1
                 - coût: 30-60 €/endpoint/an
 
Network      ─► NIDS open-source (Suricata + Zeek)
                 - choke points DMZ + core + Internet egress
                 - alertes EVE JSON vers SIEM
                 - coût: 10-30 k€/an ingénierie + hardware TAP
 
Cloud        ─► Natif : CloudTrail / Activity Log / Cloud Audit
                 + CSPM (Wiz / Prowler) pour posture
                 + runtime (Falco sur K8s)
 
SIEM         ─► Commercial scale-up : Elastic Security ou Sentinel
                 + corrélation multi-sources
                 + détection engineering 1-2 ETP dédiés
                 - coût: 80-200 k€/an
 
SOAR         ─► Commercial (XSOAR / Tines / Swimlane)
                 - automation réponse L1
                 - runbooks versionnés Git
                 - coût: 30-80 k€/an
 
MDR / SOC    ─► Externalisation partielle (nuit + weekend)
                 OR SOC interne 24/7 (10-15 ETP minimum)
                 - coût: 150-500 k€/an selon modèle
 
Threat hunt  ─► 1 ETP dédié threat hunting + CTI
                 - proactif, non-alerting
                 - coût: 80-120 k€/an (salaire + outillage)

Pour le panorama métiers SOC / détection, voir Qu'est-ce qu'un analyste SOC, Qu'est-ce qu'un forensic analyst, Qu'est-ce qu'un analyste CTI, et pour le volet offensif complémentaire Red Team vs Blue Team, Qu'est-ce qu'une purple team.

Points clés à retenir

• Définition : capacité à identifier l'activité malveillante sur systèmes et réseaux avant impact métier.
• 4 familles d'outils : NIDS/NDR (Suricata, Zeek, Darktrace), HIDS/EDR (CrowdStrike, SentinelOne, Wazuh), SIEM/XDR (Splunk, Sentinel, Elastic), UEBA/NDR (Exabeam, Securonix).
• 3 approches : signature (CVE, malware connu), anomaly (baseline, 0-day), behavioral (chaînes TTPs ATT&CK).
• Placement réseau : choke points DMZ + core + egress + service mesh, SPAN < 5 Gbps sinon TAP.
• Detection engineering ATT&CK-driven : Sigma rules, Atomic Red Team pour tests, DeTT&CT pour coverage mapping.
• 6 KPIs : MTTD < 24h critique, MTTR < 1-4h, FP rate < 5 % matures, Coverage ATT&CK 50-70 % mature.
• 8 anti-patterns : alert fatigue (64 % du temps analyste sur FP), règles copiées sans tuning, pas de threat hunting proactif.
• Stack ETI 2025 : EDR + NIDS OSS + SIEM commercial + SOAR + MDR ou SOC 24/7 + 1 ETP threat hunting = 300-600 k€/an.

Pour comprendre pourquoi la détection seule ne suffit pas et doit se combiner à d'autres couches (pentest validation, DevSecOps shift-left), voir Pourquoi le pentest ne suffit pas. Pour les vulnérabilités applicatives que les règles doivent détecter côté application, Principes de secure coding.