À partir de quand une faille de sécurité cyber doit-elle vous inquiéter ?

La première approche est purement technique : un risque, c’est une probabilité P (ou vraisemblance) multipliée par un impact I – qu’il faut découper selon au moins 3 axes, financier / image / juridique, mais on ne va pas aller jusque-là. Donc on calcule PxI. Une faille de sécurité qui présente un risque calculé faible (PxI faible), on vit avec. Ce qui suppose l’existence de seuils, partagés, opposables et eux-mêmes révisés.
La deuxième approche est hiérarchique et découle de la précédente. Parce que si PxI est faible, on a d’autres combats à mener, d’autres failles à corriger pour lesquelles PxI est supérieur. Dit autrement, on choisit ses combats. Certes, il est possible que des malfrats passent par les égouts pour chiper les serveurs du DPI dans le datacenter de l’hôpital à la façon Spaggiari, mais c’est arrivé à qui ?
La troisième approche est politique. Il y a des failles qui ne sont quasiment jamais exploitées (PxI faible) mais qui, si elles l’étaient, entraîneraient une médiatisation telle que l’on passerait tous pour des incompétents. Pas besoin d’aller chercher bien loin, le cambriolage du Louvre en est une parfaite illustration. Et cela se complique, parce que par définition ces failles peuvent être exploitées de façon multiple, surtout s’il y a des malfrats en face, ou simplement le hasard et le clin d’œil du grand barbu dans les nuages. Dit autrement, on sait que l’efficacité des contre-mesures est structurellement limitée, mais le pire serait de ne rien faire. Si la fenêtre et la vitrine du Louvre avaient été d’une résistance suffisante et auditée, on n’était pas à l’abri d’une intrusion utilisant des outils démesurés, mais l’impact médiatique n’aurait pas été le même.
Mais la dernière approche, qui me paraît la plus intéressante et qui m’a valu une joute verbale high level et passionnante avec mon auditeur interne (qui se reconnaîtra), est celle qui est couverte par le concept du SMQ (système de management de la qualité) et en particulier du SMSI à la sauce 27001. Et la question est la suivante : un SMSI sert-il à améliorer la sécurité du SI, ou sert-il à améliorer le système de management de la sécurité du SI ? Ou, dit autrement, à partir de quel moment une faille de sécurité doit-elle être considérée comme une non-conformité (mineure ou majeure) au sens 27001 ?
Si la réponse à cette question est : une faille de sécurité est une non-conformité du SMSI, cela revient à adopter l’approche technique ou hiérarchique : on corrige le PxI, s’il est au-dessus d’un certain seuil. Mais si on lit l’introduction de la norme NF 27001, il est clairement écrit qu’un SMSI sert à améliorer le système de management de la sécurité du SI. Et dans ce cas, ce qui est une non-conformité, ce n’est pas d’avoir un PxI, mais de ne pas l’intégrer dans une dynamique qui consiste à :
-
avoir des seuils et les réévaluer ; ce qui suppose des audits internes ou externes, organisationnels ou techniques ;
-
calculer un PxI et le réévaluer ; ce qui suppose un processus d’appréciation des risques régulièrement appliqué et dont la méthode elle-même est réévaluée ;
-
se tenir au courant de l’état de l’art des PxI de tous les copains RSSI et de l’intégrer dans notre propre système d’analyse ; ce qui suppose une veille ;
-
et, si besoin, faire passer ce PxI devant les autres risques identifiés parce qu’à un moment l’environnement a bougé ; si les autres musées de France n’ont pas réévalué leurs systèmes de protection à la suite du cambriolage du Louvre, c’est là qu’il y a un problème.
Alors qu’une bonne partie de l’écosystème cyber fantasme plein tube sur la méthode d’appréciation des risques, il est notable de constater qu’il n’y a qu’une seule demi-phrase sur ce sujet dans la 27001 : « identifie les risques de sécurité de l’information » (6.1.2c). Par contre, personne ou presque ne percute sur le 8.2 qui spécifie pourtant très clairement que les appréciations de risques doivent être rejouées à intervalles réguliers ou à chaque changement significatif intégrant les critères d’acceptation. Le cambriolage du Louvre, ce n’est pas la root cause : la root cause, c’est une appréciation des risques défaillante et jamais réévaluée (je vous invite à écouter l’excellent podcast Code Source qui explique que le risque de cambriolage ne faisait pas partie du schéma mental des dirigeants).
Conclusion : ce n’est pas tant une faille de sécurité qui doit vous inquiéter, mais plutôt celle qui n’a jamais été révisée, voire celle que la dernière appréciation des risques n’a pas débusquée parce que cette appréciation a été faite entre le RSSI et lui-même et que l’on est tous persuadés d’avoir raison quand on n’est confronté au regard de personne d’autre.
Tout est dans la 27001, il suffit juste de la lire.

Cédric Cartau
Avez-vous apprécié ce contenu ?
A lire également.

Comment quantifier un risque
31 mars 2026 - 08:06,
Tribune
-Après avoir expliqué qu’une PSSI et une appréciation des risques ne servaient à rien (ici 1) -mais un peu quand même -, intéressons-nous à un autre sujet brûlant qui déchaîne les passions, pire que JR (2) et la fin du Prisonnier (3) : la quantification du risque.

RSSI externalisé : structurer la cybersécurité des établissements de santé
23 mars 2026 - 18:19,
Tribune
-La cybersécurité est devenue un enjeu structurant pour les établissements de santé. Entre montée des cybermenaces et multiplication des exigences nationales, les organisations doivent structurer le pilotage de la sécurité de leurs systèmes d’information. Dans ce contexte, la fonction de RSSI prend u...

Les grandes tendances des systèmes d’information hospitaliers en 2026
09 mars 2026 - 09:40,
Tribune
-L’an dernier, nous présentions plusieurs tendances des systèmes d’information hospitaliers : cybersécurité, convergence des SI dans les GHT, données de santé, intelligence artificielle ou interopérabilité.
La cyber, les bras et le chocolat
09 mars 2026 - 09:00,
Tribune
-S’il est un truc dont l’écosystème cyber ne manque pas (l’écosystème IT aussi, du reste), ce sont les consultants encravatés qui vous expliquent, avec force schémas bien léchés et PowerPoint tout enluminés, qu’il faut aborder la cyber par là, puis par là, avec moult comités Théodule et méthodes perl...
