15 recomendaciones de ciberseguridad para una plataforma telemática resistente a las ciberamenazas

Los vehículos conectados presentan innumerables ventajas como la seguridad, la eficiencia y la comodidad. Sin embargo, la conexión de los vehículos a Internet ha arrastrado consigo diversas preocupaciones relacionadas con la ciberseguridad, abriendo un amplio debate en el sector. El FBI, la NHTSA y la NAFA, entre otros, han manifestado abiertamente su preocupación. En concreto, el FBI recomendó que los “propietarios de los vehículos consulten las políticas sobre seguridad y privacidad de otros fabricantes de dispositivos y proveedores de servicios y que no conecten al puerto OBD II ningún dispositivo desconocido o que no fuese de su confianza”. En la misma línea, la NAFA recomienda que los “administradores de la flota apliquen políticas que garanticen que únicamente se conecten al puerto dispositivos seguros”. Este blog es, en parte, un punto de partida para este debate.

No cabe duda de que para los propietarios de los vehículos y los administradores de la flota supone todo un reto saber en qué se deben fijar exactamente cuando evalúan las políticas y las medidas de seguridad relacionadas con la plataforma telemática. El objetivo de este blog es ofrecer orientación en este sentido y fomentar el debate sobre cómo debe evolucionar la seguridad en el sector de la telemática en su conjunto.

El sector de la telemática solía basarse mayormente en redes inalámbricas 3G y en nuevas infraestructuras celulares que proporcionaban una medida de seguridad. No obstante, el GSM ha demostrado que la infraestructura celular, al igual que cualquier otro sistema conectado, no es inmune a los ataques y que es necesario seguir trabajando. Tras haber dedicado una gran cantidad de tiempo y esfuerzo a estudiar el problema y a analizarlo con otros expertos, presentamos estas 15 recomendaciones sobre seguridad para crear una plataforma telemática resistente.

1. Implementar una transferencia de datos segura

La implementación de un cifrado de datos para sockets contribuye a la privacidad de los datos con independencia del estado de la red celular o de cualquier otro soporte intermedio de conexión. El uso de un sistema de autenticación servirá para verificar que tanto las fuentes de los datos recibidos y transmitidos, como sus destinos sean realmente los que parecen ser. Para profundizar en el tema, consulta las recomendaciones del NIST sobre los algoritmos aceptables de cifrado y autenticación.5

Utiliza bibliotecas estándar siempre que sea posible. Desarrollar algoritmos propios requiere mucho tiempo y es difícil de implementarlos correctamente. Si el sistema contiene elementos en los que los enfoques estándar no cumplen los requisitos o no son compatibles, asegúrese de contar con uno o varios de terceros que realicen pruebas de penetración. Siempre es mejor identificar y solucionar los problemas antes de que alguien encuentre un modo de aprovecharlos.

2. Firmar digitalmente las actualizaciones

La firma digital de las actualizaciones de una aplicación es un aspecto fundamental de la seguridad de los dispositivos telemáticos. Cuando se interceptan las comunicaciones de datos, por muy peligroso que sea el ataque, se limitará el conjunto de funciones del dispositivo. Con frecuencia, los ataques más peligrosos de los sistemas embebidos requieren la inserción de una aplicación maliciosa o una imagen de firmware. De este modo, un atacante puede activar elementos del sistema que el desarrollo no había previsto o que había restringido por motivos de seguridad.

La firma de las actualizaciones de una aplicación permite que los dispositivos verifiquen si la actualización procede de una fuente de confianza. Si deseas obtener más información sobre los algoritmos que se pueden utilizar en la firma, consulta estas recomendaciones del NIST.5 Es importante implementar un proceso interno y seguro de firma, así como una ubicación clave de almacenamiento a fin de minimizar las amenazas internas.

3. Habilitar la protección del código de hardware

Si lo permite el microcontrolador, se debe desactivar la capacidad para leer el código del firmware desde el dispositivo. Al habilitar la protección del código en el microcontrolador se limita en gran medida la capacidad del atacante para realizar procesos de ingeniería inversa, ya que no dispone de acceso al código. Es una herramienta fantástica a la hora de protegerse frente a amenazas de personas con escasos recursos o conocimientos, pero resulta de poca utilidad cuando se trata de personas con recursos y conocimientos medios o altos. Existen empresas que prestan servicios de pago mediante los cuales extraen el código de varios procesadores con código protegido. Es un ejemplo perfecto de por qué debemos suponer siempre que los atacantes conocen a la perfección cómo se ha implementado nuestro sistema.

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

La seguridad implementada en un entorno poco claro es una solución muy débil. Los elementos de seguridad se deben diseñar dando por sentado que el atacante conoce todo nuestro sistema y que ya puede acceder a todo el código. Aunque en el momento presente pensemos que el estado de las máquinas y los repositorios internos es seguro, puede que esto no haya sido así en el pasado o que no vaya a serlo en el futuro. Un antiguo empleado puede haber tenido la oportunidad de copiar el código del sistema en el equipo de su casa.

5. Utilizar números aleatorios criptográficamente seguros

Son muchos los algoritmos de seguridad que utilizan la generación aleatoria de números. Es importante que la fuente de números aleatorios pueda proporcionar números criptográficamente seguros, ya que, si no lo son (si «no son suficientemente aleatorios»), se pueden debilitar drásticamente los puntos fuertes de los algoritmos que utilizan dichos números aleatorios.

6. Individualizar datos críticos para la seguridad

Los datos críticos para la seguridad, como por ejemplo las claves de cifrado y los tokens de autenticación, deben ser únicos para cada dispositivo. El hecho de que un dispositivo esté en riesgo no debe afectar nunca a los demás dispositivos ni a una parte del ecosistema. Los sistemas embebidos son especialmente conocidos por utilizar una clave para varios dispositivos.

7. Utilizar claves diferentes para roles distintos

El riesgo de un elemento de la lógica de seguridad no debe afectar nunca a los demás elementos. Los distintos roles deben tener claves diferentes. Por ejemplo, no se debe utilizar para la comunicación entre sockets la misma clave que para la firma de aplicaciones.

8. Supervisar los metadatos

Ser capaz de detectar y reaccionar con tiempo ante las actividades sospechosas es fundamental para minimizar los daños provocados por agentes maliciosos. La búsqueda activa de errores o tendencias en la información de depuración puede reducir los daños de un ataque o evitarlos por completo. Existen numerosos servicios de procesamiento disponibles en la nube para poder supervisar en tiempo real grandes cantidades de datos sobre rendimiento. La creación de servicios que notifican a las personas adecuadas la detección de errores o anomalías es crucial para identificar a tiempo los ataques.

9. Deshabilitar las funciones de depuración

Los datos y los modos de depuración constituyen una parte fundamental del desarrollo, la resolución de problemas y la verificación de la funcionalidad. También son una herramienta fantástica para detectar anomalías en un sistema. Sin embargo, la lógica relacionada con la depuración se suele pasar por alto desde el punto de vista de la seguridad. La lógica de depuración que contiene información crítica para la seguridad no debe estar accesible en las versiones del software de producción.

10. Encargar auditorías a terceros

Se deben auditar correctamente todos los componentes del sistema pertinentes para la seguridad. No debemos tener reticencias a la hora de revelar el código a un tercero profesional ya que debemos diseñar el sistema dando por sentado que el atacante conoce todo el código base. Siempre es mejor descubrir y solucionar nuestras vulnerabilidades en privado. Si se identifican vulnerabilidades con un riesgo inaceptable, se deben implementar medidas en un plazo de tiempo razonable.

11. Limitar el acceso al servidor

La jerarquía de cuentas internas se debe implementar de tal forma que solo dispongan de acceso a las funciones y los servidores de backend aquellas personas que lo necesitan. La autenticación de factores múltiples es una herramienta muy potente para controlar el acceso. Para ello se pueden utilizar diversas aplicaciones de teléfono celular o hardware. Los registros de inicios de sesión en los servidores son fundamentales para realizar un análisis forense de la actividad sospechosa de una cuenta.

12. Aplicar prácticas de diseño seguras

La seguridad se debe tener en cuenta ya en las fases de diseño, y no ser algo que se añade a posteriori. Aplique el principio de privilegios mínimos: garantizar que cada elemento del sistema solo permite acceder a aquellas personas que lo necesitan. Las posibilidades de que un atacante sondee su sistema no se deben restringir con medidas basadas en la introducción de datos por parte de los usuarios.

13. Implementar apoyo para las actualizaciones del software o el firmware

No es realista dar por sentado que un sistema va a ser totalmente seguro en cualquier momento de su vida. Surgirán problemas relacionados con la seguridad y debemos contar con un proceso para solucionarlos. La capacidad para actualizar el software y el firmware es una característica fundamental de la seguridad en un sistema conectado. Poder realizar actualizaciones en poco tiempo tiene un valor incalculable a la hora de mitigar las amenazas del día cero. Es esencial que el fabricante sea responsable del mantenimiento del firmware del dispositivo. La responsabilidad de la actualización y la seguridad del dispositivo no debe recaer en el usuario final, ya que las actualizaciones se deben aplicar de forma automática en todos los dispositivos de campo. Los fabricantes de los dispositivos telemáticos (u otros dispositivos de Internet de las cosas) deben ser responsables de sus propias áreas de seguridad.

14. Verificar y comprobar

El código base del sistema cambia constantemente. Es necesario contar con un proceso formal de desarrollo. Con las revisiones de los cambios por parte de homólogos se identificarán innumerables problemas antes de que puedan causar ningún daño. La comprobación de las unidades también es fundamental para garantizar que la lógica de seguridad sigue siendo funcional. Dicha comprobación se debe configurar tanto a nivel de código, como de hardware para disponer de una cobertura integral.

15. Desarrollar una cultura de seguridad

Incluso los sistemas con el diseño más seguro pueden verse amenazados por las acciones de los usuarios. Todo el personal con acceso a la red (no solo los desarrolladores de seguridad) deben recibir periódicamente información sobre las prácticas seguras del uso de Internet y se deben comprobar sus conocimientos. Aquí se incluye la resistencia a los ataques por suplantación de la identidad, el uso de contraseñas seguras, el acceso consciente a las URL y la atención que se presta a los certificados de seguridad. La formación por sí sola es un buen punto de partida, pero resulta mucho más efectivo que el personal se interese por la seguridad y que sea consciente de ella.

Aunque consideramos que estas recomendaciones suponen un paso importante para que una plataforma telemática sea resistente ante las ciberamenazas, la formación y la mejora serán esenciales para la seguridad de los sistemas y sus usuarios. Este debe ser un trabajo de todo el sector.