Aller au contenu
ZxR Cyber Sentinel 4.1 est disponible — Découvrir nos modeles IA
Technique

Réponse aux incidents : construire un playbook qui tient sous pression

Équipe Zaxyr 2026-02-01 11 min

Un playbook se juge sur un seul critère : quelqu'un qui n'a pas participé à sa rédaction doit pouvoir l'exécuter à trois heures du matin. La plupart échouent à ce test, non par manque de contenu, mais parce qu'ils décrivent une doctrine au lieu de donner des instructions.

Les quatre phases, et celle qu'on oublie

Le NIST SP 800-61 structure la réponse en quatre phases : préparation ; détection et analyse ; confinement, éradication et rétablissement ; activité post-incident.

La quatrième est celle qu'on saute. L'incident est clos, l'équipe est épuisée, et le retour d'expérience est reporté puis oublié. C'est pourtant la seule phase qui améliore les trois autres. Une organisation qui traite dix incidents sans jamais conduire de retour d'expérience traite le onzième exactement comme le premier.

Ce qui distingue un playbook exploitable

Un déclencheur nommé. Pas « en cas de suspicion d'intrusion » mais « alerte X sur le système Y », ou « signalement d'un tiers ». Un playbook sans déclencheur précis ne se déclenche pas.

Des décisions, pas des étapes. Le cœur d'un playbook n'est pas la liste des commandes, c'est l'arbre de décision : isoler ou observer, couper l'accès distant ou le laisser pour tracer, prévenir le client maintenant ou après qualification. Ces choix ont des conséquences opposées et doivent être arbitrés à froid.

Un décideur par décision. Une décision sans nom est une décision qui attend. Écrire la fonction et le moyen de la joindre, avec un suppléant.

Ce qu'il ne faut pas faire. Éteindre une machine détruit la mémoire vive et les traces. Réinitialiser un mot de passe prévient l'attaquant. Ces contre-indications ont plus de valeur que les étapes positives, parce qu'elles corrigent le réflexe.

Un critère de sortie. À quelle condition l'incident est-il clos. Sans lui, un incident reste ouvert des semaines ou se ferme trop tôt.

La matrice d'escalade

Trois niveaux suffisent. Ce qui compte est le critère de bascule, pas le nombre de niveaux.

| Niveau | Critère | Qui décide | |---|---|---| | 1 | Poste isolé, pas de donnée sensible, pas de propagation | Équipe d'exploitation | | 2 | Plusieurs systèmes, service dégradé, ou donnée personnelle possiblement touchée | Responsable sécurité | | 3 | Activité essentielle interrompue, données exfiltrées, ou notification réglementaire probable | Direction générale |

Le passage au niveau 3 doit être une décision réversible : mieux vaut escalader et redescendre qu'attendre la certitude. Le coût d'une escalade inutile est une réunion, celui d'une escalade tardive est une notification hors délai.

Les horloges réglementaires démarrent tôt

Deux obligations courent en parallèle, avec des points de départ différents.

NIS2. Pour les entités concernées, alerte précoce dans les 24 heures suivant la prise de connaissance d'un incident significatif, notification étayée sous 72 heures, rapport final sous un mois. Le déclencheur est la prise de connaissance, pas la confirmation.

RGPD. Notification à l'autorité de contrôle dans les 72 heures après en avoir pris connaissance, lorsque la violation est susceptible d'engendrer un risque pour les droits et libertés. Communication aux personnes concernées si le risque est élevé.

Conséquence pratique : la qualification réglementaire doit figurer dans le playbook, à exécuter dans les premières heures, et pas à la fin. Une équipe technique concentrée sur le confinement laisse passer le délai sans s'en apercevoir. Un rôle distinct doit porter cette question dès l'ouverture de l'incident.

Les cinq playbooks qui couvrent le plus de cas

Rançongiciel, compromission de messagerie, exfiltration de données, compromission de compte à privilèges, indisponibilité d'un fournisseur critique. Ils ne couvrent pas tout, mais ils couvrent l'essentiel des cas réels et partagent une bonne part de leurs étapes, ce qui rend l'écriture des suivants plus rapide.

L'éprouver, sinon il ne vaut rien

Un playbook non testé est une intention. Trois formats, par coût croissant.

La revue sur table réunit les décideurs autour d'un scénario écrit, sans rien exécuter. Elle révèle les décisions sans décideur et les numéros de téléphone obsolètes, ce qui est déjà beaucoup.

L'exercice fonctionnel exécute réellement les étapes techniques sur un périmètre restreint. Il révèle les accès manquants et les procédures qui supposent un outil indisponible.

L'exercice de crise mobilise la direction et la communication. Il révèle le point de rupture le plus fréquent, qui n'est pas technique : personne ne sait qui parle aux clients.

Un point à vérifier explicitement : la documentation reste-t-elle accessible si le système d'information est chiffré. Un playbook stocké sur l'intranet compromis n'existe plus au moment où il sert.

Ce que Zaxyr apporte

Zaxyr rattache chaque playbook aux exigences qui l'imposent, notamment la gestion des incidents de NIS2 et les contrôles correspondants de l'annexe A d'ISO 27001. La date du dernier exercice est suivie comme une preuve à part entière, puisque c'est elle que l'auditeur demande, et les délais de notification sont décomptés depuis l'ouverture de l'incident plutôt que rappelés dans un document.

Automatisez votre conformité

Découvrez comment Zaxyr transforme votre approche de la cybersécurité.