Chapitre 15.3 — Réponse à incident & notification

⏱️ TL;DR — Quand la détection sonne (ou qu’on apprend une compromission), il faut un plan — pas improviser dans la panique. Le cycle classique : Préparer (avoir le plan, les contacts, les accès avant) → Détecter/analyser → Contenir (limiter la propagation : isoler, révoquer, couper) → Éradiquer (retirer la cause : patcher, supprimer la backdoor) → Rétablir (remettre en service, proprement) → Retour d’expérience (post-mortem sans blâme : que corriger pour que ça ne se reproduise pas ?). Si des données personnelles sont touchées, c’est une violation de données au sens du RGPD : notification à l’autorité (la CNIL) sous 72 h si risque, et information des personnes si risque élevé — un pont direct avec le cours RGPD.

🎯 Objectifs

Connaître les phases d’une réponse à incident (préparer → contenir → éradiquer → rétablir → apprendre).
Comprendre l’importance de la containment (contenir vite) et de la préparation en amont.
Mener un post-mortem utile (sans blâme, orienté correctifs).
Gérer une violation de données : obligations RGPD (72 h, personnes concernées).

Préparer AVANT l’incident

Le meilleur moment pour préparer une réponse à incident, c’est avant qu’il n’arrive. En pleine crise, on n’a pas le temps de chercher qui appeler, comment isoler un service, où sont les sauvegardes. La préparation, c’est :

Un plan de réponse écrit (runbook) : qui fait quoi, dans quel ordre, avec quels outils.
Des contacts : responsable sécurité, DPO (délégué à la protection des données), direction, hébergeur, éventuellement autorités/experts. Et une chaîne d’escalade.
Des accès et des sauvegardes prêts : pouvoir isoler, révoquer, restaurer rapidement (sauvegardes testées — Partie 14, Serveur Linux).
Des exercices : simuler un incident pour que le plan ne reste pas théorique.

Le cycle de réponse

Détecter & analyser

Confirmer qu’il s’agit bien d’un incident (pas un faux positif), en évaluer la portée (quels systèmes, quelles données, depuis quand) grâce aux logs (chapitres 15.1-15.2). Documenter dès le début (horodatage des actions, preuves) — utile pour la suite et pour d’éventuelles obligations légales.

Contenir : arrêter l’hémorragie

La containment est souvent l’action la plus urgente : limiter la propagation et l’aggravation, sans forcément tout résoudre. Selon le cas :

Isoler le système compromis (le couper du réseau, l’arrêter) pour empêcher l’attaquant d’agir/pivoter.
Révoquer les accès et secrets potentiellement compromis (Partie 13 : régénérer clés/mots de passe), invalider les sessions (Partie 4).
Couper le vecteur (désactiver un endpoint, bloquer une IP, appliquer un virtual patch WAF).

Un dilemme fréquent : isoler tout de suite (stoppe l’attaque mais alerte l’attaquant et peut détruire des preuves/interrompre le service) vs observer un peu pour comprendre. La décision dépend de la gravité — mais pour une fuite de données en cours, on contient vite.

⚠️ Piège — Deux erreurs opposées en containment. (1) Trop attendre (« on observe pour comprendre ») pendant qu’une exfiltration se poursuit → les dégâts s’aggravent. (2) Bâcler l’éradication : redémarrer/restaurer sans avoir retiré la cause (backdoor, compte créé par l’attaquant, faille non patchée, secret non révoqué) → l’attaquant revient aussitôt. Contenir vite, mais éradiquer complètement avant de rétablir. Restaurer une sauvegarde elle-même compromise, ou remettre en ligne sans patcher la faille d’entrée, est une rechute assurée.

Éradiquer : retirer la cause

Supprimer définitivement la cause et la présence de l’attaquant : patcher la faille d’entrée (la dépendance, l’endpoint, la config), retirer les backdoors/webshells/comptes malveillants créés, révoquer tout ce qui a pu être compromis, vérifier l’intégrité du système. On ne rétablit pas tant que la cause n’est pas éradiquée.

Rétablir : remettre en service proprement

Remettre les systèmes en production sains : restaurer depuis des sauvegardes propres (antérieures à la compromission, testées), surveiller de près (l’attaquant peut retenter), et confirmer le retour à la normale. Rétablissement progressif et monitoré.

Retour d’expérience (post-mortem)

Une fois la crise passée, on apprend. Un post-mortem répond à : que s’est-il passé, comment l’attaquant est entré, pourquoi ça n’a pas été bloqué/détecté plus tôt, et quels correctifs mettre en place (techniques et de process). Deux règles :

Sans blâme (blameless) : on cherche les causes systémiques (un contrôle manquant, un angle mort de détection), pas un coupable. La culpabilisation pousse à cacher les incidents — l’inverse de ce qu’on veut.
Orienté action : le post-mortem produit des correctifs concrets et suivis (patcher, ajouter une détection, durcir un process), pour que le même incident ne se reproduise pas.

💡 Réflexe — Un incident est aussi une occasion d’amélioration. Chaque incident bien géré doit se traduire par des changements durables : le trou qui a laissé entrer l’attaquant est comblé, la détection qui a manqué est ajoutée, le process qui a ralenti la réponse est corrigé. Un post-mortem sans blâme et actionnable transforme une mauvaise expérience en défense renforcée. À l’inverse, un incident dont on ne tire rien (ou qu’on cache par peur du blâme) se répétera.

Violation de données : les obligations RGPD

Si l’incident implique des données à caractère personnel (ce qui est très fréquent — Partie 13), ce n’est pas seulement un incident technique : c’est une violation de données personnelles au sens du RGPD, avec des obligations légales (détaillées dans le cours RGPD) :

Documenter la violation (nature, données concernées, personnes, conséquences, mesures prises) — obligatoire, même si non notifiable.
Notifier l’autorité de contrôle (en France, la CNIL) sous 72 heures après en avoir pris connaissance, si la violation est susceptible d’engendrer un risque pour les droits et libertés des personnes.
Informer les personnes concernées si la violation présente un risque élevé pour elles (ex. fuite de données sensibles, de moyens de paiement).
Impliquer le DPO et suivre la procédure interne prévue.

C’est un pont direct avec le cours RGPD : la sécurité (empêcher/détecter/répondre) et la conformité (documenter/notifier) sont le même sujet dès qu’il y a des données personnelles (rappel Moodle, Partie 11). Le compteur des 72 h est une raison de plus d’avoir une détection rapide (chapitre 15.2) et un plan prêt.

🎯 Côté attaquant — L’attaquant compte sur une réponse désorganisée : pas de plan, panique, décisions lentes, éradication incomplète. Il persiste (backdoors, comptes créés, tâches planifiées) pour revenir après un simple redémarrage. Il agit vite pour exfiltrer avant d’être contenu. Une organisation préparée (plan, contacts, sauvegardes testées) qui contient vite et éradique complètement lui retire son avantage : sa fenêtre se referme, ses points de persistance sont retirés, et la fuite est limitée — réduisant aussi l’ampleur de la violation à notifier.

🧭 Sur FormaCampus — FormaCampus a un plan de réponse à incident écrit et testé : rôles définis (responsable sécu, DPO, direction), chaîne d’escalade, contacts (hébergeur, CNIL), et sauvegardes propres testées prêtes à restaurer (Partie 14). En cas d’alerte, l’équipe contient vite (isoler, révoquer secrets et sessions — Parties 4/13, couper le vecteur), éradique (patcher la faille, retirer toute persistance), puis rétablit depuis une sauvegarde saine sous surveillance renforcée, et mène un post-mortem sans blâme produisant des correctifs suivis. Comme elle traite des données d’apprenants, tout incident est évalué comme une violation de données potentielle : documentation systématique, notification CNIL sous 72 h si risque, information des personnes si risque élevé — en lien avec le cours RGPD. La détection rapide (15.2) rend ces délais tenables.

✏️ Exercices

Exercice 1 — Ordonne la réponse. Une exfiltration de données est détectée en cours via une faille d’un endpoint. Remets dans l’ordre et justifie : (a) restaurer depuis une sauvegarde propre, (b) patcher l’endpoint et retirer toute persistance, (c) isoler le système et révoquer les secrets/sessions, (d) post-mortem, (e) notifier la CNIL si risque.

✅ Solution

Ordre : (c) contenir → (b) éradiquer → (a) rétablir → (d) apprendre, avec (e) notifier en parallèle dès que la violation est qualifiée. Justification : (c) Contenir d’abord — isoler le système et révoquer secrets/sessions stoppe l’exfiltration en cours et empêche l’attaquant de continuer/pivoter (l’urgence absolue). (b) Éradiquer — patcher l’endpoint vulnérable et retirer toute persistance (backdoor, compte créé) : sinon l’attaquant revient. (a) Rétablir — restaurer depuis une sauvegarde propre (antérieure et testée) une fois la cause éradiquée, sous surveillance renforcée. (d) Post-mortem — comprendre et corriger durablement (sans blâme). (e) Notifier — dès que la violation de données personnelles est qualifiée avec un risque, notifier la CNIL sous 72 h (et informer les personnes si risque élevé) — cette obligation court en parallèle de la remédiation technique, pas après. Ne jamais restaurer/rétablir avant d’avoir contenu et éradiqué (sinon rechute immédiate).

Exercice 2 — Post-mortem sans blâme. Pourquoi un post-mortem « sans blâme » est-il plus efficace qu’un post-mortem cherchant un coupable ?

✅ Solution

Parce que chercher un coupable pousse les gens à se défendre et à cacher l’information (voire à dissimuler les incidents à l’avenir), ce qui empêche de comprendre les vraies causes et de s’améliorer. Un post-mortem sans blâme (blameless) part du principe que les personnes ont agi de bonne foi avec l’information dont elles disposaient, et cherche les causes systémiques : un contrôle manquant, un angle mort de détection, un process défaillant, une doc absente. C’est bien plus efficace car cela produit des correctifs durables (combler le trou, ajouter la détection, corriger le process) plutôt qu’une punition qui ne change rien au système. La culture de la transparence — favorisée par l’absence de blâme — fait qu’on apprend de chaque incident et qu’on le signale tôt, au lieu de le cacher. C’est ce qui renforce réellement la sécurité dans le temps.

🧠 Quiz de révision

1. Quelles sont les phases d’une réponse à incident ?

Préparer (plan, contacts, accès, sauvegardes — avant l’incident) → Détecter/analyser → Contenir (limiter la propagation) → Éradiquer (retirer la cause) → Rétablir (remettre en service proprement) → Retour d’expérience (post-mortem). Le cycle boucle vers une meilleure préparation.

2. Que signifie « contenir » et pourquoi est-ce urgent ?

Limiter la propagation et l’aggravation de l’incident : isoler le système compromis, révoquer secrets/sessions, couper le vecteur. C’est souvent l’action la plus urgente car elle stoppe l’hémorragie (exfiltration en cours, pivot de l’attaquant), avant même de tout résoudre.

3. Pourquoi ne pas rétablir avant d’avoir éradiqué la cause ?

Parce que rétablir sans avoir retiré la cause (faille non patchée, backdoor, compte malveillant, secret non révoqué) ou en restaurant une sauvegarde compromise fait revenir l’attaquant aussitôt — rechute assurée. On éradique complètement, puis on rétablit depuis une sauvegarde propre et testée, sous surveillance.

4. Qu’est-ce qu’un post-mortem « sans blâme » et pourquoi ?

Une analyse d’incident qui cherche les causes systémiques (contrôle manquant, angle mort) et non un coupable. Sans blâme, les gens partagent l’information et signalent les incidents (au lieu de les cacher), ce qui produit des correctifs durables. Orienté action : on comble le trou pour que ça ne se reproduise pas.

5. Quelles obligations RGPD en cas de violation de données ?

Documenter la violation (obligatoire), notifier l’autorité (la CNIL) sous 72 h si la violation présente un risque pour les personnes, et informer les personnes concernées si le risque est élevé. Impliquer le DPO. La détection rapide rend le délai de 72 h tenable (lien cours RGPD).

Fin de la Partie 15. La boucle est fermée : journaliser sans fuiter, détecter et alerter à temps, répondre avec méthode et notifier. Il ne reste qu’à capitaliser tout le cours en outils réutilisables : la Partie 16 — Cookbook & Annexes.