Blog de Internet Security Auditors: Ciberseguridad en los coches inteligentes: Pasado, Presente y Futuro

Escrito por Internet Security Auditors | Dec 1, 2017 5:00:00 AM

Se habla mucho del término ciberseguridad, y, de hecho, cada vez es más popular. Los consumidores, así como los fabricantes, son cada vez más conscientes de que la seguridad es un elemento muy importante para tener en consideración cada vez que se realiza una compra de un producto tecnológico conectado a Internet.

Y no, no estamos hablando solamente de teléfonos móviles, ordenadores, televisiones y/o servidores, ya que la era ‘smart’ añadida a todo lo imaginable e inimaginable que queda por llegar, de la mano de la ‘Internet of Things’, comprende un abanico cada vez más grande de componentes.

Al comprar un coche ya no nos fijamos solamente en el motor, la aerodinámica, el consumo, la comodidad que ofrece, la reputación de la marca etc. sino que cada vez más nos fijamos también en las prestaciones tecnológicas, y es en dichas prestaciones, donde se debe hacer hincapié por lo que incumbe a la seguridad informática.

Los hackeos de coches más sonados hasta el momento hacen referencia a dos marcas, Jeep (propiedad de Fiat Chrysler) y Tesla. Y lo que no debería ser noticia, pero lo es, es la actuación de dichas empresas al conocer las brechas de seguridad, como veremos más adelante.

Claro está que la seguridad debe ser tomada por igual en todos los campos, aun así, cuando una intrusión no deseada puede causar un daño físico, tendríamos que ser aún más prudentes y proactivos, y no hablo solamente de los fabricantes, sino también de los consumidores. El ejemplo que expongo en dicho artículo son los coches inteligentes, analizando los recientes acontecimientos ocurridos y las medidas tomadas por parte de los fabricantes, los gobiernos, entidades y otro tipo de agencias y organizaciones con el fin de dar una salida a la situación actual.

Nociones básicas

Antes de empezar, es necesario describir algunos conceptos que serán mencionados a lo largo del artículo, para facilitar la lectura y comprensión de éste al lector.

Bus CAN: Se trata de un protocolo de comunicaciones basado en una topología bus para la retransmisión de mensajes o intercambio de información en entornos distribuidos. Las características de este sistema son varias, entre ellas destacan la priorización de mensajes, la garantía de tiempos de latencia, la flexibilidad en la configuración, recepción multicast con sincronización de tiempo y la retransmisión automática de mensajes corruptos cuando el bus se encuentra nuevamente disponible. [1] Todos los elementos tecnológicos del vehículo se conectan a un mismo cable [2], y cualquier elemento puede mandar mensajes. El resto de elementos los escuchan, si el mensaje no es de interés, simplemente lo ignoran.

Unidad central del vehículo: Una unidad de control del vehículo o más comúnmente conocida por sus siglas en inglés Engine Unit Control (ECU) actúa como cerebro del coche. Se utilizan para monitorear y controlar funciones del coche como por ejemplo la posición del pedal de aceleración, para determinar el volumen de combustible a inyectar en el motor, de las transmisiones, y de funciones relacionadas con las ventanas, el bloqueo de puertas, el techo solar etc. [3] Así pues, son un elemento imprescindible para el funcionamiento del vehículo.

Actualización OTA: Distribución de nuevas versiones de software realizadas mediante conexiones inalámbricas.

Vulnerabilidad 0-Day: Se trata de una vulnerabilidad desconocida, indetectable, que se puede utilizar para materializar ataques informáticos. En este caso de vulnerabilidades no existe parche alguno para evitar el aprovechamiento, y, por lo tanto, se está expuesto hasta la aparición de actualizaciones, parches de seguridad o similares. [4]

Fiat Chrysler

El primer hackeo que menciono en el artículo es el realizado a la marca Jeep, modelo Cherokee, en el año 2015. El hackeo se llevó a cabo por un equipo formado por dos referentes en la investigación de coches inteligentes, Charlie Miller y Chris Valasek. Además, Miller y Valasek realizaron toda la investigación utilizando su tiempo libre, después de cumplir con sus obligaciones familiares y laborales.

Para poder realizar la intrusión al vehículo, era necesario obtener conexión con este. En este caso, los investigadores intentaron conectarse al vehículo mediante la conexión Wi-Fi, algo que no resultó ser demasiado difícil dado que la contraseña se genera de forma automática, basándose en la fecha de puesta en marcha del coche y del sistema multimedia. Si se conoce el año de fabricación del coche, las posibles contraseñas se ven reducidas.

Pero el Wi-Fi del coche, que solamente se encuentra disponible bajo suscripción del propietario del coche con la marca, no es la única vía de intrusión. La unidad central del coche se encuentra conectada a la red móvil de Sprint. Así que Miller y Valasek se pusieron manos a la obra para determinar si se podía realizar algún tipo de intrusión que afectase a un mayor número de vehículos, y así fue. Compraron una estación móvil y se introdujeron en la red interna de Sprint. Una vez dentro, realizaron un escaneo masivo de direcciones IP escuchando algunas llamadas en concreto. De este modo, consiguieron localizar todos los coches Chrysler equipados con el mismo tipo de unidad central.

Una vez ganado el acceso al sistema multimedia era esencial determinar si se podían enviar mensajes CAN, mensajes que interconectan todos los componentes esenciales de un vehículo. La raíz de la cuestión es: ¿se encuentra interconectado el D-BUS directamente con los componentes multimedia? La respuesta es no pero sí. Directamente no se encuentran conectados, pero indirectamente sí. Y os preguntaréis, ¿desde este elemento intermedio se podían enviar mensajes CAN para, por ejemplo, mover el volante? Pues no, solamente permitía la lectura de mensajes CAN.

El elemento intermedio que permitió dicho acceso indirecto con el D-BUS es el controlador V850. El firmware, accesible en Internet, NO se encontraba firmado ni tampoco tenía firma de código… De modo que se podía hacer ‘cualquier cosa’ con él. Los investigadores lo modificaron con una puerta trasera, y después, lo instalaron como actualización en el vehículo.

Una vez aplicada dicha actualización maliciosa, los investigadores ganaron acceso a cada uno de los componentes del coche, incluyendo elementos cruciales como el volante, el motor, la transmisión, el sistema de frenado etc. mediante el envío de mensajes CAN.

Los investigadores facilitaron la información al fabricante del vehículo el 24 de octubre de 2014, aun así, no se dio una solución al problema hasta el 24 de julio de 2015. ¿Y si en este tiempo algún grupo de ciberdelincuentes hubiera tenido el conocimiento suficiente para llevarlo a cabo? La respuesta podría ser dramática… El modo de parcheo de los vehículos también es curioso, pues se tuvieron que enviar los vehículos a los talleres; puede ser más una cuestión de imagen que de necesidad. Además, si ya dispones de una solución, ¿por qué esperar a que el propietario lleve el vehículo al taller y no aplicar el parcheo vía OTA?

A continuación, puede verse el vídeo de demostración:

Fuente : https://www.youtube.com/watch?v=MK0SrxBC1xs

Pasado un año, en 2015, los mismos investigadores volvieron a tomar el control del vehículo. [5] En este caso, el ataque no se pudo realizar mediante Internet, sino que fue necesario conectarse físicamente al BUS CAN del coche, gracias al puerto presente debajo del cuadro de mandos. Entre otras cosas, se consiguió cambiar el ángulo de las ruedas en 90 grados, y controlar los pedales del gas y del freno.

Tesla

Otro ejemplo de car hacking, puede ser el hackeo realizado a un Tesla, modelo S, el año 2016. Sí, hackearon ni más ni menos que un Tesla. La hazaña fue realizada por unos investigadores chinos de la empresa Keen Security, que encontraron vulnerabilidades que permitieron controlar el coche de forma remota, en el modo conducción y en el modo de aparcamiento. El resultado desencadenó en el control del techo solar, los intermitentes del vehículo, la posición del sillín o la apertura de las puertas. En el modo conducción, tomaron control de los limpiaparabrisas, de los retrovisores, de la apertura del maletero y del sistema de frenado [6], entre otros.

Los investigadores facilitaron todos los descubrimientos a Tesla mediante el Tesla Bug Bounty Program, que ofrece recompensas de 100$ hasta 10.000$ por vulnerabilidad [7].

Para corregir los bugs, Tesla lanzó una nueva actualización en solamente 10 días desde que tuvo noticia de las vulnerabilidades, que no solo solucionaba las dos vulnerabilidades explotadas (una en el navegador del vehículo, basado en el framework WebKit y otra en el sistema Linux [8]), sino que también añadió la firma de código con una clave criptográfica, que se encuentra únicamente bajo posesión y conocimiento de la propia Tesla. La distribución de la actualización se realizó vía OTA, de modo que no fue necesario llevar el vehículo a ningún taller.

A continuación, puede visualizarse el vídeo de demostración del hackeo realizado:

Fuente: https://www.youtube.com/watch?v=c1XyhReNcHY

El mismo equipo de investigadores volvió a hackear coches Tesla este año. La investigación realizada en 2017 resultó en un ataque similar al realizado en el año 2016, que permitió implementar código arbitrario al BUS CAN y a los controles remotos de la unidad central del vehículo. El equipo de KeenLab se saltó la firma de código implementada por Tesla en la actualización promovida debido al anterior hackeo y descubrió múltiples vulnerabilidades 0-Day en distintos módulos [9]. Tesla emitió un comunicado notificando que se había dado respuesta de forma inmediata a todas las vulnerabilidades encontradas por dicho equipo de investigación, liberando una nueva actualización vía OTA, en este caso la versión 8.1, 17.26.0+, dejando claro que no tienen constancia de que ningún cliente se haya visto afectado por dichas vulnerabilidades y agradeciendo el trabajo realizado por los investigadores. [10]

A continuación, puede visualizarse el vídeo de demostración del hackeo realizado:

Fuente: https://www.youtube.com/watch?v=5jQAX4540hA

Lo que nos queda por llegar

El auge, no solamente de los coches conectados, sino también de los coches autónomos, llevará consigo nuevas vías de ataque para este tipo de vehículos. Un ejemplo claro es el llevado a cabo por investigadores de las universidades de Washington, Michigan, Stony Brook y Berkeley, quienes han descubierto la forma de hackear vehículos autónomos modificando las señales de tráfico, poniéndoles pegatinas. [11] Los métodos utilizados van desde superposición de un póster encima de una señal real, con algunas áreas difuminadas con spray, hasta la inclusión de las pegatinas anteriormente mencionadas. La utilización de un póster provocó, dependiendo del ángulo de visión y de la distancia, la confusión de la señal de STOP con una de limitación de velocidad. La inclusión de pegatinas en la señal, formando palabras de “LOVE” y “HATE” provocó que la inteligencia artificial del vehículo interpretara, según la situación, una señal de limitación de velocidad o de ceda el paso.

Incluyendo la seguridad como elemento fundamental

Una vez analizada la situación actual, y viendo la envergadura de los ataques realizados, quizás nos deberíamos preguntar cómo es posible que se haya llegado hasta aquí. Y la respuesta a dicha pregunta es bien simple, porqué la industria del automóvil empezó a incorporar novedades tecnológicas, haciendo los coches cada vez más inteligentes e interconectados, sin modificar su guion de actuación. Claro está que, antes de introducir nuevas prestaciones, deberían ser analizadas todas las consecuencias que pudieren producirse, pero, en este caso, no se tomaron todas las medidas ni se modificaron los estándares, procedimientos, guías y, en definitiva, el conjunto de marcos normativos empleados por la industria con tal fin.

Esto es lo que nos ha llevado a la situación actual. Y ahí estamos. La seguridad informática no se tomó como un elemento fundamental en los procesos de desarrollo de los nuevos vehículos ni sus servicios asociados. Los gobiernos también se han percatado de este hecho, y antes de tener que arrepentirse de alguna desgracia, ya han empezado a promover buenas prácticas, por lo que a seguridad informática se refiere, para la industria del automóvil.

En Estados Unidos, la National Highway Traffic Safety Administration publicó, en octubre de 2016, un conjunto de buenas prácticas para la industria automovilística con el fin de mejorar la seguridad de los vehículos. [12] Los pilares de dicho documento y su contenido incluyen, pero no se limitan a:

- Intercambio de información: El intercambio de información y la colaboración entre fabricantes, ONG, departamentos ejecutivos, agencias y otras entidades sobre riesgos e incidentes relacionados con la ciberseguridad. Con este fin, no solamente se han tomado medidas en Estados Unidos con la creación, a finales de 2015, del centro de análisis e intercambio de información de la automoción (Auto ISAC), ya que en Europa se creó el CarSEC, un grupo de trabajo para el intercambio de información relacionada con amenazas, retos y soluciones con el fin de proteger la seguridad de los ciudadanos.

Sobre el Auto ISAC, que se encuentra operativo desde enero de 2016, en julio del mismo año presentó una guía de buenas prácticas de ciberseguridad para la industria del automóvil.

- Reporte de vulnerabilidades y la política de divulgación: Se especifica que los miembros de la industria automovilística deberían crear sus propias políticas, o adoptar políticas utilizadas en otros sectores y/o estándares técnicos para facilitar a los investigadores en ciberseguridad cómo debe realizarse el proceso de dicha divulgación.

- Proceso de respuesta ante incidentes: Se especifica que la industria automovilística debería documentar procesos ante la respuesta de incidentes, vulnerabilidades y el aprovechamiento de estas. Dichos procesos deberían cubrir la evaluación de impactos, la contención, la recuperación, así como el conjunto de acciones de remediación, y las pruebas asociadas. Se tiene que incluir el reporte de todos los incidentes, el aprovechamiento de estas y las vulnerabilidades a el Auto ISAC, el US-CERT y a los CERT de los sistemas de control industriales.

- Auditoria: Deberían documentarse todos los procesos de ciberseguridad, para permitir la auditoría y la rendición de cuentas. Dicha documentación debe incluir:

Evaluación del riesgo
Las vulnerabilidades y los potenciales impactos tienen que ser analizados, teniendo en consideración toda la cadena de distribución de operaciones. Al menos, se tienen que cubrir las redes internas de los vehículos, las redes inalámbricas externas, y cualquier interface de las ECU.

Pruebas de penetración y documentación
Se tendrían que realizar pruebas de penetración, incluyendo las fases de selección de los probadores, que no deben formar parte del equipo de desarrolladores. El reporte, al menos, deberá identificar a los probadores, sus calificaciones y sus recomendaciones, así como una disposición con el conjunto de vulnerabilidades detectadas. Siempre que una vulnerabilidad sea solucionada, los detalles también tendrán que documentarse. En cambio, si una vulnerabilidad no es solucionada, se tendrá que justificar la aceptación del riesgo inherente a dicha vulnerabilidad.

Auto revisión
Se tendrían que establecer procedimientos para la revisión interna de la documentación de todas las actividades en relación con la ciberseguridad. Un ejemplo de enfoque sería la realización de informes anuales que contemplen el estado actual de todos los controles de ciberseguridad implementados, los descubrimientos realizados a partir de las actividades de auditoría y el estado de mantenimiento de los registros.

- Protecciones de seguridad fundamentales:
Las buenas prácticas incluyen un conjunto de acciones que pueden ayudar a mover la industria automovilística hacía una postura de concienciación ante la seguridad. A continuación, se enumeran las acciones:

Limitar el acceso de desarrollador para todos los dispositivos en producción
No permitir el acceso, por parte de los desarrolladores, a las ECU de los vehículos desplegados en caso de no existir una justificación operacional. Además, se establece que los accesos a la ECU deberían ser facilitados mediante un puerto de depuración o una consola serial.

Claves de control

Controlar el acceso de diagnóstico utilizado en el mantenimiento
Las características de diagnóstico deberían ser desarrolladas específicamente para el modo de evaluación del vehículo, acorde con las limitaciones técnicas que este posea, con el fin de limitar las consecuencias que pudiere tener un mal uso de estas en un entorno real.

Controlar el acceso al firmware
Se debería evitar, en la medida de lo posible, que terceras partes pudieren obtener el firmware sin cifrar durante la actualización del software.

Limitar la capacidad de modificar el firmware

Controlar la proliferación de puertos, protocolos y servicios de red

Uso de técnicas de segmentación y de aislamiento en el diseño de la arquitectura de los vehículos

Controlar las comunicaciones internas de los vehículos

Registro de eventos

Control de la comunicación realizada hacía servidores de Back-End

Control de interfaces inalámbricas

Algunas otras consideraciones hacen referencia a la educación, para que los fabricantes, distribuidores y otros stakeholders trabajen conjuntamente con la NHTSA con el fin de promocionar medidas formativas para todo el conjunto de trabajadores y futuros trabajadores, en campos técnicos y no técnicos. También menciona otros aspectos como la protección de todos los dispositivos conectados al vehículo dado que pueden tener un impacto en la seguridad de los vehículos, entre otras.

En el mismo sentido, el gobierno del Reino Unido ha publicado recientemente, en agosto de 2017, un conjunto de principios clave para mejorar la seguridad de los vehículos, titulado: “ The Key Principles of Cyber Security for Connected and Automated Vehicles.” [13] El contenido del documento incluye, pero no se limita a:

- Principio 1: La seguridad organizativa es propietaria, gobernada y promocionada al nivel de la junta directiva.

Existencia de un programa de seguridad alineado con la misión y los objetivos de la organización.
Las responsabilidades del personal se llevan a cabo a nivel de la junta directiva.
Se implementan un conjunto de concienciaciones y formaciones para incorporar una cultura de la seguridad.
Los nuevos diseños deben adoptar la seguridad por diseño.

- Principio 2: Los riesgos de seguridad deben ser evaluados y gestionados de forma apropiada y proporcional, incluyendo aquellos específicos a la cadena de suministro.

Las organizaciones tienen que requerir conocimientos y entendimiento de las amenazas actuales.
Las organizaciones colaboran y trabajan con terceras partes para enriquecer la concienciación ante amenazas y una planificación de respuesta apropiada.
Los procesos de evaluación y gestión de los riesgos de seguridad se llevan a cabo en la organización.
Los riesgos de seguridad específicos y/o con afectación a las cadenas de suministro, los subcontratados y los proveedores de servicios son identificados y gestionados mediante el diseño, la especificación y la adquisición de prácticas.

- Principio 3: Las organizaciones deben tener un cuidado posterior del producto, y la respuesta ante incidentes para asegurar que los sistemas sean seguros durante todo su tiempo de vida.

Las organizaciones tienen un plan de cómo mantener la seguridad durante el tiempo de vida de sus sistemas.
Se llevan a cabo planes de respuesta ante incidentes.
Programa para identificar vulnerabilidades críticas.
Las organizaciones aseguran que sus sistemas están preparados para realizar forenses de datos.

- Principio 4: Todas las organizaciones, incluyendo los sub contratados, los distribuidores y las terceras partes deben trabajar conjuntamente para mejorar la seguridad del sistema.

Las organizaciones, incluyendo los suministradores y las terceras partes, tienen que ser capaces de asegurar la seguridad de sus procesos y productos (ya sea física, personal y cyber).
Establecer y validar la autenticidad de todos los suministradores.
Las organizaciones planifican conjuntamente cómo el sistema interactuará de forma segura con los dispositivos externos.
Las organizaciones gestionan e identifican todas las dependencias externas.

- Principio 5: Los sistemas son diseñados utilizando un enfoque de defensa en profundidad.

La seguridad del sistema no recae en puntos de falla únicos.
La arquitectura de seguridad aplica técnicas de defensa en profundidad y de segmentación.
Establecimiento de controles para mediar las transacciones a través de perímetros de confianza: acceso basado en el mínimo privilegio, encriptación completa del disco, minimización de los datos almacenados en la nube…
Los sistemas remotos y de back-end que pudieren proveer acceso al sistema tienen unos niveles apropiados de protección y monitoreo para prevenir accesos no autorizados.

- Principio 6: La seguridad de todo el software es gestionada durante su tiempo de vida.

Las organizaciones adoptan prácticas de codificación seguras.
Debe ser posible comprobar el estado de todo el software, el firmware y sus respectivas configuraciones.
Es posible actualizar el software de forma segura.
El software adopta prácticas de diseño abiertas y la revisión por pares es utilizada siempre que se puede.

- Principio 7: El almacenamiento y la transmisión de datos es seguro y puede ser controlado.

Los datos tienen que ser almacenados y transmitidos de forma segura, de modo que solamente el receptor real, o funciones del sistema, sean capaces de recibirlo y/o accederlo.
Los datos personales identificables tienen que ser gestionados de una manera apropiada.
Los usuarios pueden eliminar datos sensibles.

- Principio 8: El sistema es diseñado para ser robusto ante ataques y responder de forma apropiada cuando sus defensas y/o sensores fallan.

Los sistemas tienen que resistir la recepción de datos corruptos o inválidos, así como comandos y datos maliciosos a través de sus interfaces, internas y externas, y permanecer disponibles para su uso primario.
Los sistemas son robustos y seguros ante fallas en caso de que funciones de seguridad críticas sean comprometidas o paren de funcionar.

La Agencia de la Unión Europea para la Seguridad de la Información y las Redes (ENISA) publicó, en diciembre de 2016, un estudio titulado Ciberseguridad y Resistencia de los Coches Inteligentes. [14] Dicho estudio no solamente introduce un conjunto de buenas prácticas y recomendaciones, sino que además analiza el estado actual de la situación, incluyendo las amenazas que podrían tener los coches conectados, las posibles vías de explotación y las consecuencias de esta explotación. A continuación, se explican los diferentes escenarios de ataque contemplados:

-Ataque remoto

Este tipo de ataque explota vulnerabilidades en las interfaces funcionales externas, relacionadas con la telemática o el entretenimiento informativo. Las ECU conectadas podrían ser utilizadas en una gran variedad de usos funcionales, todos ellos suponiendo un posible punto de entrada para dichos ataques.

El escenario de ataque podría seguir los siguientes pasos:

Identificación de un coche vulnerable.
Ganancia de acceso a los servicios internos.
Acceso a los sistemas del vehículo.

-Alteración persistente del vehículo

Este tipo de ataque podría consistir en:

La ganancia de una conexión directa con los componentes de un vehículo, para posteriormente intentar alterar, de forma persistente, la conducta de una ECU.
El uso de equipamiento relacionado con el diagnóstico del vehículo, con el fin de explotar vulnerabilidades para alterar la conducta de una ECU.

El escenario de ataque podría seguir los siguientes pasos:

Obtener una conexión directa con los componentes del vehículo u obtener de forma legítima o ilegítima el equipamiento de diagnóstico del vehículo.
Mediante la conexión a la red CAN del vehículo, obtener acceso a los componentes del sistema.

-Robo

Este tipo de ataque puede tener distintos escenarios, que se listan a continuación:

Redes inalámbricas locales comprometidas.
Copia del llavero.
Ataques de equipos sin llave (coches que se abren y cierran con aplicaciones de smartphones etc).
Ataques de relay.
…

-Vigilancia

La vigilancia puede realizarse de distintas formas:

Vigilancia con un objetivo fijado, mediante la explotación de una vulnerabilidad en los sistemas del vehículo afectado.
Vigilancia masiva, mediante la explotación de una vulnerabilidad común en los vehículos afectados.

Los vectores de ataque podrían ser los siguientes:

Emisiones inalámbricas: Wi-Fi, Bluetooth, redes móviles etc.
Almacenamiento en la nube que recolecte la información de posición de un conjunto de vehículos.

Las recomendaciones hacen referencia a los siguientes temas:

Mejorar la ciberseguridad de los vehículos inteligentes.
Mejorar el intercambio de información entre los diferentes actores de la industria.
Clarificar las responsabilidades de los actores de la industria.
Conseguir un consenso sobre las buenas prácticas y los estándares técnicos.
Definir un sistema de evaluación independiente por parte de terceros.
Construir herramientas que permitan realizar análisis de seguridad.
Mejorar el intercambio de información entre los investigadores de seguridad y las terceras partes.

Para finalizar el análisis de dicho documento, se lista, en la siguiente figura, el conjunto de buenas prácticas propuesto. Se categorizan en:

Políticas y estándares.
Medidas organizacionales.
Medidas técnicas.

Figura 1 : Buenas prácticas (Fuente: Enisa)

Los anteriores documentos no son los únicos que han abordado el debate de la ciberseguridad en los vehículos conectados e incluso existe una política federal en Estados Unidos que va un poco más allá, y se centra directamente en los coches autónomos [15].

Agencia Europea de Ciberseguridad

Además, en la revisión del presente artículo, se realizó el discurso de estado de la Unión Europea 2017 [16]. Dicho discurso hace referencia a la creación de la Agencia de Ciberseguridad Europea, un organismo que debería asistir a combatir los ciberataques en todos los Estados miembros. Además, el nuevo sistema europeo de certificación tiene la intención de garantir que los productos y servicios sean seguros para su uso.

Es realmente destacable la declaración de Federica Mogherini, alta representante y vice presidenta, que mencionó: “La Unión Europea perseguirá una política de ciberseguridad internacional, promoviendo un ciberespacio libre, abierto y seguro […]”.

La Agencia de Ciberseguridad Europea organizará y/o facilitará, entre otras, las siguientes actividades:

Ejercicios de ciberseguridad paneuropeos.
Intercambio de conocimiento y amenazas, mediante la habilitación de centros de intercambio de información.
Ayudará al desarrollo de la directiva sobre la seguridad de la red y los sistemas de información.
Implementará el nuevo marco de certificación europeo, para asegurar que los productos y los servicios sean seguros.

Para el presente artículo, es destacable la parte del marco de certificación, dado que tiene como objetivo la certificación de los dispositivos y equipos TIC, incluyendo los dispositivos IoT. Desde los que gestionan infraestructuras críticas relacionadas con las redes de transporte y la energía, hasta los de consumidor final, como por ejemplo coches conectados.

En la propuesta de regulación para la Agencia de Cibersuguridad Europea se detallan más aspectos del dicho marco [17]. El propósito general es dar fe de que los productos y servicios certificados cumplen con los requerimientos de ciberseguridad especificados. Por ejemplo, esto incluiría la capacidad de proteger los datos (en su almacenamiento, transmisión y procesamiento) frente a un almacenamiento, procesado, acceso, exfiltración, destrucción, pérdida o modificación no autorizados o accidentales. Los marcos Europeos harán uso de estándares de requerimientos técnicos y procesos de evaluación existentes.

Todos aquellos marcos y/o procedimientos nacionales de certificación para productos y servicios TIC, cubiertos por el marco de certificación Europeo, dejarán de aplicarse a partir de la fecha establecida en las actas de ejecución aprobadas por el susodicho marco Europeo. En la propuesta se establece que los Estados Miembros serán los encargados de las tareas de monitorización, supervisión y cumplimiento, mediante una autoridad nacional de supervisión de certificaciones.

Los marcos de certificación serán preparados por ENISA; con asistencia de expertos y en cooperación con el European Cybersecurity Certification Group, y serán adoptados por la Comisión mediante actas de ejecución.

Finalmente, mencionar que la certificación de ciberseguridad Europea será voluntaria, a no ser que se prevea el caso contrario en la legislación de la Unión, en relación con los requisitos de seguridad de los servicios y dispositivos TIC.

Conclusiones

Para cualquier industria que tenga relación con el IoT, es extremadamente importante, esencial e imprescindible tomar la seguridad como uno de los factores clave del producto. Por supuesto que, si hablamos de coches, estos tienen que tener un buen motor, diseño, consumo, prestaciones etc. pero su seguridad debe ser óptima en cada momento, y con esto me refiero no solo en el momento de materializar la compra, sino también durante la vida del vehículo. Y es que ya es muy común que en otros campos IoT, como por ejemplo las televisiones inteligentes, los equipos dejen de recibir actualizaciones pasado un tiempo. Si tienes un coche que vale un ‘pastizal’ y que hoy es ‘una pasada’, pero pasados dos años deja de ofrecerte actualizaciones de seguridad de la totalidad o alguno de sus elementos, y se van descubriendo nuevas vulnerabilidades, que con el tiempo acontecen fácilmente explotables a raíz de la creación de métodos de explotación semi-automáticos, el coche puede resultar en una fatídica trampa. Por ejemplo, recientemente se hizo público [18] que un módem 2G utilizado por varios modelos de coche de las marcas BMW, Ford, Infiniti y Nissan disponía de dos vulnerabilidades, y que una de ellas permitía explotaciones desde localizaciones remotas. [19] Cabe destacar que los años de fabricación de dichos vehículos se remite a 2009, 2010, 2013, 2014, 2015 y 2016, según la marca y el modelo.

Hemos visto que, dada la gravedad de la situación, las instituciones y agencias, entre otras organizaciones han empezado a realizar estudios, buenas prácticas y guías con el fin de abordar el tema y aportar posibles soluciones a la industria. Aun así, de la situación expuesta se deja entrever una falta de coordinación internacional entre todos estos actores. Creo firmemente que deberían definirse este tipo de marcos documentales a nivel global, del mismo modo que los futuros marcos normativos. Esto es así dado que, en algún momento, dichas prácticas tendrán que, bajo mi punto de vista, ser de obligado cumplimiento.

En referencia con el uso de un marco común hemos visto como la futura Agencia de la Ciberseguridad Europea busca harmonizar la normativa entre los Estados miembros, estableciendo un marco de validez único, facilitando que las empresas que ofrezcan servicios y productos puedan certificarlos de una manera más fácil, ágil y económica.

Un claro ejemplo de la exposición anterior es lo que sucedió con los programas que tenían las distintas marcas de pago para asegurar la protección de los datos de las tarjetas de pago (véase programas específicos de VISA, MasterCard etc.), que finalmente acabaron uniéndose para crear un marco común de trabajo, las PCI DSS. Un marco mucho más efectivo y fuerte, dado que normalizaba e internacionalizaba una primera actuación a realizar por parte de los comerciantes para gestionar los datos de las tarjetas de pago.

Referencias
[1] BOSCH (1991, Septiembre) CAN Specification (2.0) [Online]. Disponible: http://www.bosch-semiconductors.de/media/ubk_semiconductors/pdf_1/canliteratur/can2spec.pdf

[2] Gonzalo Lara (2013, Enero) CAN Bus: la forma de transmitir información en el automóvil [Online] Disponible: https://www.motorpasion.com/coches-hibridos-alternativos/can-bus-como-gestionar-toda-la-electronica-del-automovil

[3] AutoECMS (2016, Enero) What is an ECU - Electronic Control Module? [Online] Disponible: https://www.autoecmstore.com/blogs/autoecms-blog/74693189-what-is-an-ecu-electronic-control-module

[4] FireEye What is a Zero-Day Exploit? [Online] Disponible: https://www.fireeye.com/current-threats/what-is-a-zero-day-exploit.html

[5] Lisa Vaas (2016, Agosto) The Jeep hackers return to ditch a car going 60 mph [Online] Disponible: https://nakedsecurity.sophos.com/2016/08/03/the-jeep-hackers-return-to-ditch-a-car-going-60-mph/

[6] Keen Security Lab (2016, Septiembre) Car Hacking Research: Remote Attack Tesla Motors [Online] Disponible: http://keenlab.tencent.com/en/2016/09/19/Keen-Security-Lab-of-Tencent-Car-Hacking-Research-Remote-Attack-to-Tesla-Cars/

[7] Bugcorwd (2017) Tesla [Online] Disponible: https://bugcrowd.com/tesla

[8] Fred Lambert (2016, Septiembre) Tesla releases more details on the Chinese hack and the subsequent fix [Online] Disponible: https://electrek.co/2016/09/27/tesla-releases-more-details-on-the-chinese-hack-and-the-subsequent-fix/

[9] Keen Security Lab (2017, Julio) New Car Hacking Research: 2017, Remote Attack Tesla Motors Again [Online] Disponible: http://keenlab.tencent.com/en/2017/07/27/New-Car-Hacking-Research-2017-Remote-Attack-Tesla-Motors-Again/

[10] Fred Lambert (2017, Julio) Keen Lab hackers managed to take control of Tesla vehicles again [Online] Disponible: https://electrek.co/2017/07/28/tesla-hack-keen-lab/

[11] Ivan Evtimov , Kevin Eykholt , Earlence Fernandes , Tadayoshi Kohno , Bo Li , Atul Prakash , Amir Rahmati , y Dawn Song (2017, Agosto 7) Robust Physical-World Attacks on Machine Learning Models [Online] Disponible: https://arxiv.org/pdf/1707.08945.pdf

[12] national Highway Traffic Safety Administration (2016, Octubre) Cybersecurity best Practices for modern Vehicles [Online] Disponible:
https://www.nhtsa.gov/staticfiles/nvs/pdf/812333_CybersecurityForModernVehicles.pdf

[13] HM Government (2017, Agosto 6) the Key Principles of Cyber Security for Connected and Automated Vehicles [Online] Disponible:
https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/624302/cyber-security-connected-automated-vehicles-key-principles.pdf

[14] Enisa (2017, Enero 13) Cyber Security and Resilience of smart cars [Online] Disponible: https://www.enisa.europa.eu/publications/cyber-security-and-resilience-of-smart-cars/at_download/fullReport

[15] National Highway Traffic Safety Administration y U.S. Department of Transportation (2016, Septiembre) Federal Automated Vehicles Policy [Online] Disponible:
https://one.nhtsa.gov/nhtsa/av/pdf/Federal_Automated_Vehicles_Policy.pdf

[16] European Comission (2017, Septiembre 19) State of the Union 2017 - Cybersecurity: Commission scales up EU's response to cyber-attacks [Online] Disponible: http://europa.eu/rapid/press-release_IP-17-3193_en.htm#_ftn1

[17] European Comission (2017, Septiembre 13) Proposal for a REGULATION OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL on ENISA, the "EU Cybersecurity Agency", and repealing Regulation (EU) 526/2013, and on Information and Communication Technology cybersecurity certification (''Cybersecurity Act'') [Online] Disponible: https://ec.europa.eu/info/law/better-regulation/initiative/111956/attachment/090166e5b507c22c_en

[18] Catalin Cimpanu (2017, Agosto) Security Flaws Found in 2G Modems Used by BMW, Ford, Infiniti, and Nissan Cars [Online] Disponible:
https://www.bleepingcomputer.com/news/security/security-flaws-found-in-2g-modems-used-by-bmw-ford-infiniti-and-nissan-cars/

[19] Common Vulnerabilities and Exposures (2017, Junio) CVE-2017-9633 [Online] Disponible: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-9633

Autor: Marc de Tébar
Dpto. Consultoría

Ver post completo