1 preámbulo
Con el continuo enriquecimiento de los medios de interacción entre los automóviles y el mundo exterior, la interacción de datos entre los equipos y sistemas relacionados de Internet de los vehículos se ha vuelto más frecuente, y los ataques a la red en el marco de Internet de todo han penetrado y extendido gradualmente a el campo de Internet de los vehículos. Esto trae consigo nuevos "desafíos exclusivos" para la industria del automóvil.
He leído brevemente varias normas internacionales importantes en el campo de la seguridad de la información automotriz en los últimos días. Este artículo analiza brevemente estos estándares y normas relacionados con la seguridad de la información automotriz.
2 Norma ISO/SAE21434
El 31 de agosto de 2021 se publicó oficialmente la primera norma internacional ISO/SAE 21434 "Vehículos de carretera: ingeniería de ciberseguridad" en el campo de la seguridad de la información automotriz. ISO/SAE 21434 fue redactada y publicada conjuntamente por la Organización Internacional de Normalización (ISO) y la Sociedad de Ingenieros Automotrices (SAE) para guiar el desarrollo de la industria de especificaciones. La norma ISO21434 define un marco completo de ciberseguridad de vehículos y procesos relacionados del ciclo de vida de ciberseguridad del producto.
2.1 Relación entre las normas ISO/SAE 21434 e ISO 26262
¿Existe alguna relación entre las normas ISO/SAE 21434 e ISO 26262? Aún debería ser relevante.
La norma ISO 26262 apareció antes y trata principalmente sobre la seguridad funcional. La seguridad funcional tiene como objetivo garantizar que las funciones se lleven a cabo normalmente de acuerdo con los requisitos de diseño y minimizar las fallas de funciones causadas por problemas de diseño del sistema; mientras que la seguridad de la información tiene como objetivo resistir ataques externos y presta más atención al funcionamiento normal del sistema. bajo ataques externos sin causar pérdidas a la propiedad y no se viola la privacidad personal. Ambos se centran en la funcionalidad a nivel del sistema y tanto las definiciones como los procedimientos están interrelacionados. En la norma ISO 26262 se dan recomendaciones de orientación para la interacción entre la seguridad funcional y la seguridad de la información. Tales como: la interacción entre HARA y TARA y la coordinación entre procesos en la etapa de concepto. Con el profundo avance de la inteligencia y las redes de automóviles, la seguridad funcional y la seguridad de la información no son independientes ni separadas y, en general, presentan una tendencia a la integración con los procesos estructurados existentes de las empresas.
2.2 Estructura de capítulos de ISO/SAE 21434
ISO/SAE 21434 tiene 15 capítulos en total. 1. Alcance 2. Referencias 3. Terminología y abreviaturas 4. Generalidades 5. Gestión de ciberseguridad global 6. Gestión de ciberseguridad relacionada con proyectos 7. Actividades de ciberseguridad distribuidas 8. Actividades de ciberseguridad en curso 9. Diseño conceptual 10. Desarrollo de productos 11. Verificación de la seguridad de la información 12 Producción 13. Operación y mantenimiento 14. Desguace 15. Método de evaluación de riesgos (TARA).
La organización del capítulo ISO/SAE 21434 se muestra en la siguiente figura.
Los capítulos 1 a 4 de la norma son una descripción básica de la norma, incluido el alcance de la norma, referencias, definiciones de términos y principios generales de la norma.
Los capítulos 5 a 8 son requisitos relacionados con la seguridad de la información presentados en la gestión general de la empresa. El objetivo es esperar que la empresa establezca procesos y mecanismos de seguridad de la información desde la perspectiva de la empresa, a fin de "buscar la situación general".
Los capítulos 9 a 14 definen los requisitos para la seguridad de la información del vehículo en las etapas de diseño conceptual, I + D, verificación, producción, operación y Los riesgos causados por amenazas a la seguridad se reducen a un rango razonable, a fin de "buscar un dominio".
El Capítulo 15 propone una metodología de evaluación de riesgos de seguridad de la información del vehículo - TARA.
En el estándar, la gestión global de la seguridad de la información brinda soporte para diversas actividades de seguridad de la información en el ciclo de vida del producto, y varias actividades de seguridad de la información en el ciclo de vida del producto están interconectadas y las dos se complementan entre sí. Como se muestra en la figura siguiente, en la etapa conceptual, es necesario definir los elementos relacionados con la seguridad de la información y se realiza el análisis TARA para generar los objetivos y requisitos de seguridad de la información como entrada en la etapa de investigación y desarrollo; en la etapa de investigación y desarrollo , los objetivos y requisitos de seguridad de la información ingresados en la etapa de concepto deben realizarse refinamientos, completar el diseño de software y hardware, integración y pruebas del sistema, y confirmar el cumplimiento de los requisitos de seguridad de la información; en la etapa de verificación, es necesario comparar la información Los objetivos de seguridad definidos en la etapa de concepto confirman que se han logrado y forman un circuito cerrado.
2.3 Vínculos importantes en la gestión de la seguridad de la información del ciclo de vida del producto
Los siguientes son los enlaces en los que es necesario centrarse en la gestión de la seguridad de la información del ciclo de vida del producto:
01 La definición de elementos relacionados
se encuentra en la etapa conceptual. Es muy importante para la seguridad de la información automotriz aclarar la definición de elementos relacionados de La dimensión de todo el ciclo de vida del producto. Esto es para aclarar el alcance de la gestión. Es una parte importante de la entrada de objetos de gestión para actividades posteriores de gestión de seguridad de la información.
02 Análisis TARA
El análisis TARA incluye pasos como la identificación de activos, la identificación de escenarios de amenazas, el análisis de impacto, el análisis de la ruta de ataque, la calificación de viabilidad del ataque, la evaluación del nivel de riesgo y las medidas de tratamiento de riesgos. Las empresas pueden obtener la seguridad de la información del producto realizando un análisis TARA sobre la seguridad de la información relacionada. artículos Objetivo.
03 Requisitos de seguridad de la información
Para lograr los objetivos de seguridad de la información del producto, las empresas deben formular requisitos de seguridad de la información, descomponerlos en varios sistemas y componentes, y formular las correspondientes medidas de mitigación de la seguridad de la información.
04 Desarrollo de la seguridad de la información
En la etapa de investigación y desarrollo, las empresas deben perfeccionar los requisitos de seguridad de la información y las medidas de mitigación, y llevar a cabo investigación y desarrollo de productos basados en los requisitos refinados y las medidas de mitigación, completar el diseño de la arquitectura, el diseño de software y hardware e integrar los sistemas.
05 Pruebas y verificación de seguridad de la información Las
pruebas de seguridad de la información consisten en verificar que el producto ha cumplido con los requisitos de seguridad de la información formulados en la etapa inicial mediante métodos de prueba, casos de prueba, etc. El propósito de la verificación de la seguridad de la información es confirmar que la seguridad de la información Se han logrado los objetivos definidos en la etapa inicial del proyecto Design Freeze.
06 Requisitos de seguridad de la información en la etapa posterior al desarrollo
Además, las empresas deben tomar medidas para garantizar la implementación de los requisitos de seguridad de la información del producto en la etapa posterior al desarrollo. Por ejemplo, formular un plan de control de producción de seguridad de la información durante la fase de producción, responder a los cambios en los métodos de ataque externos mediante la respuesta de emergencia a incidentes de seguridad de la información y la recopilación y gestión de vulnerabilidades durante la fase de operación y mantenimiento, y considerar los problemas de seguridad de la información después de que el producto esté disponible. desguazado.
En general, ISO/SAE 21434 especifica exhaustivamente los requisitos de seguridad de la información para vehículos de carretera y sus componentes e interfaces, y describe en detalle cómo lograr los objetivos de gestión de seguridad de la información de los vehículos basándose en cuestiones de seguridad de la información, así como un importante documento de referencia para el control interno. de las empresas, también favorece la promoción de importantes consensos alcanzados por todos los sectores de la sociedad en el ámbito de la seguridad de la información en el sector del automóvil.
3 UN/WP.29 Estándar de Internet de los vehículos
En junio de 2020, el Foro Mundial de las Naciones Unidas para la Armonización de la Regulación de Vehículos (UN/WP.29 para abreviar) publicó tres regulaciones importantes sobre vehículos inteligentes conectados R155/R156/R157, a saber, seguridad de la información (ciberseguridad)/actualizaciones de software (actualizaciones de software). )/Sistema automático de mantenimiento de carril (ALKS). Esta serie de regulaciones es aplicable a los estados miembros bajo el acuerdo de 1958 (el número de partes del acuerdo de la CEPE de 1958 ha aumentado a 54, incluidos todos los países de la UE y otros países de la OCDE. Aunque China no está en los países del acuerdo de 1958, siempre que los automóviles producidos se venden a estos. La certificación correspondiente debe aprobarse en el país.
En realidad, WP.29 tiene muchas especificaciones, pero las especificaciones anteriores no tienen nada que ver con la seguridad de la información. Y R155/R156 es el estándar que más me preocupa.
3.1 R155
R155 (Seguridad de la información y Sistema de gestión de seguridad de la información) es la primera regulación obligatoria del mundo sobre seguridad de la información automotriz, lo que significa que la seguridad de la información de los vehículos ha entrado en la era del cumplimiento de las normas.
La especificación R155 tiene 12 capítulos 1. Alcance 2. Definición 3. Solicitud de aprobación 4. Marcado 5. Aprobación 6. Certificado de cumplimiento CSMS 7. Requisitos de especificación 8. Modificación y extensión del modelo 9. Cumplimiento del producto 10. Sanciones por incumplimiento del producto 11. Producto descontinuado 12. La información de contacto del proveedor de servicios técnicos responsable de la prueba de aprobación y la agencia de aprobación del modelo.
Las regulaciones estipulan los requisitos obligatorios de seguridad de la información que los fabricantes de vehículos deben cumplir. La implementación obligatoria significa que los fabricantes de vehículos que planean exportar a la UE u otros países de la OCDE enfrentarán severos desafíos de acceso.
3.1.1 Ámbito de aplicación del R155
R155 cubre básicamente el ámbito de aplicación de turismos y vehículos comerciales en términos de seguridad de la red.
a) Vehículos de categoría M y vehículos de categoría N
b) Vehículos Clase O equipados con al menos una ECU.
c) Modelos L6 y L7 con funciones de conducción automática L3 y superiores.
3.1.2 Planificación del tiempo de regulación R155
Varios nodos temporales importantes:
• El 22 de enero de 2021, la ley entrará en vigor, abierta a la solicitud de certificado CSMS (Sistema de gestión de seguridad cibernética) y certificado VTA (Aprobación de tipo de vehículo); • Julio de 2022 Aplicable
a nuevos modelos de julio de 2024; aplicable a todos los modelos a partir de julio de 2024;
• Se lanzarán nuevos modelos con estructuras existentes dentro de dos años desde 2022 a 2024. Si no se pueden desarrollar de acuerdo con CSMS, VTA debe demostrar que la red se ha considerado completamente durante el etapa de desarrollo Seguridad:
• El período de transición finaliza en enero de 2025, exigiendo que todos los modelos de todas las arquitecturas estén certificados (CSMS+VTA).
3.1.3 Requisitos de certificación de cumplimiento R155
La certificación de cumplimiento R155 se divide principalmente en dos partes: una es la certificación del sistema de gestión de seguridad cibernética (CSMS); la otra es la certificación del tipo de seguridad de la red del vehículo (VTA).
La certificación CSMS examina principalmente si el fabricante del vehículo ha establecido un proceso de gestión de seguridad de la red en todas las etapas del ciclo de vida completo del vehículo para garantizar que existan las medidas de proceso correspondientes durante todo el ciclo de vida del vehículo. Cada proceso se implementa en cada etapa de desarrollo, producción, producción en masa, operación y mantenimiento para garantizar que el diseño, la implementación y la respuesta de la seguridad de la información estén guiados por el sistema de procesos.
La certificación VTA consiste en revisar elementos de trabajo específicos en el desarrollo de la seguridad de la información, con el objetivo de garantizar que la tecnología de protección de la seguridad de la información implementada en los vehículos sea suficientemente completa durante la revisión y certificación. En otras palabras, la certificación CSMS es un requisito previo para la certificación VTA, y la certificación CSMS y la certificación VTA deben completarse para el acceso final del vehículo.
3.1.4 Requisitos del sistema de gestión de seguridad de red (certificación CSMS)
Los fabricantes de vehículos deben cumplir el contenido de "7.2 Requisitos del sistema de gestión de ciberseguridad" del Reglamento R155, cuyo capítulo 7.2.2 detalla específicamente los aspectos específicos que debe cubrir la certificación CSMS.
● 7.2.2.1 Los requisitos del sistema de gestión de seguridad de la red se establecen en cada etapa del ciclo de vida completo del vehículo:
· Etapa de desarrollo
· Etapa de producción
· Etapa de postproducción.
● 7.2.2.2 Garantizar que la seguridad se considere plenamente en el CSMS y que existan medidas de proceso durante todo el ciclo de vida del vehículo para controlar los riesgos relacionados:
· Tener un proceso completo para gestionar la implementación del CSMS;
· Tener un proceso para identificar todos los riesgos posibles de un modelo de vehículo (los riesgos mencionados en la Parte A del R155 Anexo 5A y otros riesgos relevantes deben ser considerados); · Tener un proceso para evaluar
/ Clasificación/manejo de riesgos identificados Procesos;
Procesos y estándares para la gestión de riesgos;
Capacidades y procesos para probar modelos de vehículos tanto en la fase de desarrollo como de producción;
Las evaluaciones de riesgos están actualizadas y actualizadas;
Monitoreo, detección y respuesta a ataques cibernéticos, Proceso de amenazas y vulnerabilidades;
· Los modelos de vehículos en toda la etapa del ciclo de vida tienen medidas efectivas para hacer frente a ataques de red, amenazas de red y vulnerabilidades;
· Proporcionar datos relevantes necesarios para el análisis del proceso de ataque de red.
● 7.2.2.3 Respuesta y mitigación:
· Los fabricantes de vehículos deben responder a las ciberamenazas y vulnerabilidades;
· Las respuestas deben mitigarse dentro de un plazo razonable.
● 7.2.2.4 Monitoreo continuo:
El proceso de monitoreo de ataques a la red de vehículos, amenazas de red y vulnerabilidades de la red es sostenible; Los
vehículos después del primer registro se incluyen en el alcance del monitoreo;
Los datos y registros de los vehículos se analizan y detectan Capacidad;
Privacidad y consentimiento ( GDPR&ISO27701&Ley de Protección de Información Personal&Ley de Seguridad de Datos...).
● 7.2.2.5 Gestión de la cadena de suministro del sistema de gestión de seguridad de la red: Demostrar que los riesgos de los proveedores/
proveedores de servicios/subsidiarias son claros y se gestionan de acuerdo con los requisitos de 7.2.2.2;
/Las subsidiarias asumen riesgos y toman las medidas correspondientes.
3.1.5 Requisitos del tipo de vehículo R155 (certificación VTA)
Los fabricantes de vehículos deben cumplir el contenido de "7.3 Requisitos de tipo de vehículo" del Reglamento R155.
Los requisitos de contenido específicos de VTA son los siguientes:
● 7.3.1 Se debe tener un certificado de cumplimiento CSMS válido relacionado con el modelo de vehículo certificado:
Si la certificación del modelo de vehículo antes del 1 de julio de 2024, si no se puede desarrollar de acuerdo con el CSMS, es necesario demostrar que la seguridad de la red se ha considerado plenamente en la etapa de desarrollo del modelo.
● 7.3.2 Se deben identificar y gestionar los riesgos relacionados con los proveedores:
· Riesgos conocidos y gestionables de los proveedores;
· Los fabricantes de vehículos pueden proporcionar pruebas, como cláusulas contractuales con proveedores que cumplan con los requisitos de R155.
● 7.3.3 Identificación de elementos del modelo, evaluación de riesgos, tratamiento/gestión de riesgos identificados.
● 7.3.4 Implementar las medidas de mitigación correspondientes:
Las medidas de mitigación implementadas deben incluir todas las medidas de enlace relacionadas con los riesgos conocidos mencionados en la Parte B y la Parte C del Apéndice 5 de R155; la
Parte B o la Parte C del Apéndice 5 de R155 Las mitigaciones mencionadas son irrelevantes o insuficiente para el riesgo identificado y el fabricante del vehículo debe garantizar que se implemente otra mitigación adecuada.
● 7.3.5 Tomar medidas apropiadas y proporcionadas para garantizar la seguridad del entorno dedicado del modelo de vehículo para almacenar y ejecutar software, servicios, aplicaciones o datos posventa:
· Demostrar que los riesgos de los proveedores/proveedores de servicios/subsidiarias se identifican y gestionan de acuerdo con los requisitos de 7.2.2.2 ·
Demostrar que se toman medidas adecuadas para los riesgos asumidos por los proveedores/proveedores de servicios/subsidiarias.
● 7.3.6 Los fabricantes de vehículos deben realizar pruebas apropiadas y suficientes antes de la certificación para verificar la efectividad de las medidas de seguridad implementadas:
● 7.3.7 estipula las medidas que los fabricantes de vehículos deben tomar para los modelos de vehículos:
· Monitorear amenazas a la seguridad, detectar y prevenir ataques a la red ·
Tener capacidades de análisis forense de datos para respaldar el análisis de intentos o ataques exitosos a la red.
● 7.3.8 El módulo de cifrado debe cumplir con el estándar de consenso:
· Si el módulo de cifrado utilizado no cumple con el estándar de consenso, el fabricante del vehículo debe justificar su uso.
3.1.6 Lista de verificación de mitigación de amenazas y respuestas R155
El Apéndice 5 de R155 es "Lista de verificación de mitigación de amenazas y respuestas".
Este anexo consta de tres partes.
La Parte A describe la línea base de amenazas, vulnerabilidades y métodos de ataque.
La Parte B describe medidas para mitigar las amenazas contra los tipos de vehículos.
La Parte C describe mitigaciones para amenazas dirigidas a áreas distintas al vehículo, como el backend de TI .
Parte A Lista de vulnerabilidades o métodos de ataque asociados con amenazas
| 4.3.1 Amenazas al servidor backend | 1 El servidor backend se utiliza como medio para atacar el vehículo o extraer datos. |
| 2 El servicio del servidor back-end se interrumpe, afectando el funcionamiento normal del vehículo. | |
| 3 Pérdida o divulgación de datos relacionados con el vehículo en servidores backend ("violación de datos") | |
| 4.3.2 Amenazas a los canales de comunicación de los vehículos | 4 El vehículo es engañado por la información o los datos recibidos. |
| 5 Uso de canales de comunicación para manipulación, eliminación u otra modificación no autorizada de códigos/datos en poder del vehículo | |
| 6 El canal de comunicación permite recibir o recibir mensajes que no son confiables/poco confiables o vulnerables a ataques de secuestro/repetición de sesión. | |
| 7 La información se filtra fácilmente. Por ejemplo, escuchando a escondidas las comunicaciones o permitiendo el acceso no autorizado a archivos o carpetas confidenciales. | |
| 8 Ataque de denegación de servicio que destruye funciones del vehículo a través de canales de comunicación | |
| 9 usuarios sin privilegios pueden obtener acceso privilegiado a los sistemas del vehículo | |
| 10 virus en el vector pueden infectar los sistemas de los vehículos | |
| 11 Los mensajes recibidos por el vehículo (por ejemplo, X2V o mensajes de diagnóstico) o transmitidos dentro del mismo contienen contenido malicioso | |
| 4.3.3 Vehículos en riesgo por actualizaciones | 12 Mal uso o destrucción de actualizaciones |
| 13 Posibilidad de rechazar actualizaciones legítimas | |
| 4.3.4 Amenazas a los vehículos causadas por comportamientos humanos no intencionales que pueden facilitar los ciberataques | 15 actores legítimos pueden facilitar ataques cibernéticos sin saberlo |
| 4.3.5 Amenazas a la conectividad y conexiones externas del vehículo | 16 Los ciberataques se pueden llevar a cabo a través de conexiones que manipulan las funciones del vehículo, incluida la telemática; sistemas que permiten la operación remota; y sistemas que utilizan comunicaciones inalámbricas de corto alcance. |
| 17 Software alojado de terceros, como aplicaciones de entretenimiento, utilizado como medio para atacar los sistemas del vehículo | |
| 18 Dispositivos conectados a interfaces externas, como puertos USB, puertos OBD, utilizados como medio para atacar los sistemas del vehículo | |
| 4.3.6 Amenazas a los datos/código del vehículo | 19 Extracción de datos/códigos del vehículo |
| 20 Manipulación de datos/códigos del vehículo | |
| 21 Borrar datos/código | |
| 22 Introducción de malware | |
| 23 Introducir nuevo software o sobrescribir software existente | |
| 24 Interrupción del sistema o del funcionamiento | |
| 25 Manipulación de parámetros del vehículo | |
| 4.3.7 Vulnerabilidades potenciales que podrían explotarse si no se protegen o refuerzan adecuadamente | 26 La criptografía puede estar comprometida o no aplicada |
| 27 Piezas o suministros podrían verse comprometidos, permitiendo que el vehículo sea atacado | |
| 28 Vulnerabilidades en el desarrollo de software o hardware | |
| 29 El diseño de red introduce vulnerabilidades | |
| 31 Pueden ocurrir transferencias de datos inesperadas | |
| 32 La manipulación física del sistema puede desencadenar un ataque |
Para las vulnerabilidades/amenazas de ataque en la figura anterior, R155 dio muchos ejemplos. Las "Partes B" y "Parte C" posteriores también analizan formas de defenderse/mitigar vulnerabilidades/amenazas.
| Descripciones de alto nivel y subnivel de vulnerabilidad/amenaza |
Ejemplo de vulnerabilidad o método de ataque |
|||
| Servidores back-end utilizados como medio para atacar un vehículo o extraer datos |
1.1 |
Abuso de privilegios por parte del personal ( ataque interno ) |
||
| 1.2 |
Acceso a Internet no autorizado al servidor (habilitado, por ejemplo, por puertas traseras, vulnerabilidades de software del sistema sin parches, ataques SQL u otros medios) |
|||
| 1.3 |
Acceso físico no autorizado al servidor (realizado, por ejemplo, mediante memorias USB u otros medios conectados al servidor) |
|||
| Los servicios del servidor back-end se interrumpen, lo que afecta el funcionamiento de un vehículo |
2.1 |
Un ataque al servidor back-end deja de funcionar , por ejemplo, le impide interactuar con los vehículos y proporcionar servicios de los que dependen. |
||
| Los datos relacionados con el vehículo almacenados en servidores back-end se pierden o se ven comprometidos ("violación de datos") |
3.1 |
Abuso de privilegios por parte del personal ( ataque interno) |
||
| 3.2 |
Loss of information in the cloud. Sensitive data may be lost due to attacks or accidents when data is stored by third-party cloud service providers |
|||
| 3.3 |
Unauthorized internet access to the server (enabled for example by backdoors, unpatched system software vulnerabilities, SQL attacks or other means) |
|||
| 3.4 |
Unauthorized physical access to the server (conducted for example by USB sticks or other media connecting to the server) |
|||
| 3.5 |
Information breach by unintended sharing of data (e.g. admin errors) |
|||
| Spoofing of messages or data received by the vehicle |
4.1 |
Spoofing of messages by impersonation (e.g. 802.11p V2X during platooning, GNSS messages, etc.) |
||
| 4.2 |
Sybil attack (in order to spoof other vehicles as if there are many vehicles on the road) |
|||
| Communication channels used to conduct unauthorized manipulation, deletion or other amendments to vehicle held code/data |
5.1 |
Communications channels permit code injection, for example tampered software binary might be injected into the communication stream |
||
| 5.2 |
Communications channels permit manipulate of vehicle held data/code |
|||
| 5.3 |
Communications channels permit overwrite of vehicle held data/code |
|||
| 5.4 |
Communications channels permit erasure of vehicle held data/code |
|||
| 5.5 |
Communications channels permit introduction of data/code to the vehicle (write data code) |
|||
| Communication channels permit untrusted/unreliable messages to be accepted or are vulnerable to session hijacking/replay attacks |
6.1 |
Accepting information from an unreliable or untrusted source |
||
| 6.2 |
Man in the middle attack/ session hijacking |
|||
| 6.3 |
Replay attack, for example an attack against a communication gateway allows the attacker to downgrade software of an ECU or firmware of the gateway |
|||
| Information can be readily disclosed. For example, through eavesdropping on communications or through allowing unauthorized access to sensitive files or folders |
7.1 |
Interception of information / interfering radiations / monitoring communications |
||
| 7.2 |
Gaining unauthorized access to files or data |
|||
| Denial of service attacks via communication channels to disrupt vehicle functions |
8.1 |
Sending a large number of garbage data to vehicle information system, so that it is unable to provide services in the normal manner |
||
| 8.2 |
Black hole attack, in order to disrupt communication between vehicles the attacker is able to block messages between the vehicles |
|||
| An unprivileged user is able to gain privileged access to vehicle systems |
9.1 |
An unprivileged user is able to gain privileged access, for example root access |
||
| Viruses embedded in communication media are able to infect vehicle systems |
10.1 |
Virus embedded in communication media infects vehicle systems |
||
| Messages received by the vehicle (for example X2V or diagnostic messages), or transmitted within it, contain malicious content |
11.1 |
Malicious internal (e.g. CAN) messages |
||
| 11.2 |
Malicious V2X messages, e.g. infrastructure to vehicle or vehicle-vehicle messages (e.g. CAM, DENM) |
|||
| 11.3 |
Malicious diagnostic messages |
|||
| 11.4 |
Malicious proprietary messages (e.g. those normally sent from OEM or component/system/function supplier) |
|||
| Misuse or compromise of update procedures |
12.1 |
Compromise of over the air software update procedures. This includes fabricating the system update program or firmware |
||
| 12.2 |
Compromise of local/physical software update procedures. This includes fabricating the system update program or firmware |
|||
| 12.3 |
The software is manipulated before the update process (and is therefore corrupted), although the update process is intact |
|||
| 12.4 |
Compromise of cryptographic keys of the software provider to allow invalid update |
|||
| It is possible to deny legitimate updates |
13.1 |
Denial of Service attack against update server or network to prevent rollout of critical software updates and/or unlock of customer specific features |
||
| Legitimate actors are able to take actions that would unwittingly facilitate a cyber-attack |
15.1 |
Innocent victim (e.g. owner, operator or maintenance engineer) being tricked into taking an action to unintentionally load malware or enable an attack |
||
| 15.2 |
Defined security procedures are not followed |
|||
| Manipulation of the connectivity of vehicle functions enables a cyber-attack, this can include telematics; systems that permit remote operations; and systems using short range wireless communications |
16.1 |
Manipulation of functions designed to remotely operate systems, such as remote key, immobilizer, and charging pile |
||
| 16.2 |
Manipulation of vehicle telematics (e.g. manipulate temperature measurement of sensitive goods, remotely unlock cargo doors) |
|||
| 16.3 |
Interference with short range wireless systems or sensors |
|||
| Hosted 3rd party software, e.g. entertainment applications, used as a means to attack vehicle systems |
17.1 |
Corrupted applications, or those with poor software security, used as a method to attack vehicle systems |
||
| Devices connected to external interfaces e.g. USB ports, OBD port, used as a means to attack vehicle systems |
18.1 |
External interfaces such as USB or other ports used as a point of attack, for example through code injection |
||
| 18.2 |
Media infected with a virus connected to a vehicle system |
|||
| 18.3 |
Diagnostic access (e.g. dongles in OBD port) used to facilitate an attack, e.g. manipulate vehicle parameters (directly or indirectly) |
|||
| Extraction of vehicle data/code |
19.1 |
Extraction of copyright or proprietary software from vehicle systems (product piracy) |
||
| 19.2 |
Unauthorized access to the owner’s privacy information such as personal identity, payment account information, address book information, location information, vehicle’s electronic ID, etc. |
|||
| 19.3 |
Extraction of cryptographic keys |
|||
| Manipulation of vehicle data/code |
20.1 |
Illegal/unauthorized changes to vehicle’s electronic ID |
||
| 20.2 |
Identity fraud. For example, if a user wants to display another identity when communicating with toll systems, manufacturer backend |
|||
| 20.3 |
Action to circumvent monitoring systems (e.g. hacking/ tampering/ blocking of messages such as ODR Tracker data, or number of runs) |
|||
| 20.4 |
Data manipulation to falsify vehicle’s driving data (e.g. mileage, driving speed, driving directions, etc.) |
|||
| 20.5 |
Unauthorized changes to system diagnostic data |
|||
| Erasure of data/code |
21.1 |
Unauthorized deletion/manipulation of system event logs |
||
| Introduction of malware |
22.2 |
Introduce malicious software or malicious software activity |
||
| Introduction of new software or overwrite existing software |
23.1 |
Fabrication of software of the vehicle control system or information system |
||
| Disruption of systems or operations |
24.1 |
Denial of service, for example this may be triggered on the internal network by flooding a CAN bus, or by provoking faults on an ECU via a high rate of messaging |
||
| Manipulation of vehicle parameters |
25.1 |
Unauthorized access of falsify the configuration parameters of vehicle’s key functions, such as brake data, airbag deployed threshold, etc. |
||
| 25.2 |
Unauthorized access of falsify the charging parameters, such as charging voltage, charging power, battery temperature, etc. |
|||
| Cryptographic technologies can be compromised or are insufficiently applied |
26.1 |
Combination of short encryption keys and long period of validity enables attacker to break encryption |
||
| 26.2 |
Insufficient use of cryptographic algorithms to protect sensitive systems |
|||
| 26.3 |
Using already or soon to be deprecated cryptographic algorithms |
|||
| Parts or supplies could be compromised to permit vehicles to be attacked |
27.1 |
Hardware or software, engineered to enable an attack or fails to meet design criteria to stop an attack |
||
| Software or hardware development permits vulnerabilities |
28.1 |
Software bugs. The presence of software bugs can be a basis for potential exploitable vulnerabilities. This is particularly true if software has not been tested to verify that known bad code/bugs is not present and reduce the risk of unknown bad code/bugs being present |
||
| 28.2 |
Using remainders from development (e.g. debug ports, JTAG ports, microprocessors, development certificates, developer passwords, …) can permit access to ECUs or permit attackers to gain higher privileges |
|||
| Network design introduces vulnerabilities |
29.1 |
Superfluous internet ports left open, providing access to network systems |
||
| 29.2 |
Circumvent network separation to gain control. Specific example is the use of unprotected gateways, or access points (such as truck-trailer gateways), to circumvent protections and gain access to other network segments to perform malicious acts, such as sending arbitrary CAN bus messages |
|||
| Physical loss of data | 30.1 | Damage caused by a third party. Sensitive data may be lost or compromised due to physical damages in cases of traffic accident or theft | ||
| 30.2 | Loss from DRM(digital right management)conflicts. User data may be deleted due to DRM issues | |||
| 30.3 | The(integrity of)sensitive data may be lost due to IT components wear and tear, causing potential cascading issues(in case of key alteration,for example) | |||
| Unintended transfer of data can |
31.1 |
Information breach. Personal data may be leaked when the car changes user (e.g. is sold or is used as hire vehicle with new hirers) |
||
| Physical manipulation of systems can enable an attack |
32.1 |
Manipulation of electronic hardware, e.g. unauthorized electronic hardware added to a vehicle to enable "man-in-the-middle" attack Replacement of authorized electronic hardware (e.g., sensors) with unauthorized electronic hardware Manipulation of the information collected by a sensor (for example, using a magnet to tamper with the Hall effect sensor connected to the gearbox) |
||
B 部分 减轻对车辆的威胁
B.1 缓解与"车辆通信通道"有关的威胁
| Table A1 reference |
Threats to "Vehicle communication channels" |
Ref |
Mitigation |
| 4.1 |
Spoofing of messages (e.g. 802.11p V2X during platooning, GNSS messages, etc.) by impersonation |
M10 |
The vehicle shall verify the authenticity and integrity of messages it receives |
| 4.2 |
Sybil attack (in order to spoof other vehicles as if there are many vehicles on the road) |
M11 |
Security controls shall be implemented for storing cryptographic keys (e.g., use of Hardware Security Modules) |
| 5.1 |
Communication channels permit code injection into vehicle held data/code, for example tampered software binary might be injected into the communication stream |
M10 M6 |
The vehicle shall verify the authenticity and integrity of messages it receives Systems shall implement security by design to minimize risks |
| 5.2 |
Communication channels permit manipulation of vehicle held data/code |
M7 |
Access control techniques and designs shall be applied to protect system data/code |
| 5.3 |
Communication channels permit overwrite of vehicle held data/code |
||
| 5.4 21.1 |
Communication channels permit erasure of vehicle held data/code |
||
| 5.5 |
Communication channels permit introduction of data/code to vehicle systems (write data code) |
||
| 6.1 |
Accepting information from an unreliable or untrusted source |
M10 |
The vehicle shall verify the authenticity and integrity of messages it receives |
| 6.2 |
Man in the middle attack / session hijacking |
M10 |
The vehicle shall verify the authenticity and integrity of messages it receives |
| 6.3 |
Replay attack, for example an attack against a communication gateway allows the attacker to downgrade software of an ECU or firmware of the gateway |
||
| 7.1 |
Interception of information / interfering radiations / monitoring communications |
M12 |
Confidential data transmitted to or from the vehicle shall be protected |
| 7.2 |
Gaining unauthorized access to files or data |
M8 |
Through system design and access control it should not be possible for unauthorized personnel to access personal or system critical data. Example of Security Controls can be found in OWASP |
| 8.1 |
Sending a large number of garbage data to vehicle information system, so that it is unable to provide services in the normal manner |
M13 |
Measures to detect and recover from a denial of service attack shall be employed |
| 8.2 |
Black hole attack, disruption of communication between vehicles by blocking the transfer of messages to other vehicles |
M13 |
Measures to detect and recover from a denial of service attack shall be employed |
| 9.1 |
An unprivileged user is able to gain privileged access, for example root access |
M9 |
Measures to prevent and detect unauthorized access shall be employed |
| 10.1 |
Virus embedded in communication media infects vehicle systems |
M14 |
Measures to protect systems against embedded viruses/malware should be considered |
| 11.1 |
Malicious internal (e.g. CAN) messages |
M15 |
Measures to detect malicious internal messages or activity should be considered |
| 11.2 |
Malicious V2X messages, e.g. infrastructure to vehicle or vehicle-vehicle messages (e.g. CAM, DENM) |
M10 |
The vehicle shall verify the authenticity and integrity of messages it receives |
| 11.3 |
Malicious diagnostic messages |
||
| 11.4 |
Malicious proprietary messages (e.g. those normally sent from OEM or component/system/function supplier) |
B.2 缓解与“更新过程”有关的威胁
| Table A1 reference |
Threats to "Update process" |
Ref |
Mitigation |
| 12.1 |
Compromise of over the air software update procedures. This includes fabricating the system update program or firmware |
M16 |
Secure software update procedures shall be employed |
| 12.2 |
Compromise of local/physical software update procedures. This includes fabricating the system update program or firmware |
||
| 12.3 |
The software is manipulated before the update process (and is therefore corrupted), although the update process is intact |
||
| 12.4 |
Compromise of cryptographic keys of the software provider to allow invalid update |
M11 |
Security controls shall be implemented for storing cryptographic keys |
| 13.1 |
Denial of Service attack against update server or network to prevent rollout of critical software updates and/or unlock of customer specific features |
M3 |
Security Controls shall be applied to back-end systems. Where back-end servers are critical to the provision of services there are recovery measures in case of system outage. Example Security Controls can be found in OWASP |
B.3 缓解与“人的意外行为导致网络攻击”有关的威胁
| Table A1 reference |
Threats relating to "Unintended human actions" |
Ref |
Mitigation |
| 15.1 |
Innocent victim (e.g. owner, operator or maintenance engineer) is tricked into taking an action to unintentionally load malware or enable an attack |
M18 |
Measures shall be implemented for defining and controlling user roles and access privileges, based on the principle of least access privilege |
| 15.2 |
Defined security procedures are not followed |
M19 |
Organizations shall ensure security procedures are defined and followed including logging of actions and access related to the management of the security functions |
B.4 减少与"外部连接"有关的威胁
| Table A1 reference |
Threats to "External connectivity and connections" |
Ref |
Mitigation |
| 16.1 |
Manipulation of functions designed to remotely operate vehicle systems, such as remote key, immobiliser, and charging pile |
M20 |
Security controls shall be applied to systems that have remote access |
| 16.2 |
Manipulation of vehicle telematics (e.g. manipulate temperature measurement of sensitive goods, remotely unlock cargo doors) |
||
| 16.3 |
Interference with short range wireless systems or sensors |
||
| 17.1 |
Corrupted applications, or those with poor software security, used as a method to attack vehicle systems |
M21 |
Software shall be security assessed, authenticated and integrity protected. Security controls shall be applied to minimise the risk from third party software that is intended or foreseeable to be hosted on the vehicle |
| 18.1 |
External interfaces such as USB or other ports used as a point of attack, for example through code injection |
M22 |
Security controls shall be applied to external interfaces |
| 18.2 |
Media infected with viruses connected to the vehicle |
||
| 18.3 |
Diagnostic access (e.g. dongles in OBD port) used to facilitate an attack, e.g. manipulate vehicle parameters (directly or indirectly) |
M22 |
Security controls shall be applied to external interfaces |
B.5 减轻与"攻击的潜在目标或动机"有关的威胁
| Table A1 reference |
Threats to "Potential targets of, or motivations for, an attack" |
Ref |
Mitigation |
| 19.1 |
Extraction of copyright or proprietary software from vehicle systems (product piracy / stolen software) |
M7 |
Access control techniques and designs shall be applied to protect system data/code. Example Security Controls can be found in OWASP |
| 19.2 |
Unauthorized access to the owner’s privacy information such as personal identity, payment account information, address book information, location information, vehicle’s electronic ID, etc. |
M8 |
Through system design and access control it should not be possible for unauthorized personnel to access personal or system critical data. Examples of Security Controls can be found in OWASP |
| 19.3 |
Extraction of cryptographic keys |
M11 |
Security controls shall be implemented for storing cryptographic keys e.g. Security Modules |
| 20.1 |
Illegal/unauthorised changes to vehicle’s electronic ID |
M7 |
Access control techniques and designs shall be applied to protect system data/code. Example Security Controls can be found in OWASP |
| 20.2 |
Identity fraud. For example, if a user wants to display another identity when communicating with toll systems, manufacturer backend |
||
| 20.3 |
Action to circumvent monitoring systems (e.g. hacking/ tampering/ blocking of messages such as ODR Tracker data, or number of runs) |
M7 |
Access control techniques and designs shall be applied to protect system data/code. Example Security Controls can be found in OWASP. Data manipulation attacks on sensors or transmitted data could be mitigated by correlating the data from different sources of information |
| 20.4 |
Data manipulation to falsify vehicle’s driving data (e.g. mileage, driving speed, driving directions, etc.) |
||
| 20.5 |
Unauthorised changes to system diagnostic data |
||
| 21.1 |
Unauthorized deletion/manipulation of system event logs |
M7 |
Access control techniques and designs shall be applied to protect system data/code. Example Security Controls can be found in OWASP. |
| 22.2 |
Introduce malicious software or malicious software activity |
M7 |
Access control techniques and designs shall be applied to protect system data/code. Example Security Controls can be found in OWASP. |
| 23.1 |
Fabrication of software of the vehicle control system or information system |
||
| 24.1 |
Denial of service, for example this may be triggered on the internal network by flooding a CAN bus, or by provoking faults on an ECU via a high rate of messaging |
M13 |
Measures to detect and recover from a denial of service attack shall be employed |
| 25.1 |
Unauthorized access to falsify configuration parameters of vehicle’s key functions, such as brake data, airbag deployed threshold, etc. |
M7 |
Access control techniques and designs shall be applied to protect system data/code. Example Security Controls can be found in OWASP |
| 25.2 |
Unauthorized access to falsify charging parameters, such as charging voltage, charging power, battery temperature, etc. |
B.6 减轻与“如果不充分保护或加固就可能被利用的潜在漏洞”有关的威胁
| Table A1 reference |
Threats to "Potential vulnerabilities that could be exploited if not sufficiently protected or hardened" |
Ref |
Mitigation |
| 26.1 |
Combination of short encryption keys and long period of validity enables attacker to break encryption |
M23 |
Cybersecurity best practices for software and hardware development shall be followed |
| 26.2 |
Insufficient use of cryptographic algorithms to protect sensitive systems |
||
| 26.3 |
Using deprecated cryptographic algorithms |
||
| 27.1 |
Hardware or software, engineered to enable an attack or fail to meet design criteria to stop an attack |
M23 |
Cybersecurity best practices for software and hardware development shall be followed |
| 28.1 |
The presence of software bugs can be a basis for potential exploitable vulnerabilities. This is particularly true if software has not been tested to verify that known bad code/bugs is not present and reduce the risk of unknown bad code/bugs being present |
M23 |
Cybersecurity best practices for software and hardware development shall be followed. Cybersecurity testing with adequate coverage |
| 28.2 |
Using remainders from development (e.g. debug ports, JTAG ports, microprocessors, development certificates, developer passwords, …) can permit an attacker to access ECUs or gain higher privileges |
||
| 29.1 |
Superfluous internet ports left open, providing access to network systems |
||
| 29.2 |
Circumvent network separation to gain control. Specific example is the use of unprotected gateways, or access points (such as truck-trailer gateways), to circumvent protections and gain access to other network segments to perform malicious acts, such as sending arbitrary CAN bus messages |
M23 |
Cybersecurity best practices for software and hardware development shall be followed. Cybersecurity best practices for system design and system integration shall be followed |
B.7 缓解与"车辆数据丢失/数据泄露"有关的威胁
| Table A1 reference |
Threats of "Data loss / data breach from vehicle" |
Ref |
Mitigation |
| 31.1 |
Information breach. Personal data may be breached when the car changes user (e.g. is sold or is used as hire vehicle with new hirers) |
M24 |
Best practices for the protection of data integrity and confidentiality shall be followed for storing personal data. |
B.8 减少与“通过物理操作系统来实现攻击”相关的威胁
| Table A1 reference |
Threats to "Physical manipulation of systems to enable an attack" |
Ref |
Mitigation |
| 32.1 |
Manipulation of OEM hardware, e.g. unauthorised hardware added to a vehicle to enable "man-in-the-middle" attack |
M9 |
Measures to prevent and detect unauthorized access shall be employed |
C部分 减轻车辆外部的威胁
C.1 缓解与“后端服务器”相关的威胁
| Table A1 reference |
Threats to "Back-end servers" |
Ref |
Mitigation |
| 1.1 & 3.1 |
Abuse of privileges by staff (insider attack) |
M1 |
Security Controls are applied to back-end systems to minimise the risk of insider attack |
| 1.2 & 3.3 |
Unauthorised internet access to the server (enabled for example by backdoors, unpatched system software vulnerabilities, SQL attacks or other means) |
M2 |
Security Controls are applied to back-end systems to minimise unauthorised access. Example Security Controls can be found in OWASP |
| 1.3 & 3.4 |
Unauthorised physical access to the server (conducted by for example USB sticks or other media connecting to the server) |
M8 |
Through system design and access control it should not be possible for unauthorised personnel to access personal or system critical data |
| 2.1 |
Attack on back-end server stops it functioning, for example it prevents it from interacting with vehicles and providing services they rely on |
M3 |
Security Controls are applied to back-end systems. Where back-end servers are critical to the provision of services there are recovery measures in case of system outage. Example Security Controls can be found in OWASP |
| 3.2 |
Loss of information in the cloud. Sensitive data may be lost due to attacks or accidents when data is stored by third-party cloud service providers |
M4 |
Security Controls are applied to minimise risks associated with cloud computing. Example Security Controls can be found in OWASP and NCSC cloud computing guidance |
| 3.5 |
Information breach by unintended sharing of data (e.g. admin errors, storing data in servers in garages) |
M5 |
Security Controls are applied to back-end systems to prevent data breaches. Example Security Controls can be found in OWASP |
C.2 减少与"非故意人类行为"有关的威胁
| Table A1 reference |
Threats relating to "Unintended human actions" |
Ref |
Mitigation |
| 15.1 |
Innocent victim (e.g. owner, operator or maintenance engineer) is tricked into taking an action to unintentionally load malware or enable an attack |
M18 |
Measures shall be implemented for defining and controlling user roles and access privileges, based on the principle of least access privilege |
| 15.2 |
Defined security procedures are not followed |
M19 |
Organizations shall ensure security procedures are defined and followed including logging of actions and access related to the management of the security functions |
C.3 缓解与"数据丢失的物理丢失"有关的威胁
| Table A1 reference |
Threats of "Physical loss of data" |
Ref |
Mitigation |
| 30.1 |
Damage caused by a third party. Sensitive data may be lost or compromised due to physical damages in cases of traffic accident or theft |
M24 |
Best practices for the protection of data integrity and confidentiality shall be followed for storing personal data. Example Security Controls can be found in ISO/SC27/WG5 |
| 30.2 |
Loss from DRM (digital right management) conflicts. User data may be deleted due to DRM issues |
||
| 30.3 |
The (integrity of) sensitive data may be lost due to IT components wear and tear, causing potential cascading issues (in case of key alteration, for example) |
应考虑对A、B和C部分进行风险评估，并由汽车制造商实施风险缓解措施。
在A部分中对高级漏洞及其相应的示例进行了索引 .在B部分和C部分的表中引用了相同的索引，将每种攻击/漏洞与相应的缓解措施列表联系起来。
威胁分析还应考虑可能的攻击影响。这些可以帮助确定风险的严重性，并识别额外的风险。可能的攻击影响包括:
(a)受影响车辆的安全操作;
(b)车辆功能停止工作;
(c)修改软件，改变性能;
(d)更改软件但无业务影响;
(e)违反数据完整性;
(f)违反数据保密性;
(g)资料缺乏;
(h)其他，包括犯罪。
SO21434标准定义了车辆网络安全的完整框架和产品网络安全生命周期的相关流程，对R155法规的落地起到支撑作用，尤其是有助于车辆制造商在供应链上实施CSMS要求。对于法规中的相关要求，可通过描述文件、技术文件、演示、审计等手段来证明。
3.2 R156
UN R156讨论的是软件升级与软件升级管理系统的统一规定。R156章节名字和R155基本一致。
3.2.1 R156 主要规定要求
R156的第七章是规定要求。
7.1 汽车厂商软件更新管理系统的要求
7.1.1 在初步评估时要验证的过程
列举了一些过程
7.1.2 汽车制造商应记录和存储下列信息，适用于特定车型的每次更新
描述汽车制造商用于软件更新的过程和用于证明其合规性的任何相关标准的文件;
在更新之前和之后描述任何相关类型批准系统配置的文件，这应包括类型批准系统的硬件和软件(包括软件版本)的唯一标识，以及任何相关的车辆或系统参数;
对于每个RXSWIN，在更新之前和之后，都应该有一个可审计的寄存器，描述与车辆类型的RXSWIN相关的所有软件。这应包括每个RXSWIN的所有相关软件的软件版本信息及其完整性验证数据。
列出用于更新的目标车辆的文档，并确认这些车辆的最新配置与更新的兼容性。
该车型所有软件更新的文档说明如下:
(a)更新的目的;
(b)更新后会影响车辆的哪些系统或功能;
(c)其中哪些型号是经批准的(如有);
(d)如适用，软件更新是否影响该类型核定系统的任何有关要求的履行;
(e)软件更新是否影响任何系统类型批准参数;
(f)是否要求核可机构核可更新情况;
(g)如何执行更新以及在什么条件下执行更新;
(h)确认软件更新将安全可靠地进行;
(i)确认软件更新已经完成并成功通过了验证和验证程序。
7.2. 车辆类型的要求
7.2.1.软件更新的要求
7.2.2. OTA更新的附加要求
车辆制造商应确保车辆在更新失败或中断时能够将系统恢复到以前的版本，或者在更新失败或中断后能够将车辆置于安全状态。
车辆制造商应确保只有在车辆有足够的功率完成更新过程时才能进行软件更新
(包括可能恢复到以前版本或使车辆处于安全状态所需要的)。
当执行更新可能会影响车辆的安全时，车辆制造商应演示如何安全执行更新。
这应该通过技术手段来实现，确保车辆处于可以安全执行更新的状态。
车辆制造商应证明车辆用户能够在执行更新之前被告知更新。提供的资料应包括:
(a)更新的目的。这可能包括更新的关键性，以及更新是否用于召回、安全和/或安全目的;
(b)车辆功能更新所作的任何改变;
(c)预计完成执行更新的时间;
(d)在更新执行期间可能无法使用的任何车辆功能;
(e)任何可帮助车辆使用者安全执行更新的指示;
在驾驶时执行更新可能不安全的情况下，汽车制造商应演示他们将如何:
(a)确保车辆在更新执行期间不能驾驶;
(b)确保司机不能使用任何会影响车辆安全或成功执行更新的车辆功能
执行更新后，汽车制造商应演示如何执行以下内容:
(a)车辆使用者能够被告知更新的成功(或失败);
(b)车辆用户能够被告知已实施的更改和用户手册的任何相关更新(如适用)
在执行软件更新之前，车辆应确保满足前提条件。
4 总结
汽车的信息安全已经从符合标准进入到遵从法规的时代，必须要将信息安全贯穿于汽车的全生命周期。