25 septembre 2020
On entend souvent parler de pacemaker pour désigner un défibrillateur cardiaque. Or, c’est un abus de langage car il existe en réalité deux types d’implants cardiaques différents.
Le pacemaker est un stimulateur cardiaque qui envoie un choc électrique lorsqu’il « constate » une fréquence cardiaque trop lente, afin d’éviter un malaise cardiaque.
Le Défibrillateur Implantable Actif (DIA) est un implant qui a vocation à traiter les fréquences cardiaques trop rapides.
Dans cet article, nous prendrons pour exemple le DIA. A noter que le fonctionnement des deux dispositifs est très semblable.
Un défibrillateur connecté est un écosystème informatique en soit, composé d’un DIA, d’une station de monitoring et d’un programmateur.
Après l’implantation du DIA, le patient a rendez-vous chez son cardiologue. Ce dernier utilise un programmateur (1) pour configurer par radiofréquence le DIA (2), notamment le type et le seuil des alertes. Toutes ces informations sont ensuite stockées sur des serveurs servant de support (3) pour les remontées d’informations et le déploiement des mises à jour.
Par la suite, le patient retourne à son domicile et installe le dernier dispositif, à savoir la station de monitoring (4) dans sa chambre, au plus près de son lit. A heure fixe, la nuit le plus souvent, la station va demander au DIA de lui transmettre des informations, non chiffrées, par radio fréquence. La station de monitoring envoie via le réseau télécom (3G, 4G en règle générale) les informations chiffrées cette fois-ci, au serveur servant de support. Le médecin peut désormais accéder aux données via une application web ou recevoir une alerte sur son téléphone en cas de problème.
A noter que la station de monitoring n’est pas censée pouvoir configurer le DIA.
Le premier enseignement que nous pouvons tirer est que les DIA ne se limitent pas à de simples implants, ils font partie d’un environnement composé de différents flux réseaux qui circulent entre plusieurs dispositifs. Aussi, en matière de sécurisation, il ne faut donc pas se limiter au DIA, mais également tenir compte du programmateur et de la station de monitoring, qui sont eux aussi des portes d’entrée pour un éventuel attaquant. Pour que cela soit plus parlant, nous allons vous présenter deux scénarios d’attaques.
Le programmateur est l’élément le plus éloigné du patient mais aussi l’un des plus critiques. En effet, compromettre le dispositif qui configure le DIA, c’est compromettre l’intégrité de ce dernier.
Pour se faire, la première étape serait d’accéder physiquement au programmateur : l’attaquant joue ainsi sur une première vulnérabilité (qui n’est pas informatique), le manque de sécurité physique au sein de l’hôpital. Et pour preuve, en 2018, des chercheurs israéliens ont déjà réussi à accéder physiquement à un scanner et y installer une machine malveillante sans se faire repérer[1] : la machine installée permettait de fausser les résultats et de faire apparaitre ou disparaître des tumeurs cancéreuses.
Dès lors, l’accès non autorisé à un programmateur nous semble vraisemblable. Une fois, devant le programmateur, il sera très simple de modifier le type d’implant souhaité car il n’y a souvent aucune mesure d’authentification. L’application gérant la configuration de l’implant est accessible directement et modifiable.
Selon le top 10 IoT de l’OWASP, les mots de passe encodés en dur (en d’autres termes : renseignés par défaut dans les systèmes) représentent les vulnérabilités les plus fréquentes. Les DIA ne font pas exceptions à la règle.
En effet, les équipes de WhiteScope[2] ont découvert des mots de passe écrits dans le code des stations de monitoring. Ces mots de passe permettent de s’authentifier auprès des serveurs de support qui déploient les mises à jour. L’attaquant peut ainsi se connecter à ces serveurs avec les identifiants récupérés et envoyer des mises à jour malveillantes. Le moniteur ne contrôlant pas leur origine, celui-ci va être infecté. Il pourrait par exemple drainer la batterie.
Le fichier malveillant va exploiter une faille de la communication entre le DIA et la station de monitoring. La station initie toujours la communication avec l’implant et ce dernier va lui répondre systématiquement. L’attaquant peut donc faire rejouer à la station ses demandes d’informations et drainer la batterie du défibrillateur, le rendant inutilisable.
[2] Security Evaluation of the Implantable Cardiac Device Ecosystem Architecture and Implementation Interdependencies, ,WhiteScope, Billy Rios et Jonathan Butts,17 mai 2017
Les dispositifs médicaux ont longtemps été pensés en tenant compte des problématiques de sûreté et non de sécurité. Ce déséquilibre est à l’origine des risques d’attaque que nous avons présentés.
En informatique, la sécurité consiste en la protection contre les actes malveillants ou criminels, tandis que la sûreté prévient les erreurs et les accidents. Par exemple, le fait qu’il existe un mode de fonctionnement dégradé, en cas de disfonctionnement, pour un objet de santé connecté relève de la sûreté. Or les fabricants et le secteur médical privilégient cette dernière.
Cela est tout à fait compréhensible, il s’agit d’une problématique plus ancienne et profondément ancrée dans le monde médical et sa vocation (sauver des vies) comparé à la sécurité informatique. De plus, il y a la crainte légitime du dysfonctionnement en cas de mise en œuvre de nouvelles mesures de sécurité. Il est d’ailleurs assez fréquent que les contrats de maintenance des appareils médicaux interdisent l’ajout de nouvelles mesures sans l’accord du fabricant.
Cependant les choses évoluent, la cybersécurité commence à se faire une place dans les environnements médicaux, y compris en milieu hospitalier et la nouvelle règlementation européenne relative aux dispositifs médicaux (Medical Device Regulation ou MDR) en est le parfait exemple. Historiquement, centré sur la sûreté et la qualité, le nouveau règlement innove en traitant de la sécurité informatique des dispositifs médicaux. Mais cela nous le verrons au sein de notre prochain (et dernier) volet.
[1] Injecting and Removing Cancer from CT Scans – Ben Gurion University : www.youtube.com/watch
[2] Security Evaluation of the Implantable Cardiac Device Ecosystem Architecture and Implementation Interdependencies, ,WhiteScope, Billy Rios et Jonathan Butts,17 mai 2017