Incident Response Playbook : que faire quand ça pète
Un incident de sécurité, c’est pas une question de “si” mais de “quand”. Ce playbook te donne une méthodologie structurée en 5 phases pour gérer un incident de bout en bout : détection, confinement, éradication, récupération, et retour d’expérience. Avec des checklists concrètes et des outils concrets.
Pourquoi un playbook ?
Quand ça pète, le stress prend le dessus. Tu oublies des étapes, tu prends des décisions à l’arrache, tu effaces des preuves sans le vouloir. Un playbook, c’est ton GPS dans le chaos. Tu le prépares avant l’incident, pas pendant.
Les incidents qu’on a couverts sur ce blog — CrowdStrike, Log4Shell, LastPass — montrent tous la même chose : les organisations qui s’en sortent le mieux sont celles qui avaient un plan.
Phase 1 : Détection
L’incident est là. Première étape : confirmer que c’est réel et évaluer l’ampleur.
Checklist Détection
- Confirmer l’alerte (faux positif ou vrai incident ?)
- Identifier le type d’incident (intrusion, ransomware, fuite de données, DDoS, supply chain…)
- Déterminer les systèmes affectés
- Horodater la première détection
- Identifier le vecteur d’attaque si possible
- Notifier l’équipe de réponse (interne ou prestataire)
Outils de détection
| Outil | Usage |
|---|---|
| Prometheus + Grafana | Métriques, alertes sur anomalies |
| CrowdSec | Détection d’attaques en temps réel |
| Nuclei | Scan de vulnérabilités post-détection |
| OSINT | Vérification de fuite sur sources ouvertes |
| Logs centralisés (ELK, Loki) | Corrélation d’événements |
Décision clé
Est-ce que l’incident nécessite un confinement immédiat ?
Si le système est compromis en temps réel (exfiltration active, ransomware en cours) → passe directement à la Phase 2. Sinon, prends le temps de documenter.
Phase 2 : Confinement
Objectif : limiter les dégâts. Isoler les systèmes compromis sans détruire les preuves.
Checklist Confinement
- Isoler le réseau des systèmes compromis (VLAN, firewall, déconnexion)
- Ne pas éteindre la machine (tu perds la mémoire volatile) — préfère un snapshot mémoire
- Bloquer les IPs/domaines malveillants au niveau UFW/iptables
- Révoquer les credentials potentiellement compromis (tokens, clés API, mots de passe)
- Activer la collecte de logs renforcée
- Sauvegarder les logs actuels (ils seront écrasés sinon)
- Identifier les comptes compromis et les verrouiller
Confinement court terme vs long terme
Court terme (heures) : isolation réseau, blocage IP, désactivation de comptes.
Long terme (jours) : segmentation réseau, mise en place de CrowdSec renforcé, patch des vulnérabilités.
1
2
3
4
5
6
7
8
# Snapshot mémoire d'urgence (Linux)
sudo dd if=/dev/mem of=/mnt/external/memdump.raw bs=1M
# Capture réseau en cours
sudo tcpdump -i eth0 -w /mnt/external/capture_$(date +%Y%m%d_%H%M%S).pcap
# Lister les connexions actives
ss -tunap > /mnt/external/connexions_actives.txt
Phase 3 : Éradication
Tu as isolé le problème. Maintenant, tu nettoies.
Checklist Éradication
- Identifier la cause racine (vulnérabilité exploitée, phishing, config fautive…)
- Supprimer les backdoors, webshells, comptes non autorisés
- Patcher la vulnérabilité exploitée (voir scan Nuclei)
- Reconstruire les systèmes compromis à partir d’une image saine
- Vérifier l’intégrité des fichiers système (
aide,tripwire,rpm -Va) - Scanner l’ensemble de l’infra pour d’autres compromissions
- Vérifier les chaînes d’approvisionnement
Forensics : ne pas tout effacer
Avant de reconstruire, image le disque :
1
2
3
4
5
# Image forensique du disque
sudo dd if=/dev/sda of=/mnt/external/disk_image.dd bs=4M status=progress
# Hash de l'image pour intégrité
sha256sum /mnt/external/disk_image.dd > /mnt/external/disk_image.sha256
Garde ces images. Elles serviront pour l’analyse post-incident et éventuellement pour des poursuites judiciaires.
Phase 4 : Récupération
Tu remets en service. Progressivement, pas d’un coup.
Checklist Récupération
- Restaurer les systèmes à partir de backups vérifiés (pas de backup ? → BorgBackup)
- Appliquer tous les patches de sécurité
- Réinitialiser tous les mots de passe et clés (pas seulement ceux compromis)
- Activer l’authentification forte (passkeys/FIDO2)
- Remettre en production par étapes (canary deployment)
- Surveiller intensivement pendant 72h minimum
- Vérifier que les reverse proxies et configs Docker sont sains
Priorisation du redémarrage
| Priorité | Systèmes | Délai |
|---|---|---|
| P0 | Authentification, DNS, VPN | 0-4h |
| P1 | Services clients, API | 4-12h |
| P2 | Monitoring, CI/CD | 12-24h |
| P3 | Outils internes, dashboard | 24-72h |
Phase 5 : Retour d’expérience (Lessons Learned)
La phase la plus importante et la plus souvent sautée. Ne la skip pas.
Checklist Retour d’expérience
- Organiser un debrief dans les 5 jours ouvrés
- Documenter la timeline complète de l’incident
- Identifier ce qui a bien fonctionné
- Identifier ce qui a foiré
- Mettre à jour le playbook avec les leçons apprises
- Former l’équipe sur les nouveaux processus
- Mettre en place les corrections techniques (automatisation, monitoring renforcé)
- Communication aux parties prenantes (clients, autorités si RGPD)
Template de rapport d’incident
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
# Rapport d'incident — [ID]
## Résumé
- **Date de détection** : YYYY-MM-DD HH:MM
- **Date de résolution** : YYYY-MM-DD HH:MM
- **Durée totale** : Xh Xm
- **Sévérité** : Critique / Haute / Moyenne / Basse
- **Type** : Intrusion / Ransomware / Fuite / DDoS / Supply Chain
## Timeline
| Heure | Événement |
|---|---|
| HH:MM | Première alerte détectée |
| HH:MM | Confinement initié |
| HH:MM | Éradication terminée |
| HH:MM | Systèmes restaurés |
## Cause racine
[Description technique]
## Impact
- Systèmes affectés : [...]
- Données compromises : [...]
- Coût estimé : [...]
## Actions correctives
1. [...]
2. [...]
## Leçons apprises
- [...]
Cas réels couverts sur le blog
Chaque incident majeur apporte des leçons. Voici ceux qu’on a décortiqués :
- CrowdStrike 2024 — Un mauvais update peut paralyser des millions de machines. Leçon : rollback automatique, déployer par vagues.
- Log4Shell 2021 — Vulnérabilité dans une dépendance omniprésente. Leçon : inventaire des dépendances, SBOM.
- LastPass 2022 — Compromission du stockage de vaults. Leçon : chiffrement de bout en bout, zero-knowledge.
- n8n RCE 2026 — Exécution de code à distance via un outil d’automatisation. Leçon : ne pas exposer d’outils d’admin sur Internet.
- Hygiène post-fuite — Guide pratique pour nettoyer après une fuite de données.
Outils indispensables dans ta boîte à outils IR
1
2
3
4
5
6
7
8
9
10
11
12
13
14
# Capture réseau
tcpdump, tshark (Wireshark CLI), netsniff-ng
# Analyse disque
autopsy, sleuthkit, volatility3 (mémoire)
# Scan de vulnérabilités
nuclei, openvas, nmap
# Logs
journalctl, lnav, logsurfer
# Collecte d'artefacts
ir-responder, linux-explorer, UAC (Unix-like Artifacts Collector)
Intègre ces outils dans ton pipeline d’automatisation pour qu’ils soient prêts quand tu en auras besoin.
Prévention > Réaction
Le meilleur incident, c’est celui qui n’arrive pas. Voire mesures préventives essentielles :
- Hardening SSH — réduire la surface d’attaque
- CrowdSec + Fail2ban — détection proactive
- Sécurité Docker — ne pas exposer le socket
- Monitoring — détecter avant que ça devienne critique
- BorgBackup — pouvoir restaurer quand tout pète
Références :
- NIST SP 800-61 — Computer Security Incident Handling Guide
- CrowdStrike 2024
- Log4Shell
- LastPass
- CrowdSec
- Nuclei scan
- BorgBackup
- OSINT
- Monitoring Prometheus/Grafana
- Hygiène post-fuite
Besoin d’un audit de ta posture de réponse aux incidents ? Contacte-moi.