Cuando se publica una vulnerabilidad crítica que afecta a un sistema de control, la primera pregunta en planta casi nunca es técnica: ¿tenemos ese equipo?, ¿dónde está?, ¿qué versión de firmware ejecuta?, ¿quién es su responsable? En muchas organizaciones industriales, responderla exige una búsqueda laboriosa. No porque falte información, sino porque está repartida entre distintas herramientas, listas y equipos.
Como se planteaba en este mismo blog, en la serie sobre NIS2, un inventario no es una arquitectura. Pero sin un inventario fiable tampoco es posible construirla: solo se pueden gestionar las vulnerabilidades, las dependencias y los riesgos de los activos que se conocen.
Por qué los activos OT se quedan fuera
La superficie de ataque industrial va mucho más allá de los servidores y los puestos de trabajo. Máquinas y sistemas de control, sensores, instalaciones de producción, automatización de edificios, redes industriales y accesos de mantenimiento remoto de terceros forman parte de ella. Y son precisamente estos activos los que con más frecuencia quedan fuera de los inventarios centrales.
Las razones se repiten: los modelos de datos rígidos de muchas CMDB no están pensados para ellos, los sistemas permanecen en uso más tiempo del planificado, los proveedores obtienen accesos y, sobre todo, muchos equipos OT no pueden detectarse de forma automática.
El resultado son componentes sin un responsable claramente definido, sistemas obsoletos y dispositivos de red desconocidos: justo el tipo de activos que los atacantes aprovechan.
El problema no es exclusivo de la industria. Según el «Data Breach Investigations Report 2025» de Verizon, el 46 % de los sistemas comprometidos con posibles credenciales corporativas en un conjunto de datos analizado no estaban integrados en la gestión central de la empresa.
Tres vías de registro, no una
Un inventario útil en entornos industriales no surge de una única herramienta, sino de combinar métodos según el tipo de activo:
- Descubrimiento automático para la infraestructura de TI: Active Directory, escáneres de red y APIs de las plataformas en la nube.
- Registro manual para activos físicos y móviles, mediante códigos QR o de barras, importación de listas existentes y recorridos in situ. La validación por parte de los responsables locales es lo que garantiza la calidad de los datos.
- Un proceso propio para OT y sistemas heredados: análisis pasivo, inventarios SCADA y coordinación con los responsables de planta. Donde no hay detección automática, hace falta un procedimiento de coordinación independiente.
Pocos datos, pero con contexto
Muchos inventarios se vuelven innecesariamente complejos porque se definen demasiados campos que luego no se mantienen en el trabajo diario. Para empezar basta con un conjunto de datos mínimos por activo: identificador único, tipo de activo, ubicación o contexto lógico, rol responsable, criticidad, estado de seguridad y estado del ciclo de vida. Según el entorno, más adelante pueden añadirse otros datos, como el fabricante, el número de serie o la versión de firmware.
La criticidad merece atención especial. Un modelo sencillo de tres niveles (alta criticidad, relevante y de apoyo) suele ser suficiente para priorizar. Y no depende solo del tipo de equipo, sino de su función: dos dispositivos técnicamente similares pueden valorarse de forma distinta si uno de ellos soporta un proceso crítico.
Del inventario a la priorización
El valor del inventario se ve cuando hay que decidir. Ante una vulnerabilidad crítica, un registro bien mantenido permite filtrar los sistemas afectados por versión, ubicación, criticidad o responsable, y saber qué tratar primero y quién debe actuar.
Pensemos en una empresa de producción con varias plantas en la que no está documentado qué instalaciones son realmente críticas, los inventarios paralelos no son coherentes entre sí y en muchos casos se desconocen las versiones de firmware. Para una situación así, el libro blanco «Gestión de activos de ciberseguridad y cumplimiento», publicado por Timly, plantea un enfoque deliberadamente acotado: empezar solo por las instalaciones críticas para la producción, utilizar el descubrimiento de red como base técnica, completar manualmente los datos específicos de OT (firmware, fabricante, área) y asignar responsables y criticidad, integrándolos en el sistema de mantenimiento. Con esa base, ante una vulnerabilidad, los sistemas afectados pueden identificarse en poco tiempo y ordenarse según su criticidad.
Lo que exige la normativa
Este enfoque no es solo una buena práctica. ISO/IEC 27001, en su Anexo A 5.9, exige gestionar de forma sistemática el inventario de información y de los activos asociados, con responsables claros. NIS2, por su parte, exige «medidas técnicas y organizativas adecuadas» para gestionar los riesgos de ciberseguridad y, en la práctica, presupone poder identificar con rapidez qué activos se ven afectados, qué criticidad tienen, qué ubicaciones están implicadas y qué dependencias existen.
Una reflexión final
El primer inventario no tiene que ser perfecto. Un registro con alrededor del 80 % de cobertura y datos clave bien mantenidos suele ser más valioso que aspirar al 100 % y retrasar el proyecto durante meses. Lo decisivo es que las responsabilidades estén claras y que la actualización forme parte de los procesos existentes, como las tareas de mantenimiento o las solicitudes de cambio.
En los entornos OT, el problema de fondo rara vez es la tecnología: es la falta de una visión compartida sobre qué sistemas son realmente críticos. Un inventario con contexto es el primer paso para construirla.
Fuente: libro blanco «Gestión de activos de ciberseguridad y cumplimiento»
Ángela Pohl
Responsable senior de marketing de contenidos en Timly Software AG/proveedor de software en la nube para la gestión de inventario y mantenimiento
