MITRE maintient des matrices ATT&CK pour l'IT d'entreprise, les appareils mobiles et les systèmes de contrôle industriels, mais aucune pour les véhicules. C'est un choix délibéré : en 2019, General Motors a demandé à MITRE s'il était possible de construire ensemble une version d'ATT&CK spécifique à l'automobile. MITRE a poliment décliné et encouragé le développement d'une version autonome, non affiliée, calquée sur ATT&CK. À partir de janvier 2020, un groupe d'utilisateurs réunissant constructeurs (OEM), équipementiers et prestataires s'est constitué sous l'égide de l'Auto-ISAC, l'Information Sharing and Analysis Center de l'industrie automobile fondé en 2015. Le 27 mars 2024, l'Automotive Threat Matrix a été rendue publique sur atm.automotiveisac.com, exploitée par Vultara, Inc. en tant que partenaire stratégique. Six releases ont suivi depuis : v1.00 (janvier 2024), v2.00, v3.00 (août 2024, première modification majeure du contenu issue des contributions de la communauté), v4.00 (février 2025, premier export STIX), v4.01 (juin 2025) et v4.02 (4 décembre 2025). En février 2025 est paru le livre blanc d'accompagnement de l'Auto-ISAC, signé par des auteurs de GM, Sumitomo Electric Wiring Systems, HORIBA MIRA, PACCAR, Eaton et de l'Auto-ISAC. La matrice n'est donc pas un produit MITRE, mais une taxonomie industrielle qui reprend le vocabulaire d'ATT&CK et en réécrit le contenu pour le véhicule.
Automotive Threat Matrix (ATM) : ATT&CK pour les véhicules
Comment la matrice de l'Auto-ISAC décrit le comportement des attaquants sur le véhicule – et comment elle donne un langage commun à la TARA selon l'ISO/SAE 21434, à la démonstration de conformité selon l'UN R155, aux catalogues de tests de l'OWASP et au Vehicle SOC.
Depuis le 7 juillet 2024, aucun véhicule neuf des catégories M, N et O ne peut plus être immatriculé dans l'UE sans homologation de type cybersécurité selon l'UN R155, et l'ISO/SAE 21434 fournit depuis août 2021 le vocabulaire d'ingénierie correspondant. Ce qui manque aux deux, c'est un langage commun pour décrire ce que les attaquants font réellement sur un véhicule. MITRE ATT&CK, le standard de fait de la sécurité informatique, ne connaît ni bus CAN, ni protocole de diagnostic, ni calculateur. C'est précisément cette lacune que comble l'Automotive Threat Matrix (ATM) de l'Auto-ISAC : une base de connaissances librement accessible, construite sur le modèle d'ATT&CK, avec 14 tactiques, 75 techniques dans la matrice et 147 exemples documentés issus de la recherche (release v4.02 du 4 décembre 2025, état des données au 11 septembre 2026). Cette page explique comment la matrice est structurée, ce que ses preuves étayent et ce qu'elles n'étayent pas, et comment elle se positionne par rapport à la TARA, à l'UN R155 Annex 5, à l'OWASP ISTG et ISVS ainsi qu'à la famille MITRE – sur la base d'une exploitation complète du jeu de données par VamiSec.
De la demande de GM à la v4.02
Cinq étapes de l'Automotive Threat Matrix — appuyez sur un jalon.
Groupe d'utilisateurs sous l'égide de l'Auto-ISAC
Après le refus poli de MITRE à la demande de GM (2019), un groupe d'utilisateurs réunissant OEM, équipementiers et prestataires se constitue sous l'égide de l'Auto-ISAC.
L'ISO/SAE 21434 fournit le vocabulaire
La norme fournit depuis août 2021 le vocabulaire d'ingénierie — mais pas de langage commun pour décrire ce que les attaquants font réellement sur un véhicule.
L'ATM est rendue publique
L'Automotive Threat Matrix est rendue publique sur atm.automotiveisac.com, exploitée par Vultara, Inc. en tant que partenaire stratégique.
UN R155 pour tous les véhicules neufs
Depuis, aucun véhicule neuf des catégories M, N et O ne peut plus être immatriculé dans l'UE sans homologation de type cybersécurité selon l'UN R155.
Release v4.02
Sixième release de la matrice ; le livre blanc d'accompagnement de l'Auto-ISAC est paru en février 2025. État des données de l'exploitation VamiSec au 11 septembre 2026.
L'essentiel en un coup d'œil
Neuf blocs thématiques — appuyez pour déplier.
Les familles de techniques spécifiques au véhicule
32 des 75 techniques ne mentionnent aucune origine ATT&CK — la véritable valeur ajoutée de la matrice, regroupée en cinq familles.
- Cinq techniques « Abuse Standard Diagnostic Protocol » se répartissent entre Execution, Persistence, Lateral Movement, Collection et Affect Vehicle Function.
- « Bypass UDS Security Access » contourne le mécanisme seed-key du service UDS 0x27 au moyen de secrets communs à toute une série, de mécanismes challenge-response statiques ou de clés courtes.
- La famille réseau de bord comprend « Unintended Vehicle Network Message », « Modify Bus Message » et « CAN Bus Denial of Service ».
- « Bridge Vehicle Networks », « Reprogram ECU for Lateral Movement » et la reprogrammation de coprocesseurs au sein du même calculateur forment la famille gateway et persistance.
- La famille cryptographie distingue proprement les procédés cassés (« Compromise Cryptographic Security ») des clés mal protégées (« Unsecured Credentials », « ECU Credential Dumping »).
- « Analog Sensor Attacks » et « Adversarial Machine Learning » couvrent les attaques contre le lidar, la caméra, le radar et les modèles de perception.
- « Aftermarket, Customer, or Dealer Equipment » recense les dongles OBD, les outils d'atelier et les téléphones appairés à la fois comme point d'entrée, canal de commande et voie d'exfiltration.
L'Automotive Threat Matrix en détail
Treize chapitres sur l'origine, le modèle de données, les preuves et l'intégration dans la TARA, la réception par type et les tests – intégralement sur cette page, sans téléchargement.
Pourquoi il n'existe pas d'« ATT&CK for Automotive » de MITRE
MITRE maintient des matrices ATT&CK pour l'informatique d'entreprise, les terminaux mobiles et les systèmes de contrôle industriels. Une matrice dédiée aux véhicules fait défaut, et ce n'est pas un oubli, mais une décision délibérée que General Motors a rendue publique en 2025.
La demande du secteur s'est manifestée tôt : en 2019, General Motors a demandé à MITRE s'il était possible de créer ensemble une version d'ATT&CK spécifique à l'automobile. MITRE a refusé, tout en encourageant GM à mener un projet propre et non affilié.
La réponse était avisée : les véhicules se distinguent si fortement des réseaux d'entreprise par leur surface d'attaque, leur cycle de vie et l'ampleur des dommages possibles qu'un simple appendice à ATT&CK Enterprise n'aurait servi ni à la communauté informatique ni à la communauté automobile. À la place, un groupe de travail réunissant constructeurs, équipementiers et prestataires a vu le jour sous l'égide de l'Auto-ISAC ; il a repris le vocabulaire d'ATT&CK et en a réécrit les contenus.
La signature du groupe de travail
Le résultat porte la signature de ce groupe : 72 des 77 techniques sont enregistrées dans le jeu de données avec Karl Leboeuf comme auteur ; les descriptions renvoient expressément à leur origine ATT&CK pour 43 techniques, et pas pour 32 d'entre elles. Ce sont précisément ces 32 techniques qui constituent la véritable valeur ajoutée de la matrice ; elles traitent de sujets propres au véhicule :
- Détournement des protocoles de diagnostic
- Messages de bus
- Pontage de la passerelle
- Tromperie des capteurs et de l'IA
Du refus à la version v4.02
| Date | Événement |
|---|---|
| 2019 | GM interroge MITRE ; MITRE refuse et encourage un projet propre |
| 01/2020 | L'Auto-ISAC fonde le groupe d'utilisateurs de l'ATM |
| 08/2023 | Création du jeu de données central : 72 techniques portent la date de création du 9 août 2023 |
| 03/2024 | Lancement public de l'ATM sur atm.automotiveisac.com |
| 08/2024 | Révision majeure : 61 techniques modifiées pour la dernière fois en août 2024 |
| 02/2025 | L'Auto-ISAC publie le livre blanc « The Automotive Threat Matrix » |
| 03/2025 | GM présente publiquement l'utilisation, la feuille de route et l'export JSON |
| 05/2025 | La tactique « Reconnaissance » s'ajoute avec deux nouvelles techniques |
| 12/2025 | Version v4.02 : Supply Chain Compromise révisée, état actuel |
Sources : conférence GM de mars 2025 ; communiqué de presse de l'Auto-ISAC de mars 2024 ; horodatages du jeu de données ATM (état de l'API au 11 septembre 2026).
Trois types d'objets, deux formats d'export, un bouton Contribute
L'ATM est plus qu'un tableau dans le navigateur. Derrière l'application web se trouve un jeu de données entièrement téléchargeable et intégrable dans ses propres outils. Qui veut utiliser la matrice de manière productive doit en connaître les objets et les limites.
Le jeu de données connaît trois types d'objets : les tactiques comme objectifs de l'attaquant, les techniques comme modes opératoires concrets et les exemples comme preuves issues de publications de recherche. Tout ce que l'on connaît par ailleurs d'ATT&CK fait défaut à ce jour ou reste vide.
Les trois types d'objets
Tactique
Objectif de l'attaquant, avec description et rang dans la matrice. Le champ mitreId renvoie à la tactique ATT&CK correspondante ; seule « Affect Vehicle Function » reste sans renvoi.
Technique
Mode opératoire concret avec description, auteur, date de création et de modification, rattachement aux tactiques (plusieurs possibles) et références.
Exemple
Une phrase issue d'une publication de recherche qui atteste qu'une technique a réellement été appliquée, par exemple ATM-P0002 : « Les chercheurs ont surmonté l'UDS Security Access sur l'ECU de passerelle en cassant sa cryptographie faible. »
Les sous-techniques sont prévues dans le modèle de données, mais le jeu de données n'en contient aucune. Une technique reste donc la plus petite unité décrite, et la profondeur de contenu ne naît qu'à travers les exemples rattachés.
Ce que fournit le téléchargement
| Fichier | Contenu | Portée pratique |
|---|---|---|
| v4.02.json | Format natif : 242 objets (14 tactiques, 77 techniques, 151 exemples) avec descriptions HTML, horodatages et liens. | Adapté aux scripts propres, aux outils de TARA dotés d'une fonction d'import et aux bases de connaissances internes. |
| mitre-v4.02.json | « MITRE-Compliant » : bundle STIX 2.1 comptant 302 objets : 14 x-mitre-tactic, 77 attack-pattern, 151 campaign (les exemples), 59 relations uses et une x-mitre-matrix. | Base pour ATT&CK Navigator, Workbench et les plateformes de threat intelligence compatibles STIX. |
Ce qui manque est tout aussi révélateur : pas de Mitigations, pas de Detections, pas de Data Sources, ni objets de groupes ou de logiciels. Les champs existent dans le modèle de données, mais restent vides. Qui cherche des mesures de protection doit les ajouter lui-même, par exemple à partir de MITRE EMB3D ou de l'UN R155, annexe 5, parties B et C.
Toutes les indications se rapportent à la version v4.02 du jeu de données ATM, état de l'API au 11 septembre 2026.
Ce que l'attaquant cherche à obtenir
Les colonnes de la matrice suivent le cycle de vie d'une attaque : de la collecte d'informations à l'accès initial, puis au déplacement dans le réseau de bord, jusqu'à ce qui distingue un véhicule de tout autre système informatique — l'action sur la fonction du véhicule.
Une tactique décrit le pourquoi d'une étape d'attaque, la technique le comment. L'Automotive Threat Matrix reprend onze des 14 tactiques, pour l'essentiel, de MITRE ATT&CK ; trois sont redéfinies spécifiquement pour le véhicule. L'identifiant entre parenthèses indique à chaque fois la tactique ATT&CK à laquelle l'Auto-ISAC renvoie dans le jeu de données.
| ID | Tactique | Techniques | De quoi il s'agit |
|---|---|---|---|
| ATM-TA0000 | Reconnaissance | 2 | Collecter des informations, dans le véhicule et à l'extérieur. |
| ATM-TA0001 | Manipulate Environment | 8 | Attaquer l'environnement : radio, capteurs, modèles d'IA. |
| ATM-TA0002 | Initial Access | 8 | Premier pied dans le réseau : radio, applications, chaîne d'approvisionnement, dongles. |
| ATM-TA0003 | Execution | 3 | Exécuter le code de l'attaquant sur un ECU. |
| ATM-TA0004 | Persistence | 5 | Conserver l'accès au-delà des redémarrages et des mises à jour. |
| ATM-TA0005 | Privilege Escalation | 8 | Obtenir des droits plus élevés sur un ECU. |
| ATM-TA0006 | Defense Evasion | 5 | Contourner les mécanismes de protection, jusqu'à l'UDS Security Access. |
| ATM-TA0007 | Credential Access | 8 | Voler des clés, des jetons et des mots de passe. |
| ATM-TA0008 | Discovery | 8 | Explorer les fichiers, les processus, le réseau et la position du véhicule. |
| ATM-TA0009 | Lateral Movement | 6 | Se déplacer de calculateur en calculateur. |
| ATM-TA0010 | Collection | 9 | Collecter position, caméra, audio, SMS et fichiers. |
| ATM-TA0011 | Command and Control | 6 | Canaux de commande : téléphonie mobile, Internet, radio de proximité, diffusion. |
| ATM-TA0012 | Exfiltration | 7 | Extraire des données, par radio ou par supports amovibles. |
| ATM-TA0013 | Affect Vehicle Function | 8 | Agir sur la propulsion, l'airbag, les affichages ou l'audio. |
Trois tactiques à part
Reconnaissance (ATM-TA0000, 2 techniques) est nouvelle depuis 2025 et délibérément scindée en deux : les informations issues du véhicule, à savoir données de diagnostic, captures de bus et micrologiciel, et les informations issues d'autres sources telles que documentation, forums et fournisseurs. Le jeu de données renvoie à ATT&CK Enterprise TA0043.
Manipulate Environment (ATM-TA0001, 8 techniques) est spécifique au véhicule : attaques contre l'environnement sans contact physique avec le véhicule, donc brouilleurs, attaques par relais sur les clés radio, fausses stations de base de téléphonie mobile et points d'accès Wi-Fi, downgrade vers des protocoles non sécurisés ainsi que tromperie des capteurs et des modèles d'IA. Le renvoi pointe vers l'ancienne tactique Mobile « Network Effects » (TA0038).
Affect Vehicle Function (ATM-TA0013, 8 techniques) n'a pas d'équivalent dans ATT&CK ; ce qui s'en rapproche le plus est « Impair Process Control » d'ATT&CK for ICS. Sont concernés la propulsion, l'airbag, les affichages ou l'audio, via des messages de bus non intentionnels, la modification de messages légitimes, un déni de service sur le bus CAN ou le détournement de services de diagnostic. Avec 35 exemples documentés, « Unintended Vehicle Network Message » (ATM-T0071) est la technique la mieux étayée de toute la matrice.
Les 75 techniques et leurs familles
Au niveau des techniques apparaît ce qui sépare l'Automotive Threat Matrix d'une matrice informatique : à côté de schémas familiers comme ATM-T0015 Phishing figurent services de diagnostic, messages de bus, reprogrammation de calculateurs et capteurs. Les 75 techniques se regroupent en quelques familles ; le nombre d'exemples montre où la base de preuves est dense.
Détournement des protocoles de diagnostic : cinq techniques partagent la même racine de nom et ne se distinguent que par leur finalité – ATM-T0020 (Persistence), ATM-T0074 (Execution), ATM-T0050 (Lateral Movement), ATM-T0055 (Collection) et ATM-T0067 (Affect Vehicle Function). Deux d'entre elles seulement portent des exemples : ATM-T0067 avec 24, ATM-T0055 avec 2. ATM-T0033 Bypass UDS Security Access s'appuie sur le même protocole (Defense Evasion, 5 exemples).
Effet sur les fonctions du véhicule : ATM-TA0013 regroupe huit techniques. Avec 35 exemples, ATM-T0071 Unintended Vehicle Network Message affiche, selon notre propre comptage, la valeur la plus élevée du tableau de synthèse, devant ATM-T0069 Local Function (7), ATM-T0072 Denial of Service on Vehicle Function (3) et ATM-T0068 CAN Bus Denial of Service (2) ; ATM-T0070 Modify Bus Message reste sans exemple.
Déplacement latéral : ATM-TA0009 comprend six techniques. Le plus grand nombre d'exemples revient à ATM-T0054 Reprogram ECU for Lateral Movement (11), devant ATM-T0053 Remote Services (7) et ATM-T0051 Bridge Vehicle Networks (2) ; ATM-T0052 et ATM-T0050 restent sans entrée.
Cryptographie et données d'accès : ATM-T0040 Unsecured Credentials arrive en tête de Credential Access ATM-TA0007 avec 12 exemples, devant ATM-T0038 Network Sniffing (8) et ATM-T0039 ECU Credential Dumping (1). ATM-T0075 Compromise Cryptographic Security est rattachée à quatre tactiques, mais ne porte, comme ATM-T0066 Standard Cryptographic Protocol, aucune entrée.
Capteurs et IA : selon notre propre comptage, seules ATM-T0004 Analog Sensor Attacks et ATM-T0005 Adversarial Machine Learning figurent à la fois dans Manipulate Environment ATM-TA0001 et dans Affect Vehicle Function ATM-TA0013 – toutes deux sans exemple. En revanche, l'environnement radio est étayé, par exemple ATM-T0003 Manipulate Communications (5).
Les techniques les mieux étayées
| ID | Technique | Tactique(s) | Exemples |
|---|---|---|---|
| ATM-T0071 | Unintended Vehicle Network Message | Affect Vehicle Function | 35 |
| ATM-T0067 | Abuse Standard Diagnostic Protocol for Affecting Vehicle Function | Affect Vehicle Function | 24 |
| ATM-T0022 | Modify OS Kernel, Boot Partition, or System Partition | Persistence | 12 |
| ATM-T0040 | Unsecured Credentials | Credential Access | 12 |
| ATM-T0012 | Exploit via Radio Interface | Initial Access | 11 |
| ATM-T0054 | Reprogram ECU for Lateral Movement | Lateral Movement | 11 |
| ATM-T0010 | Aftermarket, Customer, or Dealer Equipment | Initial Access, Command and Control, Exfiltration | 10 |
| ATM-T0038 | Network Sniffing | Credential Access, Collection | 8 |
| ATM-T0065 | Short Range Wireless Communication | Command and Control, Exfiltration | 8 |
Chiffres issus du tableau de synthèse des techniques de l'Automotive Threat Matrix ; ATM-T0053 Remote Services et ATM-T0069 Local Function suivent avec 7 exemples chacune.
147 exemples, 23 sources, deux équipes de recherche
Ce qui distingue l'ATM d'un recueil d'idées, ce sont ses exemples : des phrases issues de travaux de recherche publiés, qui attestent qu'une technique a réellement été appliquée. Nous avons analysé les 147 – une force et un avertissement à la fois.
Deux équipes fournissent 95 des 147 exemples ; les sept sources les plus importantes couvrent 114 exemples (77,6 %). C'est l'ère de recherche 2010 à 2018 : WebKit dans le head unit, Telnet vers la passerelle, services UDS non authentifiés.
| Source (titre dans l'ATM) | Année | Équipe / cible | Exemples |
|---|---|---|---|
| Adventures in Automotive Networks and Control Units | 2013 | Miller & Valasek ; Ford Escape, Prius | 27 |
| Free-fall: Hacking Tesla from wireless to CAN bus | 2016/17 | Keen Security Lab ; Tesla Model S | 17 |
| CAN Message Injection | 2016 | Miller & Valasek ; Jeep, Prius | 17 |
| Over-the-Air: Gateway, BCM and Autopilot ECUs of Tesla cars | 2018 | Keen Security Lab ; Tesla S/X | 15 |
| Experimental Security Analysis of a Modern Automobile | 2010 | Koscher et al. (UW/UCSD) ; deux berlines | 15 |
| Hacking a Tesla Model S: What we found and what we learned | 2015 | Mahaffey/Rogers (DEF CON 23) ; Tesla Model S | 13 |
| Remote Exploitation of an Unaltered Passenger Vehicle | 2015 | Miller & Valasek ; Jeep Cherokee | 10 |
Attribution de l'année et des auteurs par VamiSec ; seuls 10 des 147 exemples indiquent une URL source ; un titre apparaît deux fois, d'où 23 publications au lieu de 24.
29 des 77 techniques sans le moindre exemple
- Analog Sensor Attacks et Adversarial Machine Learning, alors que le spoofing de lidar est publié depuis des années
- Supply Chain Compromise, révisée en décembre 2025, mais toujours sans preuve
- Disable Software Update, le thème central de l'UN R156
- Compromise Cryptographic Security, rattachée à quatre tactiques depuis avril 2025, sans exemple
- Modify Bus Message, alors que des exemples de suppression d'identifiants CAN existent, mais sont rattachés ailleurs
- Trois des cinq techniques ajoutées depuis 2024
La tactique la plus mince est Persistence : quatre techniques sur cinq sans preuve ; Credential Access et Collection suivent avec cinq techniques vides chacune. Selon notre propre attribution, aucun exemple ne provient de 2025 ou de 2026.
Ce que révèle par ailleurs le jeu de données
Un auteur, un compte
72 des 77 techniques citent Karl Leboeuf (GM) comme auteur, six seulement ont un éditeur. Un même compte est le dernier intervenant sur 73 techniques et 10 tactiques : une qualité curatée, mais un facteur bus de un.
La croissance stagne
Sur les 87 exemples dotés d'une date de création, 82 ont vu le jour en décembre 2023, quatre en août 2024 et un en mai 2025. Les 51 lacunes dans l'espace d'identifiants P0001 à P0198 le montrent : environ un quart des exemples créés au fil du temps a été supprimé par la suite.
Tout n'est pas démontré
Au moins sept exemples issus de « CAN Message Injection » commencent par « Researchers discussed the possibility » : ce sont donc des hypothèses. Sept résumés insérés produisent à eux seuls 34 liens vers des techniques : lire la preuve, pas seulement la compter.
Pourquoi maintenant : les attaques passent à l'échelle, et elles viennent à distance
Le nombre d'incidents cyber publiquement connus dans le secteur automobile augmente depuis des années, et leur nature s'est déplacée : de l'ordinateur portable branché sur le port OBD vers la télématique, le cloud et la chaîne d'approvisionnement.
Allemagne : le panorama du BSI
Le panorama sectoriel du BSI « Cybersicherheit im Straßenverkehr 2025 » analyse 107 signalements entre février 2024 et mars 2025. Sur 67 cas classables selon la voie d'accès, 18 passaient par Internet, 23 par la proximité immédiate (Bluetooth, Wi-Fi), 21 par un accès physique, 3 par le réseau local et 2 par démontage. Sur 59 cas évalués selon leur statut, 46 étaient des preuves de concept, 9 des cas théoriques et 4 des cas activement exploités.
Pour la période 2018 à 2024, le BSI dénombre 1 663 CVE liées aux véhicules ; la valeur CVSS moyenne a reculé de 8,08 (2019) à 7,19 (2024), tout en restant dans la plage « élevée ».
Pwn2Own Automotive
| Édition (Tokyo) | Zero-Days | Primes versées | Master of Pwn |
|---|---|---|---|
| janvier 2024 | 49 | 1 323 750 $ | Synacktiv (modem Tesla, IVI) |
| janvier 2025 | 49 | 886 250 $ | Sina Kheirkhah (uniquement Tesla Wall Connector) |
| janvier 2026 | 76 | 1 047 000 $ | fuzzware.io (équipe allemande) |
Source : Zero Day Initiative / Trend Micro. À Berlin (mai 2025), personne ne s'est présenté dans la catégorie Automotive.
Deux branches d'attaque
| Année | Cas | Entrée → effet | Lien avec l'ATM |
|---|---|---|---|
| 2015 | Jeep Cherokee (Miller/Valasek) | Réseau mobile → Uconnect → reflash du V850 → CAN : freins, direction, moteur ; 1,4 million de véhicules rappelés | Chaîne d'attaque 1 |
| 2016/17 | Tesla Model S/X (Keen Security Lab) | Wi-Fi et navigateur → noyau → micrologiciel de la passerelle → CAN ; première attaque à distance sur le bus CAN d'une Tesla | Chaînes d'attaque 2 et 3 |
| 2018 | BMW (Keen Security Lab) | 14 vulnérabilités dans l'unité multimédia, la télématique et la passerelle ; requêtes de diagnostic arbitraires sur CAN | ATM-P0006, 13 techniques |
| 2023 | Injection CAN, câble de phare (Tindell/Tabor) | Un dispositif logé dans le boîtier de haut-parleur usurpe les trames de la clé intelligente, l'antidémarrage cède ; Toyota RAV4 | T0016/T0071, aucun exemple |
| 2025 | Nissan Leaf (PCAutomotive) | Bluetooth → IVI → contournement du Secure Boot → C2 par réseau mobile → CAN : direction en roulant | aucun exemple |
| 2024 | Portail concessionnaires Kia (Curry et al.) | Jeton concessionnaire → VIN → données du détenteur → véhicule pilotable en 30 s à partir de la plaque d'immatriculation | Backend, hors du périmètre de l'ATM |
| 2025 | Subaru STARLINK (Curry/Shah) | Réinitialisation de mot de passe sans jeton, 2FA uniquement côté client → démarrage/arrêt, historique de localisation à 5 m près | Backend, hors du périmètre de l'ATM |
| 2024 | Cariad/VW (CCC, 38C3) | Environnement cloud mal configuré → données de localisation d'environ 800 000 véhicules électriques | Backend, hors du périmètre de l'ATM |
| 2025 | Jaguar Land Rover | Attaque informatique, environ cinq semaines d'arrêt de production, 196 millions de livres de coûts trimestriels, 1,9 milliard de livres de dommages (CMC) | Informatique d'entreprise, ATT&CK |
Branche A : le véhicule lui-même
Entrée par les interfaces radio, l'infodivertissement ou le diagnostic, puis élévation de privilèges, franchissement de la passerelle, effet sur le CAN. Stable depuis 2015, décrite par l'ATM.
Branche B : backend, portails, chaîne d'approvisionnement
Kia, Subaru, Cariad et JLR n'ont touché aucun calculateur et ont pourtant frappé des flottes et des usines. L'annexe 5 de l'UN R155 commence par ces menaces (4.3.1).
Trois niveaux, un véhicule : qui exige quoi en 2026
En Europe, la cybersécurité des véhicules est réglementée à trois niveaux : le produit (UN R155/R156), l'entreprise (NIS2, TISAX) et le composant hors réception par type (CRA).
ISO/SAE 21434 est la référence d'ingénierie pour le niveau produit, pas la loi. L'UN R155 s'applique via le règlement (UE) 2019/2144 : nouveaux types à partir du 6 juillet 2022, tous les véhicules neufs à partir du 7 juillet 2024 ; le supplément 3 s'applique depuis le 10 janvier 2025 aux catégories L, M, N et O comportant au moins un calculateur.
NIS2 et le BSIG 2025 sont en vigueur depuis le 6 décembre 2025, le délai d'enregistrement courait jusqu'au 6 mars 2026 ; le niveau des composants relève du CRA.
| Texte de référence | Ce qui s'applique | Échéance | Lien avec la matrice |
|---|---|---|---|
| UN R155 (CSMS) | CSMS certifié (3 ans au maximum, 6.7), évaluation exhaustive des risques au regard de l'annexe 5 partie A (7.3.3), détection des attaques (7.2.2.2 g), rapport annuel (7.4.1) | Tous les véhicules neufs depuis le 7 juillet 2024 | Annexe 5 = liste de menaces, ATM = comportement de l'attaquant |
| UN R156 (SUMS) | Système de gestion des mises à jour, authenticité et intégrité des mises à jour ; la série 01 rend le RxSWIN obligatoire | Série 01 en vigueur le 4 juin 2026 ; transition jusqu'au 1er septembre 2028/2030 | ATM-T0021, T0022, T0054 |
| ISO/SAE 21434:2021 | Ingénierie de cybersécurité sur l'ensemble du cycle de vie ; la clause 15 = TARA ; les annexes E et G sont informatives | Août 2021 ; deuxième édition : développement à partir de 2026 | Chemins d'attaque (15.6), faisabilité (15.7) |
| ISO/SAE PAS 8475, TR 8477, SAE J3322, ISO/PAS 5112, ISO 24089 | Précision des notions de CAL/TAF, vérification et validation ; guide d'audit pour le CSMS ; ingénierie des mises à jour au titre de la R156 | DPAS 8475 : 2026-07 ; J3322 depuis le 3 mai 2025 ; 5112 : 2022 ; 24089 : février 2023 | Planification des tests, constitution des preuves |
| Cyber Resilience Act | Ne s'applique pas aux produits relevant du règlement 2019/2144 (art. 2, par. 2, point c) ; s'applique en revanche aux composants vendus séparément, aux dongles et aux bornes de recharge | Obligations de notification à partir du 11 septembre 2026, application complète le 11 décembre 2027 | ATM-T0010 « Aftermarket, Customer, or Dealer Equipment » |
| NIS2 / BSIG 2025 | NACE C 29 et C 30 = entités importantes ; gestion des risques (§ 30), obligation de notification (§ 32), amende jusqu'à 7 millions d'euros ou 1,4 % (§ 65) | En vigueur depuis le 6 décembre 2025 ; délai d'enregistrement au 6 mars 2026 | Incidents avec identifiants de techniques |
| TISAX (ENX) | Sécurité de l'organisation et protection des prototypes ; ISA 6 jusqu'au 31 décembre 2026, VDA ISA2027 à partir du 1er janvier 2027 | ISA2027 annoncé pour le 1er juillet 2026 | Exigences fournisseurs dans les colonnes de l'ATM |
| Data Act, règlement délégué 2026/699 | Accès aux données du véhicule (access by design à partir du 12 septembre 2026) ; nouvelle annexe X du règlement 2018/858 | Le Data Act s'applique depuis le 12 septembre 2025 ; règlement délégué au JO le 3 juin 2026 | L'accès au diagnostic comme surface d'attaque |
Dans le monde : même logique, autres échéances
Japon
R155/R156 via les normes de sécurité rattachées à la loi sur la circulation routière ; nouveaux types compatibles OTA depuis juillet 2022, parc existant sans OTA depuis mai 2026.
Corée du Sud
Agrément préalable du CSMS par le MOLIT ; nouveaux types depuis le 14 août 2025, types existants à partir d'août 2027.
Royaume-Uni
Le SI 2025/1110 transpose R155/R156 dans la réception par type GB : nouveaux types à partir du 1er juin 2026, tous les véhicules à partir du 1er juin 2027.
Chine
GB 44495-2024 et GB 44496-2024 s'appliquent aux nouveaux types depuis le 1er janvier 2026 et aux types déjà homologués à partir du 1er janvier 2028.
La norme exige des chemins d'attaque. Elle n'en fournit aucun.
ISO/SAE 21434 exige des scénarios de menace, des chemins d'attaque et une faisabilité d'attaque motivée. La norme ne fournit délibérément aucun comportement concret d'attaquant. C'est précisément là que l'Automotive Threat Matrix vient s'articuler, avec des briques documentées et des identifiants stables.
La clause 15 d'ISO/SAE 21434 définit sept étapes, de l'identification des actifs au traitement des risques. Deux d'entre elles supposent une connaissance du comportement des attaquants que la norme ne fournit délibérément pas : l'identification des scénarios de menace (15.4) et l'analyse des chemins d'attaque (15.6). La faisabilité de l'attaque (15.7) constitue un troisième point d'accroche.
- 15.3Identifier les actifs : intégrité, disponibilité, confidentialité
- 15.4 point d'accrocheScénario de menace construit à partir de l'actif, d'une technique ATM et de la propriété violée
- 15.5Impact du dommage Safety, Financial, Operational, Privacy : de negligible à severe
- 15.6 point d'accrocheChemins d'attaque issus des cellules de l'ATM ; 22 chaînes d'attaque consignées dans le jeu de données, 147 exemples
- 15.7 point d'accrocheFaisabilité de l'attaque : une valeur de départ calibrée par technique, ajustée pour chaque chemin
- 15.8Valeur de risque de 1 à 5 à partir de l'impact et de la faisabilité, matrice d'exemple à l'annexe H
- 15.9Traitement du risque : éviter, réduire, partager, accepter
Pour la faisabilité, la norme autorise trois approches : l'Attack Potential avec cinq paramètres (temps, expertise, connaissance de l'item, fenêtre d'opportunité, équipement), l'exploitabilité CVSS ou le vecteur d'attaque selon le tableau G.9 ; l'annexe G est informative et qualifie expressément ses tableaux d'exemples. Le livre blanc de l'Auto-ISAC de février 2025 décrit la matrice comme une bibliothèque d'étapes potentielles d'un chemin d'attaque et propose d'attribuer à chaque élément une faisabilité par défaut. Ces valeurs par défaut sont une méthode, pas des données : le jeu de données ne contient ni valeurs de faisabilité, ni classes d'impact, ni références aux actifs. Le calibrage reste à la charge de l'organisation.
Faisabilité par défaut par technique : exemples de calcul
| Technique | Hypothèse | Paramètres (temps, expertise, connaissance, fenêtre d'opportunité, équipement) | Somme | Faisabilité |
|---|---|---|---|---|
| T0033 Bypass UDS Security Access | clé statique par série de modèles, déductible de l'outil d'atelier (comme ATM-P0033, P0167) | 1, 3, 3, 1, 0 | 8 | élevée |
| T0033 Bypass UDS Security Access | véritable challenge-response par ECU, clé dans le HSM, blocage après tentatives infructueuses | 17, 6, 7, 4, 4 | 38 | très faible |
| T0012 Exploit via Radio Interface | débordement de tas Bluetooth dans l'infodivertissement (comme Lexus 2020, ATM-P0060) | 17, 8, 3, 4, 4 | 36 | très faible |
| T0054 Reprogram ECU for Lateral Movement | après accès à la passerelle, l'ECU cible ne vérifie qu'un CRC (comme ATM-P0117) | 1, 3, 3, 4, 0 | 11 | élevée |
Valeurs selon ISO/SAE 21434:2021, annexe G, tableau G.6 (exemple d'agrégation) et G.7 (exemple de correspondance : élevée 0–13, moyenne 14–19, faible 20–24, très faible à partir de 25) ; les deux sont informatifs. Le choix des paramètres relève de notre appréciation, à titre d'illustration, et ne constitue pas une évaluation de produits réels.
La valeur par défaut dépend du contrôle en place
La même technique passe de 8 à 38 points selon que l'accès UDS repose sur un secret commun à toute une série de modèles ou sur des clés individuelles.
Une faisabilité faible ne signifie pas un risque faible
Avec 36 points, l'entrée par Bluetooth est très faible, mais elle passe à l'échelle à distance ; selon le tableau G.9, elle serait même moyenne en tant qu'adjacent. La valeur de risque selon 15.8 la maintient dans le périmètre.
Ce qui est évalué, c'est le chemin, pas la cellule
Isolée, la reprogrammation d'un calculateur est d'une faisabilité élevée ; dans la chaîne, elle hérite de la fenêtre d'opportunité et de l'équipement de l'entrée qui la précède.
Deux listes, une évaluation des risques
L'UN R155 exige, au point 7.3.3, une évaluation exhaustive des risques au regard de toutes les menaces de l'annexe 5 partie A ; ISO/SAE 21434 exige des chemins d'attaque. Nous avons mis en correspondance les 14 tactiques et 75 techniques de l'ATM avec les 67 entrées de l'annexe 5 : forte superposition dans le véhicule, lacunes nettes à ses marges.
L'annexe 5 est la seule partie de la R155 qui nomme concrètement des menaces : non pas une taxonomie d'attaquants, mais une liste de vulnérabilités et de méthodes d'attaque, ordonnée par surface d'attaque. L'annexe 5 demande quelle vulnérabilité pourrait être exploitée ; la matrice demande ce que l'attaquant fera ensuite et classe selon l'objectif. Pour l'évaluation exhaustive des risques exigée au point 7.3.3, l'annexe 5 est obligatoire ; pour les chemins d'attaque, la matrice est le meilleur outil.
| Tactique ATM | Entrées principales de l'annexe 5 (partie A, tableau A1) | Mesures héritées |
|---|---|---|
| Reconnaissance | 7.1 écoute, 28.2 résidus de développement ; 1.2/1.3 uniquement comme cible de reconnaissance | M12, M23 |
| Manipulate Environment | 4.1 usurpation (V2X, GNSS), 6.2 Man-in-the-Middle, 8.2 attaque par trou noir, 16.3 brouillage des liaisons radio de proximité et des capteurs | M10, M13, M20 |
| Initial Access | 16.1 fonctions à distance, 17.1 applications tierces, 18.1–18.3 USB/supports/dongles OBD, 5.1 injection de code, 11.2 V2X | M20, M21, M22, M10, M6 |
| Execution | 22.2 introduction de logiciels malveillants, 23.1 falsification de logiciels, 11.3 messages de diagnostic | M7, M10 |
| Persistence | 12.1/12.2 compromission des mises à jour OTA et locales, 23.1 | M16, M7 |
| Privilege Escalation | 9.1 élévation de privilèges, 28.1 défauts logiciels, 28.2 ports de débogage | M9, M23 |
| Defense Evasion | 11.3 messages de diagnostic, 6.3 rejeu/rétrogradation, 12.x mises à jour, 26.1–26.3 cryptographie | M10, M16, M11 |
| Credential Access | 19.2 données du détenteur, 19.3 extraction de clés, 28.2, 7.2 accès non autorisé aux fichiers | M8, M11, M23 |
| Discovery | en grande partie sans correspondance ; 29.1 ports ouverts | M9 |
| Lateral Movement | 29.2 contournement de la séparation réseau (passerelles), 23.1, 6.3 | M7, M10, M16 |
| Collection | 19.1 piratage de produits, 19.2 données du détenteur | M7, M8 |
| Command and Control | aucune entrée directe ; la R155 ne connaît que l'effet, pas le canal | – |
| Exfiltration | 19.x ; partiellement 31.1 changement de détenteur | M7, M8, M12 |
| Affect Vehicle Function | 24.1 inondation du CAN, 25.1 paramètres du véhicule (frein, airbag), 11.1–11.3 messages internes et de diagnostic malveillants, 8.x | M13, M15, M10, M7 |
Mise en correspondance réalisée par VamiSec sur la base des descriptions de techniques (ATM v4.02) et du libellé de l'annexe 5 (JO L 2025/5). Mesures issues des parties B/C, notamment M7 contrôle d'accès aux données et au code, M9 protection contre l'accès non autorisé, M10 authenticité et intégrité des messages reçus, M11 stockage des clés, M13 détection des dénis de service, M16 procédures de mise à jour sécurisées.
Ce que connaît l'annexe 5 et que la matrice ignore
Le serveur backend (4.3.1) presque intégralement : 1.1 acteur interne malveillant, 2.1 indisponibilité du backend, 3.1–3.5 fuite de données et perte dans le cloud ; pour les menaces 2 et 3, il n'existe aucune contrepartie dans l'ATM. S'y ajoutent 15.2 procédures de sécurité non respectées, 20.1, 20.2 et 20.5 sur l'identité et les données de diagnostic, 21.1 effacement des journaux d'événements, ainsi que 31.1 changement de détenteur, 25.2 paramètres de charge et 4.2 attaque Sybil.
Ce que connaît la matrice et que l'annexe 5 ignore
Toute la famille Discovery après l'entrée (T0045–T0049, T0060), les canaux de commande et d'exfiltration (T0062–T0066) ainsi que Adversarial Machine Learning (T0005), Native API (T0019) et Process Injection (T0029). Les entrées les plus souvent touchées sont 28.2 résidus de développement et 19.2 données du détenteur, avec huit techniques chacune, suivies de 11.3, 23.1 et 19.3 avec six chacune.
Le rapport annuel prévu au point 7.4.1 doit montrer quelles nouvelles attaques ont été observées et si les contrôles retenus restent efficaces. Avec des identifiants stables des deux côtés, il en résulte un tableau de couverture qu'un service technique peut vérifier : entrée de l'annexe 5, techniques ATM, preuves issues des ATM-P et de cas propres, mesure issue de la partie B et preuve issue d'un test d'intrusion ou d'un événement IdsM. Pour 2.1 et 3.x, la colonne des techniques ATM reste vide ; ce sont alors des entrées d'ATT&CK Enterprise qui prennent le relais.
La matrice indique ce que font les attaquants. Elle n'indique pas comment tester.
Une matrice de menaces ne représente qu'un tiers de la chaîne. Entre le comportement de l'attaquant et la question de savoir si un véhicule est sûr s'intercalent deux autres catalogues : les exigences applicables au produit et les cas de test destinés à la preuve. OWASP fournit les deux, conçus pour les équipements IoT.
Auto-ISAC ATM
14 tactiques, 75 techniques, auxquelles s'ajoutent R155 Annex 5 partie A et EMB3D (81 menaces).
OWASP ISVS
Cinq chapitres, niveaux de vérification L1 à L3, auxquels s'ajoutent R155 parties B/C (23 mesures) et EMB3D (89 mesures).
OWASP ISTG
101 cas de test répartis en huit composants, auxquels s'ajoutent FSTM et SAE J3322 / ISO/SAE TR 8477.
L'ISTG est un projet incubateur OWASP de Luca Pascal Rotsch et Aaron Guzman : version 1.0.0 du 1er mars 2024, 1.0.1 du 1er juin 2024, derniers cas de test ajoutés en juillet 2026. Le modèle d'attaquant combine l'accès physique PA-1 (à distance) à PA-4 (invasif) avec le niveau d'autorisation AA-1 à AA-4 ; les identifiants se présentent par exemple sous la forme ISTG-FW[UPDT]-CRYPT-004.
L'ISVS classe les exigences en cinq chapitres : V1 écosystème IoT, V2 application en espace utilisateur, V3 plateforme logicielle, V4 communication, V5 plateforme matérielle. Le niveau 3 des trois niveaux de vérification s'applique aux équipements dont la compromission doit être évitée « à tout prix », avec les véhicules connectés comme exemple explicite.
Attention à l'état des versions : le seul tag de publication est la 1.0RC de décembre 2020, avec 124 exigences, alors que la branche principale mentionne « version 1.0, octobre 2025 » avec 156 à 169 exigences. L'annexe B établit une correspondance avec l'annexe I du CRA, le règlement délégué RED 2022/30 et l'ETSI EN 303 645, mais pas avec l'UN R155.
Les techniques ATM rapportées aux composants ISTG
| Composant ISTG | Équivalent dans le véhicule | Techniques ATM | Chapitre ISVS |
|---|---|---|---|
| Processing Units (PROC) | SoC d'infodivertissement, CPU télématique | Injection de processus, élévation de privilèges (T0026, T0029, T0024) | V3 plateforme logicielle |
| Memory (MEM) | Flash, RAM, mémoires sécurisées | Credential Dumping, accès mémoire (T0039, T0074, T0022) | V5 matériel |
| Firmware (FW, INST/UPDT) | Firmware d'ECU, mise à jour, OTA | Reprogrammation, cryptographie (T0031, T0054, T0075, T0021) | V3 plateforme logicielle |
| Data Exchange Services (DES) | UDS/DoIP, passerelle CAN | Abus du diagnostic, messages de bus (T0067, T0071, T0068, T0050) | V4 communication |
| Internal Interfaces (INT) | Bus d'ECU, UART de débogage | Pontage de réseaux, contournement de filtres (T0051, T0032) | V4 communication |
| Physical Interfaces (PHY) | OBD-II, JTAG, USB | Fault Injection, modification (T0016, T0028, T0073, T0013) | V5 matériel |
| Wireless Interfaces (WRLS) | Réseau mobile, Wi-Fi, Bluetooth, NFC, TPMS | Exploit radio, relais (T0012, T0065, T0007, T0009) | V4 communication |
| User Interfaces (UI) | Écran tactile, assistant vocal | Enregistrement des saisies, Screen Capture (T0037, T0061) | V2 application |
| Lacune de l'ISTG | Caméra, lidar, radar | Analog Sensor Attacks, Adversarial ML (T0004, T0005) | via MITRE ATLAS |
Le schéma d'identifiants prévoit des spécialisations telles que ISTG-DES[UDS], mais elles ne sont pas renseignées. Ni EN 303 645 ni M/606 ne référencent ISTG ou ISVS ; cette mise en correspondance résulte de notre propre analyse.
Cinq cartes pour un véhicule
Aucun référentiel isolé ne couvre un véhicule connecté avec son backend, son application, ses calculateurs et son IA. L'ATM est la carte du véhicule lui-même. Qui connaît les cartes voisines sait où poursuivre sa lecture.
| Base de connaissances (état) | Structure et volume | Usage dans le contexte automobile | Limite |
|---|---|---|---|
| Auto-ISAC ATM v4.02 (04/12/2025) | 14 tactiques, 75 techniques (77 dans le jeu de données), 147 exemples | Chemins d'attaque pour la TARA, cadrage de pentest, marquage CTI | s'arrête à la frontière du véhicule, preuves de 2010 à 2018 |
| ATT&CK Enterprise v19 (28/04/2026) | 15 tactiques, 222 techniques, 475 sous-techniques | IT de l'OEM, backend OTA, cloud, catégorie R155 4.3.1 | ne connaît ni CAN, ni UDS, ni ECU |
| ATT&CK Mobile v19 | 12 tactiques, 77 techniques, 47 sous-techniques | Applications compagnons, modèle pour cinq tactiques de l'ATM | terminal mobile, pas véhicule |
| ATT&CK for ICS v19 | 12 tactiques, 79 techniques, 18 sous-techniques | ancêtre de « Affect Vehicle Function » | conduite de processus industriels, pas réseau de bord |
| EMB3D v2.0.2 (01/06/2026) | 81 menaces, 89 mesures, STIX 2.1 | quelle propriété d'ECU ouvre quelle menace | pas de tactiques, pas de chaînes |
| ATLAS v2026.08 (01/09/2026) | 16 tactiques, 114 techniques, 83 sous-techniques, 72 études de cas | Attaques d'IA sur la perception, les modèles, les données d'entraînement | aucune étude de cas portant sur un véhicule |
| CAPEC v3.9 (24/01/2023) | 559 modèles d'attaque, perspective ICS/OT | pont vers CWE | figé de fait depuis 2023 |
ATT&CK paraît deux fois par an, ATLAS tous les mois ; l'ATM a connu six versions depuis mars 2024, aucune en 2026.
ATT&CK compte trois fois plus de techniques que l'ATM, mais aucune pour les protocoles de diagnostic. EMB3D compte 89 mesures, mais aucune chaîne d'attaque. Seule la chaîne allant de la technique ATM à la menace EMB3D puis à la mesure EMB3D comble la lacune.
« MITRE-compliant » désigne un format, pas une appartenance
Depuis la v4.00 (12 février 2025), Auto-ISAC fournit, à côté du JSON natif, un fichier STIX 2.1 conforme au modèle d'objets ATT&CK. Nous avons décomposé mitre-v4.02.json : 302 objets, dont 1 matrix, 14 tactiques (ATM-TA0000 à TA0013), 77 attack-pattern, 151 campaign portant les alias ATM-P0001 et suivants, 59 relationship et 0 course-of-action.
- Avec pertes : 59 relations au lieu de 221 liens entre techniques et exemples ; 140 des 151 exemples restent orphelins, seules 37 techniques sont étayées.
- Les 91 phases de kill chain portent toutes la mention « not applicable » au lieu d'un domaine ; le Navigator a besoin d'une référence de domaine cohérente.
- Ni objet identity, ni objet marking-definition, donc aucune condition d'utilisation lisible par machine.
- Le fichier natif v4.02.json (242 objets) contient tous les liens et constitue l'artefact de publication complet.
Préparer le bundle
Extraire mitre-v4.02.json de son enveloppe base64 issue de l'API de publication, fixer kill_chain_name sur un nom de domaine, compléter les relations.
Configurer le Navigator
Déclarer le bundle comme fichier local dans config.json (STIX 2.0 et 2.1), créer un layer 4.5 avec customDataURL.
Trois layers, un backlog
Layer A : les techniques ATM étayées (48). Layer B : votre propre périmètre de pentest. Layer C : ce qui est observable par le VSOC. Les écarts constituent le backlog.
Chaînes reconstituées, de l'accès initial à la fonction du véhicule
Des attaques réelles sur des véhicules se laissent traduire en tactiques et en techniques de la matrice. Nous avons ordonné deux cas le long des colonnes de tactiques ; chaque étape indique la technique, l'identifiant ATM et la source.
L'attaque de Charlie Miller et Chris Valasek contre un Jeep Cherokee est la seule chaîne entièrement pilotée à distance du jeu de données qui aille jusqu'à l'actionnement ; dix exemples ATM la décrivent.
- Initial AccessExploit via Radio InterfaceATM-T0012 · ATM-P0074
Chaque Cherokee répondait, via le réseau mobile Sprint, à tout autre appareil Sprint.
- Discovery / ExecutionSystem Network Configuration Discovery ; Command and Scripting InterpreterATM-T0048, T0018 · ATM-P0093, P0176
Interrogation GPS et commandes shell arbitraires via le service D-Bus ouvert.
- Persistence / PivotModify OS Kernel, Boot Partition, or System PartitionATM-T0022 · ATM-P0075
Prise de contrôle de la puce V850 de la head unit au moyen d'une mise à jour de firmware manipulée.
- Affect Vehicle FunctionLocal Function ; Unintended Vehicle Network Message ; Abuse Standard Diagnostic ProtocolATM-T0069, T0071, T0067 · ATM-P0073, P0144, P0145, P0192, P0094
Climatisation et affichage, puis clignotants et verrouillage des portes, enfin commandes de direction via une session de diagnostic.
Le point décisif n'est pas l'accès initial, mais la prise de contrôle de la puce V850, un coprocesseur situé dans la même head unit et dépourvu de vérification de signature. En langage R155 : Annex 5 n° 12.2 et 11.3, mesure M16. Le 24 juillet 2015, FCA a rappelé 1,4 million de véhicules.
Tesla Model S 2016 : Wi-Fi, navigateur, noyau, passerelle, CAN
- Manipulate Environment / Initial AccessRogue Wi-Fi Access Point ; Browser CompromiseATM-T0009, T0011 · ATM-P0103, P0042
Point d'accès falsifié, puis exploit WebKit pour CVE-2011-3928.
- Privilege Escalation / Defense EvasionExploit OS Vulnerability ; Bypass Mandatory Access ControlATM-T0026, T0034 · ATM-P0001, P0003
Vulnérabilité du noyau CVE-2013-6282, puis contournement d'AppArmor.
- Credential Access / Defense EvasionUnsecured Credentials, Network Sniffing ; Bypass UDS Security AccessATM-T0040, T0038, T0033 · ATM-P0004, P0105, P0149, P0002, P0043
Clés SSH, identifiants statiques, clé UDS obtenue par capture du trafic CAN.
- Lateral Movement / Affect Vehicle FunctionRemote Services ; Unintended Vehicle Network MessageATM-T0053, T0071 · ATM-P0044, P0106, P0045
Telnet et SSH vers la passerelle ; celle-ci traduisait en CAN les paquets UDP des ports 20100/20101.
« Free-fall », du Tencent Keen Security Lab, est la chaîne la plus profonde du jeu de données : 17 exemples, 13 techniques, 9 tactiques. Tesla l'a refermée le 18 septembre 2016 par une mise à jour OTA ; la CISA la référence sous ICSA-16-341-01. Le plus grand bloc de preuves provient de Miller et Valasek sur le port OBD, avec 44 exemples.
| Technique | dans les chaînes | Exemples |
|---|---|---|
| T0022 Modify OS Kernel, Boot Partition, or System Partition | 5 / 5 | 10 |
| T0071 Unintended Vehicle Network Message | 4 / 5 | 33 |
| T0067 Abuse Standard Diagnostic Protocol | 4 / 5 | 24 |
| T0018 Command and Scripting Interpreter | 4 / 5 | 5 |
| T0040 Unsecured Credentials | 3 / 5 | 12 |
Notre propre analyse portant sur cinq chaînes reconstituées.
- Un secure boot sur chaque ECU reprogrammable brise T0022 dans les cinq chaînes, ainsi que T0031 et T0054.
- Des clés UDS individuelles plutôt que statiques dévaluent T0033 et T0067 ; SecOC vise T0071.
- L'absence de secrets dans les firmwares et les outils d'atelier fait s'effondrer T0040.
Ce à quoi la matrice sert, et ce à quoi elle ne sert pas
Une évaluation équitable distingue ce que la matrice apporte de ce que ses utilisateurs y projettent : 147 exemples sourcés d'un côté, un champ de mesures vide sur l'ensemble des 77 techniques de l'autre.
Ce à quoi la matrice est utile
- Un langage commun entre OEM, fournisseurs, testeurs et VSOC : 14 colonnes familières aux habitués d'ATT&CK.
- Une bibliothèque de chemins d'attaque pour la TARA : 147 exemples étayés et 22 chaînes pour l'ISO/SAE 21434, clause 15.
- Un marquage CTI et pentest avec des identifiants stables, inchangés depuis août 2023, plus un export STIX 2.1.
- Une planification des tests par cadrage colonne par colonne ; les techniques UDS et CAN sont bien étayées, avec 57 exemples.
- Rapport annuel R155 : les menaces considérées deviennent un tableau de couverture vérifiable.
Ce que la matrice n'est pas
- Pas une analyse de risque : ni faisabilité, ni impact, ni champ de probabilité. Elle alimente la TARA, elle ne la remplace pas.
- Pas un catalogue de mesures : le champ des mesures est vide sur les 77 techniques.
- Pas une bibliothèque de détection : pas de data sources, pas d'analyses, aucune référence de télémétrie.
- Pas une liste de contrôle de conformité : aucune correspondance avec R155 Annex 5, les clauses de l'ISO 21434 ou TISAX.
- Ni actuelle, ni neutre : 85,7 % des preuves s'arrêtent en 2018, un tiers concerne Tesla, le backend est presque vide.
La gouvernance du jeu de données détermine elle aussi sa solidité en situation d'audit.
Facteur de bus : un
72 des 77 techniques proviennent d'un seul auteur, six versions en deux ans, aucune à ce jour en 2026. Traitez la matrice comme une dépendance open source : figez la version, vérifiez les diffs.
Dérive silencieuse
Aucun mécanisme de dépréciation : T0056 et T0057 sont de fait désactivées, mais restent présentes dans l'export. Le fichier de publication (151 exemples) et l'API en direct (147) divergent.
Confusion d'identifiants
Un exemple fourni par un éditeur marque une persistance par diagnostic avec « ATM:T1543 », un identifiant ATT&CK Enterprise. Les identifiants ATM ont le format ATM-T00xx.
Dix étapes font passer la matrice du navigateur à la TARA, au pentest et au VSOC.
| Étape | Ce qu'il faut faire |
|---|---|
| 1 Apparier EMB3D | Mettre en correspondance les techniques utilisées avec les menaces EMB3D et hériter de leurs mesures. |
| 2 Maintenir une extension | Plage d'identifiants propre pour le backend, l'application, le serveur OTA, la recharge (ISO 15118, OCPP), le V2X. |
| 3 Figer la version | Consigner l'ATM v4.02 (04/12/2025) dans la TARA et dans l'artefact CSMS, archiver l'export STIX. |
| 4 Mapper sur R155 Annex 5 | 4.3.2 à 4.3.7 se transposent bien, 4.3.1 backend reste largement ouvert. |
| 5 Construire des heatmaps | Techniques étayées (48) face au périmètre de pentest et à la visibilité du VSOC ; l'écart constitue le backlog. |
| 6 Ancrer les identifiants dans le PSIRT | Marquer les vulnérabilités, les cas de bug bounty et les incidents ; au bout de douze mois, vous disposez de vos propres données de tendance. |
| 7 Cas d'usage VSOC | Commencer par T0067, T0071 et T0033 : 25,8 % de tous les exemples. |
| 8 Contribuer des cas | Soumettre via le bouton Contribute ; 29 des 77 techniques n'ont aucun exemple. |
| 9 Les données comme données | Importer le JSON, clarifier le doublon P0083, les exemples orphelins et les techniques sans tactique. |
| 10 Compléter les dimensions | Impair vs. Inhibit issus d'ATT&CK for ICS et faisabilité selon l'annexe G pour chaque technique. |
Automotive Threat Matrix – ATT&CK pour les véhicules : du jeu de données à la TARA
34 pages sur la matrice de l'Auto-ISAC : le jeu de données complet exploité, trois chaînes d'attaque réelles reconstruites en langage ATM, correspondance avec l'ISO/SAE 21434, l'UN R155 Annex 5, l'OWASP ISTG et ISVS ainsi que MITRE EMB3D – avec des exemples chiffrés de faisabilité de l'attaque et un playbook en dix points pour la mise en œuvre.
Le jeu de données complet exploité
14 tactiques, 75 techniques, 147 exemples issus de 23 sources : origine, familles de techniques, paternité et les preuves avec leurs angles morts.
Trois chaînes d'attaque en langage ATM
Jeep Cherokee 2015, Tesla « Free-fall » 2016 et Miller/Valasek étape par étape – avec les cinq points de rupture où les défenseurs coupent les chaînes.
Mapping vers R155, ISO/SAE 21434 et OWASP
Annex 5 face à l'ATM, étapes TARA 15.4 à 15.7 avec faisabilité par défaut selon l'Annex G, composants ISTG par composant du véhicule.
Réalité STIX et playbook en dix points
Ce que contient réellement l'export « MITRE-compliant », comment naissent les heatmaps Navigator et quelles dix étapes font entrer la matrice dans la TARA, le pentest et le VSOC.
Livre blanc en langue allemande, état septembre 2026 – gratuit après une courte inscription.
Normes & sources
Le contenu de cette page s'appuie sur les guides et études suivants, accessibles publiquement.
Automotive Threat Matrix (ATM), Release v4.02
Base de connaissances publique avec 14 tactiques, 75 techniques dans la matrice et 147 exemples ; état des données de cette page : 11 septembre 2026. Consultable gratuitement et téléchargeable en JSON natif ainsi qu'en bundle STIX 2.1.
The Automotive Threat Matrix (ATM) – Whitepaper
Sept cas d'usage, de la TARA à la déclaration R155 en passant par la threat intelligence ; décrit la méthode de la faisabilité par défaut par élément. Auteurs de GM, Sumitomo, HORIBA MIRA, PACCAR, Eaton et de l'Auto-ISAC.
Enhancing Vehicle Cyber Security: Updates to the Automotive Threat Matrix Tool
Présentation de mars 2025 retraçant la genèse : en 2019, MITRE a décliné la demande de GM et encouragé une version autonome ; feuille de route et export JSON.
ISO/SAE 21434:2021 – Road vehicles – Cybersecurity engineering
Norme d'ingénierie couvrant l'ensemble du cycle de vie du véhicule ; le chapitre 15 (Clause 15) définit la méthodologie TARA, l'Annex G les tableaux d'exemple pour la faisabilité de l'attaque, l'Annex E les Cybersecurity Assurance Levels.
UN Regulation No. 155 – Cyber security and cyber security management system (version consolidée avec le Supplement 3)
Règlement d'homologation de type avec certificat CSMS, évaluation exhaustive des risques selon l'Annex 5 partie A et mesures issues des parties B et C ; contraignant dans l'UE via le règlement (UE) 2019/2144 depuis juillet 2024 pour tous les véhicules neufs.
OWASP IoT Security Testing Guide (ISTG)
Méthodologie de test avec 101 cas de test répartis en huit composants d'appareil et un modèle d'attaquant fondé sur l'accès physique (PA-1 à PA-4) et les autorisations (AA-1 à AA-4) ; version 1.0 de mars 2024, maintenue en continu.
OWASP IoT Security Verification Standard (ISVS)
Catalogue d'exigences en cinq chapitres avec les niveaux de vérification L1 à L3 ; les véhicules connectés sont cités comme exemple du niveau L3.
MITRE EMB3D Threat Model, Version 2.0.2
Modèle de menaces pour les appareils embarqués : propriétés des appareils, 81 menaces et 89 mesures échelonnées, avec export STIX 2.1 ; l'automobile est expressément citée comme secteur cible. Complément naturel d'une ATM dépourvue de mesures.
MITRE ATT&CK, Version 19
Enterprise, Mobile et ICS ; l'ATM renvoie à des identifiants ATT&CK pour 13 de ses 14 tactiques, en partie issus de la matrice Mobile. ATT&CK lui-même ne contient aucun domaine véhicule.
Cybersécurité dans la circulation routière 2025 – Tableau de situation sectoriel (Cybersicherheit im Straßenverkehr 2025 – Branchenlagebild)
107 signalements entre février 2024 et mars 2025, répartition par voie d'accès et par statut ainsi que 1 663 CVE liées aux véhicules de 2018 à 2024 – la base de comparaison nationale pour une situation de menace recensée avec des identifiants ATM.
Global Automotive & Smart Mobility Cybersecurity Report 2026
494 incidents signalés publiquement en 2025, 92 % exécutés à distance, 67 % via des systèmes télématiques et cloud, 44 % liés à des ransomwares.
Pwn2Own Automotive 2026 – Résultats
76 zero-days et 1 047 000 dollars US de récompenses à Tokyo ; infotainment via USB, bornes de recharge via NFC. Montre où se situe le front de la recherche en 2026 et ce qui manque encore dans les preuves de l'ATM.
Votre TARA, vos tests et votre SOC dans un seul langage ?
Lors d'un premier entretien sans engagement, nous vous montrons comment intégrer l'Automotive Threat Matrix dans votre TARA selon l'ISO/SAE 21434, votre planification de pentests et vos preuves de conformité selon l'UN R155 – y compris les lacunes que vous devrez combler vous-même.