virtu-desk (virtu, IA & cyber...) VIRTU-DESK - Technologies de virtualisation et sécurisation de l'environnement utilisateurs.

Objets médicaux connectés : DAI et cybersécurité…

Francis MILLOT Par Le dimanche, 12 mai 2024 0

Dans Cybersécurité

Peu de temps encore, et principalement pour des raisons évidentes liées au monde médical dont la vocation première est de sauver des vies, les fabricants de dispositifs médicaux concevaient leurs produits en ne tenant compte que des problématiques de sûreté et non celles de sécurité.

Leur seul objectif : Être en capacité de traiter les erreurs et les accidents, de manière à garantir un mode de fonctionnement dégradé de leur dispositif en cas de disfonctionnement. Dans le domaine informatique, la sécurité traite quant à elle, de la protection contre les actes malveillants ou criminels. Mais les choses ont bien évolué aujourd’hui dans les environnements médicaux. La cybersécurité s’y est bien incrustée, y compris en milieu hospitalier, depuis l’application de la règlementation européenne relative aux dispositifs médicaux (Medical Device Regulation ou MDR). Historiquement centrée sur la sûreté et la qualité, son nouveau règlement couvre maintenant les problématiques liées à la sécurité informatique des dispositifs médicaux. Malheureusement, les industriels de la santé ne garantissent pas une sécurité à 100% pour leurs appareils médicaux connectés aux patients et la course aux armements entre hackers et fabricants d’objets médicaux connectés semble donc infinie, même si ces derniers insistent quand même sur un bénéfice supérieur au risque.

Dispositif cardiaque connecté

Dans cet article, nous allons nous focusser sur les failles liées à un dispositif cardiaque connecté et implanté sur un patient car il n’est pas impossible d'en trouver dans le Firmware (micrologiciel) de certains dispositifs. D’ailleurs, David LUPONIS, ex-spécialiste en cybersécurité au cabinet de conseil Mazars et aujourd'hui « Partner Techno Risks - Digital Risks Services » chez PwC, le confirmait en parlant des pacemakers : « Demain quelqu'un trouvera toujours une nouvelle faille. Le pacemaker est connu par les spécialistes, mais aussi par les hackers. Chaque fois qu'un objet électronique ou informatique sort, il est mis à l'épreuve par des hackers pour savoir comment contourner ses systèmes de sécurité ». Même si aujourd’hui la probabilité qu'une personne puisse accéder à ce type de dispositif sans autorisation est quasiment nul, ne dit-on pas « mieux vaut prévenir que guérir » ?

Il existe deux types d’implants cardiaques capables de réguler les fréquences du cœur d’un patient :

  1. Le pacemaker : C’est un stimulateur cardiaque qui envoie un choc électrique au cœur si sa fréquence cardiaque est trop lente, afin d’éviter un malaise cardiaque (bradycardie).
  2. Le Défibrillateur Automatique Implantable (DAI) : C’est un implant qui a vocation à traiter les fréquences cardiaques trop rapides (tachycardie).

Nous allons nous intéresser, dans ce contexte lié à la cybersécurité, au défibrillateur cardiaque (DIA). Il est généralement connecté indirectement à un réseau télécom externe et fait partie d'un pack de télésurveillance, composé de trois éléments :

  1. Le DAI lui-même
  2. Une station de monitoring (transmetteur), conforme à la Directive 1999/5/CE et à la Directive 90/385/CEE.
  3. Un programmateur.

La télésurveillance

Le principe

Globalement, les systèmes de télésurveillance de DAI fonctionnent tous sur le même principe. L’objectif est de transférer au « centre implanteur », les données collectées par le DAI à échéance périodique ou en cas d’événements majeurs qui nécessiteraient une potentielle modification de suivi et/ou d’une prise en charge médicale.

Les transmissions sont sécurisées, les données recueillies sont consultables sur un site internet sécurisé en données de santé et pour des raisons de sécurité, il est interdit d’intervenir ou de modifier les réglages du DAI à distance. Seuls le cardiologue et l’équipe en charge de votre surveillance du centre implanteur peuvent accéder à ces données, la confidentialité est ainsi garantie.

Transmission infos DAI

  • En présentiel, le cardiologue du centre implanteur utilise le programmateur pour configurer par radiofréquence le DAI du patient (type et seuil des alertes). Les informations de configuration sont aussi stockées sur un serveur distant implémenté chez un hébergeur certifié HDS (Hébergeur de Données de Santé). La certification HDS est une norme de sécurité spécifiquement conçue pour garantir la protection des données de santé en France. Ce serveur sert de support pour les remontées d’informations et le déploiement des mises à jour.
  • Le DAI surveille le rythme cardiaque en continu, réalise des séries de mesures/tests à intervalles réguliers et mémorise des données relatives aux troubles du rythme détectés et à leur traitement, à la fonction de stimulation et au rythme du patient.
  • A son domicile, le patient installe une station de monitoring (transmetteur). A heure fixe, en cas de déclenchement d’alertes ou manuellement par le patient, elle demande au DAI de lui transmettre des informations. La transmission de données se fait par signaux radio sur une bande de fréquence spécifique (401-406 MHz) appelée MICS (Medical Implant Communication System). Cette communication de courte portée (2 à 3 m) est cryptée et utilise le numéro d'identification unique du DAI.
  • Le transmetteur collecte les informations envoyées par le DAI. Il les transmet au serveur distant chez l'hébergeur de données de santé, via le réseau téléphonique ou internet, toujours de manière cryptée et en utilisant le numéro d'identification unique du DAI.
  • Les données transmises (communication sécurisée avec le numéro d’identification unique du DAI) sont accessibles en ligne à tout moment aux utilisateurs autorisés du centre implanteur pour consultation sur une interface web sécurisée dédiée.
  • En cas d’alerte, une notification est également transmise aux utilisateurs du centre implanteur enregistrés, selon des modalités paramétrables (e-mail, sms, fax, etc.).

Les protocoles de communication

La transmission des données du patient, collectées par le DAI, se fait depuis le transmetteur jusqu’au serveur implémenté chez l’hébergeur de données de santé. La connectivité ne sert qu’à faire transiter/récolter les données, mais elle ne concerne en aucun cas leur intégration au niveau du système d’information hospitalier. Elle peut s’appuyer sur différents types de protocoles de communication, standards ou propriétaires :

  • Le Wifi : C’est un réseau local à haut débit nécessitant de se connecter à un accès réseau. Plusieurs normes existent actuellement, elles sont fonction de l’évolution de la performance. Le wifi à l’avantage d’avoir une grande portée (environ 100m).
  • Le Bluetooth : C’est une technologie de proximité permettant de connecter deux appareils entre eux sans passer par un point d’accès ou un réseau existant. Contrairement au wifi, il a une portée d’environ 10m et un débit très limité.
  • Le réseau GSM : C’est un réseau mobile fonctionnant au moyen de divers antennes relais réparties sur l’ensemble du territoire, garantissant une large porté (jusqu’à 500m dans les grandes villes et 30Km en campagne). Les antennes relais sont reliées par l’intermédiaire de la fibre optique au Datacenter de l’hébergeur, en 4G et récemment la 5G qui ont l’avantage d’avoir un très grand débit, et une portée très importante.

Les protocoles standards n’ont pas vraiment su s’imposer dans le domaine des dispositifs liés à la santé personnel. Pour garder la main sur les données, les fabricants implémentent bien souvent leur propre protocole de communication prioritaire. En général, dans le milieu hospitalier, il est primordial de mettre en place des outils collaboratifs pour faciliter l’exploitation des données des patients, car elle conditionne la qualité et la coordination des soins. Les protocoles d’échanges standardisés sont donc plus communs dans le secteur hospitalier pour que le langage de communication entre les différents dispositifs permette l’intégration et le partage des données avec différents interfaces, systèmes et utilisateurs. On parle alors d'interopérabilité sémantique. Parmi ces standards, on retrouve :

  • Le HL7-CDA : Il permet la gestion du flux et du transport des documents cliniques tels que le carnet de santé de l’enfant ou encore le compte rendu d’une imagerie médicale.
  • Le DICOM : Il permet le transfert d’images sous un format standard évitant ainsi les formats propriétaires pour chaque fabricant.

Il existe aussi plusieurs types de connectivité en fonction de la marque et des besoins. La plus commune étant de passer par une passerelle HL7. HL7 pour « Health Level Seven » est un protocole standardisé d’échange de données entre un dispositif médical et le SIH (Système d’Information Hospitalier). Ce protocole est appelé ainsi, car il agit au niveau de la couche 7 applicative du modèle OSI pour permettre une interopérabilité standard entre chaque dispositif médical connecté et le système informatique hospitalier.

La gestion du risque

Le DAI fait partie d’un environnement composé de différents flux réseaux qui circulent entre plusieurs dispositifs. Il faut donc traiter les problématiques de sécurité sur l’ensemble de la chaîne, et non seulement sur de DAI en lui-même. Un attaquant peut le pirater, soit en passant directement par le programmateur depuis les locaux de l'hôpital, soit en passant directement par la station de monitoring depuis l'extérieur puisqu’elle est connectée au réseau télécom (GSM). Implicitement, il présente des risques en cas de compromission.

Et en ce qui concerne la cybersécurité, les analyses de risque doivent se concentrer sur l'évaluation du risque de préjudice pour le patient en prenant en considération, l’exploitabilité de la vulnérabilité de la cybersécurité et la gravité du préjudice subi par le patient si la vulnérabilité était exploitée.

Ces analyses doivent également prendre en compte les contrôles compensatoires et les mesures d'atténuation des risques. L'évaluation des risques relie la conception aux modèles de menace, aux dangers cliniques, aux mesures d'atténuation et aux essais. Il est important d'établir une architecture de conception sécurisée afin que les risques puissent être gérés de manière adéquate. De nombreux outils et approches peuvent être utilisés pour cette évaluation, notamment l'évaluation des risques de sécurité, la modélisation des menaces et l'évaluation des vulnérabilités :

  • Évaluation des risques de sécurité : Les fabricants doivent prendre en compte les risques, les menaces et les contrôles en matière de cybersécurité tout au long du cycle de vie du produit.
  • Modèle de menace : Un modèle de menace est un moyen d'évaluer systématiquement les risques liés aux menaces qui pèsent sur le dispositif et le système. Plus précisément, un modèle de menace au niveau du système prend en compte les risques au niveau du système, y compris, mais sans s'y limiter, les risques liés à la chaîne d'approvisionnement (par exemple, pour garantir que le dispositif reste exempt de logiciels malveillants), à la conception, à la production et au déploiement (par exemple, dans un environnement connecté/en réseau).
  • L'évaluation de la vulnérabilité : La notation des vulnérabilités permet de caractériser et d'évaluer la gravité d'une vulnérabilité en matière de cybersécurité. Les vulnérabilités et expositions communes connues (CVE) identifiées lors de la conception et du développement sont analysées et évaluées à l'aide d'une méthodologie cohérente de notation des vulnérabilités.

Les deux risques majeurs pour le patient sont :

  1. Une atteinte à sa vie privée. Si les données de santé collectées par le DAI fuitent sur Internet, l’état de santé du patient n’est plus confidentiel.
  2. Une atteinte à la vie du patient. SI un attaquant fausse les informations envoyées par le DAI, le médecin se trompe dans son diagnostic.

En effet, un attaquant peut se renseigner sur le programme de télésurveillance du patient. S’il possède une certaine expertise, il va très rapidement se rend compte que l’application web pour se connecter à la plateforme de télésurveillance est par exemple indexée sur un moteur de recherche très connu. De plus le système d’authentification utilisé par le médecin (identifiant/mot de passe) peut être vulnérable, et dans ce cas, l’attaquant peut extraire toutes les bases de données liées au patient, dont ses données de santé. La vulnérabilité correspond à l’insuffisance de sécurisation des différentes interfaces. Il faut bien entendu sécuriser le DAI, mais aussi ses différents modes d’accès (Classement des vulnérabilités les plus critiques des objets connectés).

Quelques recommandations pour réduire le risque :

  • Vérifier que les pages du site web ne sont pas référencées sur un moteur de recherche
  • Faire un audit de code pour limiter/empêcher les injections de commandes
  • Mettre en place du MFA (authentification multi-facteurs).

Les vecteurs d'attaques

Les scénarios ci-dessous présentent deux vecteurs d’attaques potentielles :

  1. Compromission du programmateur du DAI
  2. Drain parasite de la batterie du DAI

Ils mettent en lumière la vulnérabilité et les conséquences désastreuses sur les DAI si l’on ne traite pas leur sécurité dans les règles de l’art.

Compromission du programmateur du DAI

Bien qu’éloigné du patient, le programmateur est un élément des plus critiques, car compromettre le dispositif qui configure le DAI, c’est compromettre son intégrité. Si l’attaquant accède physiquement au programmateur, il joue sur une première vulnérabilité, même si elle n’est pas « informatique ». Une fois, devant le programmateur, il peut modifier le type d’implant souhaité car bien souvent, aucune mesure d’authentification n’est mise en place et l’application qui gère la configuration de l’implant est directement accessible et modifiable.

Failles potentielles :

  • Accès de l’hôpital non sécurisé
  • Absence d’authentification pour accéder au programmateur.

Risques associés :

  • Un attaquant pourrait s’introduire dans l’hôpital, accéder au programmateur et modifier les configurations de certains implants.

Probabilité : Probable.

Impact : Majeur.

Niveau de risque : Sérieux.

Difficulté de correction : Moyen

Priorité : Elevée

Quelques recommandations :

  • Mettre en place un contrôle d’accès par badge
  • Mettre en place une authentification multi-facteurs (MFA) ou SSO (Single Signe-On)
  • Durcissement du poste.

Drain parasite de la batterie du DAI

Une des vulnérabilités les plus fréquentes concerne les mots de passe encodés en dur par défaut dans les systèmes et les DAI ne font pas exceptions à la règle. En effet, des mots de passe peuvent être écrits dans le code des stations de monitoring, ce qui permet à un attaquant de s’authentifier avec les identifiants récupérés, auprès des serveurs de support qui déploient les mises à jour. A partir de là, il peut envoyer un fichier malveillant qui va exploiter une faille de la communication entre le DAI et la station de monitoring. Comme la station initie toujours la communication avec l’implant qui va systématiquement lui répondre, s’il fait rejouer ses demandes d’informations à la station de monitoring, l’attaquant va « drainer » la batterie du défibrillateur pour le rendre inutilisable.

Failles potentielles :

  • Identifiants de connexion des serveurs inscrits en dur au sein de la station de monitoring
  • Absence de contrôle d’intégrité des mises à jour de la station de monitoring
  • La station de monitoring initie la communication avec le DAI et ce dernier répond obligatoirement.

Risques associés :

  • Un attaquant pourrait infecter une station de monitoring via une mise à jour frauduleuse et rejouer les communications afin de drainer la batterie du DAI.

Probabilité : Peu probable.

Impact : critique.

Niveau de risque : Sérieux.

Difficulté de correction : Elevée

Priorité : Moyen

Quelques recommandations :

  • Réalisation d’un audit de code
  • Mise en place d’une politique de gestion des mots de passe
  • Renforcement du contrôle d’intégrité dans le DAI (acceptation des patchs signés par le fabriquant uniquement).
  • Notification en cas de communications trop nombreuses avec le DAI

Cyber-considérations relatives à la conception...

Bien que la cybersécurité des dispositifs médicaux doive être prise en compte tout au long du cycle de vie du produit, il existe des éléments importants qu'un fabricant doit prendre en compte lors de la conception et du développement d'un dispositif médical connecté avant sa mise sur le marché. La prise en compte proactive des menaces de cybersécurité au stade de la conception permet de mieux atténuer les dommages causés aux patients que les seules activités réactives postérieures à la mise sur le marché. Ces données de conception peuvent provenir de différentes phases du cycle de vie du produit, telles que la définition des besoins, les essais de vérification de la conception ou les activités de gestion des risques avant et après la mise sur le marché.

Afin de fournir des exemples concrets de considérations relatives à la conception de la sécurité, voici une liste non exhaustive qui présente certains principes qu’un fabricant de dispositifs médicaux connectés doit prendre en compte lors de la conception de ses produits.

Les cyber-considérations qu’il doit prendre en compte pour ces différentes thématiques :

  • Communications sécurisées
    • Prendre en compte la manière dont le dispositif sera interfacé avec d'autres dispositifs ou réseaux (connexions câblées, communications sans fil, interface Wi-Fi, l'Ethernet, le Bluetooth et l'USB, …).
    • Examiner la manière dont le transfert de données vers et depuis le dispositif est sécurisé afin d'empêcher tout accès ou modification non autorisé (authentification, cryptage, fin aux sessions de communication après un délai prédéfini, …).
  • Confidentialité des données
    • Déterminer si les données stockées sur l'appareil, ou transférées depuis ou vers celui-ci, nécessitent un certain niveau de protection, tel que le cryptage.
    • Déterminer si des mesures de contrôle du risque de confidentialité sont nécessaires pour protéger les champs de contrôle/séquencement des messages dans les protocoles de communication ou pour empêcher la compromission des clés cryptographiques.
  • Intégrité des données
    • Envisager des contrôles de conception qui tiennent compte d'un dispositif qui communique avec un système et/ou un dispositif moins sûr (par exemple, un dispositif connecté à un réseau domestique ou un dispositif ancien).
    • Evaluer l'architecture du système afin de déterminer si des contrôles de conception sont nécessaires pour garantir la non-répudiation des données (par exemple, en prenant en charge une fonction d'enregistrement d'audit).
  • Accès des utilisateurs
    • Envisager des contrôles d'accès des utilisateurs qui permettent de valider qui peut utiliser le dispositif, d'accorder des privilèges à différentes catégories d'utilisateurs ou de permettre aux utilisateurs d'accéder au dispositif en cas d'urgence. Parmi les exemples d'authentification ou d'autorisation d'accès figurent les mots de passe, les clés matérielles ou la biométrie.
  • Maintenance des logiciels
    • Réfléchir à la manière dont le dispositif sera mis à jour pour le protéger contre les menaces de cybersécurité nouvellement découvertes. Par exemple, on peut se demander si les mises à jour nécessiteront l'intervention de l'utilisateur ou si elles seront initiées par le dispositif.
    • Tenir compte des connexions nécessaires pour effectuer les mises à jour et de l'authenticité de la connexion, de la mise à jour ou du correctif.
    • Tenir compte de la fréquence à laquelle un dispositif devra être mis à jour par le biais de mises à jour régulières et/ou de routine.
    • Réfléchir à la manière dont les logiciels du système d'exploitation, les logiciels tiers ou les logiciels libres seront mis à jour ou contrôlés.
  • Conception matérielle ou physique
    • Envisager des contrôles pour empêcher une personne non autorisée d'accéder à l'appareil. Il peut s'agir, par exemple, de verrous physiques ou de la désactivation d'un port USB utilisé uniquement en mode service.

Il ne faut pas oublier que les principes de développement de logiciels sécurisés font partie intégrante de la conception de dispositifs sécurisés. Nombre de modèles ou normes actuels du cycle de vie du développement logiciel n'intègrent pas ces principes par défaut. Il est donc important que les fabricants de dispositifs qui développent des logiciels pour dispositifs médicaux reconnaissent cette lacune et intègrent ces principes de sécurité dans le développement de leurs logiciels.

Stratégie de gestion post-commercialisation

Étant donné que les menaces de cybersécurité ne cesseront d'évoluer, les fabricants doivent surveiller, identifier et traiter de manière proactive les vulnérabilités et les exploits dans le cadre de leur stratégie de gestion post-commercialisation. Un plan doit être élaboré avant la mise sur le marché afin de surveiller en permanence les menaces émergentes en matière de cybersécurité et d'y répondre. Ce plan doit s'appliquer tout au long du cycle de vie du dispositif. Les éléments à prendre en compte dans le cadre de ce plan, élaboré avant la mise sur le marché, devraient inclure :

  • Vigilance post-commercialisation : Un plan de surveillance proactive et d'identification des vulnérabilités de cybersécurité récemment découvertes, d'évaluation de leur menace et de réponse.
  • Divulgation des vulnérabilités : Processus formalisé de collecte d'informations auprès des personnes chargées de trouver les vulnérabilités, d'élaboration de stratégies d'atténuation et de remédiation, et de divulgation de l'existence de vulnérabilités et d'approches d'atténuation ou de remédiation aux parties prenantes.
  • Corrections et mises à jour : Un plan décrivant la manière dont le logiciel sera mis à jour pour maintenir la sécurité et les performances du dispositif, soit régulièrement, soit en réponse à une vulnérabilité identifiée.
  • Récupération : Un plan de récupération pour le fabricant, l'utilisateur ou les deux afin de remettre l'appareil en état, son état de fonctionnement normal à la suite d'un incident de cybersécurité.
  • Partage de l'information : Participation aux organisations d'analyse et de partage de l'information ou les centres de partage et d'analyse de l'information, qui favorisent la communication et l'échange d'informations, le partage d'informations actualisées sur les menaces et les vulnérabilités en matière de sécurité.

Conclusion

Tuer à distance ou prendre un appareil cardiaque en otage ne relève pas de la science-fiction. Certes, les dispositifs cardiaques connectés disposent aujourd’hui de systèmes informatiques intégrés qui sont beaucoup moins vulnérables qu’auparavant, mais le risque zéro n’existe pas. On peut donc aisément imaginer que pirater un DAI connecté à un système de télésurveillance, est tout à fait possible pour un cybercriminel expérimenté. Maintenant reste à trouver la motivation qui le conditionnerait à faire cet acte de piratage à une personne lambda...

  • 18 votes. Moyenne 5 sur 5.
Vous devez être connecté pour poster un commentaire