Cyberattaque contre le CHRU Brest : ce qu’il s’est passé
Le centre hospitalier a évité le pire. Récit, avec Jean-Sylvain Chavanne, RSSI du CHRU de Brest, de la réponse à une cyberattaque découverte alors qu’elle n’en était qu’à ses prémices.
Lors d’un point presse, ce vendredi 24 mars, la direction du CHRU de Brest a expliqué que la reconnexion à Internet avait commencé, les agents pouvant à nouveau envoyer et recevoir des e-mails, notamment. Après deux semaines de fonctionnement en mode dégradé. Récit, depuis les coulisses du système d’information de l’hôpital, de ce qu’il s’est passé.
Tout commence le jeudi 9 mars, dans la soirée. Environ 10 minutes avant 21h, les équipes informatiques du CHRU de Brest reçoivent une notification : le système d’information du centre hospitalier est susceptible d’être victime d’une intrusion.
Sans attendre, Jean-Sylvain Chavanne, RSSI du CHRU de Brest, et ses collègues lancent les premières investigations afin de qualifier l’alerte.
Cette notification est relativement sommaire : elle porte sur les identifiants d’un compte utilisateur compromis. Mais c’est suffisant pour rechercher des connexions avec ce compte.
Très vite, un constat s’impose : ce compte a bien été utilisé pour accéder frauduleusement au système d’information du CHRU. Les actions menées avec celui-ci ne laissent pas de place au doute : elles relèvent clairement de la reconnaissance initiale – cette phase, aux prémices d’une cyberattaque, durant laquelle l’assaillant entame la découverte et l’exploration de l’environnement IT auquel il a réussi à accéder.
Un compte utilisateur détourné
Les journaux de pare-feu permettent d’établir l’existence des connexions et les serveurs internes auxquels elles ont servi à accéder. Le système de détection et de réponse sur les hôtes (Endpoint Detection and Response, EDR) a détecté ces actions de reconnaissance réalisées et généré les alertes correspondantes.
C’est l’ensemble de ces observations qui conduit à conclure que la meilleure approche, pour empêcher l’assaillant d’aller plus loin, consiste à déconnecter tout le CHRU d’Internet.
Jean-Sylvain Chavanne se souvient : « en tout, il nous a fallu 2h30 pour décider que, pour être sereins, être sûrs d’arrêter l’attaque au bon moment et ne pas passer à côté de quelque chose, il fallait couper Internet ».
Mais les investigations se sont poursuivies dans la nuit, avec le soutien de l’Agence nationale de la sécurité des systèmes d’information (Anssi), jusqu’à 3h du matin.
En parallèle, il fallait organiser les services de soin en mode dégradé, « un travail collectif, avec les différents directeurs, la DSI, et bien sûr la direction générale, qui a parfaitement pris la mesure de la gravité de la situation ».
Un assaillant arrêté dans son élan
Lorsque la décision est prise, l’état exact d’avancement de la cyberattaque n’est pas encore établi. Il faudra attendre le lendemain et l’intervention d’un prestataire de réponse à incidents de sécurité (PRIS). Ce dernier est prêt à 8h.
À la mi-journée, la bonne nouvelle tombe : l’attaquant n’est pas parvenu à élever ses privilèges. Ses capacités de nuisances sont dès lors restées très limitées, bien en deçà de ce dont il aurait eu besoin pour réussir à déployer largement un rançongiciel et à le déclencher.
Les traces réseau font ressortir le recours à un serveur de commande et de contrôle apparu peu de temps avant, d’ailleurs partagé sur Twitter par des chercheurs, mais sans qu’il soit possible de l’attribuer à un groupe de cybercriminels connu. Et sans que les listes de blocage des pare-feu aient eu le temps d’être actualisées.
L’enquête laisse à suspecter l’implication, préalable au début de la cyberattaque, d’un maliciel dérobeur, un infostealer : le collaborateur dont le compte a été compromis a par ailleurs été victime de détournement de comptes de réseaux sociaux autour du 20 février.
Les investigations n’ont pas fait ressortir la mise en place de capacités de persistances, comme des portes dérobées ou de nouveaux comptes utilisateurs qui permettraient à l’assaillant de revenir après avoir été débusqué.
Un environnement complexe
Le CHRU Brest a adopté l’EDR d’HarfangLab, avec un prestataire de services managés de détection et de réponse (MDR). Mais l’EDR n’était pas encore configuré en mode bloquant au moment de la cyberattaque : « nous étions encore en phase d’épuration des nombreux faux positifs ».
« Le dossier patient informatisé était toujours disponible. C’est pour cela que l’on a pu conserver les consultations, les urgences, la maternité, notamment ».
Jean-Sylvain ChavanneRSSI du CHRU de Brest
Car il n’est pas question de prendre le risque, en activant trop tôt le mode bloquant, de perturber le fonctionnement d’un serveur d’imagerie médicale, par exemple.
Illustration : « notre EDR nous remonte régulièrement des alertes pour des exécutables non signés réalisant des commandes susceptibles de paraître suspectes. Alors qu’elles sont légitimes ». Et c’est le fait d’équipementiers biomédicaux qui ne signent pas systématiquement leurs exécutables.
Le CHRU de Brest, ce sont près de 8 000 utilisateurs, 350 serveurs, et surtout un parc applicatif très fortement hétérogène. L’EDR d’HarfangLab couvre l’ensemble des postes de travail et environ 300 des serveurs. De quoi disposer d’une bonne visibilité, même si elle n’est pas totale, du fait notamment de certains systèmes d’exploitation non supportés.
Le centre hospitalier aimerait aller plus loin, notamment avec le déploiement de sondes réseau permettant de pallier ces limites, « mais nous ne sommes pas en mesure de disposer d’une personne qui permettrait de les opérer », explique Jean-Sylvain Chavanne, en soulignant une difficulté de recrutement chronique sur ce genre de profil. Une fiche de poste est ouverte de longue date.
Déconnecter d’Internet ? Un choix bénéfique
Jean-Sylvain Chavanne souligne la résilience dont ont fait preuve les professionnels de santé dans cette épreuve. Mais déconnecter le CHRU d’Internet a eu plusieurs effets bénéfiques.
Tout d’abord, cette déconnexion a permis d’enquêter sur des machines actives, à la recherche de traces directement en mémoire vive, tout en contenant la menace.
En outre, les applicatifs métiers on-premise ont pu continuer de fonctionner et d’être utilisés normalement, limitant ainsi l’impact métier : « le dossier patient informatisé était toujours disponible. C’est pour cela que l’on a pu conserver les consultations, les urgences, la maternité, notamment ». L’activité de soins a pu rester quasiment normale.
La situation a toutefois permis d’identifier des applications devant être requalifiées comme critiques, à commencer par celle du brancardage. Elle est essentielle pour maintenir un bon taux de sortie et éviter l’engorgement des services de soin.
L’incident survenu début mars conduit dès lors à revoir les analyses de risque en tenant compte de la nécessité potentielle de devoir un jour, à nouveau, couper les flux d’Internet : « dans un cas pareil, il faut que l’on ait des procédures dégradées qui nous permettent de continuer à fonctionner ».
