Aller au contenu
←Retour au glossaireCyber

Analyse de cause racine (après incident)

Enquête menée après un incident pour remonter de son déclencheur aux défauts de processus, de contrôle ou de technique qui l'ont permis, exigée par DORA et par le rapport final de NIS2, et lue par le souscripteur au sinistre comme au renouvellement.

Définition

L'analyse de cause racine est l'enquête qui part du déclencheur d'un incident pour retrouver les défauts de processus, de contrôle ou de technique qui l'ont rendu possible. Le 6 août 2024, CrowdStrike publie l'analyse de cause racine de la panne du 19 juillet, qui avait fait tourner en boucle de redémarrage plus de huit millions de machines Windows. Le capteur attendait vingt champs, la mise à jour du Channel File 291 en fournissait vingt et un, d'où une lecture hors limites de la mémoire. Le document dit aussi ce qui change : déploiement par étapes des mises à jour de contenu, tests supplémentaires, et main laissée aux clients sur le calendrier. DORA en fait une obligation. L'article 17 du règlement (UE) 2022/2554 impose un processus de gestion des incidents. L'article 13, paragraphe 2, impose une revue après tout incident majeur qui perturbe les activités essentielles, chargée d'en examiner les causes, de vérifier que les procédures ont été suivies et de dire quelles améliorations s'imposent. Les changements sont communiqués à l'autorité sur demande. Le rapport final de l'article 19 arrive quand l'analyse de cause racine est terminée. Côté NIS2, le rapport final de l'article 23, paragraphe 4, dû un mois après la notification, décrit le type de menace ou la cause profonde qui a probablement déclenché l'incident. Pour le souscripteur, c'est la pièce la plus utile du dossier. Au renouvellement, elle dit si la cause est corrigée ou seulement contournée. Au sinistre, elle nourrit trois débats. Le premier est la subrogation, quand la cause est la mise à jour d'un éditeur ou l'erreur d'un infogéreur. Viennent ensuite l'exclusion de défaut connu non corrigé, quand elle nomme une vulnérabilité publiée depuis des mois, puis la clause de mesures de sécurité minimales, quand elle constate une authentification forte absente sur l'accès distant. D'où la tentation de la faire rédiger sous la direction de l'avocat. Nuance : un document dû au superviseur se protège mal, et un mois suffit rarement, de sorte que le rapport final NIS2 parle souvent de cause probable, que la forensique corrige plus tard.

Ses 10 renvois, tissés sur les 18 catégories du glossaire
Analyse de cause racine (après incident) : illustration de la fiche Cyber du glossaire AlgoPolis
Exemple

Cas d'école : une ETI (entreprise de taille intermédiaire) fictive est chiffrée par un rançongiciel. Son analyse de cause racine établit l'entrée par un boîtier VPN (réseau privé virtuel) dont la faille était publiée depuis 120 jours. Sa police exclut les vulnérabilités non corrigées plus de 90 jours après publication : 120 > 90, l'assureur oppose l'exclusion sur les 600 000 euros de pertes d'exploitation et laisse les 180 000 euros de frais de réponse, que le libellé garantit sans condition. Au renouvellement, le souscripteur demande le plan d'action du rapport et la preuve que les boîtiers sont désormais corrigés sous trente jours.

À lire ensuite
Passer à la pratique
Termes associés
Également connu sous

analyse des causes profondes, RCA, revue post-incident, retour d'expérience incident, RETEX cyber, analyse post-incident

Rester informé

Suivez la recherche

Une lettre par semaine. En tête, la note de souscription de la semaine, quand il en paraît une : une décision datée et argumentée, signée de Paul Bernardski. Ensuite, ce que l'observatoire a publié en risque cyber, en risque politique et en assurance. Sans compte, sans suivi.

Pas de spam, désinscription en un clic, aucune donnée revendue.