L’appréciation des risques façon Armageddon

Pendant des années, les pouvoirs publics ont prôné jusqu’à l’indigestion des méthodes formelles type Ebios, arguant que le déroulé de ladite méthode permettait d’être exhaustif sur l’identification des risques. Sauf que c’est faux, et même trois fois faux. D’abord parce que toute méthode formelle est par nature incomplète, comme le confirme un résultat connu depuis 1931 avec le théorème d’incomplétude de Gödel : la méthode fait des choix sur les axiomes de base, choix qui limitent forcément la complétude du résultat obtenu. Par exemple, Ebios est totalement incapable de prendre en compte la survenue de deux menaces conjointes, comme Fukushima (tremblement de terre et tsunami en même temps). Ensuite parce que ces méthodes s’appuient sur des données statistiques pour évaluer par exemple les risques climatiques, et l’expérience montre que la probabilité de ce type de risque est presque toujours sous-évaluée. Enfin parce qu’à aucun moment ces méthodes ne peuvent prendre en compte la bêtise humaine, à l’origine d’accidents tels Tchernobyl ou l’incendie du tunnel sous le mont Blanc (lancement des extracteurs d’air dans le mauvais sens). 

Alléluia, Dieu et la Cnil (pas forcément dans cet ordre) nous ont pondu un outil de suivi du PIA (Privacy Impact Assessment) qui est un vrai bonheur, un peu la truffe chocolatée au milieu d’un plat d’endives. Et, ô surprise ! la partie qui concerne l’analyse des risques à proprement parler est simplissime, comme on aimerait en voir plus souvent. Elle se découpe en trois parties : les mesures de protection existantes, les risques répartis en trois sections (disponibilité, intégrité et confidentialité), et la synthèse. Génuflexion, yeux clos et nuque baissée. 

Mais il y a aussi une troisième voie, pas forcément habituelle pour les RSSI, mais en revanche très parlante pour les décideurs, ce qui est un tantinet paradoxal. La plupart des crashes que nous vivons dans les SI ne sont pas « létaux » : on finit tant bien que mal par s’en relever, au bout d’un temps plus ou moins long, avec des conséquences financières, juridiques ou médiatiques plus ou moins graves. Fuiter une base de clients, de patients ou d’employés sur Internet n’a encore pas provoqué – en France en tout cas – la fermeture de l’entreprise. Même l’affaire Ashley Madison (site de rencontres dont la totalité des comptes ont fuité sur le Net, y compris les billets doux entre adhérents) n’a pas provoqué la fermeture du site. Est-ce un bien ou un mal ? Là n’est pas la question. La question des pannes est plus ennuyeuse : nous avons en mémoire les cryptolockers qui ont stoppé totalement plusieurs hôpitaux aux USA et en Grande Bretagne. Cela étant, à ma connaissance on ne déplore aucun impact patients ; ils ont été reroutés vers d’autres établissements de soins périphériques et, au final, les conséquences sont essentiellement financières (perte d’activité) et médiatiques.

Mais qu’en est-il des risques létaux ? Il s’agit de risques pour lesquels le SI est irrémédiablement perdu. On ne parle donc pas là d’incidents de confidentialité, mais d’intégrité ou de disponibilité. Même dans le cas des hôpitaux susnommés, les équipes IT ont dû remonter à la mimine les sauvegardes : certes, cela a pris du temps (parfois des semaines), mais au final le SI est opérationnel. Se poser la question des risques létaux est intéressant à deux titres : il s’agit d’un outil de communication sans équivalent auprès du directeur général, et auprès de la DSI.

Chacun dans son secteur pourra se poser la question de la liste de ces risques. Pour ma part j’en ai dénombré cinq :

a) une attaque en cryptolocker qui chiffre à la fois les données et les sauvegardes ;

b) une malveillance d’un administrateur interne de la DSI, qui détruit les FAT des baies de disques et des espaces de sauvegarde ;

c) une malveillance administrateur, mais d’un prestataire externe ;

d) une attaque physique (terrorisme ou simplement vandalisme) des datacenters avec destruction physique (feu, inondation, etc.) ;

e) un bug logiciel (volontaire ou non) qui détruit (corruption logique) les données d’une base en partant des plus anciennes (celles auxquelles les utilisateurs n’accèdent jamais, donc bug indétectable pendant un bon moment) et « grignote » petit à petit toute la base ; quand on s’en aperçoit, il est trop tard : la durée de rétention des sauvegardes a été dépassée.

Les protections contre les risques a) et d) sont relativement faciles à concevoir (la mise en œuvre, c’est une autre paire de manches), mais par contre pour les autres je vous souhaite bon courage ! 

Bonnes fêtes quand même…