CSAF: gestionar vulnerabilidades OT a base de PDFs no escala
Cada semana ocurre más o menos lo mismo.
Siemens publica un advisory, Schneider otro, Fortinet tres, Rockwell actualiza uno de la semana pasada y Microsoft publica sus parches. Y algún fabricante que nadie recordaba que estaba instalado en planta anuncia una vulnerabilidad crítica en un producto que lleva funcionando perfectamente desde 2014.
Entonces empieza la fiesta: ¿Tenemos ese modelo? ¿Qué versión? ¿En qué planta? ¿Ese firmware está afectado? ¿Existe parche? ¿Podemos instalarlo? ¿Obliga a reiniciar?
Y así, CVE tras CVE.
En IT ya es complicado, incluso con entornos relativamente homogéneos. Sin embargo, en OT, donde conviven equipos de múltiples fabricantes, versiones antiguas, ciclos de vida de quince o veinte años y ventanas de mantenimiento bastante limitadas, una operativa manual y selectiva dificulta su sostenibilidad a lo largo del tiempo, pudiendo derivar en un aumento del riesgo operativo.
Aquí es donde entra el Common Security Advisory Framework, o CSAF.
Y la idea, aunque el nombre suene bastante más complicado, es sencilla: que nuestras plataformas de gestión de vulnerabilidades puedan empezar a leer los advisories que hoy seguimos leyendo los humanos. Es decir, se trata de establecer un marco automatizado de intercambio directo de información entre proveedores y clientes. Un marco que se lleva impulsando en otros países como Alemania, donde la Oficina Federal de Seguridad de la Información (BSI) impulsa, estandariza y proporciona facilidades tecnológicas.
El problema no es conocer el CVE
Información sobre vulnerabilidades tenemos de sobra: CVE, CVSS, CWE, advisories de fabricantes, CERT, CISA, scanners, plataformas de vulnerability management, etc.
El problema es más meridiano. Supongamos una planta con 2.000 activos y productos de Siemens, Rockwell, Schneider, Phoenix Contact, Fortinet, Microsoft o VMware, entre otros.
Aparece una CVE. Saber que existe es fácil: te vas a la NVD, CISA, EUVD o INCIBE y allí aparecen las novedades bien relucientes. Lo complicado es responder rápido a lo que realmente importa:
¿Tengo exactamente la versión afectada? ¿Existe una versión corregida? ¿Hay workaround? ¿Puedo parchear sin afectar al proceso?
CSAF intenta convertir toda esa información en datos estructurados y procesables automáticamente, y no solo problemas de seguridad asociados a CVE, sino también a configuraciones de equipamiento. En lugar de limitarse a publicar un PDF o una página web, el fabricante puede distribuir un advisory en formato JSON, indicando productos, versiones, vulnerabilidades, estados y remediaciones.
Y aquí cambia bastante la película.
SBOM, CSAF y VEX no son lo mismo
Aquí conviene separar y aclarar conceptos.
Una SBOM responde principalmente a:
"¿Qué componentes contiene este producto?"
Un CVE identifica una vulnerabilidad de un componente de software.
Un VEX, que puede formar parte de este ecosistema, responde a una pregunta todavía más interesante:
"Vale, existe esa vulnerabilidad en uno de mis componentes. ¿Pero mi producto está realmente afectado?"
Finalmente, CSAF responde a:
"¿Qué vulnerabilidad existe, qué producto o versión afecta y qué recomienda hacer el fabricante?"
Esto es especialmente importante.
Un scanner puede detectar una librería vulnerable dentro de un producto y generar una alerta crítica.
CVSS 9 → Rojo → Prioridad máxima.
Hasta que el fabricante indica mediante VEX que la funcionalidad vulnerable no se utiliza, no es accesible o no puede explotarse en ese producto. Hay que señalar que el fabricante no dispone de información del contexto operativo del producto afectado.
El estado puede quedar marcado como not_affected, affected, fixed o under_investigation, y no es un simple matiz técnico: permite distinguir entre vulnerabilidades que realmente requieren actuación y aquellas que no afectan al producto, reduciendo ruido y evitando gestionar miles de alertas sin contexto.
Para automatizar hay un pequeño problema: hay que saber qué tenemos
Y volvemos otra vez al clásico de OT, el "archi famous" inventario.
CSAF puede utilizar diferentes mecanismos para identificar productos y componentes (CPE, PURL, hashes, SKU, referencias a SBOM, entre otros).
Eso permite construir un flujo bastante interesante:
Fabricante publica CSAF → La plataforma lo consume → Se correlaciona producto y versión → Se identifican los activos afectados → Se actualiza el riesgo → Y se propone remediación.
Fantástico, salvo que en nuestro inventario tengamos esto:
"PLC LÍNEA 4"
Fabricante: Siemens. Modelo: "creo que 1500". Firmware: vacío.
Entonces podemos tener el CSAF más perfecto del mundo, que da exactamente igual: no podemos correlacionar aquello que no hemos identificado correctamente.
Por eso automatizar la gestión de vulnerabilidades OT depende directamente de la calidad del inventario: fabricante, familia, modelo, revisión hardware, firmware, software instalado y relaciones entre activos.
En OT, "parche disponible" no es suficiente
CSAF también permite describir diferentes tipos de remediación. No todo tiene que terminar en "instala el parche": puede existir un vendor fix, un workaround, una mitigation, no existir todavía una solución o incluso no estar prevista. Incluso es posible proponer un simple cambio de configuración a un problema de seguridad.
También puede especificarse si una acción requiere reiniciar un componente o un sistema completo. Pero CSAF va más allá: estructura de forma clara los workarounds y mitigaciones alternativas validados por el fabricante. En IT esto puede parecer información adicional, pero en OT es información operacional crítica para proteger el activo sin necesidad de tocar el firmware.
En muchos entornos hay que comprobar compatibilidades, validar con el fabricante de maquinaria, disponer de backup, preparar rollback, probar previamente y coordinar una ventana de parada. Aquí es donde nos podemos apoyar en la norma como marco teórico ideal para realizar este proceso: la IEC 62443-2-3.
Si queremos una introducción y explicación mucho más cercana y descriptiva de este proceso, también podemos consultar el artículo "Security Issues and Software Updates Management in the Industrial Internet of Things (IIoT) Era", Sensors 20(24), de Mugarza et al. DOI: 10.3390/s20247160. En cada contexto se tendrá que materializar de una forma u otra dependiendo de muchos aspectos asociados al proceso.
Por eso una plataforma de vulnerabilidades industriales no debería limitarse a decir:
"CVSS 9. Parche disponible."
Gracias.
Necesitamos bastante más contexto.
Y después hay que priorizar
Automatizar la recepción y correlación de vulnerabilidades no significa automatizar ciegamente el parcheo.
CSAF mejora mucho la información disponible, pero la decisión sigue perteneciendo al propietario de la instalación.
Un CVSS 9 sobre un activo aislado y con controles compensatorios puede requerir menos urgencia que un CVSS 7,5 explotado activamente sobre un sistema crítico situado en una zona mal segmentada.
La priorización real debería combinar: severidad técnica + explotabilidad + exposición + criticidad del activo + arquitectura + controles compensatorios + impacto operacional.
Dicho de otra manera: CSAF mejora el dato. No sustituye el análisis de riesgo.
El objetivo real es acortar la ventana de exposición
Entre el primer paso y el último pueden pasar días, semanas o meses. Es ahí donde CSAF intenta automatizar buena parte de todo lo que ocurre en medio. No porque JSON tenga nada especialmente emocionante, sino porque un advisory que una máquina puede consumir, correlacionar y procesar automáticamente es bastante más útil que un PDF esperando en una bandeja de entrada.
¿Y qué cambia en una planta?
Imaginemos que mañana un fabricante publica una vulnerabilidad que afecta únicamente a determinadas versiones de firmware de una familia concreta de PLC.
Con un proceso manual, alguien tiene que localizar el advisory, interpretarlo, comprobar las versiones afectadas, cruzarlo con el inventario, identificar los equipos y decidir qué hacer. En una arquitectura más madura, CSAF automatiza gran parte de ese recorrido: la información se ingiere y correlaciona con el inventario, VEX descarta productos que el fabricante declara no afectados y las remediaciones se asocian directamente a los activos.
A partir de ahí, la plataforma puede añadir el contexto operacional necesario para priorizar. Eso se parece bastante más a una gestión continua de vulnerabilidades y bastante menos a ejecutar un scanner los viernes y generar otro Excel.
CSAF no resuelve todo, pero resuelve una parte importante
CSAF no sabe que el PLC de la línea de envasado no puede reiniciarse hasta Navidad. Tampoco sabe que aquella estación de ingeniería es la única que conserva una determinada versión de software. Y por supuesto tampoco sabe que una vulnerabilidad aparentemente media afecta al activo que controla la parte más crítica del proceso.
Eso sigue siendo responsabilidad del propietario.
Pero sí ayuda a resolver algo mucho más básico que todavía hacemos demasiado a mano: conseguir que fabricantes y propietarios hablen el mismo idioma cuando aparece una vulnerabilidad. En una instalación con cientos o miles de activos y decenas de fabricantes, no es poca cosa.
Porque el futuro de la gestión de vulnerabilidades OT probablemente no consiste en contratar a más personas para leer más advisories y gestionar cientos de vulnerabilidades. Consiste en conseguir que inventario, SBOM, CSAF, VEX y contexto operacional trabajen juntos, y dejar a las personas la parte para la que realmente hacen falta: decidir qué riesgo importa y qué hacemos con él.
Comentarios
Publicar un comentario