Playbooks de réponse à incident — cinq runbooks alignés sur le NIST

La question traitée

Lorsqu'un incident survient, la question n'est pas « avons-nous une politique pour cela ? » — la plupart des SOC en ont une. Elle est plutôt : « l'analyste de permanence en ce moment exécutera-t-il les mêmes étapes, dans le même ordre, avec les mêmes déclencheurs d'escalade, que l'analyste qui a rédigé le playbook il y a six mois ? » Ce dépôt y répond en dotant chacun des cinq types d'incidents les plus courants (phishing, malware, compromission de compte, violation de données, DDoS) de son propre runbook autonome, avec une structure de sections identique — Objet, Périmètre, Prérequis, Critères de détection, Étapes de réponse par phase SANS, arbre de décision Mermaid, table d'escalade, checklist de preuves, actions de reprise, modèles de communication et activités post-incident — de sorte qu'un analyste ayant assimilé la structure d'un playbook puisse naviguer dans les quatre autres sans réapprendre le format.

Référentiels de base — et pourquoi deux révisions du NIST sont délibérément citées

Le dépôt s'appuie sur le cycle de vie en quatre phases de NIST SP 800-61 Rev. 2 (Préparation → Détection et analyse → Confinement, éradication et reprise → Activités post-incident) — qui reste la base opérationnelle citée par les playbooks fédéraux de réponse à incident publiés par la CISA en 2024, bien qu'il ait été officiellement retiré. NIST SP 800-61 Rev. 3 (avril 2025) en est le remplaçant officiel actuel, mais abandonne le modèle en phases autonome au profit d'une mise en correspondance des activités de réponse à incident avec les six fonctions du NIST CSF 2.0 (Govern, Identify, Protect, Detect, Respond, Recover) — un document de gouvernance et d'intégration des risques, et non un runbook d'analyste. Plutôt que de trancher silencieusement, le README indique clairement que la Rev. 3 est la version en vigueur, tandis que le modèle en phases de la Rev. 2 (via sa déclinaison SANS en six phases, plus granulaire) reste celui réellement utilisé au quotidien pour la rédaction des playbooks ; il inclut une table de correspondance explicite entre les trois, afin qu'un même playbook fonctionne que l'interlocuteur d'une escalade ait été formé à la terminologie NIST ou SANS.

Envergure

Modèle de sévérité — deux niveaux, à dessein

Tous les playbooks partagent la même matrice de sévérité à quatre niveaux (Critique / Élevée / Moyenne / Faible) pour un triage rapide — elle détermine directement le délai de réponse initial et les personnes à notifier : par exemple, Critique implique l'alerte immédiate du RSSI, de la direction informatique et du service juridique, tandis que Faible donne uniquement lieu à une journalisation. Pour les incidents devant faire l'objet d'un signalement formel à la direction ou aux autorités de régulation, les playbooks renvoient plutôt au modèle CISA/NCISS à trois axes — impact fonctionnel, impact informationnel et récupérabilité, évalués indépendamment — précisément parce que réduire l'ensemble à un seul qualificatif de sévérité masque la différence entre une exposition de données limitée mais très sensible et une attaque DDoS massive mais entièrement absorbée ; les deux peuvent être « significatives » sans pour autant constituer des incidents équivalents.

Réponse aux incidents de phishing

Couvre le phishing signalé par les utilisateurs ou détecté par la passerelle de messagerie, les liens de collecte d'identifiants et les leurres de type BEC. La phase d'identification de ce playbook comporte une étape spécifique : après avoir extrait les en-têtes et fait exécuter l'URL ou la pièce jointe dans une sandbox, l'analyste doit rechercher tous les autres destinataires du même message et qualifier l'interaction de chacun (aucune interaction / clic sans saisie d'identifiants / identifiants saisis / pièce jointe exécutée) — car « le phishing vise rarement une seule cible », et c'est cette qualification par destinataire qui détermine réellement la sévérité, et non le seul cas de l'utilisateur ayant signalé le message.

Branche clé de l'arbre de décision : si un utilisateur a cliqué sur un lien menant à une page de saisie d'identifiants et y a saisi ses identifiants, la sévérité passe à Élevée et le confinement exige, en une seule action coordonnée, la réinitialisation du mot de passe, la révocation des sessions et des jetons, et le réenrôlement MFA — une branche supplémentaire recherche ensuite des signes d'activité post-compromission (nouvelle règle de boîte aux lettres, autorisation OAuth, connexion suspecte). Si de tels signes existent, l'incident bascule directement vers le playbook de compromission de compte, puis vers le playbook de violation de données si des données ont effectivement été consultées — les arbres sont conçus pour se relayer les uns les autres, et non pour aboutir à un point d'« escalade » générique.

Réponse aux infections par malware

Couvre les exécutions signalées par l'antivirus ou l'EDR, les ransomwares et l'activité de beacon C2 associée à un hôte. La phase de confinement met explicitement en garde contre un réflexe courant : ne jamais éteindre un hôte infecté — cela détruit les preuves en mémoire volatile et, pour un ransomware déjà en cours de chiffrement, n'arrête même pas le processus de façon fiable sur batterie ou onduleur. L'isolement réseau via l'EDR est privilégié, en préservant délibérément la communication de l'agent EDR pour conserver la visibilité.

Branche clé de l'arbre de décision : un ransomware confirmé ou un comportement de chiffrement actif mène directement à une sévérité Critique, avec isolement complet du segment et vérification de l'intégrité des sauvegardes avant toute autre action sur l'infrastructure de sauvegarde — les sauvegardes étant identifiées comme une cible secondaire fréquente dès qu'un attaquant dispose d'un accès au niveau du domaine. Une branche distincte vérifie si le malware maintient une connexion C2 active : si le beaconing est confirmé, l'incident est traité comme une compromission active en cours, nécessitant une collecte forensique complète avant toute réinstallation, plutôt que comme une éradication de routine.

Réponse à la compromission de compte

Couvre le vol d'identifiants, les connexions en « voyage impossible », le vol de sessions ou de jetons et le BEC. Un détail structurel mérite d'être souligné : le confinement exige de révoquer les sessions et les jetons de rafraîchissement en même temps que la réinitialisation du mot de passe, car le playbook précise qu'une réinitialisation seule n'invalide pas les jetons de session déjà émis — une lacune facile à manquer sous pression. L'identification vérifie aussi spécifiquement les nouvelles règles de boîte aux lettres et les consentements d'applications OAuth avant de s'en tenir aux journaux de connexion, car ce sont les mécanismes de persistance post-compromission les plus courants, et ils passent inaperçus si l'analyste s'arrête à l'historique des connexions.

Branche clé de l'arbre de décision : une fois l'accès non autorisé confirmé, l'arbre bifurque selon l'action effectuée par le compte — une règle de boîte aux lettres, une autorisation OAuth ou un e-mail BEC envoyé mènent à une sévérité Élevée, avec notification des destinataires si le BEC a visé l'extérieur ; la consultation ou le téléchargement de données sensibles, tout comme une élévation de privilèges ou la création d'un nouveau compte, mènent directement à une sévérité Critique et déclenchent en parallèle le playbook de violation de données.

Réponse aux violations de données

Couvre l'accès non autorisé à des données sensibles ou leur exfiltration, et est explicitement conçu pour s'exécuter en parallèle du playbook traitant la compromission initiale (phishing, malware, compromission de compte), plutôt que de manière autonome. Sa différence structurelle déterminante : le service Juridique/Conformité est mobilisé immédiatement et en parallèle de l'investigation technique, et non après confirmation technique — car les délais de notification (l'exigence de 72 heures de l'article 33 du RGPD est explicitement citée) peuvent courir dès la prise de connaissance, et non à partir de la certitude. C'est également le seul playbook à responsabilité partagée : le SOC pilote la réponse technique, le service Juridique & Conformité le volet réglementaire et les notifications.

Branche clé de l'arbre de décision : la bifurcation centrale consiste à déterminer si les données ont seulement été exposées/accessibles (par exemple un bucket public mal configuré sans preuve d'accès), réellement consultées ou bien exfiltrées — chaque cas correspond à une sévérité différente et à un niveau de preuve différent pour la décision de notification du service juridique. Une simple exposition sans trace d'exploitation dans les journaux d'accès est tout de même documentée pour examen juridique plutôt que clôturée d'office, car l'exposition en elle-même peut déclencher des obligations de notification indépendamment de tout accès confirmé.

Réponse aux attaques DDoS

Le cas à part, par conception : le playbook commence par rappeler qu'il s'agit avant tout d'un incident de disponibilité, et non de confidentialité ou d'intégrité, de sorte que l'ordre des priorités et l'outillage diffèrent des quatre autres. L'identification exige d'écarter explicitement les explications liées à un trafic légitime (pic viral lié à une campagne marketing, scraper interne mal configuré) avant de s'engager dans la mitigation, car appliquer à tort un rate limiting agressif à un trafic légitime risque de provoquer une panne auto-infligée en plus — voire à la place — de la vraie. La sévérité est évaluée selon l'impact réel sur les clients et l'activité plutôt que selon le volume brut de l'attaque : une attaque massive entièrement absorbée sans impact visible peut être classée moins grave qu'une attaque plus modeste qui met totalement hors service un service exposé aux clients.

Branche clé de l'arbre de décision : la classification du vecteur d'attaque (volumétrique/protocolaire ou applicative) détermine la couche de mitigation employée — nettoyage en amont (scrubbing) ou WAF/rate limiting — et une branche distincte vérifie la présence d'une demande d'extorsion, qui est transmise directement au service juridique et à la direction, avec pour consigne explicite de ne pas échanger directement avec l'attaquant et de conserver la communication comme élément de preuve.

Modèles réutilisables

Quatre modèles indépendants du type d'incident se trouvent dans templates/ ; ils sont référencés par les cinq playbooks plutôt que dupliqués dans chacun d'eux :

• Modèle de notification des parties prenantes — le format de référence à partir duquel sont construits les éléments de communication propres à chaque playbook (à destination des utilisateurs concernés, de la direction générale, des destinataires externes).
• Modèle de synthèse pour la direction — utilisé lorsque la matrice de sévérité à quatre niveaux n'est pas assez précise et qu'il faut recourir à la classification d'impact CISA/NCISS à trois axes.
• Modèle de revue post-incident — exigé dans les 5 jours ouvrés suivant la clôture pour chaque playbook (immédiatement, sans attendre ce délai, pour les incidents critiques et les ransomwares).
• Registre de chaîne de traçabilité des preuves — cité nommément dans la section Collecte de preuves de chaque playbook pour tout élément susceptible d'étayer une action RH ou judiciaire, un signalement aux forces de l'ordre ou une enquête réglementaire.