Dedalus victime d’une attaque cyber

La réaction de l’écosystème des RSSI de santé a par contre été d’une rapidité remarquable : coupure quasi immédiate des accès en télémaintenance (VPN la plupart du temps) des équipes Dedalus vers nos solutions internes pour la supervision : comme pour le Covid, Dedalus s’est fait confiner en deux temps trois mouvements.

Côté communication, Dedalus a envoyé à ses clients un communiqué officiel, au demeurant très difficile à trouver (je n’ai pas réussi à mettre la main dessus sur le site officiel de l’entreprise, peut-être ai-je mal cherché). Côté rapidité, il s’est tout de même écoulé entre 24 heures et 48 heures avant la transmission de ce communiqué. Certains ingénieurs et techniciens de l’entreprise en charge de la relation client n’en avaient aucune connaissance (ni de l’attaque ni du communiqué) et se demandaient vendredi pourquoi diable ils n’avaient plus accès aux portails VPN de télémaintenance des hôpitaux ! Côté précision, le communiqué n’indique pas quels systèmes clients sont opérés depuis le site de Mérignac et fait référence à un retour à la normale en début de semaine suivante, ce qui a conduit la majorité des RSSI d’établissements hospitaliers à décider de maintenir la coupure pendant le week-end.

Derrière cet incident se pose la question de fond des accès en télémaintenance des fournisseurs sur les SI des clients. Accès ouverts en permanence, aucune revue des comptes fournisseurs (je ne dis pas que certains comptes restent ouverts des années après la fin des marchés… mais je ne dis pas l’inverse non plus), accès LAN to LAN, quand il ne s’agit pas d’un fournisseur qui vous demande benoîtement de ne pas changer le mot de passe, ben oui, il utilise le même chez tous ses clients, ah bon, il fallait pas ? on lui avait rien dit, quoi m’enfin. Bref, c’est la fête au village.

Incontestablement, si certains fournisseurs frisent le zéro pointé dans le domaine, côté établissements, nous ne sommes pas très nets non plus. Parmi les mesures connues à mettre en œuvre, on cite notamment :

– des comptes de connexion à durée limitée (de six mois à un an au maximum) ;

– une revue régulière des comptes ;

– une revue des accès par échantillonnage ;

– la conservation des traces de connexion ;

– un accès ouvert à la demande ;

– le bannissement des connexions LAN to LAN, et, dans l’impossibilité de faire autrement, l’isolation des équipements cibles de la prise en main dans un VLAN dédié filtré en interne par un firewall spécifique ;

– le verrouillage automatique de tout compte fournisseur non utilisé depuis une durée à convenir en interne (trois mois, six mois ?).

Le point qui revient le plus souvent dans les échanges concerne l’ouverture du canal à la demande : sur le papier, rien à redire, c’est une bonne pratique ; dans les faits, c’est un peu plus complexe. Quel numéro doit appeler le fournisseur pour se faire ouvrir l’accès ? Quel circuit interne de validation doit suivre la demande ? De qui doit-elle émaner et sur quelle base ? Comment régler la question des accès en urgence ? Le sujet n’est pas trivial du tout, a fortiori dans une grosse structure (CHU) qui compte des centaines de systèmes sous télémaintenance, des accès 24/365, des sites multiples, etc.

Le dernier sujet concerne ce que nous, établissements, allons exiger de nos fournisseurs en termes de sécurisation de ces accès. Tous les CHU sont peu ou prou OIV ou OSE (quand ce n’est pas les deux à la fois), la réglementation nous contraint, mais elle nous aide aussi car elle est opposable. Ceux qui se sont engagés dans une certification ISO 27001 savent que la revue des fournisseurs est une obligation légale, on n’y coupera pas. Plan de sécurisation, revue côté fournisseurs, annexes : bref on a de quoi s’occuper.