Threat model d'un dispositif médical : les vues d'architecture et la matrice de risques

Votre organisme notifié ou la FDA réclame un « threat model ». L’équipe produit alors une énumération STRIDE et quelques contre-mesures, ou à l’inverse un jeu de schémas d’architecture très propres. Dans les deux cas, il manque la moitié du livrable — et surtout le fil qui relie l’un à l’autre jusqu’au patient. Car la guidance premarket de la FDA de septembre 2023 ne demande pas de choisir : elle attend des vues d’architecture documentées et une analyse de risques cotée, reliées entre elles et transférées vers l’analyse de risques sécurité patient. Voici la méthode que j’applique chez mes clients, et ce que le texte exige précisément.

Qu’est-ce qu’un threat model de dispositif médical ?

Définition : le threat modeling est le processus qui identifie les objectifs de sécurité, les risques et les vulnérabilités à l’échelle du système du dispositif médical, puis définit les contre-mesures destinées à prévenir, atténuer, surveiller ou traiter les effets des menaces sur tout son cycle de vie.

La différence avec un threat model informatique classique ne tient pas à la technique, elle tient au critère de sortie. En IT, la question est « l’attaque est-elle possible, et comment la bloquer ? ». En dispositif médical, la question est « si elle réussit, quel préjudice pour le patient, et ce préjudice est-il acceptable ? ». Tout le reste de la méthode découle de ce déplacement.

L’exigence est explicite des deux côtés de l’Atlantique : la FDA recommande que le threat modeling soit conduit tout au long du processus de conception et couvre l’ensemble des éléments du système, et l’analyse de menaces fait partie des activités imposées par l’IEC 81001-5-1, dont c’est l’un des chantiers du rattrapage à mener sur du code existant.

Ce que la FDA attend précisément du threat model

C’est le point le plus souvent survolé, alors que la guidance est très directive. Le threat model doit faire quatre choses.

Identifier les risques et les mesures, et alimenter les cotations avant et après mitigation reprises dans l’évaluation des risques cybersécurité. La double cotation n’est donc pas une coquetterie méthodologique : elle est attendue nommément.

Énoncer ses hypothèses sur le système et son environnement d’utilisation. La guidance donne elle-même l’exemple à suivre : les réseaux hospitaliers sont intrinsèquement hostiles, et il est recommandé de supposer qu’un adversaire contrôle le réseau, avec la capacité d’altérer, de supprimer et de rejouer des paquets. Un threat model qui ne déclare pas ses hypothèses laisse l’évaluateur les deviner — et il les devinera en votre défaveur.

Couvrir tout le cycle de vie, pas seulement le produit en fonctionnement : les risques introduits par la chaîne d’approvisionnement, la fabrication, le déploiement, l’interopérabilité avec d’autres dispositifs, les activités de maintenance et de mise à jour, et la mise hors service. La guidance précise que ce sont précisément les risques qu’une analyse de sécurité patient traditionnelle laisse échapper — l’attaque Stryker de mars 2026 en donne l’illustration la plus nette.

Justifier la méthode retenue. Vous êtes libre de choisir votre méthodologie, ou d’en combiner plusieurs, mais la motivation de ce choix doit être fournie avec la documentation. C’est une phrase à ne pas négliger : elle transforme « on a fait du STRIDE » en une décision à argumenter.

Matrice ou diagrammes ? La FDA demande les deux

Voilà l’erreur de cadrage que je vois le plus souvent, dans les deux sens. Certains livrent une matrice de risques sans schéma, d’autres de très beaux diagrammes sans cotation ni décision. La guidance attend les deux, et les articule.

Côté schémas, elle recommande de fournir dans la soumission au minimum quatre vues d’architecture de sécurité :

• la Global System View, vue d’ensemble du système ;
• la Multi-Patient Harm View, qui traite les scénarios de préjudice à plusieurs patients ;
• l’Updateability/Patchability View, sur le mécanisme de mise à jour et de correctif ;
• une ou plusieurs Security Use Case Views, par cas d’usage sensible.

Chacune se documente avec des diagrammes et du texte explicatif — les deux, pas l’un ou l’autre. Les formes acceptées sont larges : diagrammes de flux de données, diagrammes d’états, swim-lanes, call-flows. Le niveau d’exigence, lui, est élevé : les vues doivent être assez détaillées pour qu’un ingénieur ou un évaluateur puisse suivre les données, le code et les commandes d’un actif à l’autre, y compris en traversant des actifs intermédiaires, avec les protocoles et leurs versions, les ports, les mécanismes d’authentification et la gestion de session.

Ces vues doivent aussi identifier les éléments du système et leurs interfaces, définir le contexte de sécurité, les domaines, les frontières, les rôles utilisateurs critiques et les interfaces externes, et établir la traçabilité entre les éléments d’architecture et les exigences de sécurité.

La guidance ajoute une phrase qui vaut de l’or en pratique : les vues d’architecture sont un moyen efficace de transmettre l’information de threat modeling, et si la documentation de threat modeling couvre déjà suffisamment une vue, la FDA n’attend pas qu’on duplique. Vues et matrice ne sont pas deux dossiers concurrents : ce sont deux faces du même travail.

En pratique, je livre donc les deux : les vues portent la démonstration — comment le système est construit et où passent les flux — et la matrice porte la décision — quel risque a été coté, maîtrisé, accepté, et par qui.

Les trois registres à constituer avant la matrice

L’erreur de méthode la plus coûteuse est de remplir la matrice directement. Il faut d’abord trois catalogues numérotés, maintenus séparément et réutilisables d’un produit à l’autre :

• Les actifs — tout ce qui a de la valeur ou constitue une cible : les données (données patient, images, configuration, rapports produits), les identifiants et secrets, les composants applicatifs, les services tiers intégrés, l’infrastructure d’hébergement, et les actifs contrôlés par le fabricant comme un serveur de mise à jour. L’inventaire des actifs recoupe votre SBOM sans se confondre avec lui : le SBOM énumère les composants logiciels, le registre d’actifs énumère ce qu’un attaquant convoite. La guidance note d’ailleurs que ce travail d’analyse aide à déterminer ce qui doit figurer dans le SBOM.
• Les menaces — formulées de façon générique et réutilisable : un acteur, une capacité, un objectif. Elles ne dépendent pas de votre produit.
• Les vulnérabilités — les conditions qui rendent une menace réalisable : authentification faible, absence de chiffrement en transit, secrets stockés en clair, absence de journalisation.

Chaque entrée reçoit un identifiant permanent. Ce détail apparemment bureaucratique est ce qui rend l’exercice rejouable : à la version suivante, vous recotez des lignes existantes au lieu de tout réécrire, et un auditeur peut suivre un fil de bout en bout.

Une ligne de risque = une menace × un groupe d’actifs

C’est le point de méthode que je vois le plus souvent manqué. Une même menace produit plusieurs lignes de risque, une par groupe d’actifs — parce que les mesures de maîtrise diffèrent.

Prenez une menace d’accès non autorisé par devinement d’identifiants. Elle s’applique à votre propre application, aux services tiers que vous intégrez, et à l’infrastructure qui héberge le tout. Trois périmètres, trois responsables, trois jeux de contre-mesures : dans le premier cas vous maîtrisez le code, dans le deuxième vous dépendez des capacités du fournisseur, dans le troisième de votre hébergeur ou de votre infogéreur.

Si vous fusionnez ces situations en une seule ligne, la colonne des mesures devient une bouillie où personne ne distingue plus qui fait quoi. Les séparer coûte trois lignes et rend la matrice honnête.

Exploitabilité, et non probabilité

Si vous ne deviez retenir qu’un point de cet article, ce serait celui-là — et c’est celui qui fait recaler le plus de dossiers.

La FDA explique qu’on ne peut pas quantifier la vraisemblance d’un incident de sécurité à partir de données historiques ou de modélisation, comme on le ferait pour une défaillance matérielle. Une attaque n’est pas un phénomène aléatoire : elle est le fait d’un adversaire qui décide. L’évaluation des risques de sécurité est donc non probabiliste, et se concentre sur l’exploitabilité — la capacité effective à exploiter une vulnérabilité présente dans le dispositif ou son système.

C’est exactement ce qui distingue votre matrice de sécurité de votre analyse ISO 14971, et la guidance le dit dans ces termes : cette approche non probabiliste n’est pas celle de la gestion des risques sécurité patient, ce qui souligne pourquoi les deux processus sont distincts mais connectés.

Deux conséquences concrètes. En premarket, certains facteurs d’exploitabilité issus du CVSS — maturité du code d’exploitation, niveau de remédiation, confiance dans le signalement — ne s’appliquent pas à un logiciel non encore publié : la guidance admet alors soit une hypothèse de pire cas assortie de mesures, soit une justification argumentée. Et l’exploitabilité augmente avec le temps : si un pentester y arrive aujourd’hui, un attaquant y arrivera plus facilement demain. Les vulnérabilités figurant au catalogue KEV de la CISA, déjà activement exploitées, doivent quant à elles être éliminées par conception.

Le pont vers l’ISO 14971 : exprimer l’impact en préjudice

La colonne d’impact ne se rédige pas en termes techniques. « Perte de confidentialité » ou « compromission du serveur » ne veut rien dire pour un évaluateur clinique. Elle se rédige en conséquence clinique dans le pire cas crédible : que se passe-t-il pour le patient si cette menace aboutit ? Une décision thérapeutique erronée, un retard de prise en charge, une intervention prolongée, une donnée faussée sur laquelle un praticien s’appuie. La dimension vie privée se déclare en parallèle, pas à la place : une violation de données de santé est un préjudice en soi.

Et surtout — c’est une exigence de soumission explicite — vous devez fournir la méthode de transfert des risques de sécurité vers le processus d’analyse de risques sécurité patient. Autrement dit, il ne suffit pas que les deux dossiers coexistent : le chemin qui mène de la ligne de matrice au dossier de gestion des risques doit être décrit, et praticable.

Un threat model qui ne mentionne jamais le patient n’est pas un threat model de dispositif médical. C’est un audit de sécurité informatique avec un logo d’entreprise medtech.

Coter deux fois : risque initial, mesures, risque résiduel

La matrice se lit de gauche à droite en deux passes. Exploitabilité × impact donnent le risque initial. On documente les mesures de maîtrise. Puis on recote les deux axes pour obtenir le risque résiduel, qui porte la décision d’acceptabilité.

De cette mécanique découle un principe à tenir fermement : les mesures réduisent l’exploitabilité, presque jamais la gravité. Une authentification multifacteur ne rend pas un plan opératoire erroné moins grave pour le patient ; elle le rend moins probable. En conséquence, la colonne d’impact est en général identique entre les deux passes — et une matrice où la gravité s’effondre après mitigation est un signal d’alarme immédiat pour un évaluateur.

Sur l’échelle elle-même, une nuance importante : puisque la cotation sécurité repose sur l’exploitabilité et non sur la probabilité, elle ne peut pas être strictement celle de votre ISO 14971, et c’est normal. Ce que la FDA demande de fournir, ce sont les méthodes de cotation avant et après mitigation, les critères d’acceptation associés, et la méthode de transfert évoquée plus haut. La cohérence exigée ne porte donc pas sur l’échelle, mais sur le verdict : les deux dossiers ne doivent jamais conclure différemment sur la gravité d’un même préjudice patient.

Ce qui rend la matrice défendable

Une colonne de mesures qui décrit des intentions ne vaut rien. Chaque mesure doit renvoyer à un document maîtrisé de votre système qualité : politique de contrôle d’accès, procédure de gestion des utilisateurs, politique de cybersécurité, enregistrement de configuration d’infrastructure. « MFA activé » est une affirmation ; « MFA activé, cf. politique de contrôle d’accès » est une preuve vérifiable. Tout ce qui n’est pas référencé sera lu comme non vérifiable — donc comme non fait.

Dernier point : la matrice est une photographie, et les vulnérabilités arrivent en continu. Le threat model doit être branché sur votre processus de veille et de triage des vulnérabilités et sur le plan de gestion post-market attendu par la FDA. Un threat model figé le jour de la soumission est faux six mois plus tard.

Récapitulatif : les colonnes de la matrice

FAQ

Le threat model remplace-t-il l’analyse de risques ISO 14971 ?

Non, et les confondre est une erreur fréquente. Ce sont deux analyses distinctes, avec des logiques d’évaluation différentes — non probabiliste et centrée sur l’exploitabilité d’un côté, probabiliste de l’autre. Elles se rejoignent par un chemin que vous devez décrire explicitement dans la soumission : la méthode de transfert des risques de sécurité vers le processus d’analyse de risques sécurité patient.

STRIDE, MITRE ATT&CK : quelle méthode faut-il choisir ?

Celle que vous saurez appliquer complètement — et que vous saurez justifier, puisque la FDA demande que la motivation du choix accompagne la documentation. STRIDE structure bien l’énumération des menaces élément par élément ; ATT&CK apporte des techniques d’adversaire réalistes. Pour démarrer, le Playbook for Threat Modeling Medical Devices du MDIC et de MITRE est la ressource que la guidance elle-même cite en référence.

Faut-il refaire le threat model à chaque version ?

Le refaire, non — le réévaluer, oui. C’est à ça que servent les identifiants stables : une nouvelle interface ou un nouveau service tiers ajoute des lignes, un changement d’architecture en fait recoter certaines, le reste est revu et daté. La FDA attend un threat modeling conduit tout au long de la conception, et l’IEC 81001-5-1 un document vivant revu aux jalons du cycle de vie — pas un livrable produit une fois pour la soumission.