Création de Playbooks de Réponse aux Incidents
Quand l'utiliser
- Établir ou faire évoluer un programme de réponse aux incidents à partir de zéro
- Documenter des procédures pour un nouveau type d'incident après une attaque inédite
- Automatiser les workflows de réponse dans une plateforme SOAR (Cortex XSOAR, Splunk SOAR)
- Se préparer à des audits de conformité exigeant des procédures IR documentées (SOC 2, PCI-DSS, HIPAA)
- Effectuer une analyse des lacunes des capacités IR existantes par rapport à des scénarios de menace spécifiques
Ne pas utiliser pour des investigations ponctuelles ad hoc ; les playbooks sont des documents de procédure réutilisables, pas des rapports spécifiques à un cas.
Prérequis
- Évaluation des risques organisationnels identifiant les principaux scénarios d'incident par probabilité et impact
- Cadre NIST SP 800-61r3 ou SANS PICERL adopté comme norme IR organisationnelle
- Inventaire des actifs avec leur criticité métier et leur classification des données
- Diagramme RACI définissant les rôles : Commandant des Incidents, analystes SOC, administrateurs système, juridique, communication
- Inventaire des capacités de détection existantes (règles SIEM, détections EDR, signatures IDS)
- Accès à la plateforme SOAR si vous construisez des playbooks automatisés
Workflow
Étape 1 : Sélectionner et Définir le Périmètre du Type d'Incident
Définir le scénario spécifique que le playbook traitera :
- Identifier les principaux types d'incidents sur la base de l'évaluation des risques organisationnels et des données historiques
- Délimiter chaque playbook à un seul type d'incident pour plus de clarté (ne pas combiner des scénarios non liés)
- Définir les conditions de déclenchement qui activent le playbook
Types de playbook courants :
Playbooks Prioritaires (à construire en premier) :
1. Réponse aux incidents ransomware
2. Compromission de phishing/identifiants
3. Compromission de courrier professionnel
4. Infection par malware
5. Violation de données/exfiltration
6. Attaque DDoS
7. Menace interne
8. Prise de compte
9. Compromission d'application web
10. Compromission d'infrastructure cloud
Étape 2 : Définir la Structure du Playbook
Chaque playbook doit suivre une structure cohérente :
MODÈLE DE PLAYBOOK
━━━━━━━━━━━━━━━━
1. Métadonnées du Playbook
- Nom, version, propriétaire, date de dernière révision
- Conditions de déclenchement
- Critères de gravité
2. Matrice RACI
- Qui est Responsable, Accountable, Consulté, Informé pour chaque étape
3. Détection & Triage
- Comment l'incident est détecté
- Liste de contrôle de triage initial
- Critères de classification de la gravité
4. Confinement
- Actions de confinement à court terme
- Actions de confinement à long terme
- Exigences de préservation des preuves
5. Éradication
- Identification de la cause racine
- Étapes de suppression du malware/menace
- Procédures de vérification
6. Rétablissement
- Étapes de restauration du système
- Critères de validation
- Exigences de surveillance après rétablissement
7. Post-Incident
- Déclencheur de réunion de retour d'expérience
- Modèle de rapport
- Actions d'amélioration de la détection
8. Communication
- Matrice de notification interne
- Exigences de notification externe (régulateurs, clients, forces de l'ordre)
- Cadence des mises à jour de statut
9. Annexes
- Procédures spécifiques aux outils
- Listes de contacts
- Listes de contrôle pour la collecte de preuves
Étape 3 : Rédiger les Arbres de Décision et les Critères d'Escalade
Définir des points de décision clairs avec des résultats binaires :
Alerte de Détection Reçue
├── L'alerte est-elle un vrai positif ?
│ ├── OUI → Classifier la gravité
│ │ ├── P1 (Critique) → Alerter le commandant des incidents, commencer le confinement immédiatement
│ │ ├── P2 (Élevé) → Notifier le responsable IR, commencer l'enquête dans les 30 min
│ │ ├── P3 (Moyen) → Mettre en file d'attente pour enquête dans les 4 heures
│ │ └── P4 (Faible) → Documenter et enquêter dans les 24 heures
│ └── NON → Documenter comme faux positif, ajuster la règle de détection
└── Impossible à déterminer → Escalader vers le niveau 2 pour analyse approfondie
Déclencheurs d'escalade :
- Tout incident P1 : Escalade immédiate au responsable IR et au RSSI
- Exfiltration de données confirmée : Avocat et délégué à la protection des données notifiés
- Données clients impliquées : Processus de notification client activé
- Implication d'un tiers : Contact de sécurité du fournisseur engagé
- Forces de l'ordre nécessaires : Le conseiller juridique autorise avant tout contact
Étape 4 : Définir les Procédures Techniques Spécifiques
Rédiger des instructions spécifiques aux outils pour chaque étape (pas de conseils génériques) :
CONFINEMENT - Isolation de l'Endpoint via CrowdStrike :
1. Ouvrir la Console Falcon > Hôtes > Rechercher le nom d'hôte affecté
2. Cliquer sur l'hôte > Détails de l'hôte
3. Cliquer sur le bouton "Contenir l'hôte" en haut à droite
4. Confirmer l'isolation (l'hôte ne communiquera qu'avec le cloud CrowdStrike)
5. Documenter l'action de confinement dans le ticket d'incident avec l'horodatage
6. Vérifier le confinement : L'hôte doit afficher le badge "Contenu"
CONFINEMENT - Bloquer le domaine C2 au niveau DNS :
1. SSH vers le serveur DNS : ssh [email protected]
2. Ajouter à la zone de blocage : echo "zone evil.com { type master; file /etc/bind/db.sinkhole; };" >> /etc/bind/named.conf.local
3. Recharger le DNS : rndc reload
4. Vérifier : dig @dns-principal evil.com (doit résoudre vers l'IP du sinkhole 10.0.0.99)
5. Documenter le domaine bloqué dans le ticket d'incident
Étape 5 : Intégrer avec la Plateforme SOAR
Convertir les étapes manuelles du playbook en workflows automatisés :
- Mapper chaque étape du playbook à une action SOAR (appel API, script, point de décision humain)
- Définir les limites de l'automatisation (ce qui s'exécute automatiquement vs. ce qui nécessite l'approbation de l'analyste)
- Créer des automatisations d'enrichissement pour la phase de triage
- Créer des automatisations de confinement avec des portes d'approbation pour les actions à fort impact
- Configurer des automatisations de notification pour la communication avec les parties prenantes
Étape 6 : Tester et Maintenir le Playbook
Valider le playbook par des exercices et assurer sa mise à jour :
- Organiser des exercices de table avec l'équipe IR en parcourant le playbook
- Effectuer des exercices en conditions réelles simulant le type d'incident dans un environnement de test
- Réviser et mettre à jour après chaque incident réel qui utilise le playbook
- Planifier des révisions trimestrielles pour l'exactitude des listes de contacts, des procédures d'outils et des chemins d'escalade
- Suivre les métriques du playbook : temps moyen de confinement, temps moyen de résolution, taux de faux positifs
Concepts Clés
| Terme | Définition |
|---|---|
| Playbook | Ensemble documenté et reproductible de procédures pour répondre à un type d'incident spécifique |
| Runbook | Plus granulaire qu'un playbook ; instructions techniques étape par étape pour une tâche spécifique au sein d'un playbook |
| Matrice RACI | Tableau d'attribution des responsabilités définissant qui est Responsable, Accountable, Consulté et Informé pour chaque activité |
| Arbre de Décision | Logique basée sur un organigramme définissant le parcours de réponse en fonction de conditions binaires à chaque point de décision |
| Critères d'Escalade | Conditions prédéfinies qui déclenchent la notification de personnel de niveau supérieur ou de parties externes |
| Playbook SOAR | Workflow automatisé dans une plateforme d'Orchestration, d'Automatisation et de Réponse de Sécurité exécutant les étapes du playbook |
Outils & Systèmes
- Cortex XSOAR : Plateforme SOAR avec éditeur visuel de playbooks, plus de 700 intégrations et War Room collaborative
- Splunk SOAR : Plateforme SOAR intégrée à Splunk ES, constructeur de playbooks par glisser-déposer avec plus de 2 800 actions automatisées
- TheHive : Plateforme open source de réponse aux incidents avec des modèles de cas qui font office de frameworks de playbook
- Confluence / GitLab Wiki : Plateformes de documentation pour maintenir des documents de playbook lisibles avec contrôle de version
- Tines : Plateforme d'automatisation de sécurité sans code pour construire des workflows de playbook sans programmation
Scénarios Courants
Scénario : Créer un Playbook de Réponse aux Phishing à partir de Zéro
Contexte : Une organisation avec une équipe SOC de 5 personnes ne dispose d'aucune procédure documentée de réponse aux phishing. Les analystes traitent les signalements de phishing de manière incohérente.
Approche :
- Interroger les analystes SOC pour documenter leur processus ad hoc actuel
- Définir le déclencheur : l'utilisateur signale un e-mail de phishing via la boîte abuse@ ou le bouton de signalement
- Rédiger les étapes de triage : extraire les en-têtes d'e-mail, vérifier la réputation de l'expéditeur, analyser les URL/pièces jointes dans un bac à sable
- Définir le confinement : mettre en quarantaine l'e-mail de toutes les boîtes aux lettres, bloquer le domaine de l'expéditeur, réinitialiser les mots de passe si des identifiants ont été saisis
- Construire l'automatisation SOAR : extraire automatiquement les IOC de l'e-mail signalé, enrichir via VirusTotal, créer un cas dans TheHive
- Tester avec un e-mail de phishing simulé et mesurer l'amélioration du temps de réponse
Pièges à éviter :
- Rédiger des procédures trop génériques qui ne font pas référence à des interfaces ou commandes d'outils spécifiques
- Ne pas inclure le plan de communication pour notifier les utilisateurs qui ont reçu l'e-mail de phishing
- Oublier de définir les critères pour lesquels un signalement de phishing devient une enquête d'incident complète
- Ne pas versionner le playbook ou ne pas planifier de cycles de révision réguliers
Format de Sortie
PLAYBOOK DE RÉPONSE AUX INCIDENTS
====================================
Nom du Playbook : Réponse aux Incidents de Phishing
Version : 2.1
Propriétaire : Responsable SOC
Dernière Révision : 2025-11-01
Prochaine Révision : 2026-02-01
Déclencheur : E-mail de phishing signalé via [email protected] ou bouton de signalement
MATRICE RACI
Activité | SOC N1 | SOC N2 | Responsable IR | Juridique | Communications
Triage initial | R | C | I | |
Analyse d'e-mail | R | A | I | |
Confinement | | R | A | I |
Réinitialisation d'identifiants | | R | A | |
Notification utilisateur | | C | A | | R
Notification réglementaire | | | C | R | A
Retour d'expérience | C | C | R | I | I
ÉTAPES DE PROCÉDURE
[Étapes détaillées avec instructions spécifiques aux outils]
ARBRE DE DÉCISION
[Logique sous forme d'organigramme]
MATRICE D'ESCALADE
[Conditions et contacts]
MÉTRIQUES
Temps cible de détection (MTTA) : 15 minutes
Temps cible de confinement (MTTC) : 1 heure
Temps cible de résolution (MTTR) : 4 heures