Les phases de la réponse à l’incident : du confinement à la remédiation

📍 Article de référence : Réponse aux incidents et analyse forensique numérique (DFIR) : guide complet 2025
Cet article est le tutoriel opérationnel des phases IR. Pour la vue d’ensemble complète du DFIR, commencez par le guide de référence.

Un incident de sécurité confirmé génère une pression intense : équipes en alerte, direction en attente de réponses, systèmes potentiellement arrêtés, clients qui posent des questions. Dans cet environnement de stress, la qualité de la réponse dépend presque entièrement de la rigueur de la méthodologie appliquée. Les organisations qui improvisent prennent des décisions qui détruisent des preuves, laissent l’attaquant en place, ou restaurent des systèmes encore compromis.

Le modèle PICERL du SANS Institute — Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned — est la structure opérationnelle la plus utilisée dans les CSIRT professionnels. Ce tutoriel vous guide phase par phase, avec les actions concrètes, les outils, les critères de validation et les points de contrôle qui permettent de progresser méthodiquement même sous pression.

Prérequis

• Compréhension des bases réseau (TCP/IP, DNS, NAT)
• Accès administrateur ou CISO sur les systèmes concernés
• Outils préinstallés : FTK Imager ou dc3dd, Wireshark, un accès SIEM
• Niveau attendu : intermédiaire à avancé
• Temps de lecture : 25-30 minutes

Phase 1 — Préparation : construire la capacité avant la crise

La préparation est la seule phase qui se déroule avant tout incident. C’est aussi la plus déterminante : une organisation bien préparée réduira son MTTR (Mean Time to Respond) de plusieurs jours. Le SANS Institute documente dans son Incident Handler’s Handbook (disponible sur sans.org) que les organisations avec un plan IR formalisé et testé régulièrement contiennent les incidents en moyenne deux fois plus vite que celles qui réagissent ad hoc.

La préparation se structure autour de cinq livrables essentiels :

1. Le Plan de Réponse aux Incidents (IRP) est le document maître qui définit : les critères de déclenchement (qu’est-ce qui constitue un incident ? quand escalader ?), les rôles et responsabilités (CISO, équipe SOC, DPO, communication, juridique), la matrice d’escalade, les contacts externes (CERT national, prestataire forensique, assureur cyber, avocat spécialisé), et les critères de clôture d’un incident.

2. Les playbooks par type d’incident détaillent les actions spécifiques pour chaque scénario : ransomware, phishing réussi, compromission de compte à privilèges, DDoS, fuite de données, attaque supply chain, insider threat. Un playbook ransomware inclura par exemple : isoler immédiatement les systèmes du réseau, ne pas payer la rançon avant analyse forensique complète, notifier le CERT, conserver les notes de rançon comme pièces à conviction, identifier le variant de ransomware via les plateformes de déchiffrement (NoMoreRansom.org).

3. Les exercices de simulation (tabletop exercises) sont des réunions structurées où les participants jouent un scénario d’incident pour tester le plan sans impact réel. Le SANS Institute recommande a minima deux exercices par an. Les purple team exercises ajoutent une dimension technique en simulant des attaques réelles.

4. La préparation technique comprend : la centralisation des logs dans un SIEM (Wazuh, Splunk, Elastic Security), la mise en place d’un EDR sur les endpoints, la configuration des alertes de détection, et la disponibilité des outils forensiques sur une station de travail dédiée et isolée.

5. Les accords et communications préalables : contrat cadre avec un prestataire forensique pour une intervention d’urgence sous 4 heures, contrat avec l’assureur cyber incluant une hotline IR, enregistrement auprès du CERT national (CERT-FR pour la France, CMCERT pour le Maroc, CI-CERT pour la Côte d’Ivoire).

Phase 2 — Identification : détecter, qualifier et trier l’incident

L’identification est la phase où une anomalie détectée devient un incident qualifié. Cette distinction est fondamentale : tous les événements de sécurité ne sont pas des incidents — il faut trier, qualifier, et décider du niveau de réponse approprié. Un faux positif traité comme un incident majeur mobilise des ressources inutilement ; un vrai incident sous-estimé laisse l’attaquant progresser.

La détection peut être proactive (alerte SIEM, EDR, IDS) ou réactive (signalement utilisateur, notification externe d’un CERT, client alertant d’une fuite). Dès la réception d’une alerte, l’analyste effectue un triage en trois étapes :

Première étape : vérifier la véracité. L’alerte est-elle un faux positif ? Une alerte SIEM sur une connexion inhabituelle peut provenir d’un test de sécurité légitime, d’un outil de monitoring, ou d’une vraie compromission. La vérification s’appuie sur la corrélation avec d’autres sources : logs firewall, logs EDR, comportement utilisateur dans l’AD/LDAP.

Deuxième étape : qualifier l’incident. Si l’alerte est confirmée, définir sa nature (type d’attaque présumé selon MITRE ATT&CK), son périmètre (combien de systèmes impliqués ?), son impact potentiel (données exposées ? systèmes critiques touchés ?), et sa sévérité. Le NIST SP 800-61 propose une classification en quatre niveaux : Bas, Moyen, Élevé, Critique.

Troisième étape : déclencher la réponse appropriée. Un incident critique (ransomware actif, exfiltration en cours de données PII, accès à des systèmes SCADA) déclenche le plan IR complet avec notification immédiate du CISO et activation de l’équipe CSIRT. Un incident moyen (compte utilisateur compromis sans élévation de privilèges) peut être géré par l’équipe SOC standard.

Les KPIs clés de cette phase sont le MTTD (Mean Time to Detect — durée entre la compromission réelle et sa détection) et le MTTQ (Mean Time to Qualify). Un MTTD élevé indique des lacunes dans la couverture de détection. Selon le Mandiant M-Trends 2024 Report, le MTTD médian global est désormais de 10 jours, contre 21 jours en 2023 — signe d’une maturité croissante des capacités de détection.

Phase 3 — Confinement : stopper la propagation sans détruire les preuves

Le confinement est souvent la phase la plus délicate, car elle exige de prendre des décisions rapides sous pression tout en préservant les preuves. Le NIST SP 800-61 distingue deux niveaux de confinement, à appliquer séquentiellement :

Le confinement court terme (short-term containment) vise à arrêter immédiatement la propagation de la menace. Les actions typiques incluent : isolation réseau du ou des systèmes compromis (désactivation du port switch correspondant, application d’une politique de pare-feu bloquant tout le trafic entrant et sortant, désactivation du Wi-Fi), désactivation des comptes compromis ou suspects dans l’Active Directory, blocage des IoCs (IPs C2, domaines malveillants) au niveau du pare-feu périmétrique et du proxy. Ces actions doivent être menées sans éteindre les systèmes — l’isolation réseau suffit à stopper la propagation tout en préservant la possibilité de capture forensique.

Avant toute action de confinement, si les ressources le permettent, déclencher la collecte forensique live :

# Sur Windows : capturer la RAM avec WinPmem (disponible sur GitHub Velocidex/WinPmem)
winpmem_mini_x64.exe /path/to/evidence/memory_HOSTNAME_DATE.raw

# Vérifier l'intégrité du dump capturé
sha256sum memory_HOSTNAME_DATE.raw | tee memory_HOSTNAME_DATE.raw.sha256

# Capturer l'état réseau AVANT isolation
netstat -ano > netstat_HOSTNAME_DATE.txt
arp -a > arp_HOSTNAME_DATE.txt
ipconfig /all > ipconfig_HOSTNAME_DATE.txt

Ces trois commandes capturent respectivement la mémoire complète du système, les connexions réseau actives (avec PIDs associés), le cache ARP (permettant d’identifier les machines voisines avec lesquelles le système compromis communiquait), et la configuration réseau complète. Elles doivent être exécutées dans cet ordre, dans les premières minutes suivant la confirmation de l’incident, avant toute action de confinement réseau.

Le confinement long terme (long-term containment) s’applique lorsque l’éradication complète immédiate est impossible (systèmes critiques ne pouvant être mis hors ligne, investigation forensique nécessitant plusieurs jours). Il consiste à maintenir les systèmes en production avec des mesures de surveillance renforcées, tout en planifiant l’éradication : patches d’urgence appliqués, mots de passe des comptes compromis réinitialisés, backdoors identifiées mais maintenues surveillées pour identifier l’étendue complète de la compromission.

Phase 4 — Éradication : éliminer la cause racine, pas seulement les symptômes

L’éradication est la phase que les équipes non spécialisées escamotent le plus souvent — avec des conséquences désastreuses. Supprimer le fichier malveillant détecté par l’antivirus sans identifier comment il est arrivé là, ni quelles autres backdoors ont été déposées, ni quels autres systèmes ont été compromis, conduit inévitablement à une re-compromission en quelques jours. L’éradication n’est pas terminée tant que la cause racine n’est pas identifiée et résolue.

L’éradication se déroule en plusieurs étapes séquentielles :

Étape 1 : Identification complète de la cause racine. Comment l’attaquant est-il entré ? Exploitation d’une vulnérabilité CVE connue non patchée ? Phishing réussi avec capture d’identifiants ? Credential stuffing sur un VPN sans MFA ? Compromission supply chain d’un outil tiers ? Cette analyse, menée sur les artefacts forensiques collectés, est la condition sine qua non d’une éradication durable.

Étape 2 : Identification de tous les systèmes compromis. À partir du « patient zéro » (le premier système compromis), l’analyste trace les mouvements latéraux de l’attaquant via les logs d’authentification (EVTX Event ID 4624/4625/4648 sur Windows pour les connexions réussies/échouées/via credentials explicites), les logs SMB, les connexions RDP. Chaque système contacté depuis le patient zéro doit être considéré comme potentiellement compromis jusqu’à preuve du contraire.

# Sur Windows : rechercher les connexions réseau établies depuis un système
# (à exécuter AVANT le confinement réseau ou sur le dump forensique)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} |
  Where-Object { $_.Properties[8].Value -eq 3 } |  # Type 3 = Network logon
  Select-Object TimeCreated, @{N='User';E={$_.Properties[5].Value}},
    @{N='Source';E={$_.Properties[18].Value}} |
  Sort-Object TimeCreated -Descending |
  Select-Object -First 50 | Format-Table -AutoSize

Cette commande PowerShell interroge les logs de sécurité Windows pour lister les connexions réseau (logon type 3) récentes avec l’utilisateur concerné et l’IP source. Elle permet de retracer rapidement les mouvements latéraux depuis le système compromis. Remplacez -First 50 par une plage temporelle (-FilterHashtable @{...; StartTime='2026-05-01'}) pour cibler la période d’intérêt.

Étape 3 : Suppression de tous les artefacts malveillants. Cela comprend : les malwares (fichiers, services Windows, tâches planifiées, clés de registre Run/RunOnce), les backdoors (web shells dans les répertoires web, tunnels SSH persistants, comptes locaux créés par l’attaquant), les modifications des configurations de sécurité (règles de pare-feu créées, politiques d’audit désactivées), et les données exfiltrées localement par l’attaquant en attente d’exfiltration.

Étape 4 : Correction de la cause racine. Si l’entrée était une CVE non patchée → appliquer le patch immédiatement et vérifier toute la surface d’attaque similaire. Si c’était un phishing → réinitialiser les identifiants compromis, activer le MFA sur tous les comptes, renforcer le filtrage email. Si c’était un accès légitime détourné → auditer tous les accès privilégiés, appliquer le principe du moindre privilège.

Étape 5 : Vérification de l’éradication. L’éradication n’est pas confirmée jusqu’à ce que des scans complets (EDR, scanner de vulnérabilités, revue des logs post-nettoyage) ne montrent plus aucune trace d’activité malveillante. Un outil comme Velociraptor permet de faire ce scan à l’échelle de toute la flotte d’endpoints en quelques minutes via des artifacts VQL de détection.

Phase 5 — Rétablissement : reprendre l’activité de manière contrôlée

Le rétablissement est la phase de retour à la normale. Elle exige une rigueur absolue car c’est souvent ici que les erreurs se produisent : pression de la direction pour remettre les systèmes en ligne le plus vite possible, réticence à reconnaître que la sauvegarde pourrait être compromise, surveillance post-restauration insuffisante.

Le premier principe fondamental du rétablissement : ne jamais restaurer depuis une sauvegarde sans avoir vérifié qu’elle n’est pas compromise. Un ransomware sophistiqué s’installe généralement plusieurs semaines avant de chiffrer — période durant laquelle les sauvegardes sont potentiellement infectées. La stratégie de rétablissement doit identifier la dernière sauvegarde propre (avant la date de compromission initiale estimée lors de la phase d’identification).

Le second principe : remettre en ligne progressivement avec une surveillance renforcée. Ne pas tout remettre en ligne simultanément. Commencer par les systèmes les moins critiques pour valider le processus de restauration, puis progresser vers les systèmes critiques. Sur chaque système restauré, activer une surveillance renforcée (EDR en mode analyse comportementale, logging étendu, alertes sur toute activité inhabituelle) pendant minimum 30 jours post-incident.

Les actions techniques de rétablissement incluent :

• Reconstruction des systèmes compromis depuis une image propre ou une sauvegarde validée, plutôt que simple « désinfection » (un système compromis au niveau kernel ne peut jamais être considéré comme sûr sans réinstallation complète)
• Réinitialisation de tous les mots de passe des comptes ayant eu accès aux systèmes compromis — pas uniquement les comptes directement utilisés par l’attaquant
• Révocation et renouvellement des certificats et secrets (API keys, tokens, certificats SSL) potentiellement exposés
• Vérification des configurations de sécurité sur les systèmes restaurés (pare-feu, politique d’audit, MFA)
• Tests fonctionnels complets avant remise en production

Phase 6 — Retour d’expérience : transformer l’incident en amélioration

Le retour d’expérience (Post-Incident Review, PIR — également appelé after-action review ou lessons learned meeting) est la phase que les organisations abandonnent le plus souvent une fois la pression retombée. C’est pourtant celle qui permet de transformer un incident coûteux en investissement durable dans la posture de sécurité.

Le NIST SP 800-61 recommande de tenir cette réunion dans les deux semaines suivant la clôture de l’incident, pendant que les souvenirs sont encore frais. Elle doit réunir toutes les parties prenantes : équipe IR/SOC, CISO, DSI, métiers impactés, éventuellement le prestataire forensique externe.

La structure du rapport post-mortem (Post-Incident Report, PIR) doit documenter :

1. Chronologie détaillée : date/heure de chaque événement clé, de la compromission initiale jusqu’à la clôture
2. Cause racine identifiée : le vecteur d’entrée, les vulnérabilités exploitées, les lacunes de détection
3. Impact mesuré : systèmes affectés, données exposées, durée d’indisponibilité, coût estimé
4. Efficacité de la réponse : ce qui a bien fonctionné, ce qui aurait dû être fait différemment
5. Actions correctives : liste priorisée d’améliorations avec responsable et délai (patches manquants, nouveaux contrôles, formation, mise à jour des playbooks)
6. Métriques IR : MTTD, MTTR, temps par phase, nombre de systèmes affectés

Ces métriques constituent le tableau de bord de maturité IR. Un MTTD qui diminue d’une année sur l’autre traduit une amélioration des capacités de détection. Un MTTR stable malgré une augmentation du nombre d’incidents indique que les processus IR scalent correctement.

Erreurs fréquentes dans la conduite des phases IR

Tutoriels complémentaires

• Analyse forensique avec Autopsy et Sleuth Kit : tutoriel pas à pas — L’outil forensique disque utilisé pendant les phases 3 et 4
• Volatility Framework : analyse de la mémoire vive — Analyse du dump RAM capturé en phase 3
• TheHive et MISP : gestion des incidents et renseignements cyber — Outil de case management pour orchestrer toutes les phases

FAQ

Q : Peut-on sauter la phase de confinement pour aller directement à l’éradication ?
R : Non. L’éradication sans confinement préalable expose au risque que l’attaquant, voyant ses outils supprimés, déploie d’autres backdoors ou accélère l’exfiltration/chiffrement. Le confinement doit précéder l’éradication pour maintenir la maîtrise de la situation.

Q : Doit-on notifier les autorités lors de tout incident ?
R : Cela dépend de la réglementation applicable. Le RGPD impose une notification à l’autorité de contrôle (CNIL en France) dans les 72 heures si des données personnelles sont concernées. NIS2 impose des notifications pour les opérateurs essentiels. Même hors obligation légale, contacter le CERT national est fortement recommandé pour bénéficier de son soutien technique.

Q : Combien de temps garder les preuves forensiques après clôture ?
R : Le NIST SP 800-61 recommande de conserver les preuves aussi longtemps que des poursuites judiciaires restent possibles. En pratique, les délais de prescription varient par juridiction et type d’infraction. En France, les infractions informatiques (accès frauduleux — article 323-1 du Code pénal) ont un délai de prescription de 6 ans. Minimum recommandé : 3 ans pour les incidents sans enjeu judiciaire apparent.

Références officielles

• NIST SP 800-61 Rev 3 — doi.org/10.6028/NIST.SP.800-61r3
• SANS Incident Handler’s Handbook — sans.org/white-papers/33901/
• MITRE ATT&CK Framework — attack.mitre.org
• NoMoreRansom Project — nomoreransom.org
• 🔝 Guide DFIR complet — Réponse aux incidents et analyse forensique numérique (DFIR) : guide complet 2025