Vous êtes dans : Accueil > Tribunes libres >

La fin de la cybersécurité ? Partie II

Cédric Cartau, MARDI 16 AVRIL 2019 Soyez le premier à réagirSoyez le premier à réagir

Dans une première partie, nous avons analysé un article du dernier numéro du mensuel Harvard Business Review qui faisait la part belle à l’analyse catastrophiste de la cybersécurité – en substance, on va tous dans le mur – et qui professait le retour à l’isolation physique des réseaux essentiels à la résilience des organisations. Suite de l’analyse.

Si l’on reprend l’une des plus importantes mesures du Guide d’hygiène de l’Anssià savoir la connaissance exhaustive du patrimoine IT, rien de nouveau sous le soleil. Ceux qui ont lu L’Art de la guerre de Sun Tzu savent que la connaissance du terrain d’affrontement est l’une des clés de la victoire. Rien d’étonnant à ce que l’Anssi mette cette mesure en tête de gondole. Sauf que, dans la réalité, j’aimerais bien que l’on me montre l’entreprise de plus de 500 agents qui serait en mesure de garantir la connaissance exhaustive (le tout) et parfaite (le détail) de la totalité des actifs connectés au LAN. Chaque fois que je tombe sur un outil, payant ou gratuit, qui prétend faire l’inventaire du parc, il se contente de répertorier le parc connu, la nuance est de taille. Quid des connexions sauvages de tel fournisseur qui vient faire la démonstration d’un logiciel dans un service métier sans que la DSI soit au courant (vécu), quid des systèmes industriels connectés au LAN et pour lesquels il est inutile de demander au fournisseur les spécifications réseau (le fournisseur en question a mis la clé sous la porte cinq ans auparavant, encore du vécu), quid des connexions LAN to LAN pour la maintenance des systèmes critiques, dans des conditions de sécurité qui feraient frémir n’importe quel spécialiste cyber (toujours vécu) ? Bref, la connaissance des actifs, c’est comme les années 1960 : si vous en parlez, c’est que vous ne les avez jamais vécues.

Dans une précédente vie, un beau jour de semaine en milieu de matinée, un de mes ingénieurs systèmes remarque que le contrôleur AD principal ne répond plus. On creuse, on cherche, on incrimine le réseau (on incrimine toujours le réseau quand un bidule ne fonctionne plus) et on ne trouve pas. Et on cherche encore. Et on finit par trouver, au bout de deux heures, et encore presque par hasard. Je ne vous dirai pas ce qui s’est passé de peur de donner des idées à quelques malfaisants, mais sachez que nous sommes passés à deux doigts, ce matin-là, d’un arrêt total du réseau informatique (5 000 PC, 8 000 agents tout de même). Le dysfonctionnement était dû à une fausse manipulation non intentionnelle d’un agent (on n’a jamais su qui), mais ce n’est pas le pire de l’histoire. Le pire, c’est que si une telle manipulation devait avoir lieu de manière intentionnelle, sachez qu’il faudrait moins de 10 minutes à un individu motivé pour écrouler la totalité du réseau de quasiment n’importe quelle entreprise de grande taille. Pas besoin d’un cryptolocker, pas besoin de connaissances pointues, la manipulation est à la portée d’un étudiant de première année de BTS Informatique, voire d’un adolescent un peu débrouillard. Et, pire que le pire, il existe très peu de moyens de se prémunir de ce genre d’incident : pour être honnête, je ne sais pas s’il existe une entreprise publique ou privée de plus de 1 000 agents en France qui a déployé des contre-mesures efficaces et adéquates en la matière – et celles qui prétendent le contraire, je fais mon saint Thomas de base, je demande à voir…

Bref, on est loin du compte, et encore il ne s’agit que de l’une des 42 mesures : sur les 15 que j’ai dénombrées et qui sont quasi irréalisables, il y en a d’autres du même acabit. C’est le moment où tout RSSI, tout DSI et tout décideur devrait arriver à la seule conclusion logique valable : OK, l’approche par le haut ne fonctionne manifestement pas, il faut donc adopter une démarche plus pragmatique, à savoir quels sont les éléments de l’IT qui sont absolument vitaux au fonctionnement de l’entreprise ? On peut couper l’informatique RH (paye incluse) pendant trois mois, la gestion des transports de patients, la restauration, les systèmes d’information décisionnels (les trucs qui produisent les beaux camemberts en couleurs), les systèmes de recherche, et j’en passe : ce sera le gros foutoir, mais l’hôpital et ses patients survivront. Par contre, il y a au moins quatre systèmes ultra-ultra-ultrasensibles : la biologie, l’imagerie, le téléphone et les prescriptions médicales. À peu près tout le reste peut être réalisé à la gomme et au crayon, certes dans des conditions organisationnelles éprouvantes, certes en réduisant l’activité médicale aux seules urgences, certes avec des conséquences importantes après le retour à la normale, certes avec des pertes financières non négligeables. Mais l’impact patient sera maîtrisé, et l’hôpital y survivra.

La directive NIS, qui nous est récemment tombée dessus, part à la base d’une bonne idée : définir un niveau de sécurité IT en adéquation avec les missions de soins des établissements de santé de la cinquième puissance mondiale au xxie siècle. Là où elle pique les yeux, c’est que les 23 mesures qu’elle comporte (et qui reflètent les 42 mesures susnommées) sont trop détaillées, irréalisables pour la plupart. Et surtout que le périmètre est beaucoup trop important : certains établissements ont été désignés OSE pour la totalité de leurs activités de soins, ce qui est incompatible avec l’analyse du périmètre minimal de résilience. La bonne approche serait de considérer un périmètre vital (j’ai cité quatre blocs, mais l’analyse peut évoluer) et définir des paliers : un établissement OSE devra avoir réalisé telle et telle mesure, avec telle ou telle précision, à un horizon de deux ans (palier 1), puis un peu plus à un horizon d’une année supplémentaire (palier 2), etc.

Le corollaire est que les domaines retenus (la biologie dans mon exemple) doivent ensuite devenir des sanctuaires pour lesquels absolument rien ne peut être connecté, aucun projet ne peut être mené sans que la conformité OSE soit traitée en amont et de façon suspensive. Et que tout manquement donne lieu à des sanctions : il fut un temps à la Cogema (c’est peut-être toujours le cas) où la connexion d’un modem par un agent était un motif de sanction disciplinaire. Certes, la critique est facile, et la directive NIS a représenté un travail important qu’il faut saluer, mais personnellement j’aurais été moins gourmand sur les mesures techniques (étendue et profondeur) et plus intransigeant sur l’opposabilité et les sanctions qui en découlent.

périmètre, dsi, biologie, sécurité