Seleccionar página

Una nueva solución para evitar “Supply Chain Attacks” y asegurar la integridad del firmware/software que se instala en entonos OT / Críticos

Fue en noviembre de 2014, cuando publicamos esta entrada en la que explicábamos cómo la APT Dragonfly había sido capaz de:

  1. Acceder a las zonas de descargar de firmware de las compañías Mesa Imaging (proveedor de cámaras utilizadas para visión guiada de vehículos en entornos industriales), eWon y MB Connect (proveedores de soluciones para el acceso remoto y telemantenimiento de entornos industriales).
  2. Modificar el software/firmware (drivers principalmente) legítimo y los certificados expedidos por los fabricantes, incluyendo en el firmware un malware malicioso (un troyano en particular).
  3. Proporcionar a los usuarios el acceso a este firmware “modificado”, de manera que la infección se realizaba a través de la descarga e instalación de dicho firmware no legítimo.

La astucia del grupo APT junto, probablemente, la ausencia de procedimientos y sistemas que permitieran comparar la función Hash primigenia proporcionada por el fabricante con la que se obtendría tras descargar el firmware, hicieron que diferentes empresas de los sectores farmacéutico, alimentación, bebidas y aguas, fueran infectadas.

Este tipo de ataques, conocido como “Supply Chain Attack” es cada vez más usual. De hecho, en el último informe publicado por ENISA (ENISA Landscape 2018), se hace mención en varias ocasiones a este tipo de amenaza.

Con el objetivo de evitar este tipo de ataques, el fundador de Tofino Eric Byres, en colaboración con el DHS (Department of Homeland Security) ha creado una nueva compañía llamada Adolus que ha desarrollado una solución denominada FACT (Framework for Analysis and Coordinated Trust).

¿Cómo funciona FACT?

De forma resumida FACT funciona así:

  1. Las fabricantes que desarrollan software o dispositivos que contienen firmware/software se suscriben al servicio aDolus (a través de la solución FACT).
  2. Las empresas (usuarios finales) que utilizan estos software/dispositivos pueden validar los parches y actualizaciones de software nuevos antes de instalarlos en equipos críticos.

En la siguiente figura, accesible aquí, se resume cómo funciona FACT.

A) Los “Vendors” crean un Digital Fingerprint

Los fabricantes certificados por Adolus crean un “digital fingerprint” del software/firmware legítimo que han desarrollado. La transferencia de este “digital fingerprint” es realizada mediante una comunicación encriptada al servidor de Adolus.

B) FACT verifica la autenticidad del firmware/software

Dentro de FACT, se verifica la autenticidad de los archivos remitido y se guarda en lo que se denomina “Trust Repository”.

Desde el Trust Repository se procede a analizar y a entender en profundidad los sub-componentes del software y si contiene vulnerabilidades.

C) El “Asset Owner” comprueba la integridad del firmware/software que quiere instalar.

Dentro de FACT el usuario se descarga el firmware/software que quiere incorporar/actualizar en su entorno crítico o de producción de la manera habitual (DVD, descarga, ISO, etc.).
Con el firmware/software descargado, accede a FACT y con la herramienta cliente, crea su propio “digital fingerprinting” de dicho firmware/software.

D) FACT lleva a cabo la comparativa entre ambos Digital Fingerprints

FACT compara el digital fingerprint del fabricante (ubicado en el Trust Repository) con el digital fingerprinting generado por el usuario.
Si coinciden, el software/firmware es legítimo, en caso contrario, ha sido modificado o alterado. Además, FACT proporciona una puntuación del grado de seguridad del firmware/software, proporcionando un análisis de las principales vulnerabilidades encontradas.

¿Quieres ver un ejemplo?

A continuación, podemos un ejemplo de cómo se lleva a cabo este flujo en Adolus.

  1. Un usuario tiene que actualizar el firmware de un PLC de Rockwell. Le proporcionan este fichero “PN-85386.bin” para ello. ¿Es fiable?

2. En FACT se observa que el fichero posee un certificado expedido por el fabricante.

3. En el siguiente caso, se observa que el firmware que se quiere analizar, está compuesto por sub-módulos que contienen vulnerabilidades específicas, no siendo recomendable su instalación.

Sin duda las consultoras/ingenierías contamos con una excelente solución para asegurar que el software/firmware que se despliega en entornos críticos no ha sido manipulado. En paralelo, es absolutamente necesario contar con un modelo de control en el que se hayan diseñado y escrito políticas y procedimientos específicos que estandaricen la forma de trabajar cuando sea necesario actualizar o incorporar nuevo software/firmware en entornos OT.