Encontrar vulnerabilidades en los sistemas de control industrial (ICS) es más difícil de lo que muchas organizaciones consideran. La mayoría de los profesionales de la tecnología de la información (TI) y de la tecnología operativa (TO) confían en la Base de Datos Nacional de Vulnerabilidades (NVD), una gran base de datos que contiene la principal colección de vulnerabilidades del mundo, con la esperanza de identificar todas las vulnerabilidades asociadas a un producto de software o al firmware de un dispositivo. Lamentablemente, este enfoque es en su mayoría ineficaz por tres razones:
- El NVD está lejos de estar completo. Se estima que falta más del 75% de las vulnerabilidades de ICS (Artem Zinenko, Kaspersky Industrial Cybersecurity Conference, 2019).
- El NVD rara vez mapea las vulnerabilidades de los componentes a los productos que contienen esos componentes.
- Gracias a las fusiones y adquisiciones, el cambio de marca de los productos, e incluso simples errores tipográficos, el nombre del proveedor en el producto en su instalación es a menudo diferente del nombre del proveedor en los detalles del NVD o el listado de CPE.
Incluso para los analistas de seguridad experimentados, cotejar las vulnerabilidades con los productos instalados (o al revés) es ineficaz, propenso a errores, caro y terriblemente tedioso. En un sector en el que ya hay una escasez crítica de profesionales de la ciberseguridad, las empresas que les encargan la búsqueda de vulnerabilidades pueden encontrarse con problemas de retención de personal.
Afortunadamente, está surgiendo una alternativa a la investigación y gestión manual de vulnerabilidades. La inteligencia artificial (IA), que incluye el aprendizaje automático (ML) y el procesamiento del lenguaje natural, puede utilizarse para crear asociaciones de vulnerabilidad de forma rápida y exhaustiva.
El NVD es un lugar razonable para empezar, pero ¿qué nombre buscaría? GE es una opción obvia, pero hay muchos nombres asociados a General Electric. También podría probar con Fanuc. De la historia de estas dos empresas surge todo un abanico de convenciones de nomenclatura:
- Cuando GE y Fanuc unieron sus fuerzas, llamaron a su línea de productos GE Fanuc Automation, y unos años más tarde la renombraron GE Fanuc Intelligent Platform.
- En 2009, disolvieron la empresa conjunta. GE mantuvo la línea de productos pero cambió el nombre a GE Intelligent Platforms.
- Al adquirir Alstom en 2015, GE volvió a cambiar de marca, esta vez a GE Automation and Controls.
- Luego, en 2019, Emerson adquirió la cartera.
Además de toda la actividad de fusiones y adquisiciones y el cambio de marca, el error humano se suma al problema del espacio de nombres. Los ingenieros que escriben el nombre de la empresa no siempre son meticulosos con las comas, los puntos o los sufijos como Ltd. o Inc. Un ejemplo sorprendente es nuestro análisis del software de un importante proveedor de OT que encontró al menos 47 variaciones del nombre de la empresa utilizadas por los desarrolladores.
Con toda esta información, ¿qué nombre debe buscar? Si se lanza una red demasiado amplia y se prueba con GE, se obtendrán más de 130.000 resultados que paralizarán la búsqueda en la base de datos NVD. Si es demasiado específico, tendrá que probar muchos nombres diferentes con las distintas permutaciones de la puntuación, y la mayoría de ellos no le darán nada. Lo importante es entender que no estás buscando un solo nombre; estás buscando miles de nombres.
Alerta de spoiler: para averiguar si este PLC en particular tiene alguna vulnerabilidad listada en el NVD, tendrá que buscar usando "Emerson" como palabra clave.
Incluso así, este fue un hallazgo afortunado. Recuerde que el 75% de todas las vulnerabilidades ICS no aparecen en el NVD, por lo que sólo tiene un 25% de posibilidades de obtener un resultado.
La IA supera el problema del espacio de nombres
La columna vertebral de la gestión de la vulnerabilidad es una sólida gestión de los proveedores. Conocer a todos los proveedores que componen su cadena de suministro de software (y tener en cuenta la probabilidad de que haya errores tipográficos, nombres de marcas nuevas, etc.) le permite evaluar y remediar la posibilidad de explotar las vulnerabilidades identificadas.
Para encontrar vulnerabilidades de forma fiable y eficiente, y gestionar el riesgo que suponen para su negocio, es necesaria la inteligencia artificial (IA). aDolus ha utilizado la IA en su plataforma Framework for Analysis and Coordinated Trust (FACT) para perfeccionar los datos de los proveedores y hacerlos mucho más útiles que intentar buscar en el NVD. La plataforma identifica
- un nombre normalizado para cada proveedor.
- todas las variaciones y sinónimos de ese nombre normalizado.
- las relaciones entre los proveedores en el dinámico panorama de las fusiones y adquisiciones.
La plataforma realiza una compleja selección ponderada entre más de una docena de flujos de entrada para determinar el fabricante de un paquete. Entre ellos se encuentran el propio agente de procesamiento de archivos de aDolus, el emisor del certificado del archivo, los datos del antivirus, las ubicaciones de descarga de los proveedores, el remitente del archivo y la National Software Reference Library (NSRL), además de los alias en los nombres de los archivos, los nombres de los productos, las descripciones de los archivos, los derechos de autor y las marcas comerciales.
Cuando varios flujos de entrada coinciden en cuanto al autor de un paquete de software, podemos estar seguros de que es correcto. Cuando hay desacuerdo, el algoritmo de selección de proveedores de la IA evalúa los flujos de entrada de metadatos y determina el nombre correcto del fabricante del paquete.
Una vez establecida la base de gestión de proveedores, la plataforma busca proactivamente vulnerabilidades en diferentes bibliotecas, yendo más allá de las fuentes habituales como el NVD o los avisos del ICS-CERT, ya que muchas vulnerabilidades de ICS no aparecen en estas fuentes. A menudo estas búsquedas incluyen PDFs y otros avisos de vulnerabilidad textuales, lo que supone un nuevo reto de datos más desestructurados. Una vez más, la IA viene al rescate, con el procesamiento del lenguaje natural (NLP) en particular, que permite a un sistema de IA dar sentido a este texto.
Dar sentido al texto mediante tokens
El primer paso para procesar las palabras en inglés mediante la IA y la PNL es una técnica llamada "tokenización". La tokenización descompone el texto en bruto en trozos más pequeños llamados tokens. Éstos ayudan a la IA a crear un contexto para que pueda interpretar el significado del texto analizando la secuencia. Los tokens permiten a la IA convertir la información no estructurada (como un documento de texto) en una estructura de datos numéricos. Una vez que tiene eso, la PNL puede empezar a aprender lo que significan las palabras en relación con las demás.
Como ejemplo, la figura 4 muestra una selección de texto de un aviso sobre los conmutadores Stratix de Allen-Bradley. Para dar sentido a este texto, la IA de la plataforma aDolus lo convierte en tokens que puede reconocer:
"15.2(4a)EA5, Allen-Bradley, Stratix, 8300, Modular, Managed, Ethernet, Switches"
Una vez que tiene estos tokens, la IA debe ser capaz de reconocer de qué proveedor se está hablando. Las listas normalizadas de nombres de proveedores mencionadas anteriormente permiten a la IA inferir a partir de los tokens que uno de ellos es un proveedor, y el proveedor en cuestión es Allen-Bradley según el aviso.
Además, gracias a los nombres de proveedores normalizados, la IA sabe que Allen-Bradley es en realidad Allen-Bradley Company. Además, sabe que Allen-Bradley es una filial de Rockwell Automation. La plataforma puede ahora acceder a su colección de archivos para Rockwell Automation y utilizar los tokens que tiene para deducir más sobre el asesor comprobando los datos jerárquicos existentes en la base de datos de la plataforma.
La plataforma utiliza el token sobre Ethernet para deducir que el aviso tiene algo que ver con la red y las comunicaciones, y reconoce Stratix e incluso Stratix 8000 como productos del sistema (Figura 5). El token "15.2(4a)EA5" acota aún más la búsqueda a la versión de firmware a la que pertenece este aviso. Finalmente, la IA puede identificar un archivo probable en la plataforma (en este caso un archivo .tar) vinculado a una vulnerabilidad a través de un registro de vulnerabilidad y exposición común (CVE). Así, la plataforma realiza la conexión.
El aviso original era para Rockwell, que no está en el NVD. De hecho, los detalles del CVE no mencionan a Rockwell en absoluto.
A menos que esté utilizando un flujo de entrada diverso para las vulnerabilidades, sus capacidades de detección de vulnerabilidades no van a ser adecuadas, y es difícil buscar manualmente a través de tantas fuentes diferentes. Es mucho más fácil dejar que una máquina itere a través de estos para usted.
El futuro de la gestión de vulnerabilidades con IA
Identificar las vulnerabilidades en su cadena de suministro de software debería ser una prioridad. Los ataques a la cadena de suministro se han vuelto cada vez más frecuentes, con un aumento del 430% en solo 12 meses en 2020, según el Informe sobre el estado de la cadena de suministro de software 2020 de Sonatype, y estos ataques se están convirtiendo en noticias habituales de primera plana.
A medida que aumenta la presión normativa sobre los operadores de sistemas críticos y los proveedores que los suministran, el futuro de la gestión de vulnerabilidades debe incluir la IA. Una vez que estas técnicas estén en marcha para detectar y hacer coincidir los avisos de vulnerabilidad con productos concretos, se podrán obtener muchas más informaciones. Un ejemplo emergente es la creación de documentos VEX (Vulnerability Exploitability eXchange) para comunicar qué vulnerabilidades son realmente explotables y peligrosas.
Fuente: https://www.automation.com/en-us/articles/may-2022/how-ai-uncovers-ics-vulnerabilities