La cyber et les probabilités paresseuses

L’idée consiste à modéliser l’ensemble des paramètres et d’en calculer les probabilités d’occurrence selon des métriques standards en invoquant des bases de données de fréquence d’incidents (le même genre que ce à quoi fait appel votre assureur pour déterminer que les voitures rouges sont plus susceptibles d’être volées que les blanches), de croiser le tout avec la partie financière (si tel risque survient, cela va coûter tant) afin de déterminer, pour chaque scénario, si le budget investi va être plus rentable (éviter plus de pertes) dans l’un ou dans l’autre cas.

Déjà, formulé en ces termes, ça picote, mais à déployer, ce n’est pas de la tarte – pas pour rien que ce sont des professionnels du sujet qui le font, on n’est pas sur de la compétence acquise dans un bouquin Pour les nuls. Ce qui saute aux yeux, c’est que rapidement les calculs deviennent très compliqués. Rien que d’estimer le ROI (en termes de réduction des risques) d’un déploiement de MFA pour les accès télémaintenance des fournisseurs fait intervenir une multitude de paramètres : occurrence d’attaques cyber par ce canal, provenance et taille des fournisseurs, secteur d’activité, présence ou non d’IoT dans les matériels télémaintenus, plages horaires de maintenance, et j’en oublie certainement. Et encore, on n’en est pour le moment qu’à calculer l’impact financier d’une attaque, qui est un paramètre quantitatif : quand il faudra aborder des aspects qualitatifs tels que l’impact juridique, d’image, etc., tout va devenir très, très compliqué.

Entendons-nous bien : ce type d’approche est utile dans des cas précis : factualiser auprès d’une DG les risques encourus ou choisir entre deux options sur des sujets relativement simples. Mais dans pas mal de cas, à titre personnel, je n’irai pas construire le tableau de mes objectifs cyber (ISO 27001, chapitre 6.1) par ce genre de méthode : on sera tous morts et enterrés que la moitié des paramètres n’aura même pas été déterminée.

Et c’est là le vrai sujet : le cerveau humain est vite noyé par la complexité et cherche à simplifier le modèle. Il y a 100 000 ans, quand on se faisait courser par des lions, on ne se lançait pas dans de complexes calculs de probabilité sur les murs d’une grotte : on cavalait vers l’issue de secours la plus proche. Un simple petit exercice de pensée permet de comprendre que le réel dépasse très vite notre capacité d’entendement : imaginez que j’ai dans la main un jeu de 52 cartes que je viens juste de mélanger. Si j’affirme que leur combinaison (l’ordre des cartes dans le jeu après le mélange) ne s’est jamais produite dans toute l’histoire de l’humanité, vous allez penser que je délire. Eh bien sachez qu’il y a factorielle 52 combinaisons possibles, ce qui excède largement tout ce que l’on pourrait obtenir, à raison de 1 000 combinaisons par seconde, du Big Bang jusqu’à la fin prévue de l’univers ! Ce simple exemple montre que la complexité nous submerge très rapidement.

Tout cela pour en venir au fait que j’ai une méfiance naturelle à l’égard de toutes les solutions cyber qui rajoutent un élément de complexité dès lors que l’on peut faire autrement. Récemment, on m’a proposé un boîtier qui sert à switcher vers un réseau bis si le réseau principal est attaqué. Outre le fait que j’ai du mal à voir comment cela fonctionne concrètement (si mon LAN est attaqué, les serveurs appli le seront aussi, donc tout déménager sur un second LAN n’a aucun sens), j’ai encore plus de mal à voir comment on va maintenir un tel dispositif. Comme dans tous les CHU, nous disposons de PC de secours pour des événements de type plan blanc, PC qui sont stockés dans des armoires et supposés être rallumés le jour J. Sauf qu’il faut régulièrement les allumer pour les KB MS, pour les mises à jour applicatives réalisées en central, etc. : dans les faits, personne ne s’en charge et rapidement ces PC deviennent inopérants. Avec l’ajout d’un simple matériel, donc d’un élément de complexité, concrètement, le procédé ne fonctionne pas sur le terrain. Idem pour les solutions de « PC durcis qui serviront pendant une attaque », de « boîtier devant l’appareil pour pallier les failles non corrigées de l’appareil en question », etc.

En fait, dès qu’un projet revient à ajouter un équipement pour remédier à un défaut, le RSSI devrait prendre en compte l’option de faire autrement avec les moyens du bord, parce que toute adjonction d’un élément se paye au prix d’une complexité dans la plupart des cas exponentielle. Revenons à notre expérience de pensée : la durée estimée entre le Big Bang et la fin de l’univers est d’environ 45 milliards d’années. Tester 1 000 combinaisons d’un jeu de cartes par seconde va être possible pour un jeu de 19 cartes, mais dès que l’on passe à 20 cartes, c’est cuit.

Dit autrement, le plus court chemin entre une analyse de risques et une formalisation du plan de traitement avec des objectifs de sécurité, c’est l’approche en mode probabilités paresseuses.

Il m’aura fallu tout cet article pour redémontrer le principe du rasoir d’Ockham, qui date du xiv^e siècle : y avait ni les lions ni la cyber, mais Guillaume d’Ockham avait déjà tout compris.