Réponse à incident et forensique

Les quatre premiers blocs répondaient à une question : comment empêcher une attaque de réussir. Ce chapitre en pose une autre, plus réaliste : que faire quand elle a réussi malgré tout ? La question n'est pas défaitiste. Aucune organisation n'empêche tous les incidents, et la maturité en sécurité ne se mesure pas au nombre d'attaques bloquées — invérifiable — mais au temps mis à détecter et à contenir celle qui passe. Les meilleures s'en tirent en heures ; la moyenne mondiale se compte encore en semaines.

La compétence de ce chapitre est autant une question de méthode et de sang-froid que de technique. La première erreur d'un incident n'est presque jamais technique : c'est une action précipitée qui détruit les preuves ou aggrave la situation.

Le cycle de réponse

Le modèle de référence (NIST SP 800-61) décompose la réponse en six phases. L'essentiel est de comprendre que ce n'est pas une liste mais une boucle : la dernière phase réalimente la première.

Deux phases sont systématiquement sous-estimées, et ce sont les deux extrémités.

La préparation décide de tout le reste. On ne peut pas analyser des journaux qu'on n'a pas collectés (chapitre 4), ni restaurer une sauvegarde qu'on n'a jamais testée, ni joindre en pleine nuit un contact qu'on n'a pas noté. La réponse à incident se joue en grande partie avant l'incident — c'est la même logique que le durcissement.

Le retour d'expérience referme la boucle. Un incident dont on ne tire aucune leçon se répétera à l'identique. Il ne s'agit pas de chercher un coupable — une culture qui punit fait taire ceux qui détectent — mais de corriger la cause racine : pourquoi ce point d'entrée existait, pourquoi il n'a pas été vu plus tôt.

Confiner sans détruire

C'est la décision la plus délicate, et le nœud de l'exercice de ce chapitre. Face à un poste compromis, le réflexe est de l'éteindre. C'est presque toujours une faute.

Éteindre coupe l'attaque, mais détruit la mémoire vive — et avec elle les clés de chiffrement, les processus en cours, les connexions réseau actives, et le maliciel qui n'existe parfois qu'en RAM sans jamais toucher le disque. On perd l'essentiel de ce qui aurait permis de comprendre.

La bonne action est d'isoler : couper le réseau — débrancher le câble, basculer le VLAN — en laissant la machine allumée. La propagation et l'exfiltration s'arrêtent, l'état est préservé. Débrancher le câble, pas la prise. Le confinement peut aussi être logique : désactiver un compte compromis, bloquer une adresse, révoquer un jeton (chapitre 3).

Collecter les preuves, et la chaîne de conservation

Une fois la machine isolée mais vivante, on collecte, dans l'ordre de volatilité : du plus fugace au plus durable. La mémoire vive d'abord, car elle disparaît à l'extinction ; puis l'état réseau ; puis l'image disque ; puis les journaux déjà centralisés.

Deux principes gouvernent la collecte, et ils sont non négociables si les preuves doivent un jour avoir une valeur — en interne comme devant un tribunal.

• Travailler sur des copies. On analyse une image, jamais l'original, dont on fige une empreinte cryptographique (chapitre 2) pour prouver qu'il n'a pas changé.
• Tenir la chaîne de conservation. Chaque preuve est tracée : quoi, quand, par qui, où stockée, à qui transmise, avec quelle empreinte. Une rupture de cette chaîne rend la preuve contestable — elle ne prouve plus rien, parce qu'on ne peut plus exclure qu'elle ait été modifiée entre-temps.

C'est ici que la journalisation du chapitre 4 rend son dû : des journaux centralisés, horodatés et à intégrité protégée, hors de portée de l'attaquant, sont la matière première de toute l'analyse. Un journal resté sur la machine compromise a probablement été effacé — l'effacement des traces est une étape standard de l'intrusion.

Analyser : journaux, artefacts, mémoire

L'analyse cherche à répondre à quatre questions : par où l'attaquant est entré, quand, jusqu'où il est allé, et ce qu'il a pris ou fait. C'est une reconstitution de la chaîne d'attaque du chapitre 1, à rebours.

Trois sources, complémentaires :

• Les journaux — le point de départ, s'ils ont été collectés. Le SIEM (chapitre 6) les corrèle : une authentification échouée est banale, mais cent échecs suivis d'une réussite, d'une création de compte, puis d'un transfert sortant dessinent l'intrusion complète.
• Les artefacts du système — ce que l'activité laisse sur le disque : traces d'exécution de programmes, tâches planifiées, clés de démarrage, historique de commandes, journaux applicatifs. C'est là que se lisent la persistance et l'escalade des chapitres 4 et 3.
• La mémoire — l'analyse (par exemple avec Volatility) révèle ce que le disque ne montre pas : processus cachés, code injecté, connexions actives, clés en clair. C'est précisément ce qu'une extinction aurait effacé, et la raison de tout ce qui précède.

L'objectif concret de l'analyse est de produire des indicateurs de compromission — empreintes, adresses IP, noms de domaine, comptes — qui permettent de chercher la même menace ailleurs dans le système d'information. Un poste compromis est rarement seul : le confinement n'est réellement complet qu'après avoir mesuré l'étendue par ces indicateurs.

Le rapport d'incident

L'analyse la plus fine ne vaut que si elle est communiquée — c'est le pont vers le chapitre 10 et la gouvernance. Un rapport d'incident sert trois publics à la fois, et un bon rapport les distingue nettement :

• la direction, qui a besoin de l'impact, du périmètre et des décisions à prendre — pas de détails techniques ;
• les techniciens, qui ont besoin de la chronologie précise, des indicateurs et des correctifs ;
• le juridique et la conformité, qui ont besoin des faits datés, des preuves et des éléments déclenchant d'éventuelles obligations de notification — celles du RGPD, dans un délai serré, que le chapitre 10 détaille.

Un bon rapport est factuel et daté : ce qui est établi, ce qui est probable, ce qui est inconnu, sans confondre les trois. Sa dernière section — les recommandations — est ce qui transforme un incident subi en amélioration durable, et referme la boucle du cycle.

À vous

L'exercice place la décision au bon endroit : elle n'est pas technique mais d'ordre. Un poste est compromis, sept actions sont sur la table dans le désordre. Rendez la bonne séquence — et surtout, justifiez pourquoi « éteindre le poste » n'est pas la bonne première réaction, alors qu'elle couperait pourtant l'attaque.

C'est le réflexe que ce chapitre vise à corriger : en réponse à incident, la préservation des preuves et l'ordre des actions priment sur la vitesse de coupure.

// 8 h 47. Un poste comptable présente une consommation CPU anormale et une
// connexion sortante inhabituelle. Vous êtes de permanence. Sept actions
// possibles sont sur la table, dans le DÉSORDRE.

const ACTIONS = {
  A: "Éteindre le poste immédiatement pour couper l'attaque",
  B: "Isoler le poste du réseau (câble/VLAN) sans l'éteindre",
  C: "Capturer la mémoire vive (RAM) et une image disque du poste",
  D: "Prévenir le responsable et consigner l'heure de chaque action",
  E: "Rechercher les mêmes indicateurs (IP, empreintes) sur les autres postes",
  F: "Réinstaller le poste et le rendre à l'utilisateur",
  G: "Rédiger le retour d'expérience et corriger la cause racine",
};

// Le cycle de réponse à incident (NIST) :
//   préparation → détection → confinement → éradication → rétablissement →
//   retour d'expérience
//
// ── À VOUS ──────────────────────────────────────────────────────────────────
// Rendez l'ordre correct des actions (ex. ["D","B",...]). Deux pièges :
//   - l'ordre entre A, B et C n'est pas indifférent ;
//   - une action doit ACCOMPAGNER toutes les autres, pas s'insérer une fois.

const ordre = []; // à compléter

// ── Vérification ────────────────────────────────────────────────────────────
const CORRECT = ["D", "B", "C", "E", "F", "G"];
console.log("Votre ordre :", ordre.join(" → "));
console.log("Attendu     :", CORRECT.join(" → "));
const ok = ordre.length === CORRECT.length && ordre.every((x, i) => x === CORRECT[i]);
console.log(ok ? "✓ correct" : "✗ à revoir — et surtout : pourquoi PAS A ?");

Ce que la suite en fait

Ce chapitre a traité l'incident individuel : le détecter, le contenir, l'analyser, en tirer les leçons. Le chapitre 10 change d'échelle. Il pose la question qui précède logiquement tout incident, mais qu'on ne comprend qu'après en avoir vécu — sur DVWA, en TP — plusieurs : comment décider, à l'avance et à l'échelle de l'organisation, ce qu'on protège, contre quoi, et avec quels moyens ?

Les obligations de notification effleurées ici y deviennent un cadre juridique complet ; le retour d'expérience s'y élargit en continuité d'activité ; et le facteur humain — souvent le point d'entrée réel de l'incident que vous venez d'analyser — y prend la place centrale qu'il mérite.

À retenir