Cybersécurité des logiciels médicaux, présentation de l’IEC 81001-5-1

La norme IEC 81001-5-1 est en enquête publique, son titre est explicite : “Logiciels de santé et sécurité, efficacité et sûreté des systèmes TI de santé – Partie 5-1: Sûreté – Activités du cycle de vie du produit“.

Présentation d’une norme plutôt bien construite, qui plus est en accord avec l’IEC 62304.

Portée de la norme

À l’image de la révision 2 de l’IEC 62304 cette norme vise les logiciels de santé, auxquels appartiennent les logiciels médicaux. La norme est applicable aux logiciels embarqués comme standalone.

Elle vise à démontrer la sûreté du soft, ici synonyme de cybersécurité.

En plus des fabricants, la norme prend en compte les organismes responsables de l’installation et de la maintenance.

La norme appelle d’autres normes : ISO 13485, IEC 62304, ISO 14971 et ISO/TR 24971 notamment.

Définitions

L’ambition d’une norme se juge souvent au nombre de définitions dont elle a besoin.

Vous en aurez ici 48, quasi toutes issues d’autres normes, avec beaucoup de notions déjà connues et quelques précisions, notamment sur le thème de l’informatique :

• Surface d’attaque informatique
• Défense en profondeur
• Analyse de composition logicielle : analyse des éléments binaires [NDLR : 🤔]
• Logiciel de santé transitoire : logiciel de santé diffusé avant publication de la norme, du coup il n’y répond pas.
• Point faible : insuffisance qui peut entrainer un risque de sûreté.

Plus dispensable, la norme redéfinie des notions de base comme celles de fabricant, d’environnement d’utilisation prévu, d’emploi prévu…

Le vocabulaire autour des risques vient de l’IEC 81001-1 et n’apporte rien par rapport à l’ISO 14971.

Exigences générales

Un SMQ est nécessaire, idéalement avec une ISO 13485. Une gestion des risques s’impose, avec l’ISO 14971.

Le §10 précise les exigences sur le SMQ, avec une horreur : on vous demande de l’amélioration continue “de la rigueur des activités de sureté“… Pour rappel : le mieux est l’ennemi du bien, la norme ISO 13485 est pourtant au courant.

Les responsabilités sont attribuées, les risques (ici des menaces) sont estimés, évalués puis maitrisés. Le §7 précise les attentes en matière de gestion des risques, avec une recommandation salutaire : utiliser un système de notation pour vos estimations et ne pas se contenter d’une approche qualitative (un peu, beaucoup, passionnément)

La norme demande une modélisation des menaces, l’annexe C liste des modèles existants.

Processus de développement

Grosso-modo, il s’agit de mettre en œuvre le cycle de vie défini dans l’IEC 62304, avec des exigences complémentaires :

• Utiliser des normes de codage
• Définir l’indépendance des testeurs
• Faire un gros focus sur les risques de cybersécurité
• Définir des limites de confiance
• Sécuriser les interface des logiciels (physiques comme numériques)
• Mettre en œuvre des essais propres à la cybersécurité :
  1. essais d’atténuation des menaces
  2. essais de vulnérabilités
  3. essais de pénétration

Processus de maintenance

Une politique de mise à jour de sûreté doit être définie, prenant en compte les impacts, la notoriété des failles, l’historique des attaques, le nombre de soft sur le marché et les éléments de maitrise déjà mis en œuvre.

À l’image de votre surveillance des événements de vigilance des DM comparables, vous surveillerez les attaques et autre vulnérabilités subies par vos petits copains.

Processus de gestion de la configuration, processus de résolution des problèmes

Sont des classiques, traités comme dans l’IEC 62304.

Source : norminfo