Réponse à incident : un tabletop de deux heures cette semaine

Un exercice sur table (tabletop) demande une salle, un scénario, deux heures et quelqu'un qui note ce qui dysfonctionne. Pas besoin de prestataire, de budget ni d'un plan de réponse à incident finalisé. L'objectif est de découvrir, tant que rien ne brûle, qui décide réellement de débrancher un serveur du réseau et où sont conservés les numéros de téléphone.

Choisissez un seul scénario et les bonnes personnes

Choisissez un scénario unique. Un ransomware sur un serveur de fichiers et la prise de contrôle d'une boîte mail de la finance sont les deux plus utiles pour une petite équipe, car tous deux obligent à trancher sur l'isolation, la communication et la restauration. N'essayez pas de couvrir les deux dans la même session.

Inutile d'écrire le scénario de zéro. L'Exercise in a Box du NCSC est gratuit, propose des exercices sur table couvrant des sujets comme le ransomware et le phishing, et fournit du matériel pour préparer, planifier, animer l'exercice et identifier les actions à mener ensuite. Les Tabletop Exercise Packages de la CISA proposent des objectifs types, des questions de discussion, un formulaire de retour d'expérience et un After Action Report, avec notamment des scénarios de ransomware et d'administration locale. Utilisez-les comme trame et adaptez les détails à vos propres systèmes.

Invitez les personnes qui seraient réellement sur l'appel :

• la personne qui administre l'annuaire et les sauvegardes
• celle qui peut approuver une interruption de service (un responsable, pas seulement l'IT)
• quelqu'un qui gère la communication externe, même s'il s'agit de la responsable administrative
• un animateur qui ne joue pas et ne répond à aucune question

L'animateur est essentiel. Si la même personne déroule le scénario et défend sa propre configuration, l'exercice se transforme en démonstration.

L'agenda de deux heures

Fixez une règle dès le départ : les réponses doivent correspondre à ce que vous feriez réellement avec les accès et les outils dont vous disposez aujourd'hui, et non à ce que dit la politique. Si quelqu'un répond « on vérifierait les logs », l'animateur demande lesquels, où, et qui y a accès à 07:40 un lundi matin.

Injects pour la version ransomware

Distillez le scénario par étapes plutôt qu'en une seule fois. Voici une séquence réaliste :

1. Un utilisateur signale que des documents d'un lecteur partagé ont changé d'extension et qu'un fichier texte contenant une demande de rançon figure dans chaque dossier.
2. Deux autres utilisateurs signalent la même chose. Le serveur de fichiers est lent.
3. La console de sauvegarde indique que la dernière tâche s'est terminée, mais le serveur de sauvegarde est joint au domaine.
4. La note de l'attaquant menace de publier des données dans 72 heures.
5. La messagerie est en panne, car le connecteur de messagerie tourne sur un hôte touché.

Chaque étape appelle une question. Qui peut isoler l'hôte, et faut-il une validation ? Les sauvegardes sont-elles accessibles avec les mêmes identifiants d'administration que l'attaquant détient peut-être ? Où se trouve la liste de contacts si l'annuaire et la messagerie sont indisponibles ? Qui décide d'impliquer la police ou une autorité de régulation, et qui contacte votre assureur ?

Injects pour la version prise de contrôle de compte

Commencez par un utilisateur de la finance qui signale des demandes MFA répétées qu'il n'a pas déclenchées. Ajoutez ensuite une connexion depuis un pays inhabituel, puis la découverte d'une règle de boîte de réception qui transfère les messages vers une adresse externe, et enfin une facture aux coordonnées bancaires modifiées envoyée à un client. Demandez comment vous révoquez les sessions et les jetons, et pas seulement comment vous réinitialisez le mot de passe. Demandez jusqu'où remontent vos logs de connexion, et qui vérifie la présence de règles et de délégations d'accès sur la boîte mail. Si vous souhaitez vérifier rapidement si des identifiants de vos collaborateurs figurent déjà dans des fuites publiques, notre vérificateur de mots de passe compromis est une bonne étape préparatoire.

Consignez les écarts tant qu'ils sont frais

Le scribe tient un journal brut. Ne le mettez pas au propre pendant la session. Une ligne ressemble à ceci :

Inject 3 | Backups reachable with domain admin | Gap: backup server domain-joined,
no offline copy confirmed | Owner: infra lead | Fix by: 30 days | Severity: high

Chaque écart a besoin d'un responsable et d'une échéance, sans quoi ce n'est qu'un vœu pieux. Classez-les selon ce qui vous aurait empêchés de travailler, pas selon leur caractère embarrassant. Les constats typiques sont prosaïques : personne ne connaissait l'identifiant du registrar, le numéro d'astreinte était périmé, la personne habilitée à arrêter la production était en congé et n'avait pas de suppléant.

Demandez aux participants un retour écrit avant qu'ils ne partent. Le package de la CISA inclut un modèle de formulaire de retour et un After Action Report, ce qui vous évite d'avoir à concevoir l'un ou l'autre.

Transformez le journal en runbook

Dans la semaine, convertissez le journal en un runbook court. Une à deux pages par scénario suffisent. Un runbook que personne ne lit pendant un incident est pire que pas de runbook.

Il doit inclure :

• La première heure : des actions numérotées, chacune attribuée à un rôle nommé plutôt qu'au nom d'une personne.
• Les droits de décision : qui peut isoler des systèmes, qui peut approuver le financement d'une aide externe, qui s'adresse aux clients.
• Les contacts : imprimés ou stockés hors ligne, couvrant les équipes, les fournisseurs, votre FAI, votre assureur et les intervenants externes.
• La gestion des preuves : ce qu'il ne faut ni effacer ni redémarrer avant que quelqu'un ait réalisé des images disques et collecté les logs.
• L'ordre de restauration : quels systèmes reviennent en premier et ce qui prouve qu'ils sont sains.

Pour une structure plus large, le Computer Security Incident Handling Guide du NIST, SP 800-61 Rev. 2, est très largement cité, mais le NIST l'a retiré le 3 avril 2025 et l'a remplacé par la Rev. 3 : prenez donc la révision en vigueur comme référence. Si vous souhaitez un regard extérieur sur le runbook ou de l'aide pour animer la session, découvrez nos services de réponse à incident et de conseil.

Planifiez ensuite la répétition. Menez l'autre scénario dans trois à six mois, et retestez les correctifs issus du premier journal des écarts.

Par où commencer

1. Réservez deux heures cette semaine et bloquez les agendas des quatre ou cinq personnes qui seraient sur l'appel.
2. Téléchargez un scénario de ransomware ou de phishing depuis Exercise in a Box ou un package de la CISA, et modifiez-le pour qu'il corresponde à vos systèmes réels.
3. Désignez un animateur qui ne jouera pas, et un scribe qui tiendra le journal des écarts.
4. Menez la session avec les vrais outils ouverts : console de sauvegarde, annuaire, logs de connexion, liste de contacts.
5. Attribuez un responsable et une échéance à chaque écart avant que la salle ne se vide.
6. Rédigez le runbook d'une page dans les sept jours et déposez-en une copie à un endroit accessible même quand votre réseau ne l'est pas.