Área de investigación · Product & OT Security
Seguridad integrada en el producto — de la unidad de control al producto sanitario
Los vehículos conectados, los sistemas de control industrial, los productos sanitarios y los dispositivos con IA permanecen mucho tiempo en campo. Vami Research investiga cómo demostrar su seguridad a lo largo de todo el ciclo de vida: desde el TARA con la Automotive Threat Matrix, pasando por IEC 62443 y el Cyber Resilience Act, hasta el mantenimiento de productos sanitarios conectados y la IA en el dispositivo.
- Automotive Threat Matrix
- ISO/SAE 21434
- IEC 62443
- Notificación CRA
- MDR e IEC 81001-5-1
- IA en el producto
- TISAX
- Deep Dives
- 10
- Whitepapers
- 3
- Soluciones
- 3
Si el producto lleva software, la seguridad se convierte en una propiedad del producto
La seguridad de producto no protege la TI propia, sino el producto en campo, a menudo con acceso físico por parte de los atacantes y durante vidas útiles que superan con creces los ciclos de soporte habituales de TI. Una vulnerabilidad afecta a toda la base instalada y puede acarrear consecuencias para la safety, retiradas del mercado o la pérdida de la homologación de tipo. Así, la responsabilidad pasa de la operación de TI al desarrollo de producto.
La regulación se pone al día: desde el 7 de julio de 2024, todo vehículo nuevo de las categorías M, N y O necesita en la UE una homologación de tipo en materia de ciberseguridad conforme a UN R155; desde el 1 de agosto de 2025 rigen requisitos de ciberseguridad para los equipos radioeléctricos con conexión a Internet, y desde el 11 de septiembre de 2026, las obligaciones de notificación del Cyber Resilience Act. A partir del 20 de enero de 2027, el Reglamento de Máquinas impone por primera vez requisitos de ciberseguridad vinculantes a las máquinas. Los productos sanitarios siguen regulados por el MDR: el CRA los excluye.
Con la IA en el dispositivo se añade una nueva dimensión: los planificadores, los skills y las llamadas a herramientas se convierten en órdenes a motores, cerraduras o válvulas. Por eso, Vami Research combina métodos consolidados como el TARA, los modelos de zonas y los pentests de IoT con modelos de amenazas para la IA agéntica, y publica los resultados como Deep Dives, whitepapers y artículos técnicos, por ejemplo en la revista mt|medizintechnik.
Preguntas abiertas de la práctica
- 01
¿Cómo se describe el comportamiento de los atacantes en el vehículo de forma que el TARA, el pentest y el Vehicle SOC hablen el mismo idioma?
Nuestro enfoque
Utilizamos la Automotive Threat Matrix del Auto-ISAC, release v4.02 del 4 de diciembre de 2025, con 14 tácticas y 75 técnicas. Congelamos la versión y la anotamos en el TARA y en el CSMS; anclamos los identificadores de técnica en el PSIRT, el alcance de los pentests y el Vehicle SOC. Para el backend, la aplicación complementaria, el servidor OTA y la recarga mantenemos una capa de extensión propia: la matriz describe sobre todo el propio vehículo.
- 02
¿Cómo anclan los fabricantes la seguridad, desde el modelo de amenazas hasta la notificación de una vulnerabilidad explotada activamente?
Nuestro enfoque
Nos orientamos por el Secure by Design and Default Playbook de ENISA: cada principio con lista de verificación, evidencia mínima y release gate. A ello se suman el Threat Modeling, una SBOM por release y un PSIRT que cumple los plazos del CRA de 24 horas, 72 horas y 14 días. VamiGRC representa el Product Security Lifecycle con release gates, TARA y SBOM; VamiAppSec prepara las notificaciones como borradores.
- 03
¿Cómo se pueden proteger las plantas de producción sin poner en riesgo la disponibilidad ni la seguridad funcional?
Nuestro enfoque
Dividimos las plantas en zonas y conduits según IEC 62443 y fijamos un nivel de seguridad objetivo por zona. La transparencia de activos se logra mediante descubrimiento pasivo, porque los escaneos activos pueden perturbar los controladores más antiguos. El mantenimiento remoto se realiza a través de pasarelas dedicadas con activación por sesión. Así, las obligaciones derivadas de NIS2, que también abarca la industria manufacturera, pueden implementarse en el entorno OT.
- 04
¿Cómo se mantienen seguros en campo los productos sanitarios conectados y asistidos por IA cuando la security es a la vez seguridad del paciente?
Nuestro enfoque
Engranamos la gestión de riesgos de security y de safety según MDCG 2019-16 e IEC 81001-5-1: inventario con SBOM, triaje con contexto clínico, parches como cambio controlado y vías de notificación coordinadas. En el caso de la IA, la prompt injection y los permisos demasiado amplios de los agentes entran en el modelo de amenazas; para los productos sanitarios con IA sujetos a organismo notificado, las obligaciones de alto riesgo del AI Act rigen a partir del 2 de agosto de 2028.
Lo que constatamos
- 01
Una evaluación exhaustiva del riesgo necesita la matriz y el catálogo de UN R155
Hemos mapeado las 75 técnicas de la Automotive Threat Matrix sobre el catálogo de amenazas de UN R155: 52 pueden asignarse limpiamente, mientras que a la matriz le faltan casi por completo las amenazas contra servidores backend. El catálogo de UN R155, a su vez, no muestra rutas de ataque ni justifica la viabilidad. Solo las dos listas juntas, vinculadas mediante identificadores estables, sustentan la evaluación del riesgo.
Fuente: Automotive Threat Matrix
- 02
En los productos con IA, una prompt injection puede tener consecuencias físicas
Si un dispositivo lleva IA, los planificadores y las llamadas a herramientas se convierten en órdenes a motores, cerraduras o válvulas. El producto es entonces a la vez dispositivo IoT, sistema de IA y sistema ciberfísico. Quien solo examina una capa pasa por alto las cadenas de ataque entre ellas; por eso modelamos según STRIDE y MAESTRO y probamos desde la interfaz de depuración hasta el LLM.
Fuente: Pentesting de productos con IA
- 03
Un dispositivo volcado puede poner en peligro toda la flota
Quien tiene en la mano un dispositivo conectado puede acceder a las interfaces de depuración, volcar la memoria flash y analizar el firmware. Las credenciales o las claves de firma de un solo dispositivo suelen servir para toda la flota. Por eso se comprueba si los puertos de depuración están desactivados, si el Secure Boot funciona y si los secretos se almacenan de forma protegida.
Fuente: Pentesting IoT
- 04
En los productos sanitarios, el contexto clínico decide la prioridad
CVSS, EPSS y KEV evalúan la severidad, la probabilidad y los ataques en curso, pero no si un equipo está junto al paciente o si una manipulación altera el diagnóstico y la terapia. Solo estas preguntas determinan la clase de prioridad. Por eso, una vulnerabilidad de valoración media en un sistema terapéutico puede ser más urgente que una crítica en un equipo aislado.
Cómo procedemos
Vami Research combina normas sectoriales con una metodología común: modelar las amenazas, comprobar todas las capas y mantener evidencias utilizables en el TARA, la documentación técnica y la evaluación de la conformidad.
TARA con la Automotive Threat Matrix
Técnicas de la matriz como piezas de rutas de ataque según ISO/SAE 21434, cotejadas con el catálogo de amenazas de UN R155; supuestos de viabilidad versionados.
STRIDE y MAESTRO
Modelo de amenazas por flujo de datos y límite de confianza; para la IA agéntica, a lo largo de las siete capas de MAESTRO, en VamiThreat con asignación a MITRE ATT&CK y ATLAS.
Zonas, conduits, descubrimiento pasivo
Dividir las plantas en zonas con nivel de seguridad objetivo según IEC 62443; inventario a partir del tráfico duplicado en lugar de escaneos activos en la red de producción.
Pruebas del chip a la nube
Pentests de productos IoT y de IA según OWASP ISVS e ISTG y ETSI EN 303 645: hardware, firmware, radio, backend, app y modelo en su conjunto.
Release gates con evidencia mínima
Playbooks de ENISA con lista de verificación y release gate; SBOM por release, VEX y proceso de PSIRT como base de la capacidad de notificación según el CRA.
Triaje clínico
Complementar la evaluación técnica con la accesibilidad, la proximidad al paciente y las consecuencias para el diagnóstico o la terapia; aplicar los parches como cambio controlado.
Cómo empezar
- 1ModelarRegistrar la arquitectura, los flujos de datos y los límites de confianza; derivar amenazas y rutas de ataque mediante TARA, STRIDE o MAESTRO.
- 2Probar y bastionarPentests desde la interfaz de depuración hasta el LLM, segmentación por zonas y release gates con evidencias mínimas.
- 3Operar en campoVigilar la SBOM de cada release, recibir avisos de vulnerabilidades a través de CVD y PSIRT y definir de antemano las vías de notificación según el CRA, el MDR y la ley BSI.
Deep Dives, whitepapers y análisis
Deep Dives 10
Whitepapers 3
Análisis y noticias
Del área a la implantación
Áreas de investigación relacionadas
¿Proteger su producto, del TARA a la notificación?
Ya sea un componente de vehículo, un sistema de control industrial o un producto sanitario: contextualizamos normas y plazos, modelamos las amenazas y probamos desde la interfaz de depuración hasta el LLM.