MITRE mantiene matrices ATT&CK para la TI corporativa, los dispositivos móviles y los sistemas de control industrial, pero ninguna para vehículos. Se trata de una decisión deliberada: en 2019, General Motors preguntó a MITRE si podía desarrollarse conjuntamente una versión de ATT&CK específica para automoción. MITRE declinó cortésmente y animó a desarrollar una versión independiente, no afiliada, tomando ATT&CK como modelo. A partir de enero de 2020 se formó, bajo el paraguas del Auto-ISAC (el Information Sharing and Analysis Center de la industria del automóvil, fundado en 2015), un grupo de usuarios compuesto por OEM, proveedores y empresas de servicios. El 27 de marzo de 2024, la Automotive Threat Matrix se hizo pública en atm.automotiveisac.com, operada por Vultara, Inc. como socio estratégico. Desde entonces ha habido seis releases: v1.00 (enero de 2024), v2.00, v3.00 (agosto de 2024, primer cambio de contenido importante a partir de contribuciones de la comunidad), v4.00 (febrero de 2025, primera exportación STIX), v4.01 (junio de 2025) y v4.02 (4 de diciembre de 2025). En febrero de 2025 apareció el whitepaper complementario del Auto-ISAC, con autores de GM, Sumitomo Electric Wiring Systems, HORIBA MIRA, PACCAR, Eaton y Auto-ISAC. La matriz no es, por tanto, un producto de MITRE, sino una taxonomía de la industria que adopta el vocabulario de ATT&CK y reescribe los contenidos para el vehículo.
Automotive Threat Matrix (ATM): ATT&CK para vehículos
Cómo la matriz del Auto-ISAC describe el comportamiento de los atacantes en el vehículo, y cómo dota de un lenguaje común al TARA según ISO/SAE 21434, a las evidencias exigidas por UN R155, a los catálogos de pruebas de OWASP y al Vehicle SOC.
Desde el 7 de julio de 2024 no puede matricularse en la UE ningún vehículo nuevo de las categorías M, N y O sin homologación de tipo en materia de ciberseguridad conforme a UN R155, e ISO/SAE 21434 aporta desde agosto de 2021 el vocabulario de ingeniería correspondiente. Lo que les falta a ambos es un lenguaje común para lo que los atacantes hacen realmente en un vehículo. MITRE ATT&CK, el estándar de facto de la seguridad TI, no conoce ni el bus CAN, ni el protocolo de diagnóstico, ni la unidad de control. Justo esa laguna la cubre la Automotive Threat Matrix (ATM) del Auto-ISAC: una base de conocimiento de acceso libre, construida a imagen de ATT&CK, con 14 tácticas, 75 técnicas en la matriz y 147 ejemplos documentados procedentes de la investigación (release v4.02 del 4 de diciembre de 2025; datos actualizados a 11 de septiembre de 2026). Esta página explica cómo está estructurada la matriz, qué sostiene su evidencia y qué no, y cómo encaja en el TARA, en UN R155 Annex 5, en OWASP ISTG e ISVS y en la familia MITRE, sobre la base de un análisis completo del conjunto de datos realizado por VamiSec.
De la petición de GM a la v4.02
Cinco hitos de la Automotive Threat Matrix — toca un hito.
Grupo de usuarios bajo el Auto-ISAC
Tras la cortés negativa de MITRE a la petición de GM (2019), se forma bajo el paraguas del Auto-ISAC un grupo de usuarios compuesto por OEM, proveedores y empresas de servicios.
ISO/SAE 21434 aporta el vocabulario
La norma aporta desde agosto de 2021 el vocabulario de ingeniería, pero no un lenguaje común para lo que los atacantes hacen realmente en un vehículo.
La ATM se hace pública
La Automotive Threat Matrix se hace pública en atm.automotiveisac.com, operada por Vultara, Inc. como socio estratégico.
UN R155 para todos los vehículos nuevos
Desde entonces no puede matricularse en la UE ningún vehículo nuevo de las categorías M, N y O sin homologación de tipo en materia de ciberseguridad conforme a UN R155.
Release v4.02
Sexta release de la matriz; el whitepaper complementario del Auto-ISAC apareció en febrero de 2025. Datos del análisis de VamiSec actualizados a 11 de septiembre de 2026.
Lo esencial en resumen
Nueve bloques temáticos — toca para desplegar.
Las familias de técnicas específicas del vehículo
32 de las 75 técnicas no mencionan ningún origen en ATT&CK: el verdadero valor añadido de la matriz, ordenado en cinco familias.
- Cinco técnicas «Abuse Standard Diagnostic Protocol» se reparten entre Execution, Persistence, Lateral Movement, Collection y Affect Vehicle Function.
- «Bypass UDS Security Access» elude el procedimiento seed-key del servicio UDS 0x27 mediante secretos comunes a toda una serie de modelos, mecanismos challenge-response estáticos o claves cortas.
- La familia de la red de a bordo comprende «Unintended Vehicle Network Message», «Modify Bus Message» y «CAN Bus Denial of Service».
- «Bridge Vehicle Networks», «Reprogram ECU for Lateral Movement» y la reprogramación de coprocesadores dentro de la misma unidad de control forman la familia de gateway y persistencia.
- La familia criptográfica distingue con claridad entre procedimientos rotos («Compromise Cryptographic Security») y claves mal protegidas («Unsecured Credentials», «ECU Credential Dumping»).
- «Analog Sensor Attacks» y «Adversarial Machine Learning» recogen los ataques contra lidar, cámara, radar y modelos de percepción.
- «Aftermarket, Customer, or Dealer Equipment» cubre los dongles OBD, los equipos de diagnóstico de taller y los teléfonos emparejados como punto de entrada, canal de mando y vía de exfiltración a la vez.
La Automotive Threat Matrix en detalle
Trece capítulos sobre su origen, el modelo de datos, la evidencia y su integración en el TARA, la homologación de tipo y las pruebas: íntegros en esta página, sin descargas.
Por qué no existe un «ATT&CK for Automotive» de MITRE
MITRE mantiene matrices ATT&CK para la TI empresarial, los dispositivos móviles y los sistemas de control industrial. Falta una matriz para vehículos, y no se trata de un descuido, sino de una decisión deliberada que General Motors hizo pública en 2025.
La demanda del sector surgió pronto: en 2019, General Motors preguntó a MITRE si podían crear conjuntamente una versión de ATT&CK específica para automoción. MITRE lo rechazó, pero animó a GM a emprender un proyecto propio y no vinculado.
La respuesta fue acertada: los vehículos se diferencian tanto de las redes corporativas en superficie de ataque, ciclo de vida y efecto del daño que un apéndice de ATT&CK Enterprise no habría beneficiado ni a la comunidad de TI ni a la de automoción. En su lugar, bajo el paraguas del Auto-ISAC surgió un grupo de trabajo formado por fabricantes, proveedores y prestadores de servicios que adoptó el vocabulario de ATT&CK y reescribió los contenidos.
La impronta del grupo de trabajo
El resultado lleva la impronta de ese grupo: 72 de las 77 técnicas figuran en el conjunto de datos con Karl Leboeuf como autor; 43 descripciones remiten expresamente a su origen en ATT&CK y 32 no lo hacen. Precisamente esas 32 constituyen el verdadero valor añadido de la matriz, ya que abordan cuestiones específicas del vehículo:
- Abuso de protocolos de diagnóstico
- Mensajes de bus
- Puenteo del gateway
- Engaño de sensores y de modelos de IA
De la negativa a la versión v4.02
| Fecha | Acontecimiento |
|---|---|
| 2019 | GM pregunta a MITRE; MITRE lo rechaza y anima a emprender un proyecto propio |
| 01/2020 | El Auto-ISAC funda el grupo de usuarios de la ATM |
| 08/2023 | Creación del conjunto de datos básico: 72 técnicas llevan la fecha de creación del 9 de agosto de 2023 |
| 03/2024 | Lanzamiento público de la ATM en atm.automotiveisac.com |
| 08/2024 | Gran revisión: 61 técnicas modificadas por última vez en agosto de 2024 |
| 02/2025 | El Auto-ISAC publica el informe técnico «The Automotive Threat Matrix» |
| 03/2025 | GM presenta públicamente el uso, la hoja de ruta y la exportación en JSON |
| 05/2025 | Se incorpora la táctica «Reconnaissance» con dos técnicas nuevas |
| 12/2025 | Versión v4.02: Supply Chain Compromise revisada; estado actual |
Fuentes: ponencia de GM de marzo de 2025; nota de prensa del Auto-ISAC de marzo de 2024; marcas de tiempo del conjunto de datos de la ATM (estado de la API: 11 de septiembre de 2026).
Tres tipos de objeto, dos formatos de exportación, un botón Contribute
La ATM es más que una tabla en el navegador. Tras la aplicación web hay un conjunto de datos que puede descargarse por completo e integrarse en herramientas propias. Quien quiera emplear la matriz de forma productiva debe conocer sus objetos y sus límites.
El conjunto de datos contempla tres tipos de objeto: las tácticas como objetivos del atacante, las técnicas como procedimientos concretos y los ejemplos como pruebas extraídas de publicaciones de investigación. Todo lo demás que resulta familiar de ATT&CK falta por ahora o permanece vacío.
Los tres tipos de objeto
Táctica
Objetivo del atacante, con descripción y orden en la matriz. El campo mitreId remite a la táctica correspondiente de ATT&CK; solo «Affect Vehicle Function» queda sin referencia.
Técnica
Procedimiento concreto con descripción, autor, fecha de creación y de modificación, asignación a tácticas (posible de forma múltiple) y referencias.
Ejemplo
Una frase procedente de una publicación de investigación que acredita que una técnica se aplicó realmente; por ejemplo, ATM-P0002: «Los investigadores superaron el UDS Security Access en la ECU del gateway rompiendo su criptografía débil.»
Las subtécnicas están previstas en el modelo de datos, pero el conjunto de datos no contiene ninguna. La técnica sigue siendo, por tanto, la unidad descrita más pequeña, y la profundidad de contenido solo surge a través de los ejemplos asignados.
Qué ofrece la descarga
| Archivo | Contenido | Relevancia para la práctica |
|---|---|---|
| v4.02.json | Formato nativo: 242 objetos (14 tácticas, 77 técnicas, 151 ejemplos) con descripciones en HTML, marcas de tiempo y vínculos. | Adecuado para scripts propios, herramientas de TARA con función de importación y bases de conocimiento internas. |
| mitre-v4.02.json | «MITRE-Compliant»: paquete STIX 2.1 con 302 objetos: 14 x-mitre-tactic, 77 attack-pattern, 151 campaign (los ejemplos), 59 relaciones uses y una x-mitre-matrix. | Base para ATT&CK Navigator, Workbench y plataformas de inteligencia de amenazas compatibles con STIX. |
Lo que falta resulta igual de revelador: no hay mitigaciones, ni detecciones, ni fuentes de datos, ni objetos de grupos o de software. Los campos existen en el modelo de datos, pero están vacíos. Quien busque contramedidas deberá añadirlas por su cuenta, por ejemplo a partir de MITRE EMB3D o de UN R155 Annex 5, partes B y C.
Todos los datos se refieren a la versión v4.02 del conjunto de datos de la ATM, estado de la API: 11 de septiembre de 2026.
Qué quiere lograr el atacante
Las columnas de la matriz siguen el ciclo de vida de un ataque: desde la obtención de información y el acceso inicial hasta el movimiento por la red de a bordo y aquello que distingue a un vehículo de cualquier otro sistema de TI: la afectación de la función del vehículo.
Una táctica describe el porqué de un paso del ataque; la técnica, el cómo. La Automotive Threat Matrix retoma once de las 14 tácticas de MITRE ATT&CK en sentido análogo y define tres de forma nueva y específica para el vehículo. El identificador entre paréntesis indica en cada caso la táctica de ATT&CK a la que remite el Auto-ISAC en el conjunto de datos.
| ID | Táctica | Técnicas | De qué se trata |
|---|---|---|---|
| ATM-TA0000 | Reconnaissance | 2 | Recopilar información, dentro y fuera del vehículo. |
| ATM-TA0001 | Manipulate Environment | 8 | Atacar el entorno: radiofrecuencia, sensores, modelos de IA. |
| ATM-TA0002 | Initial Access | 8 | Primer punto de apoyo en la red: radiofrecuencia, aplicaciones, cadena de suministro, dongles. |
| ATM-TA0003 | Execution | 3 | Ejecutar código del atacante en una ECU. |
| ATM-TA0004 | Persistence | 5 | Mantener el acceso a través de reinicios y actualizaciones. |
| ATM-TA0005 | Privilege Escalation | 8 | Obtener mayores privilegios en una ECU. |
| ATM-TA0006 | Defense Evasion | 5 | Eludir mecanismos de protección, incluido el UDS Security Access. |
| ATM-TA0007 | Credential Access | 8 | Robar claves, tokens y contraseñas. |
| ATM-TA0008 | Discovery | 8 | Explorar archivos, procesos, red y posición del vehículo. |
| ATM-TA0009 | Lateral Movement | 6 | Desplazarse de una unidad de control a otra. |
| ATM-TA0010 | Collection | 9 | Recopilar posición, cámara, audio, SMS y archivos. |
| ATM-TA0011 | Command and Control | 6 | Canales de control: red móvil, internet, radio de corto alcance, radiodifusión. |
| ATM-TA0012 | Exfiltration | 7 | Extraer datos, por radiofrecuencia o mediante soportes extraíbles. |
| ATM-TA0013 | Affect Vehicle Function | 8 | Influir en la propulsión, el airbag, los indicadores o el audio. |
Tres tácticas con una posición especial
Reconnaissance (ATM-TA0000, 2 técnicas) es nueva desde 2025 y está deliberadamente dividida en dos: información procedente del vehículo, es decir, datos de diagnóstico, capturas de bus y firmware, e información procedente de otras fuentes, como documentación, foros y proveedores. El conjunto de datos remite a ATT&CK Enterprise TA0043.
Manipulate Environment (ATM-TA0001, 8 técnicas) es específica del vehículo: ataques al entorno sin tocar físicamente el vehículo, es decir, inhibidores de señal, ataques de relé contra llaves por radiofrecuencia, estaciones base de telefonía móvil y puntos de acceso Wi-Fi falsificados, degradación a protocolos inseguros, así como el engaño de sensores y de modelos de IA. La referencia apunta a la antigua táctica de Mobile «Network Effects» (TA0038).
Affect Vehicle Function (ATM-TA0013, 8 técnicas) no tiene equivalente en ATT&CK; lo más cercano es «Impair Process Control» de ATT&CK for ICS. Se ven afectados la propulsión, el airbag, los indicadores o el audio, mediante mensajes de bus no previstos, la alteración de mensajes legítimos, una denegación de servicio en el bus CAN o el abuso de servicios de diagnóstico. Con 35 ejemplos documentados, «Unintended Vehicle Network Message» (ATM-T0071) es la técnica mejor acreditada de toda la matriz.
Las 75 técnicas y sus familias
En el plano de las técnicas se aprecia qué separa a la Automotive Threat Matrix de una matriz de TI: junto a patrones conocidos como ATM-T0015 Phishing aparecen servicios de diagnóstico, mensajes de bus, reprogramación de unidades de control y sensores. Las 75 técnicas se agrupan en pocas familias; el número de ejemplos muestra dónde la base probatoria es sólida.
Abuso de protocolos de diagnóstico: cinco técnicas comparten la raíz del nombre y solo se diferencian por su finalidad — ATM-T0020 (Persistence), ATM-T0074 (Execution), ATM-T0050 (Lateral Movement), ATM-T0055 (Collection) y ATM-T0067 (Affect Vehicle Function). Solo dos de ellas cuentan con ejemplos: ATM-T0067 con 24 y ATM-T0055 con 2. Sobre el mismo protocolo actúa ATM-T0033 Bypass UDS Security Access (Defense Evasion, 5 ejemplos).
Efectos sobre funciones del vehículo: ATM-TA0013 agrupa ocho técnicas. Según recuento propio, ATM-T0071 Unintended Vehicle Network Message alcanza con 35 ejemplos el valor más alto del resumen, por delante de ATM-T0069 Local Function (7), ATM-T0072 Denial of Service on Vehicle Function (3) y ATM-T0068 CAN Bus Denial of Service (2); ATM-T0070 Modify Bus Message se queda sin ejemplo.
Movimiento lateral: ATM-TA0009 comprende seis técnicas. La que más ejemplos reúne es ATM-T0054 Reprogram ECU for Lateral Movement (11), por delante de ATM-T0053 Remote Services (7) y ATM-T0051 Bridge Vehicle Networks (2); ATM-T0052 y ATM-T0050 se quedan sin entrada.
Criptografía y credenciales: ATM-T0040 Unsecured Credentials encabeza Credential Access ATM-TA0007 con 12 ejemplos, por delante de ATM-T0038 Network Sniffing (8) y ATM-T0039 ECU Credential Dumping (1). ATM-T0075 Compromise Cryptographic Security figura en cuatro tácticas, pero no tiene ninguna entrada, al igual que ATM-T0066 Standard Cryptographic Protocol.
Sensores e IA: según recuento propio, solo ATM-T0004 Analog Sensor Attacks y ATM-T0005 Adversarial Machine Learning figuran a la vez en Manipulate Environment ATM-TA0001 y en Affect Vehicle Function ATM-TA0013, ambas sin ejemplo. En cambio, sí está acreditado el entorno radioeléctrico, por ejemplo ATM-T0003 Manipulate Communications (5).
Las técnicas mejor acreditadas
| ID | Técnica | Táctica(s) | Ejemplos |
|---|---|---|---|
| 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 |
Cifras procedentes del resumen de técnicas de la Automotive Threat Matrix; ATM-T0053 Remote Services y ATM-T0069 Local Function siguen con 7 ejemplos cada una.
147 ejemplos, 23 fuentes, dos equipos de investigación
Lo que distingue a la ATM de una colección de ideas son sus ejemplos: frases procedentes de trabajos de investigación publicados que acreditan que una técnica se aplicó realmente. Hemos analizado los 147, y son a la vez una fortaleza y una advertencia.
Dos equipos aportan 95 de los 147 ejemplos; las siete fuentes más extensas cubren 114 ejemplos (77,6 %). Es la era de investigación de 2010 a 2018: WebKit en la head unit, Telnet hacia el gateway, servicios UDS sin autenticación.
| Fuente (título en la ATM) | Año | Equipo / objetivo | Ejemplos |
|---|---|---|---|
| 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); dos berlinas | 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 |
Asignación de año y autoría realizada por VamiSec; solo 10 de los 147 ejemplos indican una URL de origen; un título aparece dos veces, de ahí 23 publicaciones en lugar de 24.
29 de las 77 técnicas sin un solo ejemplo
- Analog Sensor Attacks y Adversarial Machine Learning, pese a que el spoofing de lidar se publica desde hace años
- Supply Chain Compromise, revisada en diciembre de 2025, pero todavía sin evidencia
- Disable Software Update, el tema central de UN R156
- Compromise Cryptographic Security, presente en cuatro tácticas desde abril de 2025, sin ejemplo
- Modify Bus Message, pese a que los ejemplos sobre la supresión de identificadores CAN solo están asignados de otro modo
- Tres de las cinco técnicas añadidas desde 2024
La más escasa es Persistence: cuatro de cinco técnicas sin evidencia; Credential Access y Collection siguen con cinco técnicas vacías cada una. Según asignación propia, ningún ejemplo procede de 2025 ni de 2026.
Qué revela además el conjunto de datos
Un autor, una cuenta
72 de las 77 técnicas indican a Karl Leboeuf (GM) como autor y solo seis tienen editor. Una única cuenta figura como último editor en 73 técnicas y 10 tácticas: calidad curada, factor bus igual a uno.
El crecimiento se estanca
De los 87 ejemplos con fecha de creación, 82 se generaron en diciembre de 2023, cuatro en agosto de 2024 y uno en mayo de 2025. Los 51 huecos en el rango de identificadores P0001 a P0198 muestran que alrededor de una cuarta parte de los ejemplos creados en algún momento se volvió a eliminar.
No todo está demostrado
Al menos siete ejemplos de «CAN Message Injection» comienzan con «Researchers discussed the possibility», es decir, son hipótesis. Siete resúmenes insertados generan por sí solos 34 vínculos con técnicas: conviene leer la evidencia, no solo contarla.
Por qué ahora: los ataques escalan y se ejecutan en remoto
El número de incidentes cibernéticos conocidos públicamente en el sector del automóvil crece desde hace años, y su carácter se ha desplazado: del portátil conectado al puerto OBD hacia la telemática, la nube y la cadena de suministro.
Alemania: el informe de situación del BSI
El informe sectorial del BSI «Cybersicherheit im Straßenverkehr 2025» evalúa 107 notificaciones entre febrero de 2024 y marzo de 2025. De los 67 casos clasificables por vía de acceso, 18 se produjeron a través de Internet, 23 por el entorno próximo (Bluetooth, wifi), 21 por acceso físico, 3 por la red local y 2 por desmontaje. De los 59 casos valorados por estado, 46 eran prueba de concepto, 9 teóricos y 4 explotados activamente.
Para el periodo de 2018 a 2024, el BSI contabiliza 1.663 CVE relacionados con vehículos; el valor medio de CVSS descendió de 8,08 (2019) a 7,19 (2024), aunque se mantuvo en la banda «alta».
Pwn2Own Automotive
| Edición (Tokio) | Zero-Days | Premio en metálico | Master of Pwn |
|---|---|---|---|
| enero de 2024 | 49 | 1.323.750 $ | Synacktiv (módem de Tesla, IVI) |
| enero de 2025 | 49 | 886.250 $ | Sina Kheirkhah (solo Tesla Wall Connector) |
| enero de 2026 | 76 | 1.047.000 $ | fuzzware.io (equipo alemán) |
Fuente: Zero Day Initiative / Trend Micro. En Berlín (mayo de 2025) no se presentó nadie en la categoría de automoción.
Dos ramas de ataque
| Año | Caso | Entrada → efecto | Relación con la ATM |
|---|---|---|---|
| 2015 | Jeep Cherokee (Miller/Valasek) | Red móvil → Uconnect → reflash del V850 → CAN: frenos, dirección, motor; 1,4 millones de vehículos llamados a revisión | Cadena de ataque 1 |
| 2016/17 | Tesla Model S/X (Keen Security Lab) | Wi-Fi y navegador → kernel → firmware del gateway → CAN; primer ataque remoto al bus CAN de un Tesla | Cadenas de ataque 2 y 3 |
| 2018 | BMW (Keen Security Lab) | 14 vulnerabilidades en head unit, telemática y gateway; peticiones de diagnóstico arbitrarias en CAN | ATM-P0006, 13 técnicas |
| 2023 | CAN injection por el cableado de los faros (Tindell/Tabor) | Un dispositivo alojado en la carcasa de un altavoz falsifica tramas de la smart key y el inmovilizador queda anulado; Toyota RAV4 | T0016/T0071, sin ejemplo |
| 2025 | Nissan Leaf (PCAutomotive) | Bluetooth → IVI → elusión del secure boot → C2 por red móvil → CAN: dirección durante la marcha | sin ejemplo |
| 2024 | Portal de concesionarios de Kia (Curry y otros) | Token de concesionario → VIN → datos del titular → vehículo controlable en 30 s a partir de la matrícula | Backend, fuera de la ATM |
| 2025 | Subaru STARLINK (Curry/Shah) | Restablecimiento de contraseña sin token, 2FA solo en el cliente → arranque y parada, historial de ubicación con una precisión de 5 m | Backend, fuera de la ATM |
| 2024 | Cariad/VW (CCC, 38C3) | Entorno en la nube mal configurado → datos de ubicación de unos 800.000 vehículos eléctricos | Backend, fuera de la ATM |
| 2025 | Jaguar Land Rover | Ataque informático, unas cinco semanas de parada de producción, 196 millones de libras de coste trimestral, 1.900 millones de libras de daños (CMC) | TI corporativa, ATT&CK |
Rama A: el propio vehículo
Entrada por radiofrecuencia, infoentretenimiento o diagnóstico; después, escalada de privilegios, salto a través del gateway y efecto sobre el CAN. Estable desde 2015 y descrita por la ATM.
Rama B: backend, portales y cadena de suministro
Kia, Subaru, Cariad y JLR no tocaron ninguna unidad de control y aun así afectaron a flotas y plantas. El Anexo 5 de UN R155 comienza con estas amenazas (4.3.1).
Tres capas, un vehículo: quién exige qué en 2026
La ciberseguridad del vehículo se regula en Europa en tres niveles: producto (UN R155/R156), empresa (NIS2, TISAX) y componente fuera de la homologación de tipo (CRA).
ISO/SAE 21434 es la referencia de ingeniería para el nivel de producto, no la ley. UN R155 actúa a través del Reglamento (UE) 2019/2144: tipos nuevos desde el 6 de julio de 2022 y todos los vehículos nuevos desde el 7 de julio de 2024; el Suplemento 3 se aplica desde el 10 de enero de 2025 a las categorías L, M, N y O con al menos una unidad de control.
NIS2 y la BSIG 2025 están en vigor desde el 6 de diciembre de 2025 y el plazo de registro corrió hasta el 6 de marzo de 2026; el nivel de componente lo regula el CRA.
| Normativa | Qué exige | Plazo | Relación con la matriz |
|---|---|---|---|
| UN R155 (CSMS) | CSMS certificado (máx. 3 años, 6.7), evaluación de riesgos exhaustiva frente al Anexo 5, parte A (7.3.3), detección de ataques (7.2.2.2 g), informe anual (7.4.1) | Todos los vehículos nuevos desde el 7 de julio de 2024 | Anexo 5 = lista de amenazas; ATM = comportamiento del atacante |
| UN R156 (SUMS) | Sistema de gestión de actualizaciones; autenticidad e integridad de las actualizaciones; la serie 01 hace obligatorio el RxSWIN | Serie 01 en vigor el 4 de junio de 2026; transición hasta el 1 de septiembre de 2028/2030 | ATM-T0021, T0022, T0054 |
| ISO/SAE 21434:2021 | Ingeniería de ciberseguridad a lo largo del ciclo de vida; la cláusula 15 = TARA; los anexos E y G son informativos | Agosto de 2021; segunda edición: desarrollo a partir de 2026 | Rutas de ataque (15.6), viabilidad (15.7) |
| ISO/SAE PAS 8475, TR 8477, SAE J3322, ISO/PAS 5112, ISO 24089 | Precisión de CAL/TAF, verificación y validación; guía de auditoría para el CSMS; ingeniería de actualizaciones conforme a R156 | DPAS 8475: julio de 2026; J3322 desde el 3 de mayo de 2025; 5112: 2022; 24089: febrero de 2023 | Planificación de pruebas, aportación de evidencias |
| Cyber Resilience Act | No se aplica a los productos cubiertos por el Reglamento 2019/2144 (art. 2, apdo. 2, letra c); sí a los componentes vendidos por separado, los dongles y los puntos de recarga | Obligaciones de notificación desde el 11 de septiembre de 2026; aplicación plena el 11 de diciembre de 2027 | ATM-T0010 «Aftermarket, Customer, or Dealer Equipment» |
| NIS2 / BSIG 2025 | NACE C 29 y C 30 = entidades importantes; gestión de riesgos (§ 30), obligación de notificación (§ 32), multas de hasta 7 millones de euros o el 1,4 % (§ 65) | En vigor desde el 6 de diciembre de 2025; plazo de registro el 6 de marzo de 2026 | Incidentes con identificadores de técnica |
| TISAX (ENX) | Seguridad organizativa y protección de prototipos; ISA 6 hasta el 31 de diciembre de 2026, VDA ISA2027 a partir del 1 de enero de 2027 | ISA2027 anunciado el 1 de julio de 2026 | Requisitos a proveedores en columnas de la ATM |
| Data Act, Reglamento Delegado 2026/699 | Acceso a los datos del vehículo (access by design desde el 12 de septiembre de 2026); nuevo anexo X del Reglamento 2018/858 | El Data Act se aplica desde el 12 de septiembre de 2025; el Reglamento Delegado se publicó en el DOUE el 3 de junio de 2026 | El acceso de diagnóstico como superficie de ataque |
En el mundo: la misma lógica, otros plazos
Japón
R155/R156 a través de las normas de seguridad de la Ley de Tráfico por Carretera; tipos nuevos con capacidad OTA desde julio de 2022 y parque sin OTA desde mayo de 2026.
Corea del Sur
Autorización previa del CSMS por el MOLIT; tipos nuevos desde el 14 de agosto de 2025 y tipos existentes a partir de agosto de 2027.
Reino Unido
El SI 2025/1110 traslada R155/R156 a la homologación de tipo de Gran Bretaña: tipos nuevos desde el 1 de junio de 2026 y todos los vehículos desde el 1 de junio de 2027.
China
GB 44495-2024 y GB 44496-2024 se aplican a los tipos nuevos desde el 1 de enero de 2026 y a los ya homologados desde el 1 de enero de 2028.
La norma exige rutas de ataque. No las proporciona.
ISO/SAE 21434 exige escenarios de amenaza, rutas de ataque y una viabilidad de ataque fundamentada. La norma no aporta deliberadamente comportamiento concreto del atacante. Justo en ese punto se acopla la Automotive Threat Matrix, con bloques documentados e identificadores estables.
La cláusula 15 de ISO/SAE 21434 define siete pasos, desde la identificación de activos hasta el tratamiento del riesgo. Dos de ellos presuponen un conocimiento del comportamiento del atacante que la norma no aporta de forma deliberada: la identificación de escenarios de amenaza (15.4) y el análisis de rutas de ataque (15.6). Como tercer punto de acoplamiento se añade la viabilidad del ataque (15.7).
- 15.3Identificar activos: integridad, disponibilidad, confidencialidad
- 15.4 punto de acoplamientoEscenario de amenaza a partir del activo, la técnica ATM y la propiedad vulnerada
- 15.5Impacto del daño en Safety, Financial, Operational y Privacy: de negligible a severe
- 15.6 punto de acoplamientoRutas de ataque a partir de celdas de la ATM; 22 cadenas de ataque registradas en el conjunto de datos, 147 ejemplos
- 15.7 punto de acoplamientoViabilidad del ataque: un valor inicial calibrado por técnica, ajustado en cada ruta
- 15.8Valor de riesgo de 1 a 5 a partir del impacto y la viabilidad; matriz de ejemplo en el anexo H
- 15.9Tratamiento del riesgo: evitar, reducir, compartir, aceptar
Para la viabilidad, la norma admite tres enfoques: attack potential con cinco parámetros (tiempo, experiencia, conocimiento del ítem, ventana de oportunidad, equipamiento), la explotabilidad según CVSS o el vector de ataque conforme a la tabla G.9; el anexo G es informativo y denomina expresamente ejemplos a sus tablas. El whitepaper del Auto-ISAC de febrero de 2025 describe la matriz como una biblioteca de pasos potenciales de una ruta de ataque y propone asignar a cada elemento una viabilidad por defecto. Estos valores por defecto son un método, no datos: el conjunto de datos no contiene valores de viabilidad, ni clases de impacto, ni referencias a activos. La calibración sigue siendo tarea de la organización.
Viabilidad por defecto por técnica: ejemplos de cálculo
| Técnica | Supuesto | Parámetros (tiempo, experiencia, conocimiento, ventana de oportunidad, equipamiento) | Suma | Viabilidad |
|---|---|---|---|---|
| T0033 Bypass UDS Security Access | clave estática por serie de modelo, derivable a partir de la herramienta de taller (como ATM-P0033, P0167) | 1, 3, 3, 1, 0 | 8 | alta |
| T0033 Bypass UDS Security Access | desafío-respuesta real por ECU, clave en el HSM, bloqueo tras intentos fallidos | 17, 6, 7, 4, 4 | 38 | muy baja |
| T0012 Exploit via Radio Interface | desbordamiento de heap por Bluetooth en el infoentretenimiento (como Lexus 2020, ATM-P0060) | 17, 8, 3, 4, 4 | 36 | muy baja |
| T0054 Reprogram ECU for Lateral Movement | tras el acceso al gateway, la ECU objetivo solo comprueba un CRC (como ATM-P0117) | 1, 3, 3, 4, 0 | 11 | alta |
Valores según ISO/SAE 21434:2021, anexo G, tabla G.6 (agregación de ejemplo) y G.7 (asignación de ejemplo: alta 0–13, media 14–19, baja 20–24, muy baja a partir de 25); ambas informativas. La elección de los parámetros es nuestra apreciación con fines ilustrativos, no una valoración de productos reales.
El valor por defecto depende del control
La misma técnica pasa de 8 a 38 puntos según si el acceso UDS se basa en un secreto común a toda la serie de modelo o en claves individuales.
Una viabilidad baja no significa un riesgo bajo
La entrada por Bluetooth es muy baja con 36 puntos, pero escalable en remoto; según la tabla G.9 sería incluso media como adjacent. El valor de riesgo conforme a 15.8 la mantiene dentro del alcance.
Se evalúa la ruta, no la celda
De forma aislada, reprogramar una unidad de control tiene una viabilidad alta; dentro de la cadena hereda la ventana de oportunidad y el equipamiento de la entrada precedente.
Dos listas, una evaluación de riesgos
UN R155 exige en su punto 7.3.3 una evaluación de riesgos exhaustiva frente a todas las amenazas del Anexo 5, parte A; ISO/SAE 21434 exige rutas de ataque. Hemos asignado las 14 tácticas y las 75 técnicas de la ATM a las 67 entradas del Anexo 5: alta coincidencia dentro del vehículo y lagunas claras en sus márgenes.
El Anexo 5 es la única parte de R155 que nombra amenazas de forma concreta: no es una taxonomía de atacantes, sino una lista de vulnerabilidades y métodos de ataque ordenada por superficie de ataque. El Anexo 5 pregunta qué vulnerabilidad podría explotarse; la matriz pregunta qué hace el atacante a continuación y ordena por objetivo. Para la evaluación de riesgos exhaustiva exigida en 7.3.3, el Anexo 5 es obligatorio; para las rutas de ataque, la matriz es la mejor herramienta.
| Táctica ATM | Entradas principales del Anexo 5 (parte A, tabla A1) | Medidas heredadas |
|---|---|---|
| Reconnaissance | 7.1 escucha, 28.2 restos de desarrollo; 1.2/1.3 solo como objetivo de reconocimiento | M12, M23 |
| Manipulate Environment | 4.1 spoofing (V2X, GNSS), 6.2 man-in-the-middle, 8.2 black hole, 16.3 interferencia de la radio de campo cercano y de los sensores | M10, M13, M20 |
| Initial Access | 16.1 funciones remotas, 17.1 aplicaciones de terceros, 18.1–18.3 USB/soportes/dongles OBD, 5.1 inyección de código, 11.2 V2X | M20, M21, M22, M10, M6 |
| Execution | 22.2 introducción de software malicioso, 23.1 falsificación de software, 11.3 mensajes de diagnóstico | M7, M10 |
| Persistence | 12.1/12.2 compromiso de las actualizaciones OTA y locales, 23.1 | M16, M7 |
| Privilege Escalation | 9.1 escalada de privilegios, 28.1 errores de software, 28.2 puertos de depuración | M9, M23 |
| Defense Evasion | 11.3 mensajes de diagnóstico, 6.3 replay/downgrade, 12.x actualizaciones, 26.1–26.3 criptografía | M10, M16, M11 |
| Credential Access | 19.2 datos del titular, 19.3 extracción de claves, 28.2, 7.2 acceso no autorizado a ficheros | M8, M11, M23 |
| Discovery | en su mayor parte sin correspondencia; 29.1 puertos abiertos | M9 |
| Lateral Movement | 29.2 elusión de la separación de redes (gateways), 23.1, 6.3 | M7, M10, M16 |
| Collection | 19.1 piratería de productos, 19.2 datos del titular | M7, M8 |
| Command and Control | sin entrada directa; R155 solo contempla el efecto, no el canal | – |
| Exfiltration | 19.x; en parte 31.1 cambio de titular | M7, M8, M12 |
| Affect Vehicle Function | 24.1 inundación del CAN, 25.1 parámetros del vehículo (freno, airbag), 11.1–11.3 mensajes internos y de diagnóstico maliciosos, 8.x | M13, M15, M10, M7 |
Mapeo realizado por VamiSec a partir de las descripciones de las técnicas (ATM v4.02) y del texto del Anexo 5 (DOUE L 2025/5). Medidas de las partes B/C, entre otras M7 control de acceso a datos y código, M9 protección frente al acceso no autorizado, M10 autenticidad e integridad de los mensajes recibidos, M11 almacenamiento de claves, M13 detección de DoS, M16 procedimientos de actualización seguros.
Lo que contempla el Anexo 5 y la matriz no
El servidor backend (4.3.1) casi por completo: 1.1 amenaza interna, 2.1 caída del backend, 3.1–3.5 fuga de datos y pérdida en la nube; para las amenazas 2 y 3 no existe ni una sola correspondencia en la ATM. A ello se suman 15.2 procedimientos de seguridad no seguidos, 20.1, 20.2 y 20.5 sobre identidad y datos de diagnóstico, 21.1 borrado de registros de eventos, así como 31.1 cambio de titular, 25.2 parámetros de carga y 4.2 ataque Sybil.
Lo que contempla la matriz y el Anexo 5 no
Toda la familia Discovery posterior a la entrada (T0045–T0049, T0060), los canales de control y de fuga (T0062–T0066), así como Adversarial Machine Learning (T0005), Native API (T0019) y Process Injection (T0029). Las entradas cubiertas con mayor frecuencia son 28.2 restos de desarrollo y 19.2 datos del titular, con ocho técnicas cada una, seguidas de 11.3, 23.1 y 19.3 con seis cada una.
El informe anual conforme a 7.4.1 debe mostrar qué ataques nuevos se han observado y si los controles elegidos siguen siendo eficaces. Con identificadores estables en ambos lados, esto se convierte en una tabla de cobertura que un servicio técnico puede seguir: entrada del Anexo 5, técnicas ATM, evidencias de ATM-P y de casos propios, medida de la parte B y prueba procedente de un pentest o de un evento IdsM. Para 2.1 y 3.x, la columna de las técnicas ATM queda vacía; ahí intervienen las entradas de ATT&CK Enterprise.
La matriz dice qué hacen los atacantes. No dice cómo se prueba.
Una matriz de amenazas es solo un tercio de la cadena. Entre el comportamiento del atacante y la pregunta de si un vehículo es seguro hay otros dos catálogos: requisitos para el producto y casos de prueba para la evidencia. Ambos los proporciona OWASP, concebidos para dispositivos IoT.
Auto-ISAC ATM
14 tácticas, 75 técnicas, además de R155 Annex 5 parte A y EMB3D (81 amenazas).
OWASP ISVS
Cinco capítulos, niveles de verificación L1 a L3, además de R155 partes B/C (23 medidas) y EMB3D (89 medidas).
OWASP ISTG
101 casos de prueba en ocho componentes, además de FSTM y SAE J3322 / ISO/SAE TR 8477.
El ISTG es un proyecto incubadora de OWASP de Luca Pascal Rotsch y Aaron Guzman: versión 1.0.0 del 1 de marzo de 2024, 1.0.1 del 1 de junio de 2024, con nuevos casos de prueba por última vez en julio de 2026. El modelo de atacante combina el acceso físico de PA-1 (remoto) a PA-4 (invasivo) con la autorización de AA-1 a AA-4; los identificadores tienen, por ejemplo, la forma ISTG-FW[UPDT]-CRYPT-004.
El ISVS ordena los requisitos en cinco capítulos: V1 ecosistema IoT, V2 aplicación en espacio de usuario, V3 plataforma de software, V4 comunicación, V5 plataforma de hardware. El nivel 3 de los tres niveles de verificación se aplica a dispositivos cuyo compromiso debe evitarse «a cualquier precio», con los vehículos conectados como ejemplo explícito.
Cuidado con el estado de versión: la única etiqueta de publicación es 1.0RC de diciembre de 2020 con 124 requisitos; la rama principal indica «versión 1.0, octubre de 2025» con entre 156 y 169 requisitos. El anexo B establece la correspondencia con el anexo I del CRA, el Reglamento Delegado RED 2022/30 y ETSI EN 303 645, no con UN R155.
Técnicas de la ATM sobre componentes del ISTG
| Componente ISTG | Equivalente en el vehículo | Técnicas ATM | Capítulo ISVS |
|---|---|---|---|
| Processing Units (PROC) | SoC de infoentretenimiento, CPU de telemática | Inyección de procesos, elevación de privilegios (T0026, T0029, T0024) | V3 plataforma de software |
| Memory (MEM) | Flash, RAM, memorias seguras | Credential Dumping, acceso a memoria (T0039, T0074, T0022) | V5 hardware |
| Firmware (FW, INST/UPDT) | Firmware de ECU, actualización, OTA | Reprogramación, criptografía (T0031, T0054, T0075, T0021) | V3 plataforma de software |
| Data Exchange Services (DES) | UDS/DoIP, pasarela CAN | Abuso del diagnóstico, mensajes de bus (T0067, T0071, T0068, T0050) | V4 comunicación |
| Internal Interfaces (INT) | Buses de ECU, UART de depuración | Puenteo de redes, elusión de filtros (T0051, T0032) | V4 comunicación |
| Physical Interfaces (PHY) | OBD-II, JTAG, USB | Fault Injection, modificación (T0016, T0028, T0073, T0013) | V5 hardware |
| Wireless Interfaces (WRLS) | Telefonía móvil, Wi-Fi, Bluetooth, NFC, TPMS | Exploit por radio, Relay (T0012, T0065, T0007, T0009) | V4 comunicación |
| User Interfaces (UI) | Pantalla táctil, asistente de voz | Registro de entradas, Screen Capture (T0037, T0061) | V2 aplicación |
| Laguna del ISTG | Cámara, lidar, radar | Analog Sensor Attacks, Adversarial ML (T0004, T0005) | a través de MITRE ATLAS |
El esquema de identificadores prevé especializaciones como ISTG-DES[UDS], pero no están desarrolladas. Ni EN 303 645 ni M/606 hacen referencia al ISTG o al ISVS; la asignación es un análisis propio.
Cinco mapas para un vehículo
Ningún marco por sí solo cubre un vehículo conectado junto con su backend, la aplicación, las unidades de control y la IA. La ATM es el mapa del vehículo en sí. Quien conoce los mapas vecinos sabe dónde debe seguir leyendo.
| Base de conocimiento (estado) | Estructura y alcance | Para qué sirve en el ámbito del automóvil | Límite |
|---|---|---|---|
| Auto-ISAC ATM v4.02 (04/12/2025) | 14 tácticas, 75 técnicas (77 en el conjunto de datos), 147 ejemplos | Rutas de la TARA, delimitación de pentests, etiquetado de CTI | termina en el límite del vehículo, evidencias de 2010 a 2018 |
| ATT&CK Enterprise v19 (28/04/2026) | 15 tácticas, 222 técnicas, 475 subtécnicas | TI del OEM, backend OTA, nube, categoría 4.3.1 de R155 | no conoce ni CAN ni UDS ni ECU |
| ATT&CK Mobile v19 | 12 tácticas, 77 técnicas, 47 subtécnicas | Aplicaciones complementarias, modelo para cinco tácticas de la ATM | dispositivo final, no vehículo |
| ATT&CK for ICS v19 | 12 tácticas, 79 técnicas, 18 subtécnicas | Precursor de «Affect Vehicle Function» | tecnología de control de procesos, no red de a bordo |
| EMB3D v2.0.2 (01/06/2026) | 81 amenazas, 89 medidas, STIX 2.1 | qué propiedad de una ECU abre qué amenaza | sin tácticas, sin cadenas |
| ATLAS v2026.08 (01/09/2026) | 16 tácticas, 114 técnicas, 83 subtécnicas, 72 casos de estudio | Ataques de IA a la percepción, los modelos y los datos de entrenamiento | ningún caso de estudio de vehículos |
| CAPEC v3.9 (24/01/2023) | 559 patrones de ataque, perspectiva ICS/OT | Puente hacia CWE | de facto congelado desde 2023 |
ATT&CK se publica semestralmente y ATLAS mensualmente; la ATM tuvo seis versiones desde marzo de 2024 y ninguna en 2026.
ATT&CK tiene tres veces más técnicas que la ATM, pero ninguna para protocolos de diagnóstico. EMB3D tiene 89 medidas, pero ninguna cadena de ataque. Solo la cadena de técnica de la ATM a amenaza de EMB3D a medida de EMB3D cierra la brecha.
«MITRE-compliant» significa formato, no pertenencia
Desde la v4.00 (12 de febrero de 2025), Auto-ISAC entrega, junto al JSON nativo, un archivo STIX 2.1 en el modelo de objetos de ATT&CK. Hemos desglosado mitre-v4.02.json: 302 objetos, de ellos 1 matrix, 14 tácticas (ATM-TA0000 a TA0013), 77 attack-pattern, 151 campaign con alias ATM-P0001 y siguientes, 59 relationship y 0 course-of-action.
- Con pérdidas: 59 relaciones en lugar de 221 vínculos entre técnica y ejemplo; 140 de los 151 ejemplos quedan sin anclaje y solo 37 técnicas están respaldadas.
- Las 91 fases de la kill chain se denominan todas «not applicable» en lugar de indicar un dominio; el Navigator necesita una referencia de dominio coherente.
- No hay objeto identity ni marking-definition, es decir, ninguna condición de uso legible por máquina.
- El archivo nativo v4.02.json (242 objetos) contiene todos los vínculos y es el artefacto de publicación completo.
Preparar el bundle
Extraer mitre-v4.02.json de la envoltura base64 de la API de releases, fijar kill_chain_name a un nombre de dominio y añadir las relaciones que faltan.
Configurar el Navigator
Registrar el bundle como archivo local en config.json (STIX 2.0 y 2.1) y crear una capa 4.5 con customDataURL.
Tres capas, un backlog
Capa A: técnicas de la ATM respaldadas (48). Capa B: alcance propio del pentest. Capa C: observable por el VSOC. Las diferencias son el backlog.
Cadenas reconstruidas desde el acceso inicial hasta la función del vehículo
Los ataques reales a vehículos pueden traducirse a tácticas y técnicas de la matriz. Hemos ordenado dos casos siguiendo las columnas de tácticas; cada paso indica la técnica, el identificador ATM y la evidencia.
El ataque de Charlie Miller y Chris Valasek contra un Jeep Cherokee es la única cadena íntegramente remota del conjunto de datos que llega hasta la actuación; diez ejemplos de la ATM la describen.
- Initial AccessExploit via Radio InterfaceATM-T0012 · ATM-P0074
Cada Cherokee respondía a través de la red móvil de Sprint a cualquier otro dispositivo Sprint.
- Discovery / ExecutionSystem Network Configuration Discovery; Command and Scripting InterpreterATM-T0048, T0018 · ATM-P0093, P0176
Consulta del GPS y comandos de shell arbitrarios a través del servicio D-Bus abierto.
- Persistence / PivotModify OS Kernel, Boot Partition, or System PartitionATM-T0022 · ATM-P0075
Toma de control del chip V850 de la head unit mediante una actualización de firmware manipulada.
- Affect Vehicle FunctionLocal Function; Unintended Vehicle Network Message; Abuse Standard Diagnostic ProtocolATM-T0069, T0071, T0067 · ATM-P0073, P0144, P0145, P0192, P0094
Climatización y pantalla, después intermitentes y cerraduras de las puertas y, por último, órdenes de dirección a través de una sesión de diagnóstico.
Lo decisivo no es el acceso inicial, sino la toma de control del chip V850, un coprocesador situado en la misma head unit y sin verificación de firma. En el lenguaje de R155: Annex 5 n.º 12.2 y 11.3, medida M16. FCA llamó a revisión 1,4 millones de vehículos el 24 de julio de 2015.
Tesla Model S 2016: Wi-Fi, navegador, kernel, pasarela, CAN
- Manipulate Environment / Initial AccessRogue Wi-Fi Access Point; Browser CompromiseATM-T0009, T0011 · ATM-P0103, P0042
Punto de acceso falso y, a continuación, exploit de WebKit para CVE-2011-3928.
- Privilege Escalation / Defense EvasionExploit OS Vulnerability; Bypass Mandatory Access ControlATM-T0026, T0034 · ATM-P0001, P0003
Vulnerabilidad del kernel CVE-2013-6282 y, después, elusión de AppArmor.
- Credential Access / Defense EvasionUnsecured Credentials, Network Sniffing; Bypass UDS Security AccessATM-T0040, T0038, T0033 · ATM-P0004, P0105, P0149, P0002, P0043
Claves SSH, credenciales estáticas y clave UDS obtenida mediante captura del tráfico CAN.
- Lateral Movement / Affect Vehicle FunctionRemote Services; Unintended Vehicle Network MessageATM-T0053, T0071 · ATM-P0044, P0106, P0045
Telnet y SSH hacia la pasarela; la pasarela traducía a CAN los paquetes UDP de los puertos 20100/20101.
«Free-fall», de Tencent Keen Security Lab, es la cadena más profunda del conjunto de datos: 17 ejemplos, 13 técnicas, 9 tácticas. Tesla la cerró el 18 de septiembre de 2016 mediante una actualización OTA; CISA la registra como ICSA-16-341-01. El mayor bloque de evidencias lo aportan Miller y Valasek en el puerto OBD, con 44 ejemplos.
| Técnica | en cadenas | Ejemplos |
|---|---|---|
| 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 |
Análisis propio sobre cinco cadenas reconstruidas.
- Secure Boot en cada ECU reprogramable rompe T0022 en las cinco cadenas, y también T0031 y T0054.
- Claves UDS individuales en lugar de estáticas devalúan T0033 y T0067; SecOC incide en T0071.
- No guardar secretos en el firmware ni en las herramientas de taller hace que T0040 se desmorone.
Para qué sirve la matriz y para qué no
Una evaluación justa separa lo que la matriz aporta de lo que los usuarios leen en ella: 147 ejemplos con fuente documentada, por un lado, y un campo de medidas vacío en las 77 técnicas, por otro.
Para esto sirve la matriz
- Lenguaje común entre OEM, proveedores, evaluadores y VSOC: 14 columnas familiares para quien conoce ATT&CK.
- Biblioteca de rutas de ataque para la TARA: 147 ejemplos documentados y 22 cadenas para la cláusula 15 de ISO/SAE 21434.
- Etiquetado de CTI y de pentests con identificadores estables, sin cambios desde agosto de 2023, más exportación a STIX 2.1.
- Planificación de pruebas mediante delimitación por columnas; las técnicas de UDS y CAN están bien documentadas, con 57 ejemplos.
- Informe anual de R155: las amenazas consideradas se convierten en una tabla de cobertura verificable.
Esto no es la matriz
- No es un análisis de riesgos: sin viabilidad, sin impacto, sin campo de probabilidad. Es una entrada de la TARA, no su sustituto.
- No es un catálogo de controles: el campo de medidas está vacío en las 77 técnicas.
- No es una biblioteca de detección: sin Data Sources, sin analíticas, sin referencias de telemetría.
- No es una lista de comprobación de cumplimiento: sin asignación a R155 Annex 5, a las cláusulas de ISO 21434 ni a TISAX.
- Ni actual ni neutral: el 85,7 % de las evidencias son de 2018 o anteriores, un tercio corresponde a Tesla y el backend está casi vacío.
También la gobernanza del conjunto de datos determina hasta qué punto resulta sólido en una auditoría.
Bus factor de uno
72 de las 77 técnicas provienen de un único autor, seis versiones en dos años y ninguna hasta ahora en 2026. Trate la matriz como una dependencia de código abierto: fije la versión y revise los diffs.
Deriva silenciosa
Sin mecanismo de obsolescencia: T0056 y T0057 están de hecho retiradas, pero siguen en la exportación. El archivo de la versión (151 ejemplos) y la API en vivo (147) difieren.
Confusión de identificadores
Un ejemplo de un proveedor etiqueta una persistencia de diagnóstico con «ATM:T1543», un identificador de ATT&CK Enterprise. Los identificadores de la ATM tienen el formato ATM-T00xx.
Diez pasos llevan la matriz del navegador a la TARA, al pentest y al VSOC.
| Paso | Qué hay que hacer |
|---|---|
| 1 Emparejar con EMB3D | Asignar las técnicas utilizadas a amenazas de EMB3D y heredar sus medidas. |
| 2 Mantener una extensión | Rango de identificadores propio para backend, aplicación, servidor OTA, recarga (ISO 15118, OCPP) y V2X. |
| 3 Congelar la versión | Anotar ATM v4.02 (04/12/2025) en la TARA y en el artefacto del CSMS, y archivar la exportación STIX. |
| 4 Mapear a R155 Annex 5 | Los apartados 4.3.2 a 4.3.7 se asignan bien; 4.3.1 backend sigue en buena medida sin cubrir. |
| 5 Construir heatmaps | Documentadas (48) frente al alcance del pentest frente a la visibilidad del VSOC; la diferencia es el backlog. |
| 6 Anclar los identificadores en el PSIRT | Etiquetar vulnerabilidades, casos de bug bounty e incidentes; tras doce meses se dispone de datos de tendencia propios. |
| 7 Casos de uso del VSOC | Empezar por T0067, T0071 y T0033: el 25,8 % de todos los ejemplos. |
| 8 Aportar casos | Enviarlos mediante el botón Contribute; 29 de las 77 técnicas no tienen ningún ejemplo. |
| 9 Datos como datos | Importar el JSON y aclarar el duplicado P0083, los ejemplos huérfanos y las técnicas sin táctica. |
| 10 Añadir dimensiones | Impair frente a Inhibit de ATT&CK for ICS y viabilidad según el Annex G para cada técnica. |
Automotive Threat Matrix – ATT&CK para vehículos: del conjunto de datos al TARA
34 páginas sobre la matriz del Auto-ISAC: el conjunto de datos completo analizado, tres cadenas de ataque reales reconstruidas en lenguaje ATM, correspondencia con ISO/SAE 21434, UN R155 Annex 5, OWASP ISTG e ISVS y MITRE EMB3D, con ejemplos de cálculo de la viabilidad del ataque y un playbook de diez puntos para la implantación.
El conjunto de datos completo analizado
14 tácticas, 75 técnicas, 147 ejemplos de 23 fuentes: origen, familias de técnicas, autoría y la evidencia con sus puntos ciegos.
Tres cadenas de ataque en lenguaje ATM
Jeep Cherokee 2015, «Free-fall» de Tesla 2016 y Miller/Valasek paso a paso, con los cinco puntos de corte en los que los defensores rompen las cadenas.
Mapping a R155, ISO/SAE 21434 y OWASP
Annex 5 frente a la ATM, pasos del TARA 15.4 a 15.7 con viabilidad por defecto según el Annex G, componentes ISTG por componente del vehículo.
La realidad de STIX y el playbook de diez puntos
Qué contiene realmente la exportación «MITRE-compliant», cómo se generan los heatmaps del Navigator y qué diez pasos llevan la matriz al TARA, al pentest y al VSOC.
Whitepaper en alemán, actualizado a septiembre de 2026; gratuito tras un breve registro.
Estándares y fuentes
Los contenidos de esta página se basan en las siguientes guías y estudios disponibles públicamente.
Automotive Threat Matrix (ATM), Release v4.02
Base de conocimiento pública con 14 tácticas, 75 técnicas en la matriz y 147 ejemplos; datos de esta página actualizados a 11 de septiembre de 2026. Consulta gratuita y descarga como JSON nativo y como bundle STIX 2.1.
The Automotive Threat Matrix (ATM) – Whitepaper
Siete casos de uso, desde el TARA y la threat intelligence hasta los informes para R155; describe el método de la viabilidad por defecto por elemento. Autores de GM, Sumitomo, HORIBA MIRA, PACCAR, Eaton y Auto-ISAC.
Enhancing Vehicle Cyber Security: Updates to the Automotive Threat Matrix Tool
Ponencia de marzo de 2025 con la historia de su origen: MITRE declinó en 2019 la solicitud de GM y animó a crear una versión independiente; hoja de ruta y exportación JSON.
ISO/SAE 21434:2021 – Road vehicles – Cybersecurity engineering
Norma de ingeniería a lo largo del ciclo de vida del vehículo; el Clause 15 define la metodología TARA, el Annex G las tablas de ejemplo para la viabilidad del ataque y el Annex E los Cybersecurity Assurance Levels.
UN Regulation No. 155 – Cyber security and cyber security management system (versión consolidada con el Supplement 3)
Reglamento de homologación de tipo con certificado CSMS, evaluación exhaustiva del riesgo según el Annex 5 Parte A y medidas de las Partes B y C; vinculante en la UE, a través del Reglamento (UE) 2019/2144, para todos los vehículos nuevos desde julio de 2024.
OWASP IoT Security Testing Guide (ISTG)
Metodología de pruebas con 101 casos de prueba en ocho componentes de dispositivo y un modelo de atacante basado en el acceso físico (PA-1 a PA-4) y la autorización (AA-1 a AA-4); versión 1.0 de marzo de 2024, con mantenimiento continuo.
OWASP IoT Security Verification Standard (ISVS)
Catálogo de requisitos en cinco capítulos con los niveles de verificación L1 a L3; los vehículos conectados se citan como ejemplo del nivel L3.
MITRE EMB3D Threat Model, Version 2.0.2
Modelo de amenazas para dispositivos embebidos: propiedades del dispositivo, 81 amenazas y 89 medidas escalonadas con exportación STIX 2.1; la automoción se cita expresamente como sector objetivo. Complemento natural de una ATM sin medidas.
MITRE ATT&CK, Version 19
Enterprise, Mobile e ICS; la ATM remite a identificadores ATT&CK en 13 de sus 14 tácticas, en parte procedentes de la matriz Mobile. ATT&CK en sí no contiene ningún dominio de vehículos.
Ciberseguridad en el tráfico rodado 2025 – Informe sectorial de situación (Cybersicherheit im Straßenverkehr 2025 – Branchenlagebild)
107 notificaciones entre febrero de 2024 y marzo de 2025, distribución por vía de acceso y estado, y 1.663 CVE relacionados con vehículos de 2018 a 2024: la base de comparación nacional para una situación de amenaza registrada con ID de la ATM.
Global Automotive & Smart Mobility Cybersecurity Report 2026
494 incidentes notificados públicamente en 2025; el 92 % ejecutados de forma remota, el 67 % a través de sistemas de telemática y cloud y el 44 % relacionados con ransomware.
Pwn2Own Automotive 2026 – Resultados
76 zero-days y 1.047.000 dólares estadounidenses en premios en Tokio; infotainment a través de USB, estaciones de carga a través de NFC. Muestra dónde está la frontera de la investigación en 2026 y qué falta todavía en la evidencia de la ATM.
¿Su TARA, sus pruebas y su SOC en un mismo lenguaje?
En una primera reunión sin compromiso le mostramos cómo integrar la Automotive Threat Matrix en su TARA según ISO/SAE 21434, en su planificación de pentests y en sus evidencias según UN R155, incluidas las lagunas que deberá cerrar usted mismo.