15 recomendaciones de seguridad para crear una plataforma telemática sólida ante las ciberamenazas

Los vehículos conectados tienen un sinfín de nuevos beneficios, como seguridad, eficiencia y demás ventajas. Sin embargo, los vehículos conectados a Internet han puesto de manifiesto una serie de preocupaciones sobre ciberseguridad que han originado un debate en toda la industria. El FBI, NHTSA y NAFA, entre otras organizaciones, ya han hecho públicas sus preocupaciones. En particular, el FBI ha recomendado que "las personas propietarias de los vehículos tienen que verificar las políticas de seguridad y privacidad de dispositivos fabricados y proveedores de servicios de terceros, y no deben conectar ningún dispositivo desconocido o sospechoso al puerto OBDII". De manera similar, la NAFA recomienda que "los equipos de gestión de flotas deben tener políticas establecidas para asegurar que solo los dispositivos verificados se conectan a ese puerto". Con este artículo, queremos presentar nuestra aportación sobre este tema.

Sabemos que para las personas propietarias de los vehículos y los equipos de gestión de flotas puede ser todo un reto saber qué tienen que tener en cuenta cuando quieran comprobar las políticas de seguridad y medidas relacionadas con su plataforma telemática. El propósito de este artículo es ofrecer esa ayuda e invitar a seguir con el debate sobre qué puede y debe hacer la industria telemática al completo para mejorar la seguridad.

En el pasado, la industria telemática ha confiado totalmente en las redes 3G inalámbricas y nuevas infraestructuras móviles que ofrecen medidas de seguridad. Sin embargo, GSM nos ha mostrado que la infraestructura móvil, como cualquier otro sistema conectado, no es inmune a infracciones de seguridad y que hay mucho más que hacer. Hemos invertido bastante tiempo y esfuerzo en estudiar este problema y hemos hablado con personas expertas para poder presentar estas 15 recomendaciones de seguridad para tener una plataforma de seguridad sólida.

1. Implementar transmisiones de datos seguras

Si se implementa una transmisión de datos encriptada, tendrá privacidad de datos, independientemente del estado de la red móvil o cualquier otro tipo de sistema de conexión intermediaria. Al implementar una autenticación, se verifica que las fuentes de datos y destinos recibidos/enviados son de confianza. Consulta las recomendaciones de NIST para conocer los algoritmos de encriptación y autenticación. 

Usa librerías estándar siempre que sea posible. Si escribes tus propios algoritmos, te llevará mucho tiempo y es muy difícil que se implementen de manera correcta. Quizá haya elementos en el sistema en donde los métodos estándares no cumplen los requisitos o no son compatibles, por lo que tienes que asegurarte de que terceros realizan un test de penetración. Es mucho mejor haber identificado y corregido los problemas, antes de tener un grave problema de seguridad.

2. Actualizar las firmas digitales

Tener actualizadas las aplicaciones de firma digital es un elemento clave en la seguridad de tu dispositivo telemático. Las infracciones en la comunicación de datos, da igual la importancia, limitan a que la persona que lo hace opere en el conjunto de funcionalidades del dispositivo. Muchas veces, los ataques más peligrosos en sistemas integrados necesitan que se instale la imagen peligrosa de una aplicación o del firmware. Esto puede permitir a esa persona activar elementos del sistema que no se usan o están restringidos por el diseño por razones de seguridad.

Las actualizaciones de las aplicaciones de firma permiten a los dispositivos verificar que las actualizaciones vienen de una fuente segura. Para más información sobre los algoritmos correctos que usar para las firmas, consulta estas recomendaciones de NIST. Es importante implementar un proceso interno seguro de firma y un lugar de almacenamiento principal para minimizar las amenazas internas.

3. Activar protección de hardware con código

Si el microcontrolador es compatible, la función de leer el código del firmware del dispositivo debería estar desactivada. Al activar la protección con código en el microcontrolador, se limita en gran medida la posibilidad de que un infractor realice ingeniería inversa en los dispositivos porque ya no tendrá un fácil acceso al código. Esta es una magnífica herramienta para protegerse ante las personas con amenazas de bajos recursos/habilidades, pero resulta muy poco beneficiosa para aquellas con amenazas de recursos/habilidades medias (o superiores). Hay empresas que pueden extraer el código de varios procesadores protegidos con código a cambio de dinero. Es un muy buen ejemplo de por qué siempre debes tener en cuenta que el infractor conoce al dedillo la implementación de tu sistema.

4. Asumir que tu código es público

La seguridad implementada a la fuerza y de mala manera es una solución muy volátil. Los elementos de seguridad se tienen que diseñar teniendo en cuenta que el infractor conoce muy bien tu sistema y ya tiene acceso a todo el código. Incluso si consideras que los equipos internos y repositorios tienen un estado seguro, no lo serían en el pasado o no lo serán en el futuro. Cualquier persona que trabajara en la empresa ha podido tener la oportunidad de copiar el código del sistema en sus equipos de casa.

5. Usar números aleatorios infranqueables desde el punto de vista criptográfico

Generar números de manera aleatoria se usa en muchos de los algoritmos de seguridad. Es importante que la fuente de esos números aleatorios pueda ofrecer números aleatorios infranqueables desde el punto de vista criptográfico. Si estos números generados de manera aleatoria no lo son (no lo suficientemente aleatorios), la solidez de esos algoritmos que usan esos números aleatorios se verá mermada.

6. Personalizar los datos más vulnerables

Los datos más vulnerables como las claves de encriptación y los tokens de autenticación deben ser únicos para cada dispositivo. Si un solo dispositivo se ve comprometido, nunca debería poner en peligro a ningún otro dispositivo o parte del ecosistema. Los sistemas integrados, en particular, se caracterizan por usar una sola clave en muchos dispositivos. 

7. Usar diferentes claves para diferentes funciones

Poner en peligro un solo elemento de la lógica de seguridad nunca debería afectar a ningún otro. Se tienen que usar diferentes claves para diferentes funciones. Por ejemplo, la misma clave no se debe usar para los puertos de comunicación como para la aplicación de firmas.

8. Controlar los metadatos

Poder ser capaz de detectar y actuar rápidamente en cualquier situación de peligro es muy importante para minimizar los daños ya causados por las amenazas. Buscar de manera activa errores o tendencias cuando se depura la información puede reducir o prevenir el daño que conlleva un ataque. Hay muchos servicios de procesamiento en la nube disponibles que son capaces de monitorizar grandes cantidades de datos de rendimiento en tiempo real. Crear servicios que avisen a las personas correctas cuando se detectan los errores y las anomalías es crucial para identificar los ataques más pronto.

9. Desactivar funciones de depuración

Los modos y datos de depuración son una parte esencial del desarrollo, resolución de problemas y verificación de las funcionalidades. También son muy buenas herramientas para detectar anomalías en el sistema. De todas formas, la lógica relativa a la depuración puede subestimarse un tanto desde el punto de vista de la seguridad. Esta lógica, que contiene información clave sobre seguridad, puede no estar disponible durante la etapa de producción de software.

10. Realizar una auditoría a terceros

Es importante que todos los componentes del sistema relacionados con la seguridad pasen una auditoría. Compartir tu código con una empresa de terceros profesional para que lo revisen puede ser la mejor idea porque tu sistema tiene que estar diseñado para saber que cualquier ataque se hace porque conocen tu código base al completo. Identificar las vulnerabilidades y corregirlas en privado es mucho mejor que tener problemas de seguridad. Hay que aplicar una contramedida dentro de un plazo razonable a todas aquellas vulnerabilidades que se identifiquen con un riesgo inaceptable.

11. Limitar el acceso a los servidores

Se debe establecer una jerarquía interna de cuentas que permita el acceso a servidores/funciones backend solo a aquellas personas que lo necesiten. La autenticación multifactor es una herramienta muy potente para controlar el acceso. Hay varios tipos de hardware o aplicaciones para móviles que se pueden usar para este fin. Los registros de acceso a los servidores son esenciales para el análisis forense de cualquier actividad sospechosa en las cuentas.

12. Establecer prácticas de diseño seguras

La seguridad se debe tener en cuenta en la fase de diseño y no al final del proyecto. Si se aplica el principio de mínimo privilegio, se garantiza que cada elemento del sistema permite acceso solo a aquellas personas que realmente lo necesitan. No confíe en ninguna entrada al sistema que limite el número de formas en las que un ataque puede testear tu sistema.

13. Implementar soporte para las actualizaciones de software/firmware

No es realista asumir que un sistema es seguro al completo durante cualquier momento de su vida útil. Los problemas relacionados con la seguridad aparecerán y se tienen que poner en marcha procesos para arreglarlos. La capacidad de actualizar el software/firmware es una característica clave de seguridad en cualquier sistema conectado. Poder realizar este tipo de actualizaciones rápidas otorga un gran potencial para protegerse ante cualquier amenaza. Es importante que los fabricantes se responsabilicen del mantenimiento del firmware en el dispositivo; no se debe dejar en manos del usuario final la responsabilidad de garantizar la seguridad y actualizaciones de sus dispositivos, estas deben automatizarse en todos los dispositivos en uso. Los fabricantes de dispositivos telemáticos (y otros IoT, Internet de las cosas) tienen que responsabilizarse de sus propios parches de seguridad.

14. Verificar y testear

El código base del sistema está en constante cambio y tiene un proceso establecido de desarrollo. Si se revisa cada cambio, se podrán identificar muchos más problemas de antemano, así se evita que no puedan ni tener la oportunidad de convertirse en errores mayores. El testeo de la unidad es también un paso importante para garantizar que la lógica de seguridad es funcional, esta se debe establecer en los niveles de código y hardware para que cubra todo al completo.

15. Desarrollar una cultura de seguridad

Incluso aquellos sistemas diseñados con seguridad de última generación tienen algún tipo de incidencia en el desarrollo de sus operaciones. Toda persona de la empresa que tenga acceso a la red (no solo el equipo de desarrollo de seguridad) tiene que formarse y pasar una evaluación de forma regular en sus conocimientos sobre las prácticas seguras de uso de Internet. Esto incluye resistencia a los ataques de fraude electrónico (phishing), usar contraseñas muy seguras, conocer las URL a las que se entra y prestar atención a los certificados de seguridad. La formación individual está bien, pero hacer que tus equipos se interesen por la seguridad y la tengan en cuenta es algo vital.

Si quieres seguir leyendo sobre el tema, consulta este whitepaper: Buenas prácticas de ciberseguridad en el ámbito de telemática y la gestión de flotas.

Creemos que estas recomendaciones son muy importantes y te ayudarán a tener una plataforma telemática sólida ante las ciberamenazas, de todas maneras, la formación y mejora hay que también tenerlas en cuenta a la hora de mantener los sistemas y a los usuarios seguros. Y esto debe ser un esfuerzo a nivel de industria. Por lo que, si tienes alguna idea o proyecto relacionado con la concienciación sobre la seguridad, por favor, no dudes en ponerte en contacto con nosotros.