Analyse post-incident : comment la conduire pour qu’elle serve

La mesure 5.27 d’ISO/IEC 27002:2022 — tirer des enseignements des incidents — est l’une des plus faciles à déclarer et des plus rarement appliquées sérieusement.

Un incident traité sans analyse se reproduira, souvent à l’identique.

Quand la conduire

Pas pendant la crise, et pas trois mois après. Pendant, les gens gèrent. Trois mois après, les souvenirs sont reconstruits et les acteurs sont passés à autre chose.

La bonne fenêtre : une à deux semaines après le retour à la normale. Assez tard pour que la fatigue soit retombée, assez tôt pour que les faits soient frais et les journaux disponibles.

La règle qui conditionne tout

On ne cherche pas de coupable. Cette règle doit être annoncée, répétée et tenue.

Si les participants pensent qu’un responsable sera désigné, ils protègeront leur périmètre. Vous obtiendrez une chronologie officielle, exacte et inutile, dont toutes les zones d’ombre auront disparu.

Un incident est presque toujours le résultat d’un enchaînement de décisions raisonnables prises avec l’information disponible. Chercher l’erreur individuelle empêche de voir le défaut systémique.

Reconstituer la chronologie

Deux fils parallèles — et c’est leur comparaison qui apprend quelque chose.

Le fil des faits techniques : quand l’attaquant est entré, ce qu’il a fait, quand les premiers signaux sont apparus. Il vient des journaux, d’où l’importance de leur rétention.

Le fil des décisions : quand quelqu’un a remarqué, qui a été prévenu, quand l’isolement a été décidé, ce qui a retardé chaque étape.

L’écart entre les deux est le vrai livrable. « L’alerte est apparue à 3 h 12, elle a été examinée à 9 h 40, l’isolement a été décidé à 14 h 20 » indique exactement où travailler.

Chercher les causes, au pluriel

Un incident a rarement une cause unique. La méthode qui fonctionne consiste à remonter par « pourquoi » successifs jusqu’à sortir du technique.

Un serveur non corrigé n’est pas une cause, c’est un symptôme. Pourquoi n’était-il pas corrigé ? Il n’était pas dans l’inventaire. Pourquoi ? Il a été mis en service hors processus. Pourquoi ? Le processus prenait six semaines et le projet était en retard.

La cause traitable est là, pas sur le serveur.

Ce qu’on découvre presque toujours

• L’alerte existait et n’a pas été traitée — problème de volume, voir alertes et incidents.
• Personne ne savait qui avait autorité pour isoler.
• Les journaux nécessaires n’existaient pas ou avaient expiré.
• Un accès prestataire oublié était le point d’entrée.
• La restauration a pris trois fois le temps annoncé.

Ces cinq constats reviennent avec une régularité frappante, et aucun n’est une surprise technique.

Le livrable

Court. Une chronologie, trois à cinq causes, et pour chacune une action avec un responsable nommé et une échéance.

Un rapport de quarante pages ne produit rien. Trois actions suivies en produisent.

Ce document sert aussi de preuve pour un auditeur, un assureur et, le cas échéant, pour le rapport final exigé par les régimes de notification.

Le suivi

C’est l’étape qui manque. Les actions décidées doivent être suivies dans la même instance que le reste — voir le comité sécurité.

Un an après, la question à poser : combien de ces actions ont été mises en œuvre ? Si la réponse est aucune, le prochain incident sera le même.

Les traces qui manquent, et ce qu’on peut faire sans elles

L’analyse bute presque toujours sur le même mur : les éléments nécessaires à la reconstitution n’existent plus, ou n’ont jamais existé. Journaux écrasés par rotation, poste réinstallé dans l’urgence, machine virtuelle supprimée, sauvegardes qui ne remontent pas assez loin.

Deux réflexes limitent les dégâts, et ils se prennent dans les premières heures, avant même que l’analyse ne commence :

• Suspendre la rotation et l’effacement automatique sur les systèmes concernés et sur ceux qui les entourent. C’est une action de quelques minutes qui préserve des semaines de travail ultérieur.
• Ne pas réinstaller avant de copier. La pression pour remettre en service est légitime et forte. Une copie du disque, même faite rapidement, permet de rétablir le service tout de suite et d’analyser ensuite. Sans elle, l’arbitrage est définitif.

Quand les traces manquent malgré tout, il reste préférable de conclure honnêtement que d’inventer. Un rapport qui écrit « le vecteur d’entrée n’a pas pu être établi, faute de journalisation sur les accès distants antérieurs au 12 du mois » produit deux résultats utiles : il évite de fonder un plan d’action sur une hypothèse fausse, et il documente précisément le manque de visibilité à corriger. C’est souvent la recommandation la plus rentable de tout l’exercice.

Les recommandations qui ne seront jamais appliquées

Un rapport post-incident produit typiquement une vingtaine de recommandations. Un an plus tard, un tiers a été traité. La sélection ne se fait pas au hasard, et connaître le mécanisme permet d’écrire un rapport plus efficace.

Ce qui ne s’applique jamais : les recommandations qui n’ont pas de destinataire nommé, celles qui supposent un budget non identifié, celles qui demandent une transformation de plusieurs années sans première étape définie, et celles qui sont rédigées comme des principes plutôt que comme des actions — « renforcer la culture de sécurité » n’est pas exécutable.

Ce qui s’applique : les actions dont le coût est inférieur au souvenir de l’incident. C’est une fenêtre courte. Dans les six semaines qui suivent une compromission sérieuse, des arbitrages refusés pendant trois ans se débloquent. Passé ce délai, le coût redevient l’argument dominant.

La conséquence pratique est un ordre de rédaction : placer en tête les mesures structurantes qui étaient jusque-là refusées, tant que la fenêtre est ouverte. Les corrections techniques immédiates, elles, seront faites de toute façon.

Distinguer trois niveaux de cause

La recherche de causes multiples s’arrête souvent trop tôt, à la cause technique. Séparer explicitement trois niveaux évite ce raccourci et change la nature des recommandations.

Le niveau technique : le service exposé, le correctif absent, le droit excessif. C’est le plus visible et le plus simple à corriger — mais le corriger seul garantit la répétition sur un autre système.

Le niveau processus : pourquoi ce service a-t-il été exposé sans revue, pourquoi ce correctif n’a-t-il pas été appliqué dans le délai prévu, pourquoi ce droit n’a-t-il pas été retiré au changement de poste. C’est le niveau qui produit les recommandations réellement préventives.

Le niveau arbitrage : quelle contrainte a conduit à ce processus. Un délai de projet tenu au prix d’une revue de sécurité sautée, une équipe dimensionnée pour l’exploitation courante et pas pour les mises à jour, un budget refusé deux ans plus tôt. Ce niveau est inconfortable parce qu’il remonte au-dessus de l’équipe technique — et c’est précisément pourquoi il doit figurer au rapport.

Un rapport qui s’arrête au premier niveau se lit facilement et ne change rien. Un rapport qui atteint le troisième est plus difficile à faire accepter, et c’est le seul qui justifie les moyens demandés.

Ce qu’on doit aussi regarder : ce qui a fonctionné

L’exercice se concentre naturellement sur les défaillances. Il passe à côté d’une information de même valeur : ce qui a limité l’impact.

Une sauvegarde hors ligne qui a permis de restaurer, un cloisonnement réseau qui a contenu la propagation, un salarié qui a signalé, une astreinte qui a répondu en vingt minutes. Ces éléments ont souvent fait la différence entre un incident et une crise — et ils sont fragiles : ce sont les premières lignes coupées au budget suivant, précisément parce que leur contribution n’a jamais été écrite nulle part.

Les documenter au rapport a un effet direct l’année suivante, quand il faudra justifier leur maintien. C’est aussi la seule partie de l’exercice qui reconnaisse le travail des équipes, dans un moment où elles n’entendent généralement parler que de ce qui a échoué.

Sources

• ISO/IEC 27002:2022, mesures 5.24 à 5.28
• Directive (UE) 2022/2555 (NIS 2), article 23 — rapport final
• ANSSI — guides de gestion de crise cyber

Aller plus loin

Nous conduisons ces analyses en gouvernance, risques et conformité. Voir aussi préparer un exercice de crise.