Domaine de recherche · Sécurité produit & OT
Une sécurité intégrée au produit – du calculateur au dispositif médical
Véhicules connectés, systèmes de contrôle industriels, dispositifs médicaux et appareils dotés d'IA restent longtemps sur le terrain. Vami Research étudie comment démontrer leur sécurité tout au long du cycle de vie – de la TARA avec l'Automotive Threat Matrix à la maintenance des dispositifs médicaux connectés et à l'IA embarquée, en passant par l'IEC 62443 et le Cyber Resilience Act.
- Automotive Threat Matrix
- ISO/SAE 21434
- IEC 62443
- Obligation de notification CRA
- MDR & IEC 81001-5-1
- IA dans le produit
- TISAX
- Deep Dives
- 10
- Livres blancs
- 3
- Solutions
- 3
Quand le logiciel est intégré au produit, la sécurité devient une propriété du produit
La sécurité produit ne protège pas l'informatique de l'entreprise, mais le produit sur le terrain – souvent face à des attaquants disposant d'un accès physique et sur des durées d'utilisation qui dépassent nettement les cycles de support IT habituels. Une vulnérabilité touche toute la base installée et peut entraîner des conséquences pour la sécurité fonctionnelle (safety), des rappels ou la perte de l'homologation de type. La responsabilité passe ainsi de l'exploitation IT au développement produit.
La réglementation suit le mouvement : depuis le 7 juillet 2024, tout véhicule neuf des catégories M, N et O dans l'UE doit disposer d'une homologation de type cybersécurité selon l'UN R155 ; depuis le 1er août 2025, des exigences de cybersécurité s'appliquent aux équipements radioélectriques connectés à Internet et, depuis le 11 septembre 2026, les obligations de notification du Cyber Resilience Act. À partir du 20 janvier 2027, le règlement Machines impose pour la première fois des exigences de cybersécurité contraignantes aux machines. Les dispositifs médicaux restent régis par le MDR – le CRA les exclut.
Avec l'IA embarquée, une nouvelle dimension s'ajoute : planificateurs, skills et appels d'outils deviennent des commandes adressées à des moteurs, des serrures ou des vannes. Vami Research associe donc des méthodes éprouvées comme la TARA, les modèles de zones et les pentests IoT à des modèles de menaces pour l'IA agentique, et publie les résultats sous forme de Deep Dives, de livres blancs et d'articles spécialisés, par exemple dans la revue mt|medizintechnik.
Les questions ouvertes du terrain
- 01
Comment décrire le comportement des attaquants sur le véhicule de sorte que TARA, pentest et Vehicle SOC parlent le même langage ?
Notre approche
Nous utilisons l'Automotive Threat Matrix de l'Auto-ISAC, release v4.02 du 4 décembre 2025, avec 14 tactiques et 75 techniques. Nous figeons la version et la mentionnons dans la TARA et le CSMS ; nous ancrons les identifiants de technique dans le PSIRT, le périmètre des pentests et le Vehicle SOC. Pour le backend, l'application compagnon, le serveur OTA et la recharge, nous tenons une couche d'extension propre – la matrice décrit avant tout le véhicule lui-même.
- 02
Comment les fabricants ancrent-ils la sécurité, du modèle de menaces jusqu'à la notification d'une vulnérabilité activement exploitée ?
Notre approche
Nous nous appuyons sur le Secure by Design and Default Playbook de l'ENISA : chaque principe avec check-list, preuve minimale et release gate. S'y ajoutent la modélisation des menaces, une SBOM par release et un PSIRT qui tient les délais du CRA de 24 heures, 72 heures et 14 jours. VamiGRC couvre le Product Security Lifecycle avec release gates, TARA et SBOM ; VamiAppSec prépare les notifications sous forme de projets.
- 03
Comment sécuriser des installations de production sans compromettre la disponibilité et la sécurité fonctionnelle ?
Notre approche
Nous structurons les installations en zones et conduits selon l'IEC 62443 et fixons un niveau de sécurité cible par zone. La visibilité sur les actifs repose sur une découverte passive, car les scans actifs peuvent perturber les automates plus anciens. La télémaintenance passe par des passerelles dédiées avec activation à chaque session. Les obligations de NIS2, qui couvre aussi l'industrie manufacturière, deviennent ainsi applicables dans l'environnement OT.
- 04
Comment les dispositifs médicaux connectés et assistés par IA restent-ils sûrs sur le terrain, lorsque la cybersécurité est aussi la sécurité des patients ?
Notre approche
Nous articulons la gestion des risques security et safety selon le MDCG 2019-16 et l'IEC 81001-5-1 : inventaire avec SBOM, triage tenant compte du contexte clinique, correctifs en tant que modifications maîtrisées, circuits de notification coordonnés. Pour l'IA, l'injection de prompt et les pouvoirs trop étendus des agents entrent dans le modèle de menaces ; pour les dispositifs médicaux à base d'IA soumis à l'intervention d'un organisme notifié, les obligations haut risque de l'AI Act s'appliquent à partir du 2 août 2028.
Ce que nous retenons
- 01
Une évaluation exhaustive des risques exige la matrice et le catalogue de l'UN R155
Nous avons mis en correspondance les 75 techniques de l'Automotive Threat Matrix avec le catalogue de menaces de l'UN R155 : 52 s'y rattachent clairement, tandis que les menaces visant les serveurs backend sont presque entièrement absentes de la matrice. Le catalogue de l'UN R155, quant à lui, ne montre aucun chemin d'attaque et ne justifie aucune faisabilité. Seules les deux listes, reliées par des identifiants stables, étayent l'évaluation des risques.
Source: Automotive Threat Matrix
- 02
Dans les produits IA, une injection de prompt peut avoir des conséquences physiques
Lorsque l'IA est intégrée à un appareil, planificateurs et appels d'outils deviennent des commandes adressées à des moteurs, des serrures ou des vannes. Le produit est alors à la fois objet connecté, système d'IA et système cyber-physique. Qui n'examine qu'une seule couche passe à côté des chaînes d'attaque qui les relient – c'est pourquoi nous modélisons selon STRIDE et MAESTRO et testons de l'interface de débogage jusqu'au LLM.
Source: Pentest des produits IA
- 03
Un appareil dont la mémoire a été extraite peut menacer tout le parc
Qui a un appareil connecté entre les mains peut solliciter les interfaces de débogage, lire la mémoire flash et analyser le firmware. Les identifiants ou clés de signature extraits d'un seul appareil sont souvent valables pour l'ensemble du parc. Sont donc vérifiés la désactivation des ports de débogage, l'efficacité du Secure Boot et le stockage protégé des secrets.
Source: Pentest IoT
- 04
Pour les dispositifs médicaux, c'est le contexte clinique qui fixe la priorité
CVSS, EPSS et KEV évaluent la gravité, la probabilité et les attaques en cours – mais pas si un appareil se trouve au chevet du patient ni si une manipulation modifie le diagnostic et la thérapie. Ce n'est qu'en répondant à ces questions que l'on détermine la classe de priorité. Une faille notée moyenne sur un système thérapeutique peut donc être plus urgente qu'une faille critique sur un appareil isolé.
Notre démarche
Vami Research associe des normes sectorielles à une méthodologie commune : modéliser les menaces, tester toutes les couches et tenir des preuves utilisables dans la TARA, la documentation technique et l'évaluation de la conformité.
TARA avec l'Automotive Threat Matrix
Techniques de la matrice comme briques des chemins d'attaque selon l'ISO/SAE 21434, confrontées au catalogue de menaces de l'UN R155 ; hypothèses de faisabilité versionnées.
STRIDE et MAESTRO
Modèle de menaces par flux de données et frontière de confiance, pour l'IA agentique selon les sept couches de MAESTRO – dans VamiThreat avec rattachement à MITRE ATT&CK et ATLAS.
Zones, conduits, découverte passive
Structurer les installations selon l'IEC 62443 en zones avec niveau de sécurité cible ; inventaire à partir du trafic mis en miroir plutôt que par scans actifs sur le réseau de production.
Tests de la puce au cloud
Pentests de produits IoT et IA selon l'OWASP ISVS et l'ISTG ainsi que l'ETSI EN 303 645 : matériel, firmware, radio, backend, application et modèle considérés ensemble.
Release gates avec preuve minimale
Playbooks de l'ENISA avec check-list et release gate ; SBOM par release, VEX et processus PSIRT comme base de la capacité de notification au titre du CRA.
Triage clinique
Compléter l'évaluation technique par l'accessibilité, la proximité du patient et les conséquences pour le diagnostic ou la thérapie ; déployer les correctifs en tant que modifications maîtrisées.
Pour démarrer
- 1ModéliserRecenser l'architecture, les flux de données et les frontières de confiance ; dériver menaces et chemins d'attaque via TARA, STRIDE ou MAESTRO.
- 2Tester et durcirPentests de l'interface de débogage jusqu'au LLM, segmentation par zones, release gates avec preuves minimales.
- 3Exploiter sur le terrainSurveiller la SBOM de chaque release, recevoir les signalements de vulnérabilités via la CVD et le PSIRT, définir à l'avance les circuits de notification au titre du CRA, du MDR et de la loi BSI.
Deep Dives, livres blancs et analyses
Deep Dives 10
Livres blancs 3
Analyses & actualités
Du domaine à la mise en œuvre
Domaines de recherche connexes
Sécuriser votre produit, de la TARA à la notification ?
Composant automobile, système de contrôle industriel ou dispositif médical : nous situons normes et délais, modélisons les menaces et testons de l'interface de débogage jusqu'au LLM.