Comment construire un plan de réponse aux incidents qui fonctionne?

La plupart des organisations n'échouent pas à la réponse aux incidents parce qu'elles manquent d'outils. Elles échouent parce que personne n'a convenu à l'avance qui fait quoi, et le premier vrai incident devient une réunion au lieu d'une réponse.

Commencez par les phases, pas par le playbook

NIST SP 800-61 énumère quatre phases : préparation, détection et analyse, confinement/éradication/récupération, et activités post-incident. Cet ordre compte. Les équipes adorent passer directement au confinement parce que cela semble productif, mais si vous n'avez pas fait le travail de préparation, vous ne connaissez pas votre propre réseau suffisamment bien pour confiner quoi que ce soit proprement.

La préparation signifie des inventaires d'actifs qui sont réellement à jour, pas la feuille de calcul de 2022. Cela signifie connaître votre fenêtre de rétention des journaux (si c'est 7 jours et que l'attaquant avait 30 jours de temps de résidence, vous avez déjà perdu la chronologie). Cela signifie des outils de forensique pré-déployés — Velociraptor, KAPE, ou même une procédure documentée tar/dd pour les images disque — pour que personne ne télécharge d'outils sur un hôte compromis pendant un incident actif.

Définissez les niveaux de sévérité avant d'en avoir besoin

Un SEV1 (exfiltration de données active, détonation de ransomware, compromission d'administrateur de domaine) nécessite une réponse différente d'un SEV3 (malware isolé sur un poste de travail non privilégié). Écrivez ceci sous forme de matrice : impact vs. portée vs. confiance. Assignez à chaque sévérité un temps de réponse requis et un chemin d'escalade. Si votre commandant d'incident pour un SEV1 est la même personne qui doit approuver chaque bon de commande de 500 $, vous avez construit un goulot d'étranglement dans votre propre processus d'urgence.

Le rôle de commandant d'incident n'est pas optionnel

Une personne dirige l'incident. Pas le plus senior ingénieur par défaut — la personne la mieux adaptée pour coordonner, déléguer, et prendre des décisions de confinement sous pression. Cette personne ne tape pas nécessairement sur un clavier pendant la réponse ; elle suit la chronologie, gère la communication avec le juridique et la direction, et décide quand appuyer sur le bouton pour isoler un segment ou mettre un système hors ligne.

Sans ce rôle, vous avez cinq personnes SSH'd dans la même boîte, aucune d'elles ne parlant les unes aux autres, et personne ne capturant la mémoire volatile avant que quelqu'un ne redémarre la machine pour "voir si cela la répare".

Les décisions de confinement qui comptent vraiment

L'appel le plus difficile dans la plupart des incidents est : isoler maintenant, ou observer un peu plus longtemps pour comprendre la portée? Couper l'accès réseau trop tôt avertit un attaquant toujours en mouvement latéral et détruit votre chance de voir son prochain mouvement. Attendre trop longtemps laisse le ransomware terminer de chiffrer les partages.

Un juste milieu raisonnable : utiliser la segmentation réseau et l'isolation EDR (CrowdStrike, Defender for Endpoint, SentinelOne supportent tous cela) pour couper un hôte des mouvements latéraux tout en le maintenant sous tension pour la capture de mémoire. L'arrêt complet doit être un dernier recours — il détruit les preuves volatiles et, pour les cas de ransomware, peut déclencher un comportement anti-forensique intégré à certaines charges utiles.

Les lacunes de journalisation que vous regretterez pendant, pas avant

Les défauts Windows Event Log ne suffisent pas. Si vous n'avez pas Sysmon déployé avec une config décente (les configs de base de SwiftOnSecurity ou d'Olaf Hartong sont un bon point de départ), vous reconstruirez des arbres de processus à partir de fragments. Du côté réseau, les journaux NetFlow ou Zeek comptent plus que la plupart des orgs le réalisent jusqu'à ce qu'elles aient besoin de répondre