MDCG 2019-16 : Guide MDCG relatif à la cybersécurité des dispositifs médicaux : résumé des principes et exigences

Un nouveau guide MDCG est disponible il concerne la cybersécurité des dispositifs médicaux.
Ce guide, très riche, est proposé par le groupe MDCG-WG7 en charge des nouvelles technologies.

Les principaux points du guide sont résumés, traduits et réorganisés ci-dessous.

Contexte règlementaire

Règlement (UE) 2017/745

Exigences générales applicables aux DM logiciels :
Le guide identifie les exigences de l’annexe I du RDM applicables en cybersécurité :

• 2,3,5,6,9… : gestion des risques
• 14.1 et 14.2.d : maitrise des risques liés à la combinaison / l’association de DM
• 14.4 : réglage/étalonnage/maintenance
• 14.5 : interopérabilité et compatibilité
• 17.2 : cycle de vie du logiciel selon l’état de l’art
• 17.4. exigences minimales concernant le matériel informatique, les caractéristiques réseaux et les mesures de sécurité, y compris la protection contre l’accès non autorisé
• 23.1, 23.4 : exigences sur les informations à fournir, notamment pour sensibiliser les utilisateurs et les inciter à la cybervigilance.

Exigences du RDM en lien avec la cybersécurité :
La gestion de la cybersécurité impacte / utilise les activités suivantes :

• Veille / suivi de l’état de l’art
• Gestion de la Documentation Technique : conception, développement, essais, évaluations …
• Surveillance après commercialisation
• Communication avec les parties intéressées

Autres règlementations applicables

• Directive NIS, une annexe fait le lien entre le guide et le CG Publication 01/2018 – Reference document on security measures for Operators of Essential Services
• RGPD
• Règlement cybersécurité
• Le cas échéant : Certification hébergeur de données de santé

Concepts clés pour la cybersécurité

Des informations pour “conceptualiser” la cybersécurité, à la manière d’une norme.

Utilisations abusives raisonnablement prévisibles

En plus des erreurs d’utilisation, la cybersécurité nécessite de prendre en compte les utilisations abusives raisonnablement prévisibles.
Cela revient à considérer que toute vulnérabilité considérée comme exploitable peut être découverte et exploitée au fil du temps.

Ces utilisations abusives sont donc à identifier lors de l’analyse des risques.

Sécurité informatique

La sécurité informatique a 3 composantes :

• Confidentialité des informations, stockées et communiquées
• Intégrité, pour assurer l’authenticité et l’exactitude de l’information
• Disponibilité des processus, des dispositifs, des données et des systèmes

La sécurité informatique est à gérer selon une approche par les risques.

Vulnérabilités

Une vulnérabilité est généralement caractérisée selon un CVE.

Un scénario dans lequel un attaquant exploite une vulnérabilité connue doit être considéré comme “prévisible”, notamment si l’environnement opérationnel prévu ou d’autres contrôles d’atténuation n’empêchent pas ce type d’attaque.

Contexte de sécurité

(Éléments du contexte d’utilisation pouvant affecter la cybersécurité).

Stratégie de défense en profondeur

Cette stratégie inclut les activités de :

1. Gestion de la sécurité : planifier, documenter, suivre les actions tout au long du cycle de vie du produit.
2. Spécification des exigences de sécurité : identifier les exigences de sécurité qui sont requises pour une protection appropriée de la confidentialité, de l’intégrité et de la disponibilité des données, des fonctions et des services du DM ainsi que le contexte de sécurité du produit spécifié.
3. Sécurisation par conception.
4. Mise en œuvre sécurisée (pour les composants d’origine externe : les exigences de gestion de la sécurité s’appliquent à la place).
5. Vérification de la sécurité et essais de validation : les méthodes peuvent comprendre des tests de caractéristiques de sécurité, des tests de fuzz, des analyses de vulnérabilité et des tests de pénétration. Des tests de sécurité supplémentaires peuvent être effectués en utilisant des outils d’analyse de code sécurisé et des outils qui analysent le code source libre et les bibliothèques utilisées dans le produit, afin d’identifier les composants présentant des problèmes connus
6. Résolution des problèmes de sécurité.
7. Gestion des mises à jour de sécurité : s’assurer que les mises à jour de sécurité et les correctifs de sécurité sont testés pour les régressions et mis à la disposition des utilisateurs du produit en temps opportun.
8. Gestion des Instructions d’utilisation liées à la sécurité : fournir et maintenir une documentation qui décrit comment intégrer, configurer et maintenir la stratégie de sécurité en fonction du contexte de sécurité.

Gestion des risques de cybersécurité

Ces éléments sont en complément du processus classique de gestion des risques.

Identification des risques de cybersécurité : vulnérabilités

Les vulnérabilités doivent être :

1. Identifiées,
2. Estimées (en considérant des exploitations hypothétiques) et
3. Classées par ordre de priorité (une évaluation des risques)

Il convient d’identifier les vecteurs d’attaques : les éléments susceptibles d’être attaqués et les attaques susceptibles d’être opérées.

Exemples de risques :

• Déni de service
• Mauvaise exécution de code
• Corruption de la mémoire
• Obtention d’informations non permises
• Obtention de privilèges non permis

Estimation des risques

La probabilité des scénarios menant à un problème de cybersécurité peut être soutenue par des systèmes de notation structurés, par exemple les CVSS.

Les estimations peuvent prendre en compte le gain de l’attaquant par rapport à l’effort requis.

Options de maitrise des risques de cybersécurité

les options définies dans le règlement (et l’ISO 14971) sont déclinées pour la cybersécurité :

1. Éliminer ou réduire les risques de sécurité dans la mesure du possible grâce à une conception et une fabrication sécuritaires ;
2. Le cas échéant, prendre des mesures de protection adéquates, y compris des alarmes si nécessaire, en ce qui concerne les risques qui ne peuvent être éliminés
3. Fournir des informations pour la sécurité (avertissements/précautions/contre-indications) y compris des informations sur les mesures que l’utilisateur est tenu de prendre dans l’environnement d’exploitation.

Exigences sur le dispositif

Exemples :

• Déconnexion automatique
• Contrôles automatiques
• Gestion des autorisations
• Mises à jour des produits de cybersécurité
• Anonymisation des données personnelles
• Sauvegarde des données et récupération après incident
• Accès d’urgence
• Intégrité et authenticité des données personnelles
• Détection et protection contre les logiciels malveillants
• Authentification des nœuds (dans les réseaux)
• Authentification des personnes
• Protections / verrous physiques
• Durcissement du système et de l’OS
• Protection via un pare-feu
• Prise en compte des guides sur la sécurité et la confidentialité
• Confidentialité du stockage des données personnelles
• Confidentialité de la transmission
• Intégrité de la transmission
• Cryptage des données
• Auditabilité du système

Exigences en rapport avec l’environnement d’utilisation

Exemples :

1. Assurer la sécurité physique du DM

• Accès physique réglementé et authentifié (ex : badges)
• Politique de sécurité physique définissant les rôles et les droits d’accès, y compris pour l’accès physique au DM
• Utilisation de zones séparées et sécurisées avec des contrôles d’accès appropriés

2. Intégrer des contrôles de sécurité

• Gestion de l’accès des utilisateurs (justificatifs d’identité pour l’accès aux applications logicielles ou aux périphériques, politique d’accès des utilisateurs, etc. )
• Logiciel antivirus / anti-malware
• Pare-feu
• Listes blanches des applications autorisées
• Durcissement du système, de l’OS
• Utilisation exclusive de logiciels authentiques et interdiction de tous les logiciels et applications illégitimes
• Mesures de gestion des sessions (p. ex., déconnexion après dépassement de temps de session)

3. Assurer le contrôle et la sécurité du trafic du réseau

• Segmentation du réseau
• Le filtrage du trafic
• Le cryptage des données

4. Cas des postes de travail connectés au DM

• Liste blanche des applications autorisées à être installées
• Durcissement de l’OS
• Mesures de protection de la mémoire pour bloquer l’exécution de code arbitraire
• Compatibilité des logiciels de gestion des dispositifs médicaux avec les solutions de sécurité qui contrent les codes malveillants
• Utilisation de mots de passe forts
• N’installez que les programmes logiciels nécessaires à l’utilisation prévue de l’environnement d’exploitation.

5. Cas des systèmes complexes intégrant plusieurs DM et d’autres systèmes

• Mécanismes de partitionnement et segmentation du réseau / trafic
• Contrôles d’intégrité des logiciels et mécanismes d’authentification des dispositifs

6. Gestion des correctifs

• L’environnement d’exploitation doit permettre l’application de correctifs sans compromettre l’interopérabilité/compatibilité
• L’exploitant devrait avoir des processus de gestion des correctifs appropriés pour s’assurer que les correctifs de sécurité pour les DM sont déployés en temps opportun
• L’exploitant devrait disposer de processus appropriés de gestion des correctifs pour s’assurer que l’environnement d’exploitation (par exemple, les systèmes d’exploitation, les applications) est à jour en termes de sécurité

7. Interopérabilité

Exigences en rapport avec les exploitants

Les exploitants sont les utilisateurs des logiciels, le plus souvent sur site de soin (l’environnement d’utilisation).

Vis-à-vis des exploitants, le fabricant doit :

• Évaluer le niveau de sécurité nécessaire pour l’environnement d’exploitation
• Intégrer le système dans l’environnement du site de l’opérateur, y compris sa configuration sécurisée
• Fournir la documentation et la formation requises par l’opérateur et son personnel
• Fournir un soutien pour les M.A.J./patchs, ainsi que pour le traitement des incidents de sécurité.

Des mesures sont listées, pour limiter les risques de cybersécurité pendant l’exploitation :

• Garantir la sécurité physique pour empêcher l’accès non autorisé aux DM ou au réseau
• Mettre en place des mesures de contrôle d’accès : autorisation et authentification pour accéder aux éléments du réseau, informations, services et applications
• Mettre en place des contrôles d’accès au réseau, tels que la segmentation, pour limiter la communication entre DM
• Gérer les correctifs de sécurité pour assurer des M.A.J. de en temps opportun
• Mettre en place des protections contre les logiciels malveillants et empêcher l’exécution de code non autorisé
• Former et sensibiliser les exploitant à la cybersécurité.
• Tenir des journaux d’événements, pour avoir la capacité de déterminer qui a apporté quels changements au système (peut être nécessaire en cas d’expertise juridique)
• Garantir la maitrise lors d’éventuelles modifications du DM par l’exploitant

Informations fournies aux utilisateurs

Les informations relatives à la sécurité à destination des professionnels peuvent être construites selon le modèle MDS2.

Informations relatives au DM

• Liste des contrôles de sécurité informatique inclus dans le DM
• Caractéristiques techniques des composants matériels
• Nomenclature des logiciels
• Description des méthodes de conservation et de récupération de la configuration du dispositif par un utilisateur privilégié authentifié.
• Description de la façon dont la conception permet au dispositif de détecter les événements de sécurité, ex : changement de configuration, anomalie du réseau, tentative de connexion, trafic anormal…
• Mesures de cybersécurité recommandés, appropriés à l’environnement d’utilisation prévu (antivirus, pare-feu…
• Caractéristiques qui protègent les fonctionnalités critiques, même lorsque la cybersécurité du dispositif a été compromise (ex : durcissement de l’OS).
• Description des fonctions de sauvegarde et de restauration et des procédures pour récupérer les configurations.

Informations relatives aux exigences sur l’environnement d’utilisation

Principes :

• Les exigences en matière de sécurité pour l’environnement devraient être fondée sur l’évaluation des risques.
• Les exigences sur l’environnement doivent être réduites au minimum.
• L’environnement ne devrait pas être utilisé pour la maitrise des risques, à moins qu’il n’y ait une justification suffisante.

Exemples d’informations à fournir :

• Hypothèses sur l’environnement d’utilisation, elles peuvent se référer aux normes / bonnes pratiques.
• Risques pour le fonctionnement de l’appareil en dehors de l’environnement de fonctionnement prévu
• Exigences minimales de la plate-forme pour le DM connecté : propriétés du matériel, versions de l’OS, drivers, pilotes, périphériques…
• Mesures de sécurité informatique recommandées (antivirus, pare-feu…)
• Si hébergement externes : la documentation doit indiquer quelles, où et comment les données sont stockées, ainsi que tout contrôle de sécurité pour sauvegarder les données dans le clood (ex : cryptage)
• Si DM connectés au réseau : matrice exhaustive des flux de données du réseau (types de protocole, origine/destination des flux de données, schéma d’adressage…)
• Liste des ports réseau et autres interfaces de données, description de la fonctionnalité des ports et si les ports sont entrants ou sortants (les ports non utilisés doivent être désactivés).
• Diagrammes de réseau suffisamment détaillés pour les utilisateurs finaux.
• Le cas échéant, des instructions techniques pour permettre le déploiement et l’entretien d’un réseau sécurisé et des instructions sur la manière de réagir en cas de détection d’une vulnérabilité ou d’un incident de cybersécurité.
• Exigences de configuration spécifiques pour l’environnement d’exploitation, telles que les règles de pare-feu (ports, interfaces, protocoles, schémas d’adressage…)

Informations relatives à l’installation, à la configuration, au fonctionnement du DM

• Exigences minimales pour les postes de travail des utilisateurs : caractéristiques matérielles, versions de l’OS, périphériques…
• Modalités de configuration de sécurité (le DM doit avoir les paramètres de sécurité les plus élevés possibles sélectionnés par défaut).
• Modalités d’installation
• Modalités de configuration initiale (ex : changer le mot de passe par défaut).
• Instructions pour le déploiement des M.A.J. et correctifs
• Dispositions pour assurer l’intégrité/la validation des M.A.J. et correctifs
• Procédures d’utilisation du DM en mode de sécurité intégrée (mode différents du fonctionnement nominal, activé après la détection d’un incident de sécurité).
• Consignes en cas de message d’alerte
• Description de la manière dont l’appareil est ou peut être durci en utilisant une configuration sécurisée.

Autres informations

Le cas échéant :

• Rôles des utilisateurs et autorisations/autorisations d’accès respectives sur l’appareil
• Exigences minimales pour le poste de travail d’administration du DM
• Une description de la façon dont les preuves médico-légales sont saisies, y compris, mais sans s’y limiter, tout journal d’événement implémenté (indiquer comment et où le fichier journal est situé, stocké, recyclé, archivé, et comment il pourrait être exploité par un logiciel d’analyse automatisé).

Surveillance après commercialisation

La surveillance doit prendre en compte :

1. Les incidents de sécurité directement liés aux logiciels de DM
2. Les vulnérabilités de sécurité qui sont liées au matériel/logiciel du DM et au matériel/logiciel de tierce partie.
3. Les évolutions des menaces, y compris les aspects liés à l’interopérabilité

Les fabricants doivent évaluer les informations recueillies, évaluer les risques et prendre les mesures appropriées. Les mesures pour corriger les vulnérabilités et/ou répondre aux incidents peuvent comprendre :

• Information aux utilisateurs sur le risque identifié et les mesures d’atténuation possibles
• Corrections rapides (ex : modifications de la configuration réseau)
• Mises à jour du logiciel (de) DM
• Mises à jour ou correctifs de logiciels tiers

Évidemment, la documentation technique et ses composantes (rapports de tests, gestion des risques, évaluation clinique…) sont mis à jours au fur et à mesure.

Incidents

Le guide invite les fabricants à utiliser la nomenclature de l’IMDRF, les codes sont reproduits ci-dessous.

Catégorie d’événement indésirable selon l’annexe A :

• A11 : Problème de logiciel : Problème associé à des programmes écrits, des codes et/ou un système logiciel qui affecte les performances du DM ou la communication avec un autre DM.
  • A1105 : Problème de sécurité d’un système informatique : Problème associé à l’accès non autorisé ou à la modification d’un système logiciel entraînant une perte de confidentialité, d’intégrité ou de disponibilité du code, du logiciel, des données ou du DM entier.
    • A110501 : Problème de sécurité logiciel : Problème associé à l’acquisition de codes de programmation informatique qui peuvent se répliquer et se propager d’un système informatique à un autre, ce qui entraîne des dommages aux logiciels, au matériel et aux données.
    • A110502 : Accès non-autorisé : Problème associé à un accès non autorisé au système informatique qui peut entraîner la modification du programme, la corruption des données et/ou la rupture de la sécurité du réseau..

Terminologie pour les investigations (root cause) selon l’annexe C , à compléter car jugée insuffisante par le MDCG :

• C10 : Problème de logiciel : problèmes liés au logiciel du DM.
  • C1007 : Vulnérabilité de sécurité : le logiciel n’a pas fourni les fonctions adéquates d’autorisation, de contrôle d’accès, de protection et/ou de responsabilité.

Enfin, le guide donne une série d’exemples d’incidents de cybersécurité en annexe II.