Cumplimiento
ISO/SAE 21434 y UN R155 te piden verificar que los controles de seguridad funcionan, y conservar la evidencia. AutoST produce esa evidencia, de forma repetible, en cada ECU.
En resumen
AutoST da soporte a un programa de ISO/SAE 21434 y UN R155 por el lado de las pruebas. ISO/SAE 21434:2021 pide pruebas de seguridad en tres puntos: Clause 10.4.2 Integración y verificación ([RQ-10-09], y [RC-10-12] que recomienda pruebas de componentes con fuzzing y escaneo de vulnerabilidades para minimizar las debilidades no identificadas), Clause 11 Validación de ciberseguridad ([RQ-11-01], que menciona las pruebas de penetración) y Clause 8.5 Análisis de vulnerabilidades como actividad continua. AutoST realiza esas pruebas (enumeración, sondeo de SecurityAccess, fuzzing, DoIP/SOME/IP e IVI) y produce la evidencia (informes PDF y SARIF, historial de escaneos, aceptación de riesgo) que las respalda. No ejecuta tu CSMS ni escribe tu TARA: para eso, Zyberum ofrece consultoría de ISO/SAE 21434.
Las cláusulas
Las referencias son a ISO/SAE 21434:2021. Esto es orientación práctica, no una certificación, pero es donde viven el fuzzing, el análisis de vulnerabilidades y las pruebas de penetración dentro de la norma.
[RQ-10-09] te exige verificar que la implementación cumple con la especificación de ciberseguridad. [RC-10-12] recomienda pruebas de componentes, con fuzz testing y escaneo de vulnerabilidades, para minimizar las debilidades no identificadas. Eso es exactamente lo que hacen la enumeración, las comprobaciones de SecurityAccess y el fuzzing de AutoST, de forma repetible.
[RQ-11-01] menciona las pruebas de penetración como forma de confirmar que se cumplen los objetivos de ciberseguridad. AutoST le da a esa validación una base repetible y documentada en toda la superficie de ataque de diagnóstico y de bus, sobre la que luego pueden construir los especialistas.
Clause 8 trata la detección y el análisis de debilidades como una actividad continua a lo largo de la vida de la ECU. Volver a ejecutar AutoST en cada build, a través de la API y de CI, lo convierte en un proceso permanente y no en una auditoría puntual.
Las rutas de ataque de tu TARA son contra lo que prueba AutoST: servicios de diagnóstico accesibles sin autenticación, SecurityAccess débil, XCP/CCP expuestos. Los hallazgos vuelven directamente al panorama de riesgo. Zyberum escribe la TARA en sí.
Trazabilidad
Un auditor no solo quiere oír que probaste. Quiere ver qué se probó, cuándo, qué se encontró y qué pasó con cada hallazgo. AutoST mantiene esa cadena intacta.
Cada hallazgo lleva una severidad y una corrección concreta. El Fix Plan da a cada tarea un estado y un campo de referencia ALM/PLM, así que enlaza con tu requisito o ticket. El historial de escaneos y la aceptación de riesgo se arrastran entre repeticiones de las pruebas, de modo que un riesgo residual aceptado queda documentado y un problema corregido aparece como resuelto. La exportación es PDF para el archivo de auditoría y SARIF para tus herramientas.
Un límite honesto
AutoST no escribirá tu TARA ni ejecutará tu sistema de gestión de ciberseguridad. Es una herramienta de pruebas, y exagerar eso no te ayudaría a pasar una auditoría.
La estrategia, la TARA, la trazabilidad de los productos de trabajo y la preparación de la auditoría son trabajo de consultoría. Zyberum también lo hace: el mismo equipo que construye AutoST tiene la certificación Automotive Cybersecurity de SAE y TÜV SÜD para ISO/SAE 21434.
FAQ
El fuzzing y el escaneo de vulnerabilidades caen bajo la Clause 10.4.2 (Integración y verificación), donde [RC-10-12] recomienda pruebas de componentes para minimizar las debilidades no identificadas. Las pruebas de penetración se mencionan en la Clause 11 (Validación de ciberseguridad), [RQ-11-01]. La Clause 8.5 (Análisis de vulnerabilidades) convierte la detección de debilidades en una actividad continua. En la práctica, el fuzz testing de las interfaces de comunicación se espera a partir de CAL 2.
Ninguna herramienta hace eso por sí sola. AutoST cubre las pruebas y la evidencia: escaneos de seguridad y fuzzing repetibles para [RC-10-12], una base de pruebas de penetración para [RQ-11-01], puntuación de riesgo, historial e informes PDF/SARIF. La TARA, el CSMS y la auditoría son trabajo de proceso, que Zyberum puede apoyar por separado.
Cada hallazgo lleva una severidad y una corrección, y cada tarea del Fix Plan tiene un campo de referencia ALM/PLM que la enlaza con tu requisito o ticket. El historial de escaneos y la aceptación de riesgo se arrastran entre repeticiones de las pruebas, así que el rastro de auditoría muestra qué se probó, qué se encontró y qué se hizo al respecto.
UN R155 exige un CSMS certificado y que las mitigaciones de su Annex 5 se demuestren efectivas, lo que significa probadas. AutoST aporta evidencia de pruebas repetible para las mitigaciones a nivel de ECU; Zyberum da soporte al lado del CSMS y de la homologación de tipo.
Míralo sobre tu ECU
En una hora definimos el alcance de un piloto: tu banco, tus protocolos, los objetivos y qué significa el éxito.
Tu demo es conTom ZaubermannFundador de Zyberum, ex responsable del VW InCar Security Testing Lab
Ya confían en él proveedores Tier 1, Tier 2 y OEM. Referencias a petición.
Respondemos en un día hábil.
Tu privacidad
Usamos cookies y tecnologías similares para medir nuestro sitio web y el éxito de nuestros anuncios. Tú decides cuáles podemos usar. Puedes cambiar tu elección en cualquier momento mediante "Configuración de cookies" en el pie de página. Política de privacidad
