Cybersécurité des dispositifs médicaux : les attentes réglementaires

La cybersécurité d’un dispositif médical est un sujet où deux cultures se croisent mal : celle de la sécurité informatique, qui raisonne en confidentialité, intégrité et disponibilité de l’information, et celle du dispositif médical, qui raisonne en sécurité du patient.

Le règlement tranche : c’est la seconde qui commande.

Ce que le règlement attend

Parmi les exigences générales de sécurité et de performance de l’annexe I figurent la protection contre les accès non autorisés et la sécurité de l’information. Elles ne sont pas isolées dans un chapitre séparé : elles sont des exigences de sécurité au même titre que les autres.

La Commission publie par ailleurs des guides MDCG traitant spécifiquement de la cybersécurité des dispositifs médicaux. Ils ne sont pas contraignants juridiquement mais constituent la doctrine à laquelle se réfèrent les organismes notifiés.

La conséquence pratique qui change tout

Une vulnérabilité doit être évaluée dans l’analyse de risques ISO 14971.

Pas dans une analyse de risques de sécurité séparée, pas dans un registre de vulnérabilités parallèle : dans l’analyse qui traite des risques pour le patient. La question à se poser n’est pas « quelle est la criticité CVSS » mais « quel dommage pour le patient cette vulnérabilité peut-elle causer ».

Un accès non autorisé qui permet de modifier une valeur utilisée pour une décision thérapeutique est un risque patient majeur. Le même accès sur un module de statistiques ne l’est pas. C’est cette différenciation que les évaluateurs cherchent — et qu’ils trouvent rarement.

Les quatre chantiers concrets

Le modèle de menace. Explicite, documenté, adossé au contexte d’usage réel : qui pourrait attaquer, avec quelles motivations, par quelles surfaces. Sans lui, les mesures de sécurité relèvent de l’habitude plutôt que du raisonnement.

Les exigences de conception. Authentification, gestion des habilitations, chiffrement, journalisation, imputabilité des actions. Elles doivent figurer comme des exigences tracées, pas comme des choix d’implémentation implicites.

La maîtrise des composants tiers. L’IEC 62304 impose déjà l’inventaire et le suivi des anomalies publiées pour les logiciels d’origine externe. Côté cybersécurité, cela devient un inventaire logiciel maintenu, une veille sur les vulnérabilités et une politique de mise à jour aux délais définis à l’avance.

Le traitement post-commercialisation. Une vulnérabilité découverte après la mise sur le marché relève de la surveillance après commercialisation, doit être évaluée quant à son impact patient, et corrigée selon un processus documenté.

L’articulation avec les autres régimes

Trois cadres se superposent et il faut savoir lequel répond à quoi :

• le règlement dispositifs médicaux, pour la sécurité du patient ;
• la PGSSI-S, pour la sécurité du système d’information de santé en France, avec une partie de corpus opposable ;
• le RGPD, pour la protection des données à caractère personnel.

Un logiciel dispositif médical déployé en France relève des trois. Les traiter séparément produit trois analyses redondantes et incohérentes ; les articuler autour d’un socle commun d’exigences produit un dossier tenable.

L’erreur la plus fréquente

Confier le sujet à une équipe sécurité qui produit une analyse de risques de sécurité de l’information de bonne facture — mais déconnectée de l’analyse de risques ISO 14971.

Les deux documents coexistent alors sans se parler, et l’évaluateur pose immanquablement la question à laquelle personne n’a de réponse : en quoi cette vulnérabilité affecte-t-elle la sécurité du patient ?