On en dénombre, à ce jour, au moins quatre en Belgique (CHwapi du côté de Tournai, St-Luc à Bouge près de Namur, André Renard à Liège, l’hôpital Heilig Hart de Mol) mais des dizaines en France (27 en 2020, environ une par semaine depuis le début de l’année.)… Le même phénomène  se produit dans de nombreux autres pays…

Depuis un peu plus d’un an, une épidémie d’un autre genre semble en effet toucher les hôpitaux: des cyber-attaques, souvent de type ransomware ces derniers temps, avec des conséquences plus ou moins majeures sur leur fonctionnement, voire sur la sécurité des maladies (l’Allemagne, notamment, a dû déplorer un décès et est l’un des deux pays européens, avec l’Espagne, a avoir connu le plus important regain de cyber-attaques visant le secteur des soins de santé). Certains chiffres parlent d’une augmentation de 475% des attaques visant des hôpitaux européens en 2020…

Que retirer comme leçons des ces attaques, non seulement dans les rangs des établissements de soins de santé mais aussi dans d’autres secteurs et catégories d’acteurs socio-économiques qui, à bien des égards, se retrouvent dans le profil des hôpitaux?

Le cas du CHwapi

En Belgique, le véritable premier incident majeur ayant touché une institution hospitalière est l’attaque qui a touché le CHwapi (Centre Hospitalier de Wallonie picarde) en janvier de cette année.

Depuis cette mésaventure subie en janvier, le CIO du CHwapi, Jacques Godart, ou d’autres personnes de l’équipe informatique, tels que Julien Rousseau, chef de service Système et Exploitation, ou Jordan Saint-Ghislain, ingénieur système, n’ont eu de cesse de communiquer et de mettre en garde leurs homologues, afin de les conscientiser.

Même si le CHwapi était loin d’être irréprochable, comme on le verra plus loin, l’établissement avait déjà mis en oeuvre des éléments de sécurité devant lui garantir une sécurité considérée comme raisonnable. Un audit avait d’ailleurs été réalisé, qui avait rassuré la direction.

Le souci? Le score obtenu avait été mal interprété. “Nous avions été classés parmi les meilleurs”, déclarait Didier Delval, directeur général du CHwapi, lors d’une de ses interventions. Un des meilleurs parmi les hôpitaux audits mais… ce que les responsables n’avaient pas “capté” est le fait que cela n’était pas forcément la meilleure des références. Le score de 90% décroché par le CHwapi par rapport à la “norme” sectorielle devenait en réalité du… 18% sur l’échelle globale, tous secteurs confondus!

L’impréparation qui semble donc caractériser le secteur tient en partie au sentiment, désormais largement battu en brèche, que le secteur hospitalier n’est pas concerné par l’appétit des hackers. Soit dit en passant, de l’aveu-même d’un CIO d’un grand hôpital belge, la prise de conscience, en dépit ds nombreux incidents de ces derniers mois, commence seulement à prendre forme…

L’attaque et ses conséquences

Comme dans de nombreux cas, l’attaque contre le CHwapi avait longuement été préparée. Après investigation, il s’est en effet avéré que les hackers s’étaient infiltrés dans l’infrastructure depuis déjà quelques semaines.

Pour autant que l’enquête judiciaire (toujours en cours à l’heure actuelle) ne révèle pas des dégâts plus larges que constatés, il n’y a pas eu de mise en péril de l’intégrité des dossiers patients, pas de vol de données. Mais, le jour de l’attaque (un dimanche), plus de 80 serveurs ont été bloqués par un rançongiciel ainsi, dès lors, que toutes applications, tant médicales qu’administratives, qui en dépendaient. Les postes de travail, eux, n’ont pas été bloqués par l’attaque (même s’ils furent ensuite déconnectés par précaution et pour analyse) étant donné qu’ils étaient déjà… protégés par cryptage.

Des intrusions et “contaminations” non détectées, en amont du déclenchement d’une attaque, sont fréquentes. Et pas que dans le secteur hospitalier, loin s’en faut. Mais, dans ce dernier, le CHwapi n’est pas le seul à s’en être aperçu. L’hôpital allemand (Düsseldorf) qui, en 2020, a dû déplorer un décès suite à une attaque par ransomware avait été “infiltré” six mois avant l’activation de l’attaque…

L’attaque a été effectuée notamment via une usurpation d’identité pour différents comptes (jusqu’au niveau de l’administrateur réseau) et s’est donc concrétisée par du chiffrement de disques durs, la suppression pure et simple de serveurs virtuels (et la disparition de tout ce qui s’y trouvait), l’écrasement de données de sauvegarde, une prise de contrôle de l’Active Directory (octroi de droits), etc.

Le CHwapi a donc été pris en défaut à plusieurs niveaux – notamment des applications laissées à l’état végétatif, d’anciens systèmes d’exploitation Windows… et l’absence de mesures qui, dans d’autres secteurs, sont désormais considérées comme élémentaires.

La preuve de la “légèreté” du CHwapi (le terme vient de la bouche-même de leurs responsables) est d’ailleurs donnée par la liste des mesures nouvelles qui furent prises dans la foulée immédiate de l’attaque. A commencer par la définition de 5 niveaux de criticité afin de déterminer quels services, quelles applications, quels processus remettre en ordre de marche en priorité afin de restaurer les activités de la société, selon les éléments critiques, essentiels ou prioritaires liés à ses objectifs ou à la nature de ses activités – un principe qui peut clairement s’appliquer dans tous les secteurs.

Par ailleurs, le CHwapi a repensé “de fond en comble” son infrastructure IT, histoire de resserrer les boulons à tous les étages. Parmi les nouvelles mesures prises:

• élimination d’applications qui n’étaient plus utilisées (ou qui n’étaient plus supportées)
• déploiement d’une solution EDR (endpoint detection and response) sur toutes les plates-formes

• Le CHwapi a réorganisé son infrastructure IT, éliminé des applications désuètes, repensé l’octroi des rôles et droits d’accès… Source: CHwapi.

  passage à une segmentation et ségrégation réseau et recours à différents pare-feu pour le VPN et les autres volets de l’infrastructure

• recours à une surveillance 24×7 via un SOC (prestataire externe)
• définition d’un volet DRP (disaster recovery planning) supplémentaire: “un plan DRP global existait mais il nous manquait un plan DRP technique. Nous avons donc étoffé le plan existant, en ce compris en termes de rôles, pour en faire un véritable plan de cyber-défense – en ce compris un scénario d’inaccessibilité de données de plusieurs semaines”
• définition d’un scénario de réponse à incident pour chaque composant du SIH (système informatique hospitalier)
• passage à des procédures d’authentification multi-factorielle
• masquage des adresses IP publiques
• décision de faire procéder régulièrement à des tests de pénétration (“lors de toute adaptation ou mise à jour importante du système informatique”)
• renforcement des processus de sauvegarde (en ce compris via recours à des bandes, en plus d’une sauvegarde sur disques, et un stockage externe).

Objectif #1: restaurer vite et bien

Univers hautement sensible, un hôpital ne peut se permettre d’être “off” ne serait-ce que quelques heures. Des vies – littéralement – en dépendent. Il a donc tout intérêt à mettre en oeuvre les conditions d’une restauration rapide même si la reprise doit se faire en “mode dégradé” (autrement dit, sans que toutes les activités et processus soient immédiatement disponibles).

Autre raison pour mettre en oeuvre les conditions de cette reprise rapide, celle évoquée par Olivier Jeuniau, CIO des cliniques universitaires Saint-Luc, à Bruxelles. Plus spécifiquement en réponse à des attaques de type rançongiciel et gel d’infrastructure qui semblent tant avoir la cote ces derniers temps: “un hôpital qui est capable de se rétablir en l’espace de quelques heures présentent clairement moins d’intérêt aux yeux des hackers…”

Aux cliniques Saint-Luc, le mot d’ordre prioritaire est donc désormais de faire en sorte que la restauration de l’infrastructure et de l’opérationnel puissent se faire dans les meilleurs délais possibles en cas de cyber-attaque. “Parce que ce n’est pas si mais quand”, souligne Olivier Jeuniau. “Attaqués, on le sera. On se fera avoir. Tôt ou tard…”

Une restauration rapide est évidemment cruciale pour un hôpital. Pour reprendre l’exemple du CHwapi, outre les serveurs cryptés par les hackers et inaccessibles, l’hôpital s’est retrouvé aveugle et inopérant pendant de long jours puisque, par mesure de prudence, l’hôpital s’est déconnecté, avec retour généralisé au papier et aux anciennes méthodes.

La remise en route des serveurs cliniques est intervenue deux semaines plus tard. La restauration opérationnelle de la totalité du parc de serveurs n’a été réalisée qu’après 10 semaines…

Certes, les activités, en mode dégradé, ont pu reprendre dans les jours qui ont suivi l’attaque mais sans qu’il y ait possibilité d’accès aux dossiers médicaux, antécédents, contre-indications… tous consignés et gérés par des solutions informatiques. Il a fallu reconstituer des dossiers, trouver les infos… “Un miracle que l’on n’ait pas déploré de décès”, estime Philippe Costard, conseiller en sécurité de l’information auprès de l’association Santhea, fédération patronale d’institutions de soins de santé wallonnes et bruxelloises. D’autres, comme l’hôpital de Düsseldorf, n’ont pas eu cette chance, une patiente n’ayant pas pu être prise en charge aux urgences est décédée avant de pouvoir l’être par l’hôpital de la ville voisine vers lequel elle avait été transférée…

Olivier Jeuniau (Cliniques Saint-Luc, Bruxelles) : “Il faut agir sur tous les maillons, sources de faiblesse: la technologie, les utilisateurs, les fournisseurs, la gouvernance… La cyber-défense est avant tout une question d’état d’esprit. Au niveau d’un hôpital, le social engineering est une catastrophe. On y entre comme dans un moulin. Il nous faut donc adapter nos outils et nos comportements. La sécurité est bien sûr toujours quelque chose de contraignant mais si vous levez le pied, ils entreront…”

Comment assurer une reprise la plus efficace et rapide possible? Cela passe notamment par une “sanctuarisation” des sauvegardes, souligne Olivier Jeuniau. Autrement dit, “les isoler le plus possible du réseau. Une copie des sauvegardes sera donc désormais conservée extra muros, sans connexion directe permanente à l’hôpital” pour éviter toute contamination (connexions interrompues dès que la copie a été réalisée). Et l’initiative de la reconnexion sera confiée au tiers qui héberge ces sauvegardes.

“Sanctuariser”, c’est aussi, rappelle pour sa part le CIO du CHwapi, protéger les sauvegardes contre des personnes qui, en raison de leur statut, pourraient y accéder: “il faut par exemple protéger les sauvegardes contre… les administrateurs réseau. Dans le cas du CHwapi, un hacker avait usurpé l’identité d’un administrateur réseau…”

Au CHwapi, la sauvegarde n’a pas pu être restaurée (notamment parce que l’hôpital, lors de l’attaque, était en plein exercice de migration du SAN). Quatorze jours de données ont ainsi été perdus…

Sanctuariser les sauvegardes n’est, bien entendu, qu’une mesure parmi bien d’autres. Citons à titre d’exemples certaines dees mesures énumérées, ces dernières semaines, par divers professionnels venus témoigner lors de ces ateliers et conférences “post-attaque CHwapi”: un état des lieux complet, un listing complet et tenu à jour de tous les équipements, composants, solutions logicielles, une documentation efficace de leur fonctionnement (or, comme le soulignait Jordan Saint-Ghislain, du CHwapi, “nous sommes rendu compte que nous manquions de connaissances à propos de nos systèmes. Sur certains éléments, personne ne savait comment intervenir parce que cela avait été fait par quelqu’un d’autre [disparu entre-temps], il y a de nombreuses années…”.

S’y ajoute encore un plan de “restauration après désastre”, avec plan détaillé des dispositifs, processus et équipements essentiels, voire vitaux, à restaurer en priorité.

Tout comme a décidé de le faire le CHwapi, un DRP doublé d’un plan de continuité opérationnelle renforcé figure également parmi les priorités des Cliniques universitaires Saint-Luc. “Les processus métier doivent pouvoir s’adapter en cas de désastre”, soulignait Olivier Jeuniau lors d’un exposé au séminaire Patient numérique. “Mais là aussi, il faut documenter et tester régulièrement. Au moins une fois par an car les gens oublient où sont les outils de secours…”

Autre mesure essentielle: la sensibilisation et la formation pour tous les employés, tous les utilisateurs, toutes les personnes qui pénètrent, pour raisons professionnelles, dans l’enceinte d’un hôpital – que ce soit comme laborantin, médecin, infirmière, étudiant, chercheur, technicien de maintenance, consultant externe… “Lors d’un exercice de type pen test (test d’intrusion), il est possible de vérifier comment se comportent les effectifs, par exemple face à une demande apparemment anodine d’une personne ayant revêtu une blouse blanche… ou un bleu de travail. Se faire passer pour un médecin pour accéder aux données consignées par une infirmière est un cas d’école. Cette simple démonstration peut être un électro-choc pour les équipes”, déclare Benjamin Desbuquoit, spécialiste solutions chez Orange Cyberdefense. “Tout comme une campagne de faux hameçonnage réalisée, à titre d’exercice, en interne.”

Le “zéro confiance”, contre-nature dans le secteur hospitalier?

Le “zero trust” ou “zero confiance”, en matière de sécurité informatique (ou autre d’ailleurs), c’est “considérer qu’aucune source (de données, de demande d’accès…) n’est fiable, sauf si elle a été dûment vérifiée. Et il implique un contrôle tout au long de la connexion dans la mesure où une altération est possible à tout moment”. Le contraire-même de ce qu’est par nature un hôpital: largement ouvert à ceux qui s’adressent à lui.

Comme le disait Olivier Jeuniau, directeur informatique aux Cliniques universitaires Saint-Luc à Bruxelles, “l’hôpital est un milieu ouvert et bienveillant par nature. On y entre comme dans un moulin. Il nous faut donc adapter nos outils et nos comportements.”

Instaurer le concept et les pratiques de “zero trust” implique de nombreux aménagements, sinon bouleversements, tant au niveau architectural que comportemental et procédural. Le “zero trust” implique une visibilité totale sur les équipements, dispositifs, utilisateurs, contextes d’utilisation ou d’accès… De même qu’une prise en compte ou le remplacement de tous les systèmes et solutions héritées du passé, un lourd travail de fond en termes d’information, de sensibilisation et de mise à niveau des compétences. Ainsi qu’une nécessaire automatisation de pans entiers de processus, rappelait par exemple Benjamin Desbuquoit, lors d’une récente session d’information organisée par la société à destination d’un public de professionnels IT hospitaliers.

Jacques Rossler (CIO de l’hôpital Erasme): “Les décideurs et responsables médicaux ne doivent pas forcer l’IT à introduire, sur le réseau, des équipements certes essentiels pour le patient mais qui sont de véritables portes ouvertes…”

Le passage au zero trust implique aussi de surmonter toute une série d’obstacles, selon lui. A commencer par l’acceptation du changement, sujet toujours épineux. “Il s’agit de limiter ou de supprimer les passe-droit historiques, avec le support de la direction. Or, ce sont souvent eux qui avaient ces passe-droit… Il est donc essentiel de clairement définir les rôles et de connaître parfaitement l’utilisation qui est faite des données selon le contexte. Il faut rendre les règles visibles.

Une visibilité de bout en bout est indispensable: qui accède à quoi, où et comment. C’est là une condition sine qua non de la confiance. Mais c’est aussi essentiel dans la mesure où cela permettra de réduire les temps de réaction en cas d’attaque…”

Les principes de base du “zero trust” – Source: Aruba, Orange Cyberdefense

La “visibilité” ne concerne pas uniquement les identités ou les profils. Elle concerne aussi et de manière tout aussi fondamentale les équipements et dispositifs. Or, bien souvent, en ce compris et de manière sans doute souvent plus marquée en milieu hospitalier, les utilisateurs et les responsables n’ont pas une connaissance intégrale des dispositifs connectés et (inter-)communicants: “La complexité s’accroît notamment du fait que le nombre de devices avec potentiel IT embarqué s’accroît sensiblement. Encore faut-il savoir que ces dispositifs sont connectés au réseau et les avoir identifiés. Un audit démontre bien souvent qu’ils sont bien plus nombreux qu’on ne le pensait…” Orange Cyberdefense dit par exemple avoir réalisé ce genre d’audit auprès d’un hôpital belge dont les responsables informatiques avaient évalué à 8.000 le nombre de dispositifs connectés à son réseau. Après audit, il s’est avéré que le nombre était de… 13.500.

Pour déployer du zero trust, il faut dès lors “commencer par un exercice de due diligence, concevoir l’infrastructure et créer des règles et des chartes ciblées, basées sur des cas d’usage.” En matière de cas d’usage, l’un des conseils que l’on entend souvent dans la bouche de consultants en cyber-sécurité est de ne pas se limiter à des situations “classiques”, habituelles. Il faut aussi et peut-être surtout imaginer des situations et scénarios inattendus, inhabituels, voire insolites – car l’imagination est souvent du côté des hackers.

A cela s’ajoute la difficulté supplémentaire suivante: “Le zero trust évolue rapidement”, souligne Benjamin Desbuquoit. “Il faut donc s’adapter en permanence, faire preuve de flexibilité, en ce compris face aux nouvelles technologies.”

D’une manière générale, la gouvernance est donc un élément-clé. “Il ne faut pas oublier, à cet égard, que le zéro confiance concerne la totalité des utilisateurs, des privilèges, systèmes et processus.” 

A paraître demain: quel financement pour la cyber-sécurité des hôpitaux?