Trazabilidad en una auditoría ISO 21434: que el fuzzing cuente

ISO/SAE 21434 no solo te pide que seas seguro. Te pide que lo demuestres, ante un evaluador, con evidencia. Esa diferencia es donde mucho buen trabajo de seguridad se cae en una auditoría, y las pruebas de seguridad son el ejemplo más claro.

El estándar pide las pruebas. También pide el rastro documental

Los requisitos de pruebas están bastante claros. La Clause 10.4.2 (integración y verificación) exige que verifiques que la implementación cumple con la especificación de ciberseguridad ([RQ-10-09]), y [RC-10-12] recomienda pruebas de componentes, con fuzz testing y escaneo de vulnerabilidades, para minimizar las debilidades no identificadas. La Clause 11 (validación de ciberseguridad) nombra las pruebas de penetración ([RQ-11-01]). A partir de CAL 2, el fuzzing de las interfaces de comunicación se espera en la práctica.

Pero una evaluación 21434 no se califica según si ejecutaste un fuzzer. Se califica según tus productos de trabajo: el informe de verificación, el informe de validación y, en última instancia, el caso de ciberseguridad que argumenta que tu elemento es adecuadamente seguro, juzgado en la evaluación de ciberseguridad (Clause 6.4.9). El evaluador lee el argumento y la evidencia que lo respalda. Una campaña de fuzzing que no está escrita en ese argumento es como si no hubiera ocurrido.

Trazabilidad bidireccional, en una frase

Lo que los evaluadores piden una y otra vez es trazabilidad bidireccional: un vínculo documentado de cada requisito de ciberseguridad a la prueba que lo verifica, y de cada prueba de vuelta a un requisito.

Para las pruebas de seguridad eso significa que un evaluador puede empezar en un objetivo de ciberseguridad (“el ECU no debe aceptar escrituras de diagnóstico sin autenticación”), seguirlo hasta un requisito de ciberseguridad, seguir ese requisito hasta la prueba que lo comprueba, y ver el resultado, su fecha y qué ocurrió con cualquier hallazgo. Y puede ir en sentido contrario: tomar un hallazgo y rastrearlo hasta el requisito que amenaza.

La mayoría de los equipos pueden producir las pruebas. Muchos menos pueden producir esa cadena el día de la evaluación.

Dónde el fuzzing se vuelve difícil en concreto

El fuzzing es especialmente incómodo de hacer trazable, por tres razones:

• Es no determinista por naturaleza. Si un crash no se puede reproducir, es una anécdota, no una evidencia. Un evaluador no puede aceptar “se cayó una vez en marzo”.
• Produce volumen, no estructura. Millones de iteraciones y un montón de logs no se asignan limpiamente a una lista corta de requisitos de ciberseguridad.
• Se ejecuta tarde y rara vez. Una campaña puntual antes de una auditoría te habla del software que tenías esa semana, no del software que entregas, y no lleva ningún historial.

Así que la pregunta que un evaluador realmente hace sobre tu fuzzing no es “¿hiciste fuzzing?”. Es: ¿puedes reproducir este hallazgo, cuándo lo viste por primera vez, con qué requisito se relaciona y qué hiciste al respecto?

Cómo es una evidencia de pruebas de seguridad lista para auditoría

Sea cual sea la herramienta que uses, la evidencia tiene que llevar cinco cosas:

1. Reproducibilidad. Una semilla o configuración almacenada para que cualquier hallazgo se pueda reproducir a demanda, por ti y por el evaluador.
2. Un historial fechado. No una instantánea, sino un registro de qué se probó y cuándo, a lo largo de la vida del ECU, para que puedas mostrar la tendencia, no solo el estado final.
3. Vínculo con los requisitos. Cada hallazgo atado al requisito de ciberseguridad o ticket que afecta, para que la traza bidireccional se sostenga.
4. Aceptación del riesgo documentada. Cuando se acepta un riesgo residual, la decisión y su justificación quedan registradas y sobreviven al siguiente ciclo de pruebas.
5. Una exportación legible. La evidencia tiene que salir de la herramienta en una forma que el evaluador y tu propio rastreador puedan consumir, PDF para el expediente y SARIF para las herramientas.

Acierta con esas cinco y una campaña de fuzzing deja de ser un archivo de log y se convierte en un producto de trabajo.

Cómo AutoST está construido para esto

Esta es la parte de un programa 21434 que AutoST está diseñado para sostener.

Cada ejecución es reproducible: la semilla del fuzzing se almacena y se muestra, de modo que un crash se puede reproducir exactamente. Cada escaneo está fechado y conservado, así el historial a lo largo de la vida de un ECU está ahí, no reconstruido. Cada hallazgo lleva una severidad y una corrección concreta, y el Fix Plan da a cada tarea un estado y un campo de referencia ALM/PLM, que es donde vive el vínculo de vuelta a tu requisito o ticket. La aceptación del riesgo y los comentarios se trasladan entre re-tests, de modo que un riesgo residual aceptado permanece documentado y un problema corregido aparece como resuelto. Y la salida es PDF para el expediente de auditoría y SARIF para tus herramientas.

Como AutoST se ejecuta desde la API y en CI, las pruebas se convierten en una actividad continua en el sentido que pretende la Clause 8.5, en lugar de una carrera a contrarreloj antes de la evaluación. El evaluador ve una tendencia y un rastro, no una única campaña heroica.

El límite honesto

AutoST produce la evidencia de pruebas y la mantiene trazable. No escribe tu TARA, ni ejecuta tu sistema de gestión de ciberseguridad, ni redacta tu caso de ciberseguridad. Eso es trabajo de proceso y de juicio de ingeniería. Zyberum también cubre ese lado, como consultoría, con un equipo que posee la certificación SAE y TÜV SÜD Automotive Cybersecurity para ISO/SAE 21434 y que ha llevado programas de Tier 1, Tier 2 y OEM exactamente por este camino. Las referencias están disponibles a petición.

Si quieres ver cómo es una evidencia de pruebas lista para auditoría en tu propio ECU, reserva una demo y la ejecutaremos contra un objetivo real.