lunes, 24 de agosto de 2026

Sin inventario no hay defensa: qué dice la guía conjunta de CISA sobre inventario de activos OT



Nueve agencias de ciberseguridad de cinco países han firmado el mismo mensaje: la arquitectura defendible de una planta industrial empieza por saber qué hay dentro de ella. No por el firewall, no por el SOC, no por la segmentación. Por el inventario.

El 13 de agosto de 2025, CISA publicó junto a la EPA, la NSA, el FBI, el ACSC australiano, el Cyber Centre canadiense, el BSI alemán, el NCSC neerlandés y el NCSC neozelandés el documento "Foundations for OT Cybersecurity: Asset Inventory Guidance for Owners and Operators". Que el BSI y el NCSC-NL aparezcan como coautores no es un detalle menor para quien opera infraestructura en Europa: lo que se describe aquí no es una particularidad estadounidense, sino un consenso técnico transatlántico sobre por dónde se empieza.

Y el punto de partida es incómodo de tan evidente: sin inventario, una organización no sabe qué tiene y, por tanto, no sabe qué debe proteger.


Por qué el inventario OT es distinto del inventario IT

Cualquiera que haya intentado levantar un inventario en una planta sabe que el ejercicio no se parece al de un CPD. Los entornos OT acumulan sistemas heredados, dispositivos especializados, instrumentación y sensores que hablan protocolos propietarios. Muchos de esos equipos no responden a un escaneo, no admiten un agente y, si se les interroga mal, dejan de hacer lo único que se espera de ellos: controlar un proceso físico.

La guía lo reconoce sin rodeos: entender el papel de un componente en la monitorización y el control del proceso puede exigir inspección física de los activos y de las áreas de proceso asociadas. No hay atajo puramente digital.

A eso se añade el motivo por el que todo esto importa. El documento enumera los vectores que los atacantes explotan una y otra vez en OT:

- Vulnerabilidades en software y firmware desactualizado.

- Mecanismos de autenticación débiles.

- Segmentación insuficiente, que permite el salto lateral de IT a OT y entre sistemas OT.

- Protocolos industriales inseguros, que permiten interceptar comunicaciones e inyectar órdenes.

- Accesos remotos mal protegidos, usados como cabeza de puente.

Ninguno de esos cinco frentes se puede cerrar sobre un inventario incompleto. No se segmenta lo que no se ha cartografiado, ni se prioriza el parcheo de un equipo cuya existencia se desconoce.

 La aportación diferencial: la taxonomía OT

La parte realmente interesante del documento no es la lista de activos, sino la insistencia en acompañarla de una "taxonomía OT": un sistema de clasificación que ordena y prioriza los activos por función y criticidad, y que hace visibles sus relaciones y dependencias.

Un inventario responde a qué tengo. Una taxonomía responde a qué significa lo que tengo. La diferencia entre ambas cosas es exactamente la diferencia entre una hoja de cálculo con 4.000 filas y una herramienta de decisión.

Los beneficios que la guía atribuye a trabajar con taxonomía son cinco, y todos ellos tienen traducción directa en el día a día:




El punto sobre comunicación merece subrayarse. En la mayoría de las plantas donde trabajamos, el mayor obstáculo del inventario no es técnico: es que el ingeniero de proceso, el responsable de mantenimiento y el CISO llaman de tres maneras distintas al mismo armario. La taxonomía es, antes que nada, un acuerdo lingüístico.


Los cinco pasos del proceso

La guía propone una secuencia de cinco fases:

1. Definir alcance y objetivos. Identificar quién exige el inventario y qué áreas lo mantienen y se benefician de él; asignar roles y responsabilidades para la recogida y validación de datos; y fijar los límites del programa —zonas, instalaciones, sistemas, calendario— incluyendo la definición de qué se considera "activo" a estos efectos. Esta última decisión parece trivial y no lo es: ¿entra un transmisor de presión? ¿un variador? ¿un portátil de un integrador que se conecta dos veces al año?

2. Identificar activos y recopilar atributos. Inspección física más levantamiento lógico, compilando activos e infraestructura de red con sus dependencias.

3. Crear una taxonomía. Cinco subpasos: clasificar, categorizar, ordenar estructura y relaciones, validar y visualizar, y revisar periódicamente.

4. Gestionar y almacenar los datos. Identificar fuentes adicionales de información —contratos con integradores, manuales de fabricante, históricos de mantenimiento, especificaciones de configuración— y establecer una base de datos centralizada, protegida ella misma frente a amenazas.

5. Implantar la gestión de ciclo de vida. Definir las etapas de vida del activo (adquisición, despliegue, puesta en marcha, mantenimiento, retirada) y las políticas asociadas. Aquí hay una frase que conviene leer dos veces: el inventario debe actualizarse ante la introducción o retirada de cualquier dispositivo en todos los casos, incluso bajo autoridad de cambio de emergencia. Es precisamente en la urgencia cuando el inventario se degrada.


Clasificar y categorizar: criticidad, función, zonas y conductos

Para la clasificación, el documento plantea dos enfoques complementarios: por "criticidad" (impacto de su fallo o compromiso sobre operación, seguridad y misión) y por "función" (sistemas de control, comunicaciones, monitorización, ingeniería, mantenimiento, gestión).

Y para la categorización, CISA se apoya explícitamente en "IEC 62443" —en concreto en la parte 3-2— organizando los activos en zonas y conductos. Una zona agrupa activos con requisitos de seguridad comunes; un conducto agrupa los activos dedicados exclusivamente a las comunicaciones entre zonas, garantizando que solo pase el tráfico autorizado. Para determinar los conductos, hay que mapear las rutas de comunicación entre zonas incorporando análisis de flujos de datos, identificación de protocolos y detalles de nivel 2 y 3.

Para las organizaciones europeas, esto cierra un círculo útil: el mismo trabajo de inventario y taxonomía alimenta a la vez la respuesta a NIS2, el modelo de zonas y conductos de IEC 62443 y, en el caso español, la categorización de sistemas del ENS. No son tres proyectos. Es uno.


Qué campos recoger (y en qué orden)

El anexo A es probablemente la parte más aprovechable del documento en la práctica. Prioriza catorce campos como "alta prioridad":

- Protocolos de comunicación activos/soportados

- Criticidad del activo

- Número de activo (identificador único interno)

- Rol/tipo de activo (estación de ingeniería, PLC, historiador, switch, hipervisor…)

- Nombre de host

- Dirección IP

- Registro de logs

- Dirección MAC

- Fabricante

- Modelo

- Sistema operativo

- Ubicación física

- Puertos y servicios

- Cuentas de usuario


En prioridad "media" quedan frecuencia y tipo de copias de seguridad, imagen base, departamento propietario, distribuidor, versión de firmware/software, versión de sistema operativo, físico o virtual y VLAN. En prioridad "baja", antivirus/protección de endpoint, fecha de fabricación, hipervisor, zona horaria local, ubicación dentro del hipervisor, monitorización de red, notas, método principal de comunicación, número de serie y fuente de tiempo.

Dos matices sensatos que aporta el propio documento: los campos de protocolos y de puertos/servicios son costosísimos de levantar y mantener, así que recomienda empezar por los activos que se comunican fuera del perímetro IT/OT o con SCADA sobre WAN, y seguir después con el resto. Y sobre la fuente de tiempo —que muchos considerarían un dato menor— advierte que la interrupción de una referencia horaria externa y la deriva asociada pueden tener impactos significativos.


El inventario no es el final: es la materia prima

Una vez levantado, el documento detalla qué hacer con él. Y es aquí donde el inventario deja de ser un entregable de consultoría para convertirse en un activo operativo:

- Gestión de vulnerabilidades y riesgo. Cruzar el inventario con el catálogo KEV de CISA y con la base CVE de MITRE; explorar controles compensatorios para lo que no se puede parchear o está fuera de soporte; priorizar activos críticos y documentar planes de redundancia y de operación bajo compromiso; usar KEV como entrada autoritativa de un marco de priorización tipo SSVC.

- Priorización de amenazas mapeando patrones de ataque contra MITRE ATT&CK for ICS y CAPEC para sistemas de control.

- Mantenimiento y fiabilidad. Revisar los planes de mantenimiento a la luz de los hallazgos y programar mitigaciones en ventanas de parada; comparar el coste de la indisponibilidad frente al de sustituir el sistema vulnerable o desplegar controles compensatorios; aplicar principios de "Cyber-Informed Engineering" y "Secure by Design" en las compras; y —detalle excelente— analizar el stock de repuestos OT para comprobar que cubre efectivamente los activos críticos identificados.

- Monitorización y reporte, tanto de variables de proceso como de diagnóstico de red y sistemas, con propietarios identificados del inventario que validen las clasificaciones.

- Formación y concienciación, y un bucle de mejora continua apoyado en la gestión del cambio y en auditorías periódicas del programa.


Tres lecturas para llevarse

Primera: el inventario es una decisión de gobierno, no un proyecto técnico. El paso 1 del método no habla de herramientas, habla de autoridad, roles y alcance. Los inventarios que fracasan casi nunca fracasan por falta de tecnología; fracasan porque nadie es responsable de mantenerlos vivos al día siguiente de entregarlos.

Segunda: la taxonomía es lo que convierte el dato en criterio. Un listado sin clasificación por criticidad y función no permite priorizar nada. Y priorizar es, literalmente, lo único que se puede hacer cuando hay más vulnerabilidades que ventanas de parada.

Tercera: el inventario o es continuo o no es. Una fotografía envejece desde el momento en que se toma. La exigencia de actualizarlo incluso en cambios de emergencia, la revisión periódica de la taxonomía y la gestión de ciclo de vida apuntan todas en la misma dirección: esto no se hace una vez.


Que nueve agencias de cinco países hayan dedicado un documento conjunto a algo tan aparentemente básico dice bastante sobre el estado real del sector. La buena noticia es que, a diferencia de otras recomendaciones de ciberseguridad industrial, esta se puede empezar el lunes por la mañana: con una reunión sobre quién es responsable de qué, y una definición honesta de qué se considera un activo.

En TITANIUM llevamos años recorriendo estos dos tramos con nuestros clientes. El diagnóstico de ciberseguridad OT cubre el arranque que describe la guía: alcance, inspección física y lógica de la instalación, levantamiento de activos y atributos, y clasificación en zonas y conductos con la brecha frente a IEC 62443 y ENS sobre la mesa. Pero, como advierte el propio documento, esa fotografía envejece desde que se toma. Para el segundo tramo —el que de verdad decide si el inventario sigue vivo dentro de dos años— desarrollamos Rutile ICS, nuestra plataforma de visibilidad y topología de activos industriales: mantiene el inventario y el gemelo digital actualizados de forma continua, cruza los activos con las vulnerabilidades conocidas, vigila el estado de las copias de seguridad y de los parches, y traduce todo ello a los términos que exigen NIS2, IEC 62443 y el ENS. Porque, al final, la conclusión de la guía y la nuestra son la misma: la ciberseguridad industrial comienza con la visibilidad.

*Fuente: CISA, EPA, NSA, FBI, ASD's ACSC, Cyber Centre, BSI, NCSC-NL y NCSC-NZ. "Foundations for OT Cybersecurity: Asset Inventory Guidance for Owners and Operators", 13 de agosto de 2025. TLP:CLEAR.*

Llueve sobre mojado...


La NSA vuelve a decir lo que llevamos mas de 10 años diciendo en Titanium...

Esta mañana al leer el advisory conjunto de NSA, CISA, FBI, Departamento de Energía y EPA sobre la amenaza activa contra PLCs Siemens S7 lo hemos pensado: Llueve sobre mojado. Cinco agencias. Cinco. Firmando un documento cuyo mensaje central, resumido sin piedad, es: amigo, no pongas el PLC (ni cualquier otra cosa que no sea necesaria) en Internet.

Vamos con los hechos, que son maravillosamente aburridos. Los atacantes están buscando PLCs Siemens expuestos —S7-200, 300, 400, 1200 y 1500, incluidos los F de seguridad funcional, que es donde uno empieza a ponerse serio— usando servicios de escaneo público como Censys o ZoomEye. Es decir: no hay un 0-day fabuloso, no hay un implante de nación-estado con nombre de constelación. Hay un buscador, un puerto 102 abierto al mundo y, en demasiados casos, autenticación por defecto o directamente inexistente.

Después entran, leen bloques de datos, entienden el proceso y se quedan ahí. El advisory lo dice con una honestidad que se agradece: esto no parece un ataque, parece preparación de un ataque. Reconocimiento persistente, prueba de capacidades y pre-posicionamiento para el día que a alguien le interese escribir en lugar de leer.

Traducido a román paladino: alguien está tomando notas de tus sistemas de planta con calma y sin prisa.

La parte que ha ocupado los titulares es la de la IA. Los actores están usando asistentes de IA para generar scripts de explotación apoyados en snap7/python-snap7, una librería abierta de toda la vida, y disfrazarlos de herramientas legítimas de monitorización OT. La NSA lo describe como una evolución de las capacidades del adversario porque reduce drásticamente el conocimiento técnico y el tiempo necesarios para tener algo que funcione.

Y es verdad. Pero conviene ponerlo en su sitio, porque hay mucho vendedor de humo afilando el PowerPoint estos días.

La IA no ha abierto el puerto 102. La IA no ha dejado la contraseña en blanco. La IA no ha decidido que el histórico se conectase directamente contra la red de proceso porque "es que si no, no va". La IA solo ha bajado el peaje de entrada al club de los que saben hablar S7comm. Ese club, hasta hace poco, exigía leerse manuales de Siemens (bastante áridos) y pelearse con capturas de tráfico un fin de semana entero. Ahora exige una noche, un buen prompt y si te pones tonto un gintonic.

Lo que la IA ha hecho es eliminar el último argumento de la seguridad por oscuridad. Ese en el que tanto se apoyó el mundo industrial durante dos décadas: "sí, está expuesto, pero ¿quién va a saber programar un S7-300?". Pues mira, ahora cualquiera. La oscuridad se ha acabado. El resto del problema es exactamente el mismo problema de siempre.

Entre todas las recomendaciones —inventario, parcheo, segmentación, control de accesos, monitorización con herramientas ICS-aware, hardening específico de S7— hay un párrafo que a mí me parece el más importante del documento y que ha pasado sin pena ni gloria.

Dice, más o menos, que estas medidas son especialmente relevantes para quienes trabajan con integradores o proveedores de servicio con acceso remoto a los PLCs, porque el propietario del activo puede no ser consciente de que sus sistemas están expuestos y en riesgo.

Porque la conversación real que tenemos en las plantas no es "no queremos protegernos". Casi nunca lo es. La conversación real es un responsable de mantenimiento diciéndote con toda la buena fe del mundo que su red está aislada, y tú encontrando cuarenta minutos después un router 4G que puso el integrador en 2019 para no tener que venir desde Zaragoza cada vez que fallaba una receta. Nadie mintió. Simplemente nadie lo sabía.

Y de ahí se deduce lo único que de verdad importa de todo este advisory: no puedes proteger lo que no sabes que tienes, y no sabes que lo tienes porque nunca lo has inventariado. No es casualidad que la primera de las siete acciones de mitigación sea, literalmente, hacer inventario. Ni que la primera de las "top mitigations" del resumen ejecutivo sea la misma. Antes que parchear. Antes que segmentar. INVENTARIAR.

Llevamos años diciéndolo. Ahora lo firman cinco agencias federales. A ver si así....

Entonces, ¿qué hago el lunes?

Sin misticismos, y en este orden:

>Sal a buscar tus S7. Todos. Los del proyecto y los que no están en ningún plano. Firmware contra copia de referencia, y mapea qué estaciones tienen TIA Portal o STEP 7.

>Mira quién entra desde fuera. Cada acceso remoto de cada integrador, cada VPN abierta "temporalmente" en 2021, cada router de operadora bajo un armario. Este es el punto donde aparecen las sorpresas de verdad.

>Cierra el 102 en el perímetro. No hay ningún motivo legítimo para que S7comm hable con Internet. Ninguno.

>Pon contraseña a los autómatas y configura los niveles de protección. Sí, ya sé que da pereza. Hazlo igual.

>Empieza a mirar el tráfico. Aunque sea con poco. Una sesión S7comm un domingo a las tres de la mañana desde una IP que no es de nadie conocido no debería ser un descubrimiento arqueológico seis meses después.

>Manda el advisory a tus integradores y pídeles por escrito qué han implementado. El propio documento te lo recomienda; úsalo como palanca.

Nada de esto es nuevo. Nada de esto es sexy.

Pero es que ese es exactamente el problema: llevamos mucho tiempo avisando (evangelizando?) de cosas aburridas, y el adversario acaba de conseguir una herramienta que le permite explotarlas más rápido que nunca.

Llueve sobre mojado, sí. Pero el agua sigue entrando por el mismo agujero del tejado que señalamos la primera vez. Y ahora, además, hay más gente sabiendo dónde está el agujero.

Si queréis leer el advisory original:

Defending Against an Active Threat to Siemens S7 Series PLCs

PDF Advisory

martes, 15 de junio de 2021

Vulnerabilidad zero day en Primion-Digitek EVALOS Secure 8

 

Durante un ejercicio de hacking ético industrial a uno de nuestros clientes, detectamos una vulnerabilidad zero day crítica en una aplicación de control de accesos y personal de planta. En este caso se trata de la aplicación Evalos8 (Primion-Digitek), en concreto en la versión v1.0.1.55 del módulo Secure8. No hemos podido acceder a otras versiones anteriores de este producto para verificar si se reproduce la vulnerabilidad, por lo que estas podrían verse igualmente afectadas.

Primion-Digitek se especializa en implantación de controles de acceso, fichaje, control de personal, etc. Tienen implantados sus sistemas tanto en infraestructuras críticas, como pueden ser aeropuertos, industrias eléctricas, hospitales, así como en edificios de administración pública, entre otros.

En este caso, hemos descubierto una vulnerabilidad de tipo Blind SQL Injection en el módulo de autenticación contra el gestor administrativo de la aplicación. Mediante esta vulnerabilidad, es posible la extracción de usuarios y hashes SHA-1 de las contraseñas. A la vez, sería posible la extracción de cualquier otro dato almacenado en la base de datos.

A esta vulnerabilidad de Blind SQL Injection se le ha asignado el código CVE-2021-3604

Todo comenzó cuando empezamos a evaluar posibles vectores de ataque que bien nos permitieran realizar un bypass de la autenticación (SQL Injection), nos ofrecieran un resultado booleano diferente dependiendo del payload introducido (Blind SQL Injection), u ofreciesen un retraso de tiempo dependiendo del payload introducido (Time Based SQL Injection).

En este caso, conseguimos resultados diferentes con los siguientes payloads, indicando que el parámetro introducido estaba siendo inyectado y ejecutado en una consulta SQL:

·         admin‘ or ‘a’=’a

·         admin’ or ‘a’=’b

 




 

Una vez que verificamos la posibilidad de evaluar consultas booleanas, es posible la obtención de datos mediante la evaluación de una consulta de tipo ‘prueba y error’:

·         ‘ or (<campo> LIKE ‘xxx%’)#

Dado que los campos son desconocidos, podemos extraer la información que necesitamos consultando la información contenida en las tablas INFORMATION_SCHEMA.TABLES y INFORMATION_SCHEMA.COLUMNS de SQLServer. De esta manera se han conseguido los nombres de columna ‘usuario’ y ‘ClaveAcceso’ de la tabla de usuarios referenciada en la consulta de autenticación.

Una vez tenemos estos datos en nuestro poder, es posible la extracción de la información de usuarios. Para ello desarrollamos un exploit que comprueba todos los caracteres del diccionario hasta obtener un usuario válido.

A continuación, se repite este proceso, pero con la columna ‘ClaveAcceso’.

Los datos obtenidos como password son una serie numérica de 120 dígitos de longitud, y la frecuencia de los números 0, 1 y 2 es mayor al resto. De aquí podemos deducir que puede tratarse de una serie de números menores de 255, y concatenados en grupos de tres. Tras comprobar que, tomando los números en tríos de dígitos, ninguno es mayor a 255, probamos a pasarlos a hexadecimal, obtenido un posible hash de 40 caracteres. Inmediatamente, nos viene a la cabeza el tipo de hash SHA-1, el cual tiene una longitud de 40 caracteres.

Finalmente probamos a crackear el hash, obteniendo la contraseña en claro en menos de 1 segundo, ya que tenía una longitud de 1 carácter.

A partir de aquí, es trivial la construcción de un exploit válido que extraiga todos los usuarios y hashes del sistema.

Una vez dentro del sistema, es posible la edición los permisos acceso, pudiendo generar nuevos usuarios, revocar la entrada a otros, control de zonas críticas de la planta, etc. De esta manera, la seguridad física de una infraestructura crítica quedaría comprometida por completo, permitiendo el acceso a la infraestructura y a las zonas más críticas a cualquier usuario que tomase el control de esta aplicación.



Podemos obtener dos conclusiones importantes de este caso:

La primera es que es muy importante no conformarse únicamente en el análisis de vulnerabilidades conocidas durante una fase de pentest, ni con el uso de herramientas automáticas. Existen componentes que, al no ser usados de una manera más extendida, pueden tener vulnerabilidades fácilmente explotables, ya que, por desgracia, muchos desarrollos no han contemplado un desarrollo seguro de la aplicación.

La otra es que, desde una simple vulnerabilidad en un componente de software, se puede poner en grave riesgo una infraestructura crítica al completo, comprometiendo la seguridad física de la misma, por lo que es fundamental identificar estos componentes críticos en las aplicaciones a desplegar en dichas infraestructuras e, idealmente, evaluar su seguridad antes de su despliegue, con empresas como Titanium Industrial Security, que disponen de los medios humanos y materiales para hacer esto.

Enlace a la publicación de INCIBE:

https://www.incibe-cert.es/alerta-temprana/avisos-sci/vulnerabilidad-inyeccion-sql-primion-digitek-secure-8

Para finalizar, agradecer a INCIBE por la ayuda prestada en la notificación y gestión de la vulnerabilidad y felicitarlos por su reciente nombramiento como Root CNA.

miércoles, 18 de noviembre de 2020

Full Stack Developers para León


 

 

 

 

 

 

 

Estamos buscando 5 Full Stack Developers para nuestro centro de desarrollo de software que acabamos de inaugurar en León.
Si eres un apasionado de la tecnología, tienes dominio y experiencia y quieres formar parte de un proyecto de largo recorrido y referencia en su sector, no esperes más y apúntate!

 

https://www.infojobs.net/leon/full-stack-developers/of-i8d45e0facf412f98f93d0c6ad2a579

 

lunes, 16 de noviembre de 2020

DSTREAMS- INVESTIGACIÓN Y DESARROLLO DE METODOLOGÍA EN LA INTELIGENCIA ARTIFICIAL (ML) ORIENTADO A CASOS INDUSTRIALES DE USO DE DATOS CONTÍNUOS DE ULTRA-ALTA VELOCIDAD





INVESTIGACIÓN Y DESARROLLO DE METODOLOGÍA EN LA INTELIGENCIA ARTIFICIAL (ML) ORIENTADO A CASOS INDUSTRIALES DE USO DE DATOS CONTÍNUOS DE ULTRA-ALTA VELOCIDAD

 

  • Organismo Público de Financiación: Ministerio de Ciencia e Innovación y la Agencia Estatal de Investigación
  • Programa: Retos RTC2019-0006871-1
  • Beneficiarios: Aingura IIoT, S.L. (líder), Titanium Industrial Security, S.L., Universidad Politécnica de Madrid, Universidad de la Iglesia de Deusto, Barcelona Supercomputing Center.
  • Presupuesto total: 2.864.671,20€

 

jueves, 29 de octubre de 2020

Invitación evento Fireeye: Cyber Defense Live 2020

 

 Os invitamos al evento anual en EMEA el 3 de Noviembre y en España el 11 de Noviembre, con interesantes presentaciones y nuestra participación en el booth virtual.

 

Si quereis asistir, registraros en el siguiente enlace: https://www.fireeye.com/company/events/cyber-defence-live-emea/spain.html

Os esperamos