Que s'est-il passé ?
Lors du congrès anniversaire des responsables informatiques hospitaliers à Berlin, le professeur Sebastian Schinzel et Nico Brüggemann de l'Institut Fraunhofer pour les technologies de l'information sécurisées (SIT) ont présenté une simulation de crise portant sur une cyberattaque contre un hôpital fictif, représentatif de la situation en Allemagne. Lors d'un séminaire, 23 participants se sont répartis en 12 rôles – de l'informatique à la direction générale, en passant par la direction médicale, les soins infirmiers, la sécurité de l'information et la cellule de crise. L'objectif était de déterminer si un établissement reste opérationnel lorsque l'informatique tombe entièrement en panne.
Ce n'est pas la technique elle-même qui a été simulée, mais la réaction organisationnelle – avec des extraits de pare-feu réalistes, des noms, domaines et réseaux adaptés, ainsi que des « injects », c'est-à-dire des événements déclenchés tels que des demandes de presse ou des pannes système.
Les détails
L'attaque simulée commence de façon banale : par une recherche classique d'OSINT (Open Source Intelligence), l'attaquant collecte via le site web de l'hôpital des adresses e-mail, des noms, des fonctions et des indices sur des systèmes externes. Sur cette base, un e-mail de phishing sur mesure est rédigé. Dans le scénario, un collaborateur ou une collaboratrice informatique disposant de droits d'administration se laisse piéger. L'attaquant utilise ensuite l'accès VPN, scanne le réseau, trouve un serveur Exchange et y dérobe des identifiants. À partir de ce moment, selon Brüggemann, l'ensemble de l'Active Directory doit en principe être considéré comme compromis.
S'ensuit l'escalade : journaux suspects, exfiltration de données, pannes de systèmes comme le système d'information hospitalier, les systèmes de radiologie et de laboratoire – et finalement une lettre de rançon.
Dans l'exercice, la chaîne d'escalade, de l'administrateur à la direction informatique puis au responsable de la sécurité de l'information (RSSI) jusqu'à la direction générale, a bien fonctionné, de même que des décisions de principe claires comme refuser de payer la rançon et déconnecter l'établissement d'Internet. Le chemin retour s'est révélé plus difficile : la cellule de crise est devenue une voie à sens unique, les informations y entraient mais en ressortaient à peine. Le personnel informatique se trouvait parfois dans la pièce voisine, sans connaissance des décisions prises.
Un résultat central a concerné la documentation : lors de l'exercice, quelqu'un a demandé des nouvelles d'une mesure déjà décidée depuis longtemps – mais personne ne l'avait consignée. La réaction réflexe consistant à tout éteindre immédiatement s'est également révélée problématique : un arrêt non contrôlé détruit les traces forensiques, et il n'est souvent pas clair quels systèmes sont urgemment nécessaires à un instant donné, par exemple pendant une opération chirurgicale. La meilleure mesure consisterait généralement en une segmentation ciblée du réseau.
En cas de panne informatique, des processus invisibles s'effondrent également : admission des patients, résultats d'examens, archivage d'images, médication, planning des équipes, approvisionnement alimentaire. L'exercice a donc aussi porté sur les allers-retours à pied, les changements d'équipe et des solutions pragmatiques comme le versement des salaires au montant du mois précédent, un nouveau calcul n'étant pas possible.
Mise en perspective
Schinzel, actif depuis plus de 20 ans dans le domaine de la sécurité informatique et ancien testeur d'intrusion, a souligné : « Je n'avais encore jamais vu une telle dynamique. » Il a évoqué une menace future possible provenant de logiciels malveillants s'appuyant sur un LLM et s'adaptant automatiquement – dans ce cas, le remède classique consistant à couper la connexion Internet pourrait ne plus fonctionner, par exemple si les attaquants trouvent en interne un GPU sur lequel faire tourner un petit modèle.
Schinzel tire sa propre expérience de la cyberattaque par rançongiciel contre la FH Münster en 2022. D'autres établissements d'enseignement supérieur touchés lui ont rapporté comment les crises peuvent déraper : des responsables informatiques mis à pied, des services qui cessent justement de communiquer entre eux au moment précis où la communication est vitale.
Le constat concernant le délai de rétablissement est particulièrement révélateur : les équipes estiment souvent le retour à un fonctionnement normal en quelques jours, alors que la réalité se situe plutôt entre plusieurs semaines et plusieurs mois. Un cas dans la région de Francfort, connu de Brüggemann, a nécessité environ un an pour revenir à l'état initial – alors même qu'aucun chiffrement n'avait eu lieu, seul l'Active Directory ayant été compromis. Les sauvegardes restent certes indispensables, mais ne résolvent pas le problème d'une infrastructure compromise.
Conseils pratiques
- Organiser la cellule de crise comme une communication à double sens : il faut des personnes qui circulent en permanence entre les salles et tiennent tous les acteurs informés de l'état d'avancement.
- Définir des rôles fixes pour la prise de procès-verbal et le tableau de situation : qui documente les décisions, qui tient la liste des mesures, qui informe en interne et en externe ?
- Attacher les rôles à des fonctions avec suppléance plutôt qu'à des noms de personnes, celles-ci pouvant être indisponibles.
- Ne pas tout éteindre par réflexe – examiner plutôt une segmentation ciblée du réseau et préserver les traces forensiques.
- Préparer des processus de secours analogiques pour l'admission, la médication, le planning des équipes et l'approvisionnement alimentaire en cas de panne du courrier électronique, de Teams et de la téléphonie.
- Prévoir des délais de rétablissement réalistes – plusieurs semaines à plusieurs mois plutôt que quelques jours seulement.
Perspectives
Ces simulations s'inscrivent dans une démarche scientifique : les déroulements et décisions sont analysés, et les établissements participants reçoivent un rapport final. Le Fraunhofer SIT recherche actuellement d'autres hôpitaux souhaitant participer à l'étude. Les scénarios sont adaptés au préalable à l'environnement informatique de chaque établissement via un questionnaire, tout en restant comparables entre eux. Brüggemann a souligné auprès de heise online que seul un nombre plus important d'exercices permettrait au final d'obtenir des données solides. Les retours des participants alimentent directement le développement de la simulation et des processus d'urgence.
Pour le secteur de l'informatique hospitalière, cet exercice apporte ainsi des enseignements importants : la sécurité de l'information ne peut pas simplement être déléguée au service informatique, elle concerne l'ensemble de l'organisation – des soins infirmiers jusqu'à la direction générale. C'est particulièrement vrai pour les groupements hospitaliers comportant plusieurs sites, où la situation peut rapidement devenir complexe en cas de crise réelle, comme l'a résumé une participante de l'exercice.
