Publicité en cours de chargement...
Sécurité des SI de santé : an 0 ?
25 nov. 2019 - 18:07,
Tribune
- Cédric CartauLe CHU de Rouen vient de subir une méga-attaque informatique, la première du genre dans un CHU français, sauf erreur. Dans son dernier article[1], Charles Blanc-Rolin liste quelques établissements qui ont connu le même genre de mésaventure en 2019, et ce qui frappe, c’est que l’on part de petits ou de moyens établissements, pour ensuite voir des CHU apparaître dans l’inventaire (celui de Montpellier, qui a subi une attaque partielle), puis tout un groupe privé (Ramsay). Le CHU de Rouen est le premier de cette taille et avec une telle ampleur et, soyons honnêtes : cela aurait pu tomber sur vous, sur moi, sur n’importe qui. En fait, la question n’est pas de savoir si un CHU va être attaqué, mais quand.
Très peu d’informations ont filtré sur les causes et les conséquences de l’attaque à Rouen, les pouvoirs publics ayant décidé le black-out quasi total. Par recoupement, on suppose tout de même a minima que les serveurs de fichiers ont été touchés (c’est ainsi que fonctionne un cryptolocker), et il y a fort à parier que l’AD aussi – l’Anssi a de très fortes compétences sur ce sujet, cf. les attaques de TV5 Monde et de Saint-Gobain, cf. également le REX de ce dernier aux Assises de Monaco.
On pourra toujours, après coup, sortir les poncifs du genre : il faut « sensibiliser ses utilisateurs » à ne pas cliquer sur n’importe quelle pièce jointe (montrez-moi comment on fait avec un public de plusieurs milliers de personnes, sans parler du turnover) ; il faut sécuriser son AD (plus facile à dire qu’à faire, chaque fois que je lance un PingCastle sur mon AD, je ne compte même plus le nombre de pages du rapport d’anomalies) ; il faut « appliquer les règles d’hygiène de l’Anssi » (42 mesures que personne, absolument personne, ne peut mettre en œuvre, pas même la moitié d’entre elles). Mais le problème n’est pas de savoir quoi faire, tout le monde le sait. Le problème est : avec quels moyens ? Et je ne parle pas d’argent.
Quand vous déployez un système qui embarque un taux d’erreur de « x », si vous ne faites pas décroître considérablement ce « x », au bout d’un moment, vous ne faites plus que régler des bugs, des plantages, des catastrophes. C’est le raisonnement que l’aviation civile a tenu dans les années 1950 : pas de business possible à long terme s’il tombe un avion sur 1000, parce que si le trafic est multiplié par 100 (c’est le cas), alors il va falloir prévoir des stocks de housses mortuaires dans les aérogares (d’où les checks avant décollage, le BEA, etc.). C’est le raisonnement qu’a tenu l’industrie, qui a mis au point, entre autres, les méthodes Toyota, Six Sigma, Lean, parce qu’on a mieux à faire que des lettres d’excuses aux clients mécontents qui se sont retrouvés en panne trois fois de suite sur l’autoroute et de payer des dommages et intérêts aux veuves des accidentés.
Rien de tel dans le monde de la santé : on déploie à tout va des DPI, des progiciels métiers, des systèmes biomédicaux et j’en passe, on rend les organisations toujours plus dépendantes du SI. Mais de réflexion de fond sur les conséquences d’un gros crash, que nenni. Alors on me rétorquera que « la sécurité SI est une priorité », comme l’affirment tous les plans HN successifs depuis 2004 (à force, cela va finir par devenir réalité un jour), mais dans le même temps les DSI sont contraintes de faire un grand écart insoutenable entre les objectifs de qualité et les budgets, qui diminuent chaque année. On nous parle de « gains d’efficience et de synergie » dans la mise en place des GHT, mais la réalité est que l’on demande à des équipes déjà sous l’eau de travailler en plus sur des projets de territoire, sans aucuns moyens additionnels, avec des projets fonctionnels qui déboulent toutes les semaines, des appels d’utilisateurs bloqués tous les jours et des évolutions réglementaires dont le volume a explosé en trois ans (et dont pourtant personne ne conteste la pertinence, cf. la certification des comptes et les améliorations qu’elle a engendrées).
La SSI, ce n’est pas juste acheter un antivirus. Améliorer la résilience face à une attaque de ses serveurs de fichiers réclame de l’ingénierie de haut niveau dans l’architecture des progiciels et dans leur implémentation, bref du temps agent. Pour auditer les dysfonctionnements, pister les trous de sécurité, mener les actions correctives, il faut du temps, de la coordination, une volonté de ne pas déshabiller les ressources affectées à ces actions au profit des projets fonctionnels. Pour durcir un AD, il n’y a pas besoin de dépenser un seul euro en logiciels : on trouve en Open Source des produits très performants : ce sont les actions de remédiation qui demandent du temps, donc des moyens. Et le temps agent, c’est ce dont les DSI manquent cruellement. Dans le cycle PDCA, c’est bien beau de disserter pendant des heures sur le Plan et d’envoyer des armées de consultants en cravate pour le Check, mais à un moment donné il faut des petites mains pour le Do.
Le secteur de la santé en France mène des projets incroyablement pointus : IA, deep learning, entrepôts de données pour la recherche, et c’est vraiment super, je suis fier de participer à certains d’entre eux. Mais les fondamentaux n’ont pas suivi, et dans trop d’endroits on se retrouve dans la situation d’une compagnie ferroviaire qui aurait consacré l’essentiel de ses ressources à ouvrir des bars dans les voitures de première classe, mais dont les rails et les aiguillages rouillent à vue d’œil. C’est exactement ce à quoi mène le fait de ne pas sanctuariser les ressources pour fiabiliser un système.
Certains RSSI de santé se demandaient quand les vrais ennuis allaient commencer. Je crains qu’on n’en soit qu’aux débuts.
