Analytics

jueves, 14 de diciembre de 2017

Documentación obligatoria en ISO 22301.

Todos los Sistemas de Gestión que se quieren certificar bajo un estándar ISO, deben cumplir una serie de requerimientos, muchos de ellos enfocados a la documentación del Sistema. En el ámbito documental, y focalizándonos en la ISO 22301 para la definición de un Sistema de Gestión de la Continuidad de Negocio (SGCN), la Organización Internacional de Normalización, no impone límites en la cantidad de documentos que una Organización que se quiera certificar presente ante el auditor, aunque sí exige una documentación mínima que debe ser contemplada. Esta documentación mínima es la siguiente:
  • Contexto de la Organización (Cláusula 4.1): Definir de forma correcta el contexto de la Organización es crítico para cualquier Sistema de Gestión, identificando los principales actores internos y externos que afectarán al Sistema. Concretamente, para establecer el contexto del SGCN, la cláusula 4.1 indica qué se debe:
    • Definir el propósito del SGCN.
    • Identificar los objetivos de la Organización en materia de la continuidad de negocio.
    • Definir los factores de riesgo, internos y externos.
    • Establecer criterios para el riesgo y definir el “apetito por el riesgo” de la Organización.
  • Procedimiento para la identificación de requisitos legales regulatorios (Cláusula 4.2.2): Se debe establecer, implementar y mantener actualizado un procedimiento que permita identificar las regulaciones aplicables a la Organización, así como identificar los cambios que se produzcan; debe contemplar también la comunicación a las partes interesadas.
  • Alcance del SGCN (Cláusula 4.3.1): Debe mantenerse un documento en el que se identifique el alcance del SGCN y que contemple los requerimientos y necesidades de las cláusulas 4.1 y 4.2.
  • Política de Continuidad de Negocio (Cláusula 5.3): La Alta Dirección debe establecer una Política de Continuidad de Negocio que sea apropiada para los objetivos de la Organización y sirva como framework para el SGCN. Además, esta política deberá ser comunicada y estar disponible para todas las partes interesadas que lo requieran.
  • Objetivos de Continuidad de Negocio (Cláusula 6.2): Los objetivos de continuidad de negocio deben estar documentados y ser comunicados al personal para quien sean relevantes. Estos objetivos deben ser coherentes con la Política de Continuidad y deben ser monitorizados de cara a actualizarlos si es necesario.
  • Competencias (Cláusula 7.2): Se debe garantizar que el personal dispone de la competencia adecuada para su función y si es necesario, facilitar su capacitación. La Organización debe mantener evidencias de esto.
  • Plan de Comunicación (Cláusulas 7.4 y 8.4.3): Se debe documentar a quien se debe comunicar una disrupción, incluyendo todas las partes interesadas (ya sean actores internos o externos).
  • Proceso de Análisis de Riesgos e Impacto en el Negocio (Cláusula 8.2.1): Documento en el que se establece el contexto, criterios y evaluación de potenciales riesgos, tratamientos y salidas del proceso.
  • Análisis de Impacto de Negocio (Cláusula 8.2.2): En el que se identifiquen las actividades críticas del negocio y se evalúen el impacto de no realizar dichas funciones.
  • Análisis de Riesgos (Cláusula 8.2.3): El resultado del proceso de análisis de riesgos, identificando los riesgos existentes y cuáles deben ser tratados, de acuerdo a los objetivos de continuidad definidos.
  • Procedimientos de Continuidad de Negocio (Cláusula 8.4.1): Para evitar situaciones de disrupción de la Organización se deben establecer Procedimientos de Continuidad. Estos procedimientos estarán documentados y deberán indicar los principales pasos a seguir por cada rol en caso de disrupción.
  • Respuesta a Incidentes (Estructura de Respuesta a Incidentes - Cláusula 8.4.2): En este documento se reflejan los umbrales que justifican el lanzamiento de los Procedimientos de Continuidad y cómo elegir qué Procedimiento debe ejecutarse.
  • Decisiones de Comunicación (Cláusula 8.4.2): Una Organización debe decidir a qué partes interesadas (incluyendo actores externos) debe comunicar que ha ocurrido una crisis y debe documentar su decisión.
  • Procedimientos de Respuesta a Incidentes (Cláusula 8.4.4): Se debe disponer de procedimientos en los que se expliquen los roles y responsabilidades de los actores involucrados, los procedimientos de gestión de la incidencia, la operativa para la continuidad de las operaciones entre otros requerimientos.
  • Procedimientos de vuelta a la normalidad (Cláusula 8.4.5): Una vez se ha finalizado la contingencia, la vuelta al servicio habitual debe ser lo menos traumática posible para los servicios y colaboradores de la Organización; por ello, se deben establecer y documentar una serie de procedimientos en los que se indique los pasos a seguir para volver a operar de la forma habitual.
  • Resultados de monitorización y evaluación (Cláusula 9.1.1): Como proceso de mejora continua, se deben monitorizar las actividades, analizarlas y evaluarlas. Estos resultados deben guardarse como evidencia del proceso.
  • Evidencia de no conformidades (Cláusula 9.1.1): Cuando se identifiquen elementos adversos o como resultado de las no conformidades detectadas, la Organización tomará las medidas oportunas para mitigar dichas deficiencias y deberá guardar registros de las acciones tomadas como evidencia.
  • Revisión post-incidente (Cláusula 9.1.2): Cuando la Organización sufra un incidente que suponga la activación del Plan de Continuidad, la Organización deberá realizar una revisión del incidente y las acciones tomadas, que deberá quedar documentado como evidencia.
  • Auditoría Interna (Cláusula 9.2): Esta cláusula indica que la Organización debe realizar auditorías internas a intervalos planificados. El informe de la auditoría deberá guardarse como evidencia de que la auditoría se ha realizado.
  • Revisión de la Dirección (Cláusula 9.3): La Alta Dirección debe estar involucrada en el SGCN. Debe revisar el SGCN a intervalos planificados y deben quedar evidencias de dicha revisión.
  • No conformidades y acciones tomadas (Cláusula 10.1): Las no conformidades detectadas como resultado de las auditorías deben ser controladas. Por ello, debe quedar constancia de la evaluación de las no conformidades y las acciones que decidan tomarse.
  • Resultados de acciones correctivas (Cláusula 10.1): Cualquier cambio derivado de las auditorías o fallos detectados en las revisiones que sea implantado debe generar un registro en el que se indique los resultados de dichas acciones.
Como puede observarse, la cantidad de documentación requerida por el SGCN es muy elevada. A toda esta documentación, debe añadirse además cualquier otra información a la que se haga referencia en la política o el alcance, o cualquier documento que la Organización considere necesaria para la Gestión de la Continuidad de Negocio.


Existen otros documentos que, si bien no son obligatorios, es muy habitual encontrarlo en los sistemas que se encuentran certificados y ayudan al mantenimiento del SGCN. Algunos de estos documentos son:
  • Plan de Formación (Cláusulas 7.2 y 7.3): Disponer de un Plan de Formación ayudará a identificar las capacitaciones que son necesarias en función de los roles y responsabilidades definidos, así como ayuda a la planificación de las tareas de formación de la Organización.
  • SLA y revisión de SLA con procesos externalizados (Cláusula 8.1): En caso de que existan procesos externalizados, estos deben ser controlados. La mejor forma de control es a través de un contrato con SLA y evidencias de que estos SLA se revisan de forma periódica. En muchas ocasiones, estos SLA son revisados a través de reuniones planificadas a intervalos regulares y son parte de los propios SLA.
  • Plan de Pruebas (Cláusula 8.5): Probar los procedimientos puede ser vital para la Organización. Estas pruebas cumplen una doble función: por un lado, asegurarán que los actores involucrados conozcan sus responsabilidades y los pasos que deben seguir en caso de incidente; por otro, garantiza la viabilidad del procedimiento o detecta fallos en el diseño.
  • Escenarios de incidentes (Cláusula 8.5): Las pruebas que se realizan en el SGCN deben ser adecuadas, para ello se identifican posibles escenarios de crisis sobre los que realizar las pruebas.
  • Revisión e informes de pruebas (Cláusula 8.5): Se recomienda que siempre que se lleve a cabo una prueba se proceda de igual forma que si la Organización estuviese afrontando una contingencia real. Esto incluye una revisión e informe de la prueba realizada, de cara a identificar deficiencias en un proceso de mejora continua.
  • Plan de Actualización (Cláusula 9.1.1): Revisar la documentación de forma periódica permite garantizar que la información está acorde a los objetivos de la Organización, así como se revisan que los procedimientos estén actualizados. Por otro lado, la revisión y actualización de las pruebas y procedimientos garantiza que se dispone de información reciente en caso de que haya que activar el Plan de Continuidad.
  • Programa de Auditoría (Cláusula 9.2): Sirve como evidencia de que la auditoría se encuentra planificada y que ha cumplido con los objetivos establecidos.

A modo de conclusión, queremos hacer notar que la cantidad de documentación necesaria para disponer de un SGCN certificable es muy extensa. Destacar también que no es obligatorio tener un documento para cada uno de los requisitos, si no que pueden integrarse varios de estos documentos en uno. Es muy importante para un SGCN operativo que se encuentre un equilibrio entre el número de documentos y la cantidad de información que contienen, de forma que dichos documentos sean manejables para la operativa diaria y faciliten su actualización y la revisión por parte de los auditores, sin olvidar que, si la información se encuentra disgregada entre varios documentos, es muy factible que se den inconsistencias entre los diferentes documentos. Por último, añadir que, si se integran varios de estos documentos obligatorios en un único documento es muy importante tener identificado, por parte de los responsables del SGCN, a qué cláusulas hace referencia cada documento, de forma que el auditor sepa dónde encontrará las evidencias que necesita y además facilitará la labor de actualización de los documentos cuando se dé cualquier cambio dentro de la Organización.

Referencias
ISO 22301:2012 – Societal Security – Business continuity management systems: https://www.iso.org/standard/50038.html
Whitepaper de Advisera – Checklist of ISO 22301 mandatory documentation: http://info.advisera.com/27001academy/free-download/checklist-of-iso22301-mandatory-documentation



Antonio Martínez Jiménez 
CISSP, ISO 20000 L.A.
Dpto. Consultoría

miércoles, 13 de diciembre de 2017

Continuidad de Negocio para Pymes

Las amenazas y la ciberdelincuencia no discriminan entre grandes compañías y pymes, pero ¿están las pymes preparadas para hacer frente a estos riesgos? .

Históricamente, cuando se pensaba en la continuidad de negocio se tendía a pensar en disrupciones de carácter natural (como incendios, inundaciones, etc.), sin embargo, en el mundo actual, donde la utilización de proveedores y sistemas informáticos es vital para las operaciones diarias de las organizaciones, el rango de amenazas ha aumentado. La delincuencia cibernética busca información allá donde esté disponible, no importa el tamaño de la empresa ni la información que puedan conseguir, ya que con esta información siempre se va a poder hacer negocio, ya sea a través del cifrado de dispositivos y servidores mediante ransomware, o bien vendiendo la información obtenida en la Deep Web.

No prever estos riesgos, o incluso menospreciarlos, puede suponer un error crítico para la viabilidad de las organizaciones. Si bien la gran mayoría de las organizaciones disponen de planes de prevención de riesgos laborales y planes evacuación de sus colaboradores en caso de incendio, no se considera cómo estos riesgos afectan a uno de los principales activos de la organización: la información, cuya perdida pone en riesgo, no sólo la continuidad inmediata de la operativa de la empresa, sino cualquier posibilidad de continuarla en el futuro.

Además de no prever estos riesgos, el coste, la indisponibilidad de personal o la reducida probabilidad de crisis son las principales razones por las que las pymes no se plantean la implantación de un sistema de gestión de continuidad de negocio. Estos Planes de Continuidad de Negocio sirven para mejorar la preparación que tienen las organizaciones ante diferentes tipos de incidente que provoquen interrupciones en las actividades de dicha empresa, recuperando a la mayor brevedad posible las actividades más críticas, aunque esto puede extrapolarse a todas las actividades de la Organización.

Muchas empresas disponen de un Plan de Recuperación ante Desastres (DRP por sus siglas en inglés) en prevención de la indisponibilidad de sus sistemas informáticos, pero un Plan de Continuidad de Negocio va más allá, identificando diferentes escenarios de crisis que puedan afectar a la organización, tomando como fuentes, no sólo la indisponibilidad tecnológica, sino también posibles indisponibilidades de las oficinas físicas, los recursos humanos, o los proveedores que ofrecen servicios críticos para la organización; priorizando la criticidad de las diferentes operaciones y estableciendo planes de recuperación, todo ello acompañado de la definición de una estrategia de pruebas y de concienciación de los colaboradores más críticos, haciendo que el Plan de Continuidad de Negocio sea realmente útil y productivo para las empresas.

Existen diferentes formas de prepararse para establecer un sistema de gestión de la continuidad de negocio, pero ¿cuáles son los pasos que debe seguir una organización para implantar uno?.
  1. Identificar los objetivos y operaciones de la propia organización. Es necesario tener claro cuáles son los objetivos que queremos conseguir y en qué debemos establecer los focos de atención.

  2. Identificar y evaluar los principales escenarios y amenazas que afectan a la Organización, sean del tipo que sea, desde amenazas naturales hasta amenazas provocadas, considerando cualquier activo de la empresa (activos humanos, tecnológicos, infraestructura, etc.). Este análisis de Riesgos será una de las principales bases sobre las que se asentará nuestro Plan de Continuidad de Negocio.

  3. Establecer las actividades críticas. En muchas ocasiones, y si la empresa es muy pequeña, la Dirección suele conocer de antemano cuales son las actividades más críticas para su negocio. No obstante, es recomendable establecer una metodología objetiva, que considere diferentes aspectos a los que afectaría una posible disrupción de dicha actividad (requisitos de otros departamentos, impacto en la reputación financiera, o, por supuesto, impacto económico que supondría). Esta fase, denominada BIA por sus siglas en inglés (Business Impact Analysis) es junto con el Análisis de Riesgos otra de las etapas más críticas y que mayor cuidado hay que tener al efectuarlas, pues todas las estrategias y procedimientos que desarrollemos irán enfocadas a la protección de las actividades más críticos y se focalizarán en los riesgos más graves que se hayan detectado.

  4. Considerando estas fuentes, ya se pueden establecer cuáles serán las estrategias de recuperación que se establecerán para la Organización, en función del presupuesto y de los tiempos de respuesta que se hayan establecido.

  5. Establecimiento de un Plan de Comunicación, en el que se identifiquen claramente los roles involucrados, así como actores internos y externos que puedan verse afectados por una disrupción en el negocio.

  6. Diseñar un Plan de Formación, en el que se identifiquen los cursos y concienciaciones necesarias para que todos los colaboradores conocen las formas de actuar y su papel en caso de una disrupción.

  7. Pruebas: Si un Plan no se pone en práctica, la probabilidad de que funcione bien cuando sea necesario es muy reducida. Establecer un Plan de Pruebas adecuado, en el que se evalúen los tiempos de respuesta y el conocimiento de los involucrados en el Plan puede suponer un hecho diferencial para la consecución de nuestros objetivos.

  8. Las organizaciones cambian de forma constante (rotación de personal, apertura de nuevas instalaciones, cambios en sistemas informáticos, etc.), por lo que es necesario mantener el Plan de Continuidad actualizado, mediante revisiones periódicas y con la retroalimentación del propio plan de pruebas.

  9. Vuelta a la Normalidad: Toda crisis llega a su fin y un Plan de Continuidad debe continuar hasta que los procesos de negocio vuelven a operar con normalidad. Por ello, existe una fase adicional a considerar, que es la de identificar los procedimientos y comunicaciones que se deben seguir para volver a operar dentro de esta normalidad. Se deberán establecer los canales de comunicación para informar a los equipos afectados, así como, diseñar los procedimientos para volver a utilizar los activos primarios y devolver los sistemas de recuperación a su estado normal.
Como puede observarse, este tipo de sistemas van más allá de la implantación de estrategias y planes de respuesta, si no que se trata de un proceso constante y cíclico, siendo necesario un esfuerzo constante por parte de la Organización para mantenerlo operativo. Siguiendo estos pasos, obtendremos un sistema de gestión de continuidad de negocio completo y con un ciclo de vida basado en la mejora continua, tal y como se define en los principales estándares y buenas prácticas.

¿Y qué ventajas ofrece este Sistema Gestor de la Continuidad de Negocio?
  • El primero y más importante, anteponerse a los desastres y disrupciones; la gestión proactiva y preventiva de las amenazas es vital para 
  • Reducción de pérdidas. Al tomar medidas con tiempos de respuesta ajustados y dar una operativa continua, se puede minimizar la pérdida de clientes, así como evitar o reducir sanciones de las instituciones regulatorias.
  • Ventaja competitiva. Disponer de un Plan de Continuidad de Negocio puede suponer una ventaja frente a los competidores, así como una fuente de confianza para inversores.

Si bien implantar un Plan de Continuidad de Negocio es un proyecto costoso en recursos y monetario para las empresas (considerando que, además del coste de lanzamiento e implantación, tiene que mantenerse vivo, derivando recursos de forma constante para su actualización y mejora), se debe tener en cuenta que cualquier Organización, grande o pequeña, se encuentra en riesgo y se enfrentan a posibles desastres si no se encuentran preparadas y no son capaces de realizar sus servicios o entregar sus productos a raíz de un incidente. Una aproximación muy útil para pequeñas empresas es la de abordar su Plan de Continuidad de Negocio por etapas, pudiendo hacerse esta aproximación de diferentes formas, ya sea focalizándose en unos pocos procesos de negocio o bien limitando los escenarios de crisis que se van a considerar y para los que se plantearán estrategias de recuperación. Sea cual sea la aproximación que se utilice, se debe ver este tipo de proyectos como una inversión y no como un coste, ya que no contar con un Plan de Continuidad de Negocio probado o no establecer los procedimientos y documentación adecuados puede suponer un coste incluso mayor al del propio Sistema Gestor de Continuidad de Negocio.

Referencias
ISO 22301:2012 – Societal Security – Business continuity management systems: https://www.iso.org/standard/50038.html
Introducción a la continuidad de negocio del Business Continuity Institute: https://www.thebci.org/knowledge/introduction-to-business-continuity.html


Antonio Martínez Jiménez 
CISSP, ISO 20000 L.A.
Dpto. Consultoría

martes, 12 de diciembre de 2017

Crónica No cON Name 2017

Este año hemos tenido la oportunidad de volver a asistir a la última edición del congreso No cON Name, el congreso público de seguridad informática más longevo de España (nacido en 1999, en Palma de Mallorca), cuya última edición se llevó a cabo en 2015. Durante el discurso inaugural, la organización remarcó que la edición de 2016 no se llevó a cabo por dificultades de financiación y que actualmente se están buscando nuevos formatos que puedan encajar con el congreso, con el objetivo de evitar la repetición de ponentes y charlas en las diversas “Cons” que se realizan en España. A continuación, os dejamos un breve resumen de las presentaciones que se realizaron durante su primera jornada.

"Win API hooking by using DBI: log me, baby!" (Ricardo J. Rodríguez)

Ricardo J. Rodriguez empezó su charla con una definición e introducción a los frameworks DBI. Esencialmente estos son capaces de controlar que sucede durante la ejecución de un binario.

Posteriormente se centró en el DBI Pin desarrollado por Intel en 2005. Pin tiene la característica de vincularse a procesos que se encuentran en marcha y tiene soporte para las arquitecturas 32 y 64 bits en Windows y Linux e Itanium sólo en Linux.

Existen 3 tipos de APIs en PIN: las básicas, que implementan funcionalidades básicas y son independientes de la arquitectura, las específicas de la arquitectura (opcodes y operands), y las APIs basadas en llamadas que proporcionan rutinas que definen donde y qué se instrumentaliza.

Pin proporciona dos modos de análisis o instrumentalización: JIT mode, donde una copia del binario se modifica al vuelo y el binario original nunca es ejecutado y el Probe mode, donde las instrucciones de la aplicación son modificadas y se insertan saltos (trampolines) para alterar el funcionamiento normal de la aplicación instrumentalizada.

Pin destaca de otros frameworks DBI por su granularidad. Más allá de la instrumentalización básica a nivel de bloque o instrucción, Pin proporciona instrumentalización de eventos a nivel de rutinas, grupos de bloques (traces), durante la creación o destrucción de hilos y en la carga y descarga de imágenes, llamadas de sistema, .... Y aún más importante, Pin proporciona las funciones necesarias para acceder a datos importantes cuando estos eventos ocurren.

La charla terminó con algunas instrucciones sobre cómo configurar Pin en entorno Windows y dos ejemplos de uso de Pin.

"WinregMITM: Inyectando código remotamente en el registro de Windows" (Santiago Hernández Ramos)

Santiago ofreció una fantástica presentación sobre un problema de seguridad en el protocolo WinReg debido a un fallo en su implementación. WinReg es un protocolo cliente/servidor que proporciona gestión remota del registro de Windows. Éste se apoya en otros protocolos como SMB, RPC para llevar a cabo su cometido.

En el protocolo WinReg, el cliente y el servidor negocian una sesión a través del protocolo RPC. Para que las llamadas RPC sean seguras hay que construir previamente un contexto de seguridad. Seis niveles de autenticación pueden establecerse según el contexto de seguridad haya negociado. Los niveles de autenticación van del 0 (ninguna protección) al 6 (integridad y cifrado). El encargado de implementar los niveles de autenticación que el contexto de seguridad exige es el proveedor de seguridad.

Cuando un cliente inicia la conexión con el servidor mediante WinReg, se le asocia un contexto de seguridad de nivel de autenticación 6. Si durante la conexión se produce un error el contexto de seguridad es desechado. Un error puede ser algo tan sencillo como el uso de credenciales incorrectas para autenticarse con el servidor de WinReg.

Un fallo en la implementación del protocolo WinReg permite que tras el error en la conexión se establezca un nuevo contexto de seguridad con nivel de autenticación 0. La comunicación a partir de ese momento se realiza en claro y sin integridad.

El trabajo de Santiago no termina ahí si no que escribe la herramienta WinregMITM para aprovechar esa vulnerabilidad. Tras envenenar la cache ARP del cliente y servidor la aplicación  WinregMITM permite romper la conexión existente entre cliente y servidor para forzar la reconexión sin cifrado. A partir de entonces la aplicación será capaz de ver y manipular la conversación entre ambos. En este punto sólo hay que esperar a que el cliente realice un cambio en el servidor para cambiar el valor introducido legítimamente por el valor deseado por el atacante.

El ataque no es trivial ya que debido al cambio de la clave de registro realizado por el atacante el tamaño del paquete cambia. Esto afecta tanto a los campos de control de las capas inferiores (SMB y/o RPC) cómo al número de secuencia de sesión TCP que se basa en la longitud del paquete. WinregMITM es capaz de filtrar los paquetes específicos, modificar los campos necesarios, recalcular los campos de control y los números de secuencia TCP para terminar reconstruyendo el paquete y reenviarlo evitando así que la conexión se rompa.

"¿Dónde has estado? Encontrando evidencias en tu móvil" (Alex Ribot)

La charla de Alex nos descubre distintas fuentes y métodos para encontrar información de posicionamiento en dispositivos móviles.

El conocido sistema de geolocalización GPS ha sido mejorado con AGPS (Assited-GPS). Éste proporciona posicionamiento en interiores, a pesar de hacerlo con menor precisión en tales circunstancias, aprovechando la información relativa a la celda de telefonía y las señales WiFi cercanas. Este método ahorra batería y necesita sólo 2 satélites GPS para lograr una localización precisa. El rango de error en la precisión mediante posicionamiento por celda de telefonía se estima entre los 25 y los 1000 metros. Usando WiFi el rango se reduce de los 10 a los 100 metros. Por último el sistema por GPS va desde los 7,8 a los 16 metros.

Tanto iOS como Android tienen en sus acuerdos de privacidad cláusulas que solicitan el consentimiento para transmitir, coleccionar, procesar y usar los datos de localización que nuestros dispositivos envían. Las API encargadas de proporcionar información de posicionamiento son la Core Location para iOS y la Google’s Fused Location o la Android  Location API en Andoid.

Las fuentes de datos para obtener la geolocalización son múltiples. A nivel de tarjeta SIM tenemos varios identificadores o códigos de área que son almacenados en la propia tarjeta: LAC (Location Area Code), FPLMN (Forbidden Public Land Mobile Network).

A nivel de sistema operativo la información guardada en el sistema de ficheros no es normalmente accesible y a menudo hay que rootear el dispositivo o sacar un dump de la memoria. En Android existe una base de datos SQLite con las redes WiFi y los IDs de las celdas (codificados en Base64) que el dispositivo ha captado. También podemos encontrar un historial con los SSSID, algunos BSSID y sus correspondientes passwords a los que el móvil se ha conectado. En IOS tenemos principalmente las Frequent Locations, una base de datos SQLlite que retiene las ubicaciones aproximadamente durante 1 día, ficheros con algunos datos de geolocalización históricos, y archivos de preferencias plist en formato binario de difícil interpretación y la Location cache, con información de posicionamiento por celdas (1 semana aprox.) y por WiFi (4 días aprox.)

A nivel de aplicación, existen múltiples aplicaciones que pueden almacenar información de geolocalización para desarrollar correctamente su actividad o para otros fines como mostrar publicidad. Evidentemente cada app necesita su correspondiente permiso para poder acceder a la posición del dispositivo.

A nivel de usuario, los dispositivos se pueden configurar para que se almacene la ubicación en los metadatos de imágenes y videos. Otras fuentes como imágenes tomadas en sitios públicos conocidos o conversaciones por chat o email donde se revela la ubicación son también válidos.

Para finalizar, a nivel de Cloud, tanto IOS como Android posibilitan la localización de los dispositivos en caso de robo o pérdida, y especialmente Android proporciona un historial de localizaciones vinculado a la cuenta Gmail del dispositivo.

"Atacando implementaciones Whitebox Cryptography" (Jordi Ventayol)

Jordi, comenzó su presentación describiendo las principales diferencias entre los diferentes tipos de implementaciones criptográficas. En primer lugar, describió el tipo Whitebox, en el cual el criptoanalista dispone del control total y toda la información acerca del sistema criptográfico. En segundo lugar, describió el tipo Greybox, en el que ya no se dispone del control del sistema, y únicamente de datos relativos a los tiempos de ejecución de los algoritmos, al consumo eléctrico del dispositivo criptográfico, del campo magnético generado, etc. Finalmente, describió el tipo Blackbox, en el que únicamente se dispone de la información de las entradas y las salidas del sistema. La ponencia nos sitúa en el primero de los tipos.

Posteriormente, Jordi explicó que las implementaciones Whitebox son utilizadas en dispositivos HCE (Host Card Emulation), generalmente incluidos en smartphones para poder realizar pagos de forma equivalente a los realizados con tarjetas (basadas en la tecnología SIM).

Finalmente, y a través de varios ejemplos, expuso los principales mecanismos de protección en entornos Whitebox. Entre ellos, se encuentran el uso de tablas de búsqueda (look-up tables) para embeber la clave de cifrado, la introducción de aleatoriedad en dichas tablas, el enmascaramiento y la ofuscación tanto del código como de los datos.

"IoT - The New Big Brother" (Luis Enrique Benitez)

Luis Benítez, miembro del Departamento de Auditoría de Internet Security Auditors, puso sobre la mesa cómo los distintos dispositivos conectados recopilan información de los hábitos de uso y consumo de sus usuarios. Luis expuso que durante los últimos años ha estado analizando distintos dispositivos y que en todas ellas ha detectado carencias en la seguridad en mayor o menor grado.

Algunos ejemplos son una Smart TV que recaudaba información; un grupo de canales en particular no solo recaudaba información cuando se accedía a su contenido sino que también envía datos técnicos del dispositivo, la lista de canales sintonizados y el orden en que estos se encontraban, remarcando además que dicha información era enviaba cada 4 segundos.

También habló de dispositivos para monitorizar el consumo energético. En este caso detectó un fallo en la plataforma web que permitía acceder a los datos de consumo en tiempo real de cualquier usuario. Comentaba Benítez que esto permitiría realizar un perfil exhaustivo del usuario. Interpretando los datos de consumo se podrían llegar a deducir hábitos como la hora en que el usuario se despierta o cuando está durmiendo o fuera de casa. A esto hay que sumarle que entre los datos recaudados estaban las coordenadas GPS de donde se encontraba instalado el dispositivo y el nombre que el usuario le había asignado.

Posteriormente habló de una lavadora smart, la cual enviaba información cada 30 segundo del estado del lavabo. Una vez comprendido la lógica de la aplicación le permitía emular las peticiones recibiendo en su dispositivo móvil mensajes ininterrumpidos de que su ciclo de lavabo había terminado. También mostro serias carencias de seguridad en el portal del fabricante, el cual permitía gracias a un fallo de seguridad crear un usuario con rol de administrador.

Luis cerró su ponencia hablando de la plataforma Smart City SENTILO, la cual contaba con múltiples deficiencias de seguridad.

Las conclusiones de la charla son sobre todo dos: la necesidad de integrar la seguridad desde el principio en el desarrollo de las aplicaciones y la necesidad de una certificación de dispositivos IoT que proporcionen un mínimo de garantías en cuando al diseño y a las actualizaciones.

"El badUSB se juntó con el wifi... Y se lió parda" (Ernesto Sanchez y Joel Serna)

Ernesto y Joel, realizaron una breve introducción a los famosos dispositivos denominados BadUSB. Estos dispositivos, son dispositivos que intentan hacerse pasar por simples unidades de almacenamiento USB, pero que presentan funcionalidades ocultas. En su ponencia, presentaron su experiencia en el desarrollo de uno de estos dispositivos, con la novedad de incorporar WiFi.

En primer lugar, Ernesto y Joel hablaron sobre la funcionalidad de estos dispositivos para evadir los antivirus de los sistemas a los que son conectados. Describieron como es posible lograrlo, forzando al sistema a reconocer el dispositivo como HID (Human Interface Device -como un ratón, teclado, etc-) en lugar de memoria USB, con el objetivo de evitar que el antivirus proceda al análisis de su contenido y pueda descubrir el malware almacenado. Esta funcionalidad, la implementaron a través del módulo ATMEGA32U4.

Posteriormente, detallaron la mejora que llevaron a cabo al incluir un módulo WiFi al dispositivo, para poderlo controlar remotamente a través de la carga de scripts. Esta mejora, la implementaron a través del módulo ESP8266. A su vez, comentaron la existencia de otros proyectos en esta línea, como por ejemplo WiDucky.

Finalmente, Ernesto y Joel expusieron las dificultades de su trabajo a la hora de incorporar un módulo SD adicional, con el objetivo de permitir al dispositivo su reconocimiento de nuevo como unidad de almacenamiento (para evitar el rechazo del mismo por parte del usuario), una vez anulado el antivirus del sistema objetivo.

Autores:
Carlos Antonio Sans García
ISO 27001 L.A., ISO 22301 L.A., CISA
Dpto. Consultoría

Francesc Guitart
Dpto. Sistemas

martes, 5 de diciembre de 2017

El (ISC)2 introduce las pruebas adaptativas computarizadas (Computerized Adaptive Testing) al examen CISSP

A partir del 18 de diciembre de 2017 el Consorcio Internacional de Certificación de Seguridad de Sistemas de Información (International Information Systems Security Certification Consortium) o (ISC)2 pondrá en funcionamiento las pruebas adaptativas computarizadas (Computerized Adaptive Testing o CAT) al examen CISSP, inicialmente en los exámenes ofrecidos en idioma inglés e introduciendo de forma paulatina la misma técnica a los demás idiomas en los que se puede presentar la prueba a lo largo del primer trimestre de 2018.

Este es uno de los cambios más significativos en el examen de esta certificación, luego de que en 2012 el examen migró de su modelo de presentación en papel (Paper Based Testing - PBT) a la presentación por ordenador (Computer-Based Testing - CBT).

¿En qué consiste la tecnología de pruebas adaptativas computarizadas?

Actualmente, el examen de la certificación CISSP (Certified Information Systems Security Professional) se realiza a través de un examen compuesto de 250 preguntas fijas y lineales que el candidato debe contestar en un tiempo máximo de 6 horas. Al finalizar la prueba, se computan los resultados y si se obtiene una calificación superior a 700 puntos sobre 1000, el candidato aprueba.

Mediante las pruebas adaptativas computarizadas el criterio de presentación de las preguntas al candidato varía de forma considerable respecto al modelo lineal. Ahora, cada pregunta es seleccionada con base en la respuesta de la pregunta anterior, maximizando la precisión del examen de acuerdo con el siguiente algoritmo iterativo:
  1. Se busca la pregunta óptima entre una base de datos de preguntas disponibles, de acuerdo con la estimación actual de la capacidad del candidato.
  2. La pregunta seleccionada es presentada al candidato, quien la responde de forma correcta o incorrecta.
  3. La estimación de la capacidad se actualiza, con base en todas las respuestas anteriores.
  4. Los pasos 1 al 3 se repiten hasta que se cumple un criterio de finalización.

Los criterios de finalización se aplican en el siguiente orden:
  1. Regla de intervalo de confianza: una vez que se cumple la duración mínima del examen (100 preguntas), el examen finalizará cuando la estimación de capacidad del candidato excluya el punto de aprobación con una confianza estadística del 95%. Para los candidatos con estimaciones de capacidad que excedan estadísticamente el estándar de aprobación, el examen estará aprobado. Para los candidatos que tienen estimaciones de capacidad que estén estadísticamente por debajo del estándar, el examen será reprobado.
  2. Regla de la longitud máxima del examen: si no se ha invocado previamente la regla de intervalo de confianza antes de llegar a las 150 preguntas, entonces la estimación de la capacidad del candidato se evaluará con respecto al estándar de aprobación. Si durante los últimos setenta y cinco (75) elementos operacionales respondidos la estimación de la capacidad del candidato está constantemente por encima del estándar de aprobación para cada elemento, entonces el resultado del examen es aprobado. Si en algún punto sobre los últimos setenta y cinco (75) elementos operacionales la estimación de la capacidad del candidato cae por debajo del estándar de aprobación, el resultado será reprobado. La evaluación de la estimación de capacidad con relación al estándar de aprobación no tiene en cuenta el intervalo de confianza.
  3. Regla Run-out-of-time (R.O.O.T.): si la regla de intervalo de confianza no se ha invocado antes del tiempo máximo del examen (3 horas), la estimación de la capacidad del candidato se evaluará con respecto al estándar de aprobación. Si durante los últimos setenta y cinco (75) elementos operacionales respondidos la estimación de la capacidad del candidato está constantemente por encima del estándar de aprobación, entonces el resultado del examen es aprobado. Si en algún punto sobre esos setenta y cinco (75) ítems la estimación de la capacidad del candidato cae por debajo del estándar de aprobación, el resultado es un error. Si el candidato no responde setenta y cinco (75) elementos operacionales dentro del tiempo máximo del examen (3 horas), el candidato automáticamente suspenderá el examen.


¿Cuáles son las ventajas del nuevo modelo de pruebas adaptativas computarizadas?

Los criterios de elección de un examen tipo CAT sobre un examen lineal son los siguientes:


  • Confiabilidad: Los exámenes del tipo CAT permiten una forma más precisa y eficiente de evaluar las capacidades del candidato, ya que permite la adaptación de las preguntas a cada individuo en particular.
  • Optimización del tiempo: En vez de emplear 6 horas para responder la totalidad de las preguntas del examen, se requerirán solamente 3 horas (como máximo) y solamente respondiendo un subconjunto de preguntas escogidas de acuerdo a la capacidad del candidato. 
  • Seguridad en las preguntas: En un examen lineal, el candidato estaba expuesto a 250 preguntas. Si no aprobaba, era muy probable que en un segundo intento muchas de esas preguntas volvieran a aparecer en su examen. Con el nuevo modelo CAT, la probabilidad de repetición es mínima, ya que la exposición de preguntas al candidato se minimiza dependiendo de sus capacidades.

¿Cuáles son las diferencias entre el modelo CAT y el modelo lineal?

A continuación, se presentan las principales diferencias entre ambos modelos:


CISSP Lineal
CISSP CAT
Cantidad de preguntas
250 preguntas (con 25 preguntas de prueba no contabilizadas ni explícitamente identificadas).
Entre 100 y 150 preguntas (con 25 preguntas de prueba no contabilizadas ni explícitamente identificadas).
Tiempo máximo disponible para contestar
6 horas
3 horas
Criterio de aprobación
700 sobre 1000 puntos
El examen termina cuando se puede determinar con una confianza del 95% que el rendimiento de un candidato está por encima o por debajo del estándar de aprobación, sin importar el número de ítems respondidos o transcurrido la cantidad de tiempo de la sesión de examen.
¿Se cuenta el tiempo de descansos (breaks)?
SI
SI
¿Se permite la revisión/cambio de preguntas ya contestadas?
SI
NO
¿Se presentan preguntas organizadas por dominios?
NO
NO, las preguntas se esquematizan con base en las respuestas previas del candidato.
Precio
699 USD
699 USD

¿Cómo debo prepararme para presentar el examen de la certificación CISSP en formato CAT?

La preparación del candidato no debe variar respecto a la presentación del examen en formato lineal. No obstante, si es importante tener en cuenta algunos puntos:
  • Debido a que no se permite la revisión de preguntas ya contestadas (ya que el algoritmo ajusta la pregunta futura con base en la respuesta inmediatamente anterior) el candidato deberá estar completamente seguro de su respuesta antes de avanzar.
  • Ya que la adaptación de las preguntas a la capacidad del candidato es la característica clave de este nuevo modelo, el estudio se debe focalizar en aquellos dominios del CBK en los que el candidato se siente con menos confianza.
  • Debido a que el tiempo de presentación del examen y la cantidad de preguntas se acortan, es importante gestionar muy bien el tiempo y no bloquearse en una pregunta.
¿En dónde puedo obtener más información al respecto?

El (ISC)2 ha publicado una guía y preguntas de uso frecuente (FAQ) en su sitio web, con relación al cambio del examen al formato CAT. Esta información puede ser consultada en la siguiente URL: https://www.isc2.org/Certifications/CISSP/CISSP-Cat

Finalmente, ¿el examen en formato CAT es más difícil que en formato lineal?

En principio, no. Como tal, en ambos formatos se parte de la premisa en la que se debe superar un umbral de aprobación. Este umbral en el formato lineal se evalúa al final de las 250 preguntas, mientras que en el formato CAT se va evaluando en cada pregunta con base en un estándar de aprobación.
Por otro lado, tanto las preguntas del examen lineal como del examen CAT provienen del mismo banco global de preguntas. Es decir: no se tendrán preguntas exclusivas para ninguno de los dos formatos del examen.


David Eduardo Acosta 
CISSP Instructor, CISM, CISA, CRISC, CHFI Instructor, CEH, PCI QSA, OPST, BS25999 L.A.
Depto. Consultoría


lunes, 4 de diciembre de 2017

Luis Enrique Benítez Jaspe entrevistado en diario ARA.cat durante el congreso NoConName

El pasado 24 y 25 de noviembre Luis E. Benítez, del departamento de Auditoría, participó como ponente en el congreso de seguridad informática NoConName, con un tema que nos afecta a todos. ¿Sabe qué tan vulnerables son sus electrodomésticos de ser hackeados y afectar su seguridad?.
El diario ARA.cat lo entrevistó durante el evento, haciendo enfoque en esta investigación.

Luis Benítez ha realizado una serie de investigaciones con un televisor, una barra de sonido, una lavadora, entre otros, que le han ayudado a descubrir cómo estos sencillos elementos que nos acompañan diariamente afectan nuestra seguridad y privacidad sin que sea notorio a simple vista.

Actualmente la mayoría de los electrodomésticos que adquirimos ya vienen con sensores que suministran a la empresa nuestros datos personales y de uso, monitoreando nuestras acciones diarias, convirtiéndose en una falta de respeto por nuestra intimidad y afectando considerablemente nuestra seguridad.



viernes, 1 de diciembre de 2017

Ciberseguridad en los coches inteligentes: Pasado, Presente y Futuro

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.

  • En caso de existir dicha justificación operacional, las interfaces de acceso tendrían que ser protegidas para que solamente los usuarios autorizados puedan tener acceso.
  • Claves de control
  • Cualquier clave o contraseña que pudiere permitir el acceso no autorizado en las plataformas de computación de los vehículos, deberá ser protegida ante su revelación. Además, cualquier clave que pudiere ser obtenida de la plataforma de computación de un vehículo, no debe facilitar acceso a otros vehículos.
  • 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.

  • Por ejemplo, para la evaluación del sistema de frenado, no hace falta probar todos los frenos a la vez, ni tampoco permitir hacerlo a 120 km/h. Así pues, y con el fin de evitar las consecuencias de un uso no autorizado de estas, la prueba debería estar confeccionada de modo que solamente opere a bajas velocidades, y que no bloquee todos los frenos en el mismo momento. En otras palabras, acotar y limitar al máximo posible el entorno de pruebas para evitar posibles ramificaciones.
  • 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.

  • Además, se recomienda el uso de prácticas de codificación seguras y el uso de encriptación completa del disco para todos los medios externos no-volátiles.
  • Limitar la capacidad de modificar el firmware
  • Con el fin de limitar la capacidad de modificar el firmware, se recomienda el uso de técnicas de firma digital, para prevenir que los vehículos ejecuten firmware modificado y/o no autorizado. También se recomienda que los sistemas de instalación del firmware utilicen dichas técnicas de firma de código para evitar la instalación de versiones no autorizadas.
  • Controlar la proliferación de puertos, protocolos y servicios de red
  • El uso de servidores de red en la ECU de los vehículos debe encontrarse limitado a las funcionalidades esenciales, y los servicios ofrecidos en dichos puertos tienen que ser asegurados para prevenir el uso por partes no autorizadas. Además, todos los servicios que no sean estrictamente necesarios deberían ser eliminados.
  • Uso de técnicas de segmentación y de aislamiento en el diseño de la arquitectura de los vehículos
  • Separación de privilegios con empleo de controles perimetrales y técnicas de aislamiento físico y lógico para separar los procesadores, las redes del vehículo, y todas las conexiones externas de una forma apropiada.
  • Controlar las comunicaciones internas de los vehículos
  • Se debe evitar el envío de mensajes críticos de seguridad en los buses de datos comunes, recomendando que se si se tienen que enviar este tipo de mensajes, se haga a través de buses de comunicación debidamente segmentados de cualquier ECU que disponga de interfaces de conexión de red externas. En caso de no ser posible, se debería emplear un sistema de autenticación de mensajes para limitar la posibilidad de ataques de suplantación de identidad.
  • Registro de eventos
  • Se debe conservar un conjunto de registros suficientes para poder trazar cualquier ataque de ciberseguridad o cualquier brecha de seguridad que pudiere ocasionarse, y mantenerlo y revisarlo periódicamente por parte de personal capacitado.
  • Control de la comunicación realizada hacía servidores de Back-End
  • Se deben usar métodos de encriptación, reconocidos por los estándares internacionales, entre los servicios externos y el vehículo.
  • Control de interfaces inalámbricas
  • Se deberían realizar controles detallados, a muy bajo nivel, en todas las conexiones de los vehículos con redes móviles.
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