Comment mener un exercice de simulation d'incident

Comment mener un exercice de simulation d’incident

Un exercice de simulation d’incident teste la capacité réelle à décider sous contrainte, pas la qualité d’un plan de réponse présenté sur cinquante slides. Le compromis est net : on immobilise quelques personnes et on expose des lacunes parfois gênantes, en échange d’erreurs détectées avant qu’un attaquant ne les transforme en indisponibilité ou en fuite.

Explication de la marmotte

Cela ressemble à une répétition générale avant un spectacle où personne ne connaît encore toutes les mauvaises nouvelles. Le but est de voir si les personnes concernées savent se parler, choisir et agir quand la situation devient confuse, sans attendre le jour où le problème sera réel.

→ Lire l’explication complète de la marmotte

Préparer le scénario et le périmètre de simulation

Un exercice utile part d’une dépendance réellement critique : annuaire d’identité, messagerie, plateforme de production, coffre de secrets, sauvegarde ou accès d’administration. Commencer par un scénario générique de ransomware sur « le système d’information » produit des décisions génériques, donc aucune décision exploitable. Choisir un périmètre qui impose des arbitrages identifiables.

Trois scénarios couvrent la majorité des mécanismes à tester :

1. Compromission d’un compte administrateur : tester l’authentification forte, les comptes d’urgence, la journalisation, la révocation de session et la capacité à isoler une identité sans couper toute l’administration.
2. Rançongiciel sur une plateforme de production : tester la segmentation réseau, l’arrêt contrôlé, l’intégrité des sauvegardes, la restauration et les priorités métier.
3. Fuite de données : tester la qualification de la donnée exposée, la conservation des preuves, les accès aux journaux, les notifications internes et les dépendances contractuelles.

Le scénario doit contenir une hypothèse de départ vérifiable. Par exemple : « Une identité d’administration fédérée effectue des connexions inhabituelles depuis un emplacement non autorisé, puis crée un jeton d’accès persistant. » Éviter « un hacker entre dans le réseau », formulation qui ne teste rien sauf la capacité à prononcer le mot hacker avec gravité.

Définir ensuite les objectifs de décision, pas des objectifs de discussion. Pour une compromission d’identité, les objectifs peuvent être :

• décider qui peut suspendre un compte privilégié ;
• déterminer si les jetons actifs sont révoqués ;
• choisir entre isolement d’un tenant, arrêt d’un service ou surveillance renforcée ;
• vérifier l’accès aux journaux d’authentification et leur durée de rétention ;
• confirmer la disponibilité d’un compte d’administration hors bande.

Le périmètre doit exclure explicitement les actions destructrices. Un exercice de type tabletop, c’est-à-dire une simulation fondée sur des décisions discutées, ne valide pas qu’une restauration fonctionne réellement. Il valide que l’équipe sait demander la bonne restauration, retrouver le bon responsable et décider dans le bon ordre. La restauration doit être testée séparément, avec une procédure technique et un environnement isolé.

Relier le scénario aux architectures existantes. Les sujets d’identité doivent notamment être recoupés avec les règles de gestion des identités et les mécanismes de durcissement NTLM. Un compte administrateur compromis n’est pas un incident IAM (Identity and Access Management) abstrait : c’est souvent une chaîne qui traverse fédération, bastion, annuaire, sauvegardes et outils d’administration.

Constituer les participants et préparer les injects

Inviter les personnes qui détiennent une décision ou une information nécessaire. Une équipe uniquement technique produira des réponses techniquement élégantes mais parfois inexécutables. Une équipe uniquement dirigeante produira des décisions rapides, dont certaines méritent de rester dans un tiroir. Il faut les deux.

Le noyau minimal comprend :

• un responsable technique du périmètre affecté ;
• un responsable sécurité capable de qualifier l’incident ;
• un responsable de la décision opérationnelle ;
• un représentant communication ;
• un représentant juridique ou conformité, pour qualifier les obligations sans transformer l’exercice en consultation juridique ;
• un secrétaire de séance, distinct du facilitateur.

Ajouter les propriétaires de données, des prestataires ou le responsable continuité lorsque le scénario les implique réellement. Ne pas remplir une salle au nom de la transversalité. Au-delà d’une douzaine de participants actifs, la simulation devient un comité de pilotage avec un costume d’incident.

Préparer des injects, c’est-à-dire des informations nouvelles délivrées progressivement. Chaque inject doit forcer une décision, invalider une hypothèse ou révéler une dépendance. Un inject informatif sans effet sur une décision est du décor.

Prévoir un inject toutes les 10 à 15 minutes. Pour un scénario de compromission d’administrateur :

Moment	Inject	Décision attendue
0 min	Alerte de connexion privilégiée inhabituelle	Qualifier, ouvrir le canal de crise, attribuer les rôles
15 min	Création d’un nouveau compte à privilèges élevés	Suspendre, investiguer, préserver les preuves
30 min	Échec d’accès au coffre de secrets par un service critique	Arbitrer entre rétablissement et confinement
45 min	Publication externe évoquant une fuite	Déclencher communication, juridique et qualification des données
60 min	Sauvegarde disponible mais dernier point de restauration incertain	Décider du niveau de reprise acceptable

Chaque inject doit préciser sa source, son niveau de fiabilité et l’information réellement disponible. Une alerte de détection n’est pas une preuve. Une adresse IP n’est pas un coupable. Une capture d’écran sans horodatage est une décoration murale numérique.

Exemple de dossier d’exercice reproductible

Stocker le scénario, les injects et la grille de décisions dans un dépôt contrôlé. Ce dépôt contient des données de simulation, jamais des secrets, journaux de production ou captures non expurgées. Les éléments sensibles doivent être référencés par emplacement et procédure d’accès, pas copiés dans un fichier Markdown qui finira dans une archive, un export ou un moteur de recherche.

# Créer un dossier de simulation et un horodatage local.
mkdir -p exercice-incident/{injects,decisions,retex}
date -u +"%Y-%m-%dT%H:%M:%SZ" > exercice-incident/date-preparation.txt

# Définir le scénario et les limites de l'exercice.
cat > exercice-incident/scenario.md <<'EOF'
# Compromission d'un compte administrateur

Périmètre : fédération d'identité et accès d'administration.
Objectif : décider de la suspension, de la révocation des sessions
et du maintien des services critiques.
Hors périmètre : aucune action sur les systèmes de production.
EOF

# Préparer un inject avec une décision explicitement attendue.
cat > exercice-incident/injects/15-minutes.md <<'EOF'
Source : journal d'authentification, fiabilité élevée
Fait : création d'un compte avec privilèges élevés après la connexion suspecte.
Décision attendue : suspendre ou surveiller, préserver quelles preuves,
et désigner le responsable de l'action.
EOF

# Créer le registre de décisions à compléter pendant la séance.
printf '| Heure | Fait connu | Décision | Responsable | Preuve attendue |\n|---|---|---|---|---|\n' \
  > exercice-incident/decisions/registre.md

Versionner le dossier permet de conserver la version exacte des injects et d’éviter une réécriture a posteriori des faits. La traçabilité d’exercice n’est pas une preuve médico-légale, mais elle doit permettre de comprendre pourquoi une décision a été prise.

Animer la session de simulation d’incident

Réserver 90 minutes : 15 minutes de cadrage, 60 minutes de simulation, 15 minutes de débrief immédiat. Dépasser deux heures réduit la qualité des décisions et augmente la production de phrases du type « il faudrait revoir globalement le processus », ce qui est le bruit blanc favori des comptes rendus.

Le facilitateur rappelle le périmètre, expose la règle de non-blâme et délivre les injects. Son rôle consiste à demander : « Quelle décision est prise, par qui, sur quelle information et avec quel délai ? » Il ne propose ni procédure ni solution. Si le facilitateur résout l’incident, l’exercice mesure la compétence du facilitateur. C’est un résultat charmant mais sans intérêt.

Utiliser un tableau partagé avec quatre colonnes :

• faits confirmés ;
• hypothèses à vérifier ;
• décisions prises ;
• actions avec responsable et échéance.

Distinguer systématiquement le fait de l’inférence. « Le compte a créé un jeton » est un fait si le journal le démontre. « L’attaquant possède le poste de travail » est une hypothèse. Cette discipline évite de lancer une restauration parce qu’une alerte a fait peur. Une alerte n’obtient pas automatiquement le statut de prophétie.

Tester les dépendances humaines aussi durement que les dépendances techniques : numéro d’astreinte, délégation de pouvoir, accès au canal de crise, disponibilité du contact fournisseur, procédure d’escalade. Un contact introuvable est une vulnérabilité opérationnelle, pas un détail administratif.

Surface d’attaque, limites et conditions d’exploitation

Un exercice ne garantit pas qu’une équipe saura gérer un incident réel. La pression, l’incertitude, les systèmes indisponibles et les absences modifient les décisions. Il ne garantit pas non plus qu’un plan est techniquement exécutable, qu’une sauvegarde est restaurable ou qu’un outil de détection couvre l’attaque simulée.

Le risque principal est l’effet théâtre : scénario connu, réponses récitées, injects prévisibles, aucune contradiction. Pour le réduire, ne communiquer que le thème général aux participants, conserver les injects chez le facilitateur et intégrer au moins une dépendance dégradée : journal indisponible, contact absent, authentification d’urgence inaccessible ou sauvegarde ambiguë.

Protéger les informations utilisées pendant l’exercice. Les journaux, exports d’identité, clés d’API (Application Programming Interface) et procédures de secours élargissent la surface d’attaque s’ils sont recopiés dans les supports. Appliquer la minimisation : données synthétiques par défaut, accès temporaire aux preuves réelles, suppression ou archivage contrôlé après le retour d’expérience.

Les comptes d’urgence doivent être inclus dans le scénario, mais leurs secrets ne doivent jamais être affichés ni saisis dans le registre. Vérifier leur propriétaire, leur emplacement, leur rotation et les journaux d’usage. Une procédure qui dépend d’un mot de passe connu d’une seule personne n’est pas une procédure, c’est une loterie avec un classeur partagé.

La supervision doit mesurer le suivi : nombre d’actions ouvertes, échéances dépassées, temps de fermeture et récurrence par domaine. Les preuves et comptes rendus doivent être sauvegardés dans un espace avec contrôle d’accès, rétention définie et restauration testée. La gouvernance de la sécurité apporte le cadre de responsabilité ; l’exercice vérifie que ce cadre survit au désordre.

Retour d’expérience et actions de remédiation

Tenir le retour d’expérience dans les 48 heures, avant que les décisions ne soient reconstruites de mémoire. Le secrétaire relit le registre, puis classe chaque lacune dans une catégorie : processus absent, responsabilité ambiguë, contact inaccessible, outil non maîtrisé, droit insuffisant, journal absent ou dépendance non documentée.

Transformer chaque lacune en action vérifiable. « Améliorer la communication de crise » n’est pas une action. « Publier la liste des contacts de crise dans l’outil X, tester son accès hors réseau avant telle date, responsable nommé » en est une.

Une action doit comporter un propriétaire, une échéance, un critère de fermeture et une preuve attendue. Pour une lacune de révocation de sessions, la preuve peut être un test démontrant qu’un jeton actif devient inutilisable après suspension du compte. Pour une lacune de restauration, la preuve doit être un compte rendu de test avec durée, périmètre restauré et écarts constatés.

Ne fermer aucune action sur déclaration. Fermer sur preuve, puis rejouer le point défaillant lors d’un exercice suivant. Les audits aiment les tableaux verts. Les incidents préfèrent les mécanismes qui marchent quand personne ne trouve le tableau.

🐝 Ce qui arrive si on s’en passe

Sans exercice, la première mise à l’épreuve du dispositif est l’incident lui-même, avec un coût de découverte payé au pire moment. Les délais s’allongent sur des points qui ne relèvent pas de la technique : qui détient l’autorité de suspendre un compte privilégié, quel canal reste utilisable si la messagerie est compromise, quel prestataire répond hors heures ouvrées. Les rétentions courtes de journaux jouent alors contre l’investigation, les preuves disparaissant par rotation avant que quiconque ait pensé à les figer. Les comptes de secours restent supposés fonctionnels jusqu’au jour où leur rotation expirée se révèle. Les obligations de notification sont qualifiées tardivement, faute d’avoir déjà identifié les données concernées. Sans registre de décisions ni retour d’expérience, aucune lacune ne devient une action fermée sur preuve : les mêmes défauts réapparaissent à l’incident suivant.

🦫 Explication de la marmotte 🍫

Un exercice de simulation d’incident réunit les personnes qui devraient agir lors d’un problème grave de sécurité, sans toucher aux systèmes réels. On choisit d’abord un événement crédible, par exemple le vol d’un compte qui donne des droits très élevés. Le scénario doit concerner un service réellement utilisé, sinon les décisions resteront théoriques.

Avant la séance, une personne prépare des informations qui seront révélées petit à petit. Chaque information oblige le groupe à choisir une action : bloquer un compte, garder un service en marche, chercher des preuves, prévenir une direction ou contacter un prestataire. Une autre personne note les faits connus, les suppositions, les décisions et la personne chargée d’agir.

Pendant la séance, l’animateur donne les nouvelles informations mais ne décide pas à la place du groupe. Si une équipe ne sait pas qui peut arrêter un accès, où trouver une sauvegarde ou comment joindre un responsable, ce défaut doit apparaître. Le but n’est pas de réussir artificiellement, mais de trouver ce qui empêcherait une réaction correcte.

Après la séance, chaque défaut devient une tâche datée et attribuée. Une tâche n’est terminée que lorsqu’une preuve montre que le problème est corrigé. Si l’accès d’urgence ne fonctionne pas, il faut le tester après correction. Sinon, le défaut reste présent, seulement mieux rédigé dans un compte rendu.

À lire aussi

• Exécuter un threat hunting à partir d'une hypothèseGuide pas-à-pas pour préparer, exécuter et pérenniser un exercice de threat hunting fondé sur une hypothèse vérifiable.
• Réagir aux premières minutes d’un incident suspectéChecklist opérationnelle pour isoler une anomalie, alerter les bonnes personnes et préserver les premières preuves avant une réponse à incident spécialisée.
• Configurer une détection open source avec WazuhGuide pratique pour centraliser les journaux, installer Wazuh et détecter les premières tentatives d’accès suspectes sans SIEM commercial.
• Pourquoi MTTD et MTTR biaisent la sécuritéLe MTTD et le MTTR valorisent les incidents détectés et traités, mais masquent structurellement ceux qui restent invisibles.

Pages voisines

La citent

• AI Act : surveillance après commercialisation et signalement des incidents graves d'une IA à haut risque (articles 72 et 73)
• Comment organiser une astreinte cybersécurité durable
• Communiquer un incident à une direction non technique
• Faille Target 2013, alertes FireEye ignorées et segmentation
• Réponse à incident NIST SP 800-61r3, cycle complet et architecture

Comment mener un exercice de simulation d'incident

Elle cite

• ⇄Lien dans les deux sens :Comment préparer un plan de communication de crise
• Communiquer pendant un incident et mener un retex
• Culture juste après un incident de sécurité
• NTLM : protocole authentification LAN Manager New Technology Microsoft

⇄ : les deux pages se citent l’une l’autre.