Réponse aux incidents cyber : les 4 phases NIST

Le NIST SP 800-61r2 (Computer Security Incident Handling Guide) reste la référence pour structurer sa réponse aux incidents. Pas parce que c'est un document américain, mais parce que les 4 phases qu'il décrit correspondent exactement à la réalité opérationnelle. Problème : 194 jours de dwell time moyen (IBM 2025) prouvent que la majorité des organisations échouent dès la phase 2.

Phase 1 : Préparation

La préparation est la phase la plus négligée et la plus déterminante. Elle se décompose en deux volets :

Volet technique

• Inventaire des actifs : vous ne pouvez pas protéger ce que vous ne connaissez pas. Cartographie réseau, CMDB à jour, Shadow IT identifié.

• Monitoring déployé : SIEM opérationnel, EDR sur les endpoints, logs centralisés (réseau, identité, cloud, applicatif)

• Baseline établi : qu'est-ce qui est "normal" sur votre réseau ? Sans baseline, toute alerte est un bruit de fond.

• Outils de forensic prêts : images forensic préconfigurées, accès aux snapshots, chaîne de custody documentée

Volet organisationnel

• Playbooks d'incident : pas un document de 200 pages que personne ne lit. Des fiches réflexe de 2 pages par scénario (ransomware, phishing, compromission de compte, fuite de données).

• Équipe de réponse identifiée : qui fait quoi, contacts à jour, astreintes définies

• Communication de crise : modèles pré-rédigés pour la direction, les clients, la CNIL, l'ANSSI

• Exercices réguliers : un tabletop exercise par trimestre minimum. Simulez le scénario de 02h17 un dimanche, qui répond ? En combien de temps ?

ThreatClaw couvre le volet technique de la préparation en 48h : déploiement des agents, baseline comportemental en 14 jours, 57 skills d'audit prêts à l'emploi.

Phase 2 : Détection et Analyse

C'est ici que tout se joue, et c'est ici que la plupart des organisations échouent. La détection repose sur trois piliers :

• Détection par signature : règles YARA, Sigma, Snort/Suricata. Efficace contre les menaces connues. Inutile contre le zero-day ou le LOLBins (Living Off The Land).

• Détection par anomalie : ML/comportemental. Identifie les écarts par rapport au baseline. C'est ce qui attrape les menaces inconnues, un utilisateur qui lance PowerShell pour la première fois, un serveur qui contacte un domaine jamais vu.

• Threat intelligence : IoC feeds (MISP, OTX, VirusTotal), corrélation avec les campagnes actives.

L'analyse est le goulot d'étranglement. Un SOC reçoit 4 500 alertes/jour (Splunk 2024). L'analyste doit déterminer : est-ce un vrai positif ? Quel est l'impact ? Quelle est l'étendue ? Quelles sont les prochaines étapes ? C'est ce processus de triage qui prend 15-25 minutes par alerte, et qui explique pourquoi 68 % des alertes restent non investiguées.

L'agent ThreatClaw automatise le triage : corrélation multi-source, enrichissement contextuel (l'alerte concerne-t-elle un serveur de prod ou un poste de dev ?), scoring de criticité adapté à votre environnement. Le temps de triage passe de 20 minutes à 3 secondes.

Phase 3 : Confinement, Éradication et Récupération

Une fois l'incident confirmé, la course contre la montre commence.

Confinement

Le confinement doit être immédiat et proportionné. Deux stratégies :

• Confinement court terme : isoler le système compromis du réseau (VLAN quarantaine, désactivation du port switch, isolation EDR). L'objectif : stopper la propagation sans détruire les preuves.

• Confinement long terme : si l'éradication n'est pas immédiate, mettre en place des contrôles temporaires (règles firewall, blocage de comptes, supervision renforcée des systèmes adjacents).

Le scénario classique : ransomware détecté à 02h17 un dimanche. Le chiffrement a commencé. Chaque minute compte. En mode Autonome, ThreatClaw isole la machine en 90 secondes, bloque le compte compromis, et capture un snapshot forensic avant que le chiffrement ne se propage. En mode Hybride, il vous envoie la proposition d'action et attend votre validation, mais le temps que vous voyez le SMS, il peut être trop tard.

Éradication

• Identification et suppression du malware

• Fermeture du vecteur d'entrée (patch, désactivation du service vulnérable)

• Réinitialisation des credentials compromis

• Vérification des systèmes adjacents (mouvement latéral ?)

Récupération

• Restauration depuis des sauvegardes vérifiées (testez vos backups avant l'incident)

• Remise en production progressive avec monitoring renforcé

• Validation que l'attaquant n'a pas laissé de persistence (comptes, tâches planifiées, clés SSH)

Phase 4 : Activité post-incident

La phase la plus souvent bâclée. Après un incident, vous devez :

• Post-mortem sans blâme : chronologie factuelle, ce qui a fonctionné, ce qui a échoué, les lacunes identifiées

• Mise à jour des playbooks : chaque incident doit améliorer votre préparation (retour à la phase 1)

• Notifications réglementaires : RGPD Art.33 (72h CNIL), NIS2 Art.23 (24h CSIRT), et rapport final dans le mois

• Indicateurs de compromission partagés : contribuez au MISP de votre secteur

ThreatClaw génère automatiquement la chronologie de l'incident, le rapport technique, et le rapport de notification réglementaire. Le post-mortem prend 2 heures au lieu de 2 jours.

Human-in-the-Loop : le bon équilibre

L'automatisation totale fait peur, à raison. Le concept de HITL (Human-in-the-Loop) est central. La question n'est pas "automatiser ou pas" mais "automatiser quoi" :

• Automatiser sans hésiter : collecte de logs, corrélation, enrichissement, notification, génération de rapports

• Automatiser avec validation : isolation d'un endpoint, blocage d'un compte, application d'une règle firewall

• Ne pas automatiser : communication de crise, décision de payer ou non une rançon, notification clients

Les trois modes ThreatClaw (Sentinelle, Hybride, Autonome) reflètent exactement ces niveaux de confiance. Vous choisissez le curseur.

FAQ

Quelle est la différence entre un incident et un événement de sécurité ?

Un événement est toute occurrence observable sur un système (login, accès fichier, requête DNS). Un incident est un événement ou une série d'événements qui viole la politique de sécurité ou qui constitue une menace imminente. Tous les incidents sont des événements, mais moins de 1 % des événements sont des incidents.

Combien de temps faut-il pour constituer une équipe de réponse aux incidents ?

Pour une PME, l'équipe de réponse est souvent le RSSI + l'admin sys + un prestataire externe. La constitution formelle prend 2-4 semaines (identification des rôles, contacts, procédures). Le premier exercice tabletop révèle systématiquement 5-10 lacunes critiques. Prévoyez 3 mois pour une maturité opérationnelle.

NIST ou ISO 27035 pour structurer sa réponse ?

Les deux sont valides. NIST SP 800-61 est plus opérationnel et concret. ISO 27035 est plus structuré d'un point de vue gouvernance et s'intègre mieux dans un SMSI ISO 27001. En pratique, les phases sont quasi identiques. Choisissez selon votre référentiel existant.

Mon organisation n'a jamais eu d'incident. Pourquoi investir dans la réponse ?

Avec tout le respect : vous n'avez probablement jamais détecté d'incident. 194 jours de dwell time signifie que les attaquants sont souvent présents sans être repérés. Le coût moyen d'une brèche en 2025 est de 4,88 M$ (IBM). L'investissement en détection et réponse n'est pas un coût, c'est une assurance mesurable. Comparez les options.