La ciberseguridad automotriz ya no es solo una cuestión técnica, sino estratégica. Con la creciente complejidad de los vehículos conectados y autónomos, garantizar su protección frente a ciberamenazas se ha convertido en una prioridad crítica para todo el mercado de automoción.
En junio de 2020, se publicaba la regulación 155 de Naciones Unidas (referidas internacionalmente como UNECE/R155), que establecía disposiciones uniformes sobre la homologación de vehículos en materia de ciberseguridad y un sistema de gestión de la ciberseguridad (abreviado CSMS por sus siglas en inglés, Cyber Security Management System).
Por ello, la práctica totalidad de fabricantes de automóviles, así como los fabricantes de componentes de automoción, se lanzaron a implantar un CSMS. Pero no había consenso sobre cómo crear dicho sistema de gestión. Es más, la norma ISO que debía regir dicho sistema de gestión no estaba aún aprobada. ¿Cómo coordinar y gestionar de forma efectiva la implementación de un sistema de ciberseguridad sin una normativa clara?
Este es el primero de dos artículos en las que exploraremos los desafíos a los que se han enfrentado las compañías del sector automoción al implantar la norma ISO 21434:2021 Road vehicles — Cybersecurity engineering, pero más importante aún, los beneficios que supuso incorporar una oficina de proyectos dentro de la iniciativa, siendo factor clave del éxito de dicha implantación.
Historia de la Norma
A diferencia de otras normas que pueden ser implantadas entendiendo únicamente la versión en curso, la ISO 21434 tiene la peculiaridad que conocer su contexto histórico, de cómo esta norma ha llegado a tener un contenido y no otro, es de gran ayuda para su implantación. Al momento de escribir este artículo (año 2024), sólo existe una primera versión de la norma, es de muy reciente publicación y que no deroga ninguna otra norma. Entonces, ¿cuál son los orígenes de esta norma?
La primera aproximación a la Ciberseguridad en el desarrollo de vehículos o componentes para automoción hunde sus raíces en la Seguridad Funcional para Automoción, conocido por sus siglas en inglés FuSa (Functional Safety). También conocida es la norma internacional que la regula, la norma ISO 26262 Road vehicles — Functional safety, con base fundamentalmente en la electrónica.
La cuestión que se planteaba era sencilla: ¿Se podían analizar las amenazas (threats) de ciberseguridad de forma análoga a como se analizaban los peligros (hazards) de la en la seguridad funcional?
Partiendo de un documento HARA (Hazard Analysis and Risk Assessment) destinado a analizar el comportamiento de nuestro sistema cuando uno de los componentes fallase, como por ejemplo un fallo en un condensador o una resistencia que se funda, ¿podríamos extrapolar un documento TARA (Threat Analysis and Risk Assessment) con el análisis de un ciberataque?
En un primer momento tenía todo el sentido esta aproximación, pues las similitudes entre un análisis HARA y un análisis TARA eran claras. Pero ya en estos primeros compases quedó evidente que la norma existente para Seguridad Funcional no daría cobertura a muchos aspectos. Se necesitaba un paradigma distinto. Así, en octubre del año 2016 se inició la propuesta para la creación de una nueva norma, seguido del correspondiente paso por los comités de trabajo, las primeras versiones en borrador y por último su publicación en octubre de 2021.
Primera Versión Publicada
Pero mientras se gestaba la norma, el mercado de automoción estaba sometido a una alta presión. No cumplir con las exigencias de la regulación 155 no era una opción debido a las consecuencias de dicho incumplimiento conllevaban no poder vender los componentes o vehículos afectados a partir de ciertas fechas, y la incertidumbre de no disponer de una norma clara y concisa, con tiempo suficiente para su implantación y posterior certificación hacía mella en las empresas. En los comités se percibía la falta de consenso sobre los borradores de la norma ISO, pero tampoco estaba claro el encaje de otras iniciativas como por ejemplo Automotive SPICE for Cybersecurity por parte de la VDA (siglas en alemán de Asociación Alemana de la Industria Automovilística). En paralelo, la norma ISO 24089 que abordaba un Sistema de Gestión para la actualización del software, planteaba desafíos adicionales desde el punto de vista de la integración; sufría también de la falta de consenso y tampoco se acababa de publicar.
Todo ello, acabó resultando en una publicación de la norma con mucho menor contenido que la versión borrador final (FDIS por sus siglas en inglés, final draft international standard). Se optó por un acuerdo de mínimos en varios aspectos clave. A modo de ejemplo, en la versión publicada no aparece ninguna vez la expresión “trazabilidad”. Automotive SPICE, siendo como es el estándar de facto en el desarrollo de software en automoción, quedaba relegado a un simple ejemplo a la hora de gestionar la calidad.
Muchas compañías que fueron avanzando en la implementación basándose en la versión borrador tuvieron que gestionar el “desaprender” un buen número de requisitos de la norma.
En este escenario el disponer de un Subject Matter Expert (SME) con respecto a la nueva norma se volvió un factor clave para el éxito de la iniciativa. Cuando una norma sufre cambios significativos en su alcance, es muy buena práctica disponer de una entidad objetiva y externa a la operativa de implantación, que pueda liderar un análisis profundo de las diferencias entre las distintas versiones. Una Oficina de Proyectos integrada en la iniciativa es una solución idónea por la cercanía a los equipos de trabajo, pero a la vez por la independencia a los trabajos previamente realizados.
La gestión del conocimiento del equipo y ayudar a adaptar el alcance de los trabajos son dos de las acciones clave, pero no menos importante es la gestión de la frustración del equipo cuando se plantea un volumen significativo de reaprendizaje y retrabajo.
Convivencia entre varias realidades
Como comentábamos anteriormente, las empresas tuvieron que avanzar en sus trabajos durante la fase vacío normativo en lo que se refiere a análisis, creación de procesos y despliegue de los mismos. Pero también los proyectos de desarrollo siguieron con su avance natural y los clientes comenzaban a solicitaban a sus proveedores requisitos de ciberseguridad.
Durante esta situación de interinidad, en la que el CSMS no estaba desplegado o quizás lo estaba parcialmente, la empresa podía encontrarse múltiples casuísticas en paralelo en sus proyectos:
- El cliente acordó una serie de requisitos que estaban presentes en la versión borrador de la norma, pero que ahora no aparecen en la versión publicada.
- El cliente pide una acción de ciberseguridad muy concreta al proveedor, como por ejemplo deshabilitar un conector en la pieza cuando ésta fuese a ser producida en masa. Es una acción que la norma, al ser más genérica, no contempla.
- El cliente demandaba una serie de requisitos, los cuales, bajo su clasificación, eran de ciberseguridad; no obstante, no aparecen reflejados en la norma.
Es esta serie de contextos y otros similares, la PMO desempeña un papel crucial con estas tres líneas de trabajo:
- La PMO actúa como un facilitador para gestionar estas realidades paralelas, brindando apoyo a las peticiones específicas de los proyectos sin comprometer el alcance original del CSMS.
- Evitando presiones por parte del equipo: Por un lado, los equipos deberán trabajar por cumplir con los acuerdos ya cerrados con sus clientes, asegurando que se implementen las características solicitadas en los productos o se gestionen otra serie de aspectos. Por otro lado, es frecuente y humano que los equipos de proyecto intenten influir en el sistema de gestión para evitar retrabajos futuros. Es sin duda un riesgo de corrupción del alcance que la PMO debe prevenir.
- Apoyando las discusiones con el cliente cuando exista una discrepancia en lo que se refiere al entendimiento común de la norma. Es frecuente que equipos con poca experiencia no deseen discutir con cliente sobre un tema del que no son expertos, pero no hacerlo aumenta los malentendidos a largo plazo. La oficina de proyectos debe apoyar al equipo y fomentar las aclaraciones pertinentes.
Complejidad en la Integración e Interesados
El último de los puntos que queremos resaltar en este artículo es la complejidad inherente a la creación de un CSMS. La norma ISO21434 tiene requisitos acerca de la integración con otros Sistemas de Gestión corporativos (cuando proceda). Cada empresa tendrá su propio ecosistema de sistemas de gestión, con relaciones y dependencias, que deberán ser conocidos y gestionados a la hora de implantar el CSMS.
En paralelo a dicha integración, hay muchas otras iniciativas corporativas que se verán influenciadas mutuamente con la creación de un CSMS, como por ejemplo abordar un mayor nivel de Automotive SPICE, etiquetas TISAX, etc.
Es necesaria que exista consistencia entre esas iniciativas, por lo que el volumen de interacciones con otros interesados será elevado, y por ende costoso en tiempo. Relacionado con lo anterior, la probabilidad de influir el alcance del CSMS será alto, con el correspondiente riesgo a mayor carga de trabajo y a una posible corrupción del alcance.
En este sentido, vuelve a cobrar sentido el disponer de una oficina de proyectos que aplique una metodología de gestión de interesados, como por ejemplo mediante la aplicación de un salience model. En paralelo a ello, aplicar una férrea gestión de las comunicaciones y reporting a alta dirección.
Conclusión
En los sectores altamente reglados como es el de la automoción, el disponer de conocimiento específico marcan la diferencia entre una correcta gestión del cambio corporativo o el caos. La falta de dicho conocimiento in-house no debe de ser excusa para frenar iniciativas de implantación de nuevas normas o sistemas de gestión.
En un siguiente artículo continuaremos desgranado las mejoras en nuestra iniciativa al disponer de una oficina de proyectos, pero exploraremos también cual son los tradeoffs asociados a estas entidades. En la vida real la solución perfecta no existe, pero conocer los compromisos que requieren por todas las partes ayudará a gestionarlos, aumentando así las probabilidades de éxito.
Jaime Bercianos es experto en ISO/SAE 21434 and Trusted Advisor en Automotive Management Systems in Safetwice