Que no nos den gato por firmware

Los sistemas industriales no paran de evolucionar, los dispositivos industriales se han adaptado a estos cambios implementando hardware cada vez más versátil, delegando el peso de posibles cambios, adaptaciones a nuevos diseños y funcionalidades sobre el firmware.

Como citan algunos autores, un firmware no deja de ser un conjunto de instrucciones que permite la funcionalidad de un dispositivo embebido. Éste sería el encargado, por ejemplo, de iniciar proceso de boot, el arranque del sistema operativo o realizar cualquier operación para la que ha sido diseñado dicho dispositivo.

Una de las principales características de un firmware es su almacenado en memoria ROM, ya que cualquier cambio puede dejar el dispositivo sin funcionalidad o modificar la forma de gestionar el hardware de dicho dispositivo totalmente.

Tanto los desarrolladores y fabricantes, como los usuarios finales, deberán aportar medidas de protección ante la posible extracción y modificación de este firmware, como ya se explicó en artículos anteriores como Hardware Hacking en Sistemas de Control Industrial.

Habitualmente existen varias razones que pueden conducir a un cambio de firmware en un dispositivo industrial:

• Introducción de nuevas funcionalidades.
• Corrección de problemas detectados (no tienen que ser específicos de seguridad).
• Corrección de vulnerabilidades, bien sean públicas o por errores detectados.
• Otros.

Si bien, aparentemente, no todas las razones anteriores nos obligan a realizar un cambio en el firmware de nuestro dispositivo industrial; cada caso requerirá un tratamiento adecuado.

Cuando se trata de una corrección de vulnerabilidades, se debería entrar en un proceso previamente bien definido de análisis de riesgos. Dentro de este ciclo se deberán sopesar todas las variables dentro del análisis, como pueden ser probabilidad de explotación, impacto en el negocio, vector de ataque, etc. Este análisis determinará si se debe proceder a un cambio de firmware. No se debe interpretar que siempre se debe cambiar el firmware, sino que, dependiendo de la industria, el dispositivo y la vulnerabilidad, debería ser siempre un proceso de análisis de riesgos el que determine cómo actuar. Por ejemplo, si existe una vulnerabilidad en un dispositivo industrial que aplica solamente cuando una funcionalidad está activada, y, por la razón que sea, nuestro sistema industrial no está empleando dicha funcionalidad, el análisis de riesgos puede dar como resultado que se opte por no actualizar en ese momento y dejarlo para más adelante o esperar a la siguiente parada programada.

De igual forma, para otro sistema industrial, un cambio de versión donde se introducen nuevas funcionalidades puede ser prioritario y se debería realizar el cambio de firmware. Esto puede suceder por varias razones, bien porque resuelva una incompatibilidad, mitigue un riesgo alto, etc. Por ejemplo, si en una versión actualizada de firmware se introduce la versión 3 del protocolo SNMP, que se considera segura, antes no soportada, y este tipo de dispositivos era el único que todavía estaba en una versión insegura, dentro de dicha red, el análisis de riesgos podría determinar que es una razón más que legítima para un cambio de firmware, ya que podría mitigar un riesgo heredado alto, que pasaría a resolverse directamente.

Introducir un procedimiento medible, auditable y mantenerlo actualizado para determinar cuándo se debe llevar a cabo un cambio de firmware en un dispositivo, es una tarea inicial esencial, dentro del procedimiento de actualización.

Una vez tomada la decisión de instalar un nuevo firmware, ¿Se dispone de un procedimiento escrito que indique cómo se debe realizar y mecanismos de roll-back si este procedimiento falla? ¿Se dispone de un procedimiento de comprobación o mecanismo que permita determinar su autenticidad? ¿Realmente se dispone de información sobre qué se está instalando? ¿Quién es el encargado de realizar la instalación? ¿Quién realiza las pruebas de aceptación? A continuación, intentaremos resolver estas cuestiones.

Firmware, binarios, software/hardware, parche, actualización… Diferenciando términos

Como usuarios finales, nuestro deber es conocer en detalle la pieza de software que va a ser instalada, determinar las diferencias existentes entre binarios, parche, actualización o firmware.

Firmware

Cuando se trata de sistemas embebidos, dentro del propio firmware, normalmente, es distribuido tanto el kernel, como el sistema operativo, el bootloader, las librerías y las aplicaciones.

La forma común de distribuir el firmware es mediante ficheros en formato binario, pudiendo contener entre otros:

• Bootloader.
• Kernel.
• Binarios de espacio de usuario.
• Sistema de ficheros.
• Ficheros comprimidos.
• Archivos en texto plano.

Parches

Los “parches” son correcciones aplicadas a un dispositivo, pero no siempre implican un cambio de firmware, puede que sea un simple parche de una aplicación sobre un sistema operativo, o unos cambios en ciertas librerías, para la corrección de algún tipo de problema.

Actualizaciones

Las actualizaciones, al igual que lo comentado en los parches, no implican intrínsecamente un cambio del firmware de un dispositivo, pueden entregarse para realizar un cambio de funcionalidad sobre la aplicación o añadir mejoras mediante librerías.

Una de las principales diferencias entre los parches y las actualizaciones radica en el hecho que el parche corrige algún tipo de problema, de ahí proviene su nombre. En cambio, una actualización puede ser desarrollada simplemente para dotar de funcionalidades extra al dispositivo en cuestión.

Binarios

Es un tipo de fichero informático, la forma normal de entrega tanto de un parche, una actualización o un firmware hecho que suele causar la confusión entre estos términos.

Como se ha comentado, debemos ser conscientes de cuándo se va a realizar un cambio de firmware ya que el procedimiento, gestión de riesgos, pruebas en laboratorio, gestión de backup, etc., pueden ser diferentes a los realizados para un parche de sistema operativo o una actualización de una aplicación.

Aclarados un poco estos términos y sin pretender entrar en más detalle, centrémonos en la relevancia de conocer esta información y, lo más importante, disponer de todas las medidas de seguridad y los procedimientos necesarios para poder aplicarlos de una manera segura.

Asegurando la integridad durante el transporte

Existen varios puntos clave a la hora de instalar un nuevo firmware, pero el principal que se tiene que tener siempre en mente es la integridad.

Si un firmware va a ser instalado en nuestra infraestructura, éste pasa a formar parte de ella, por lo tanto, el proceso de desarrollo de dicho firmware y sobre todo el transporte de dicho firmware (digital o no), pasa a formar parte de nuestra ciberseguridad. Como parte de nuestro sistema se le deben aplicar los mismos mecanismos de seguridad: análisis de riesgos y resto de procedimientos definidos en nuestra política de seguridad. Los términos de chain of trust, software integrity y demás controles que aparecen en muchas de las normativas internacionales, hacen referencia a este hecho, a la cadena de confianza que proporciona el desarrollador de un nuevo firmware hasta que pasa a estar en nuestras manos.

Existen diversas formas de entrega de un nuevo firmware:

• Delegada al propio fabricante de manera remota: Es el desarrollador del nuevo firmware el encargado de subir directamente este firmware a la infraestructura. La principal desventaja de este método es la gestión del control de accesos a terceros, ya que es un punto nuevo de riesgo que tiene que ser contemplado.
• Delegada al propio fabricante de manera presencial: Este método implicaría a una persona física en el proceso de transporte e instalación del nuevo firmware. Los mayores inconvenientes son la gestión para coordinar a la persona encargada de instalación, el coste que conlleva y el posible desconocimiento de la infraestructura, para analizar los posibles riesgos.
• Entrega personal o “Llave en mano”: El desarrollador realiza una entrega personalizada, empleando a las personas y medios adecuados. (Medio extraíble cifrado y firmado, PC de fabricante con el nuevo firmware, etc.). La política de seguridad para el control de dispositivos extraíbles y la política de BYOD, será clave para la correcta gestión de este método de entrega.

Todas las formas anteriormente descritas son perfectamente válidas y son una opción empleada, aunque el más utilizado para la obtención de un nuevo firmware, suele ser mediante una descarga desde una página web de “confianza”. Pero seguro que todos hemos oído hablar de zero trust ¿verdad?, pues a poner y exigir medidas.

No disponemos de control sobre la página de la que descargamos, por lo que a parte de la confianza, ¿qué nos pueden ofrecer para asegurar la integridad de un firmware?

El mecanismo más utilizado es la realización, desde origen, de un resumen o hash del fichero que descargamos, en la mayoría de los casos suficiente, pero no es precisamente la solución más segura. Si un atacante es capaz de comprometer el servidor web desde el que se descarga el firmware, simplemente debería modificar el “md5”, por lo que, a priori, debemos poner algún medio adicional.

La integridad, en la medida de lo posible, debe ser aplicada al igual que la defensa, en varias capas. Distribuir por un canal seguro el firmware (exigiendo certificados reglados en servicios web, por ejemplo), requerir por otro canal el método de integridad robusto de dicho firmware (optando por “SHA256” en vez de md5 cuando sea posible), alguna medida adicional como firmware firmado o comprimido mediante una contraseña, etc. Cuantas más medidas de seguridad se apliquen o se exijan, mayor será la confiabilidad en la integridad del firmware.

Pero no es el único punto clave, exigir un desarrollo seguro a nuestro proveedor es parte de nuestro derecho, y, como tal, se pueden exigir estos requisitos de seguridad como medidas a contemplar.

Libre de fallos conocidos

Parece impensable adquirir algo que no funcione bien o que disponga de fallos cuando hablamos de un producto, pero ¿exigimos lo mismo cuando se trata de un firmware? Poner requisitos de calidad a la hora de disponer de un nuevo firmware nos puede ahorrar muchos problemas.

Cuando se realiza un análisis de riesgos o una auditoría de un dispositivo industrial, en muchas ocasiones, se comprueba que existen ciertos servicios instalados en versiones conocidas vulnerables. Al final es el cliente el que asume este riesgo, por lo que debe ser éste el que requiera un producto libre de fallos, al menos a día de entrega, y adicionalmente unas medidas que aseguren un ciclo de correcciones en tiempo y forma adecuados.

Por otro lado, como cliente, se debería tener un procedimiento bien definido para la instalación y pruebas de un nuevo firmware.

Las pruebas son el último punto clave a tratar, este proceso es, si cabe, uno de los más importantes en el procedimiento de instalación de un nuevo firmware, por desgracia no siempre es tomado con la relevancia que se merece.

1, 2, 3... ¡PROBANDO!

Como se ha venido comentando en otros artículos, disponer de un entorno de pruebas y realizar un plan de pruebas específico previo a instalar un nuevo firmware reducirá en gran medida futuros problemas.

Todo nuevo desarrollo se debería probar en origen, pero la casuística particular de cada entorno sería imposible simularla, por lo que las pruebas en destino, en un entorno controlado de test, es en muchas ocasiones la única forma de detectar posibles adversidades que puedan surgir.

Esta fase de test previa a la puesta en producción sería el momento ideal pare realizar las auditorías y comprobaciones anteriormente mencionadas.

Tener información sobre lo que se va a instalar exactamente, el formato de entrega, cómo ha sido la cadena de confianza, asegurar la integridad de lo recibido, exigir a los terceros implicados requisitos mínimos de seguridad bien definidos y realizar un plan de pruebas específico, reducirán el riesgo de muchos de los vectores de ataque utilizados.

Pero todo esto ya estaba contemplado en nuestra política de seguridad ¿Verdad?