Cada año Dragos publica su reporte de ciberseguridad OT/ICS. Es uno de los documentos más citados de la industria: aparece en presentaciones ejecutivas, se comparte en LinkedIn y suele resumirse con frases como “el riesgo está creciendo” o “la industria debe actuar”.
Y cada año pasa algo parecido: muchas veces lo leen quienes ya están convencidos de su importancia, mientras que buena parte de quienes operan los sistemas descritos en el reporte no llegan a revisarlo completo.
No por falta de interés.
Sino porque está en inglés, es extenso, usa terminología especializada y, mientras tanto, la operación sigue corriendo.
Yo trabajo cerca de sistemas industriales reales: servidores de planta, estaciones de ingeniería, sistemas de historización de datos, visualización, redes separadas por firewalls y aplicaciones que no pueden tratarse como si fueran solo “IT”.
No soy analista de inteligencia de amenazas.
Soy el ingeniero que, cuando algo falla, tiene que entender qué pasó, recuperar visibilidad y ayudar a que el sistema vuelva a operar de forma estable.
Por eso el reporte Dragos 2026 me importa menos como documento académico y más como mapa práctico de riesgos. No lo leo pensando en una sala de crisis ideal, sino pensando en decisiones reales de planta:
- ¿Qué acceso remoto sigue abierto?
- ¿Qué servidor tiene visibilidad limitada?
- ¿Qué estación de ingeniería no se puede actualizar fácilmente?
- ¿Qué regla de firewall sigue existiendo porque nadie pidió cerrarla?
- ¿Qué pasaría si una plataforma OT virtualizada queda cifrada?
Este post es mi lectura práctica del reporte: los puntos que más me llamaron la atención y lo que significan cuando estás cerca de la operación.
Este artículo tiene fines educativos. Resume y comenta hallazgos públicos del reporte Dragos OT/ICS Cybersecurity Year in Review 2026 desde una mirada práctica de operación industrial. No representa a ninguna empresa, cliente, proveedor ni fabricante.
Datos clave del reporte Dragos 2026
| Punto | Dato relevante |
|---|---|
| Grupos de amenaza OT rastreados por Dragos | 26 grupos |
| Grupos activos durante 2025 | 11 grupos |
| Nuevos grupos identificados | AZURITE, PYROXENE y SYLVANITE |
| Grupos de ransomware observados contra organizaciones industriales | 119 grupos |
| Organizaciones industriales afectadas por ransomware en 2025 | 3,300 organizaciones |
| Sector más afectado | Manufactura, con más de dos tercios de las víctimas observadas |
| Tiempo promedio de contención con visibilidad OT amplia | 5 días |
| Tiempo promedio de contención sin visibilidad OT amplia | 42 días |
| Fuente principal | Dragos OT/ICS Cybersecurity Year in Review 2026 |
El cambio que más me llamó la atención
Lo más importante del reporte no es solo que haya más actividad maliciosa. Eso, lamentablemente, ya no sorprende demasiado.
Lo que más me llamó la atención es el tipo de actividad que se está observando dentro de los entornos OT.
Antes, la preocupación principal era que un adversario lograra entrar a la red de planta. Eso por sí solo ya era grave.
Ahora el reporte describe un escenario más incómodo: actores que logran presencia, no necesariamente hacen ruido de inmediato y dedican tiempo a entender cómo funciona el entorno.
Eso cambia completamente la conversación.
En una red industrial, entender el entorno no significa solo saber nombres de servidores o direcciones IP. Significa comprender relaciones:
- qué estación de ingeniería administra qué controladores;
- qué servidor historiza qué variables;
- qué aplicación entrega visibilidad a operación;
- qué segmento de red se comunica con otro;
- qué sistema depende de un hipervisor;
- qué acceso remoto permite llegar a una zona sensible.
Para alguien que trabaja en control o infraestructura OT, esto es especialmente incómodo porque el atacante no solo estaría buscando “máquinas Windows”.
Estaría intentando entender la operación.
Ransomware industrial: cuando el impacto OT se disfraza de incidente IT
Uno de los puntos más importantes del reporte es el crecimiento del ransomware contra organizaciones industriales.
Dragos reporta 119 grupos de ransomware observados atacando organizaciones industriales en 2025, con 3,300 organizaciones afectadas globalmente. También indica que manufactura concentró más de dos tercios de las víctimas observadas.
Pero hay una idea más importante que el número:
muchos incidentes pueden ser tratados inicialmente como “IT” porque afectan servidores Windows, hipervisores, archivos compartidos o estaciones de trabajo.
El problema es que, en entornos industriales, esos activos muchas veces sostienen funciones operativas.
Un servidor Windows puede alojar:
- historización de datos;
- interfaces HMI;
- software de alarmas;
- aplicaciones de reportabilidad;
- servicios de integración;
- herramientas de ingeniería;
- sistemas de visualización;
- clientes de operación.
Desde afuera, puede parecer “un servidor Windows más”.
Desde planta, puede ser el sistema que permite ver tendencias, reconstruir eventos, analizar una parada o confirmar qué ocurrió durante una desviación del proceso.
Cuando ese activo queda cifrado, la pérdida no es solo de archivos.
Puede ser pérdida de visibilidad operativa.
Y en operación, quedarse sin visibilidad también es una forma de impacto.
El número que más me impactó: 5 días contra 42 días
El dato más útil del reporte, al menos para mí, es la diferencia en tiempo de contención.
Dragos indica que las organizaciones con visibilidad OT amplia lograron contener incidentes de ransomware en un promedio de 5 días, mientras que aquellas sin esa visibilidad tardaron alrededor de 42 días.
No es una diferencia menor.
Son casi seis semanas adicionales en las que un adversario puede:
- moverse lateralmente;
- ampliar persistencia;
- revisar sistemas;
- identificar activos críticos;
- exfiltrar información;
- comprometer más servidores;
- dificultar la recuperación.
Lo importante no es leer ese dato como una invitación inmediata a comprar una plataforma.
La lectura más práctica es esta:
si no puedo ver lo que ocurre en mi red de planta, voy a tardar mucho más en entender qué pasó.
Y eso aplica incluso antes de tener herramientas avanzadas.
Visibilidad también puede empezar con cosas básicas:
- logs de Windows;
- eventos de inicio de sesión;
- inventario de servidores;
- reglas de firewall documentadas;
- listado de cuentas locales;
- registro de accesos remotos;
- monitoreo de conexiones entre segmentos;
- respaldos probados;
- historial de cambios.
No es perfecto, pero es un punto de partida.
En OT, muchas veces el problema no es que no exista ninguna herramienta. Es que nadie tiene una vista ordenada de lo que ya existe.
Lo que el reporte me hizo mirar con más atención
Después de leer el reporte, hubo varios tipos de activos que empecé a mirar con otra sensibilidad.
Estaciones de ingeniería
Las estaciones de ingeniería son uno de los activos más delicados de cualquier entorno de control.
Desde ahí se configura, modifica o mantiene lógica que puede afectar directamente al proceso.
Y, al mismo tiempo, suelen ser equipos difíciles de actualizar. Muchas dependen de versiones específicas de software del fabricante, sistemas operativos antiguos, licencias particulares o compatibilidades que nadie quiere romper.
El riesgo no es solo que una estación de ingeniería tenga Windows desactualizado.
El riesgo es que tenga acceso privilegiado a controladores, redes industriales o configuraciones críticas.
Si un adversario entiende esa estación, entiende una parte importante del proceso.
Acceso remoto
Este punto conecta directamente con el artículo anterior sobre acceso remoto OT.
El acceso remoto mal gestionado sigue siendo una puerta silenciosa: cuentas antiguas, reglas temporales, accesos de proveedores que nunca se cerraron, VPNs sin revisión, herramientas instaladas durante proyectos y sesiones que permanecen habilitadas más tiempo del necesario.
No siempre se ve como una vulnerabilidad dramática.
A veces se ve como una excepción operativa que se volvió permanente.
Y ese tipo de excepción es difícil de defender.
Infraestructura de virtualización
Muchos entornos OT ya no viven en servidores físicos aislados. Viven en plataformas virtualizadas.
Eso trae ventajas enormes: snapshots, alta disponibilidad, consolidación, recuperación más rápida y mejor administración.
Pero también concentra riesgo.
Si un hipervisor o una plataforma de virtualización que aloja aplicaciones OT queda comprometida, el impacto puede multiplicarse.
No se cae una aplicación.
Se puede caer un conjunto completo de servicios industriales: historización, visualización, reportes, servidores de aplicación, herramientas de ingeniería o sistemas auxiliares.
Por eso la pregunta no es solo:
“¿Tenemos backups?”
La pregunta debería ser:
“¿Podemos recuperar la plataforma OT si la infraestructura que la aloja también queda afectada?”
Transferencia de archivos e integraciones
Otro punto importante son los sistemas que mueven información entre zonas.
En muchas plantas existen carpetas compartidas, SFTP, servicios intermedios, servidores puente o mecanismos manuales para transferir archivos entre corporativo y planta.
A veces transportan reportes.
A veces respaldos.
A veces configuraciones.
A veces archivos de ingeniería.
Si esos flujos no tienen dueño, logs, revisión y controles claros, se convierten en caminos poco visibles entre mundos que deberían estar bien separados.
Qué significa esto cuando estás en planta
La lectura ejecutiva del reporte puede resumirse en “el riesgo OT está creciendo”.
Pero desde planta, la pregunta real es otra:
¿Qué hago con esta información mañana?
Para mí, el valor del reporte está en que ayuda a ordenar prioridades.
No todo se puede resolver en una semana. No todas las operaciones tienen el mismo presupuesto, madurez o equipo de seguridad.
Pero sí se puede empezar por lo más básico y más cercano a la operación.
1. Saber qué accesos remotos existen
No basta con saber que “hay RDP” o que “el proveedor entra por VPN”.
Hay que saber:
- quién entra;
- desde dónde entra;
- a qué servidor entra;
- por qué entra;
- desde cuándo existe ese acceso;
- quién lo aprobó;
- cuándo debería cerrarse.
Un acceso sin fecha de cierre no es una solución temporal.
Es una excepción permanente.
2. Saber qué activos son realmente críticos
No todos los servidores tienen el mismo impacto.
Un servidor de pruebas no tiene el mismo peso que una estación de ingeniería.
Un servidor de visualización no tiene el mismo riesgo que un controlador.
Un servidor que aloja datos históricos puede ser crítico si esos datos son necesarios para análisis, cumplimiento, investigación de eventos o toma de decisiones operativas.
La criticidad no la define solo el sistema operativo.
La define el proceso.
3. Saber qué logs existen y si alguien los revisa
Tener logs no es lo mismo que tener visibilidad.
Si nadie sabe dónde están, cuánto tiempo se guardan o qué evento buscar, los logs solo sirven después del problema, y a veces ni siquiera eso.
Una revisión básica debería responder:
- ¿dónde se registran los accesos?
- ¿cuánto tiempo se retienen los eventos?
- ¿quién puede consultarlos?
- ¿qué se considera actividad normal?
- ¿qué sería anómalo?
4. Saber si los respaldos sirven
En ciberseguridad industrial, un backup no probado es casi una suposición.
Y en ransomware, las suposiciones cuestan caro.
No basta con que el software diga “backup exitoso”. Hay que saber si se puede restaurar, cuánto demora, qué dependencias tiene y si el backup está aislado del entorno que podría quedar cifrado.
Qué aprendí de leer el reporte con otro lente
El adversario no necesita entender toda tu planta para causar impacto.
A veces basta con encontrar el servidor correcto, la estación correcta o el acceso correcto.
No necesita conocer cada detalle del proceso.
Solo necesita afectar el punto donde la operación pierde visibilidad, control o capacidad de recuperación.
La visibilidad OT no empieza necesariamente con una gran plataforma.
Empieza con inventario, logs, accesos documentados, reglas revisadas y conocimiento operativo.
Una plataforma puede ayudar mucho.
Pero si nadie sabe qué servidores existen, qué accesos están abiertos o qué sistemas son críticos, la herramienta llega a un entorno desordenado.
Los reportes globales sirven cuando se traducen a decisiones locales.
Dragos puede mostrar tendencias globales, pero el valor aparece cuando uno pregunta:
- ¿Esto existe en mi operación?
- ¿Tenemos ese tipo de acceso?
- ¿Tenemos estaciones así?
- ¿Tenemos backups probados?
- ¿Tenemos visibilidad suficiente?
- ¿Quién respondería si esto pasa a las dos de la mañana?
Reducir superficie también es defender.
No todo es detección avanzada.
Cerrar cuentas que ya no se usan también es defensa.
Eliminar reglas sin justificación también es defensa.
Desinstalar herramientas de soporte remoto obsoletas también es defensa.
Documentar accesos también es defensa.
En entornos OT, donde los cambios deben ser cuidadosos, reducir exposición innecesaria puede ser una de las acciones más efectivas y menos invasivas.
Acciones que me llevaría a una operación industrial
Si tuviera que convertir esta lectura en acciones concretas, empezaría por estas:
- Revisar accesos remotos hacia servidores de planta.
- Identificar cuentas locales habilitadas sin uso reciente.
- Revisar reglas de firewall creadas como temporales.
- Confirmar qué estaciones de ingeniería tienen acceso a controladores.
- Validar qué servidores OT están virtualizados y dónde corren.
- Revisar si los respaldos de sistemas OT están aislados y probados.
- Confirmar qué logs existen para accesos RDP, VPN y cuentas privilegiadas.
- Documentar quién aprueba y quién revoca accesos de proveedores.
- Identificar sistemas de transferencia de archivos entre redes.
- Definir qué activos OT deberían monitorearse primero.
No es una auditoría completa.
Es una primera línea de defensa práctica.
Una forma simple de priorizar
Si todo parece importante, yo empezaría con tres preguntas.
¿Qué accesos permiten entrar a la red OT?
Aquí entran VPN, RDP, herramientas de soporte remoto, cuentas de proveedores, reglas de firewall y accesos desde redes corporativas.
¿Qué activos permiten modificar o afectar el proceso?
Aquí entran estaciones de ingeniería, servidores de aplicación, herramientas de configuración, controladores, gateways industriales y sistemas con privilegios altos.
¿Qué sistemas necesito para ver, entender y recuperar la operación?
Aquí entran historizadores, sistemas de alarmas, backups, virtualización, servidores de reportes, monitoreo y documentación operativa.
Si un activo cae en más de una categoría, probablemente merece atención prioritaria.
Cierre
El reporte Dragos 2026 no debería quedarse en una presentación ejecutiva ni en una frase de LinkedIn.
Para quienes trabajamos cerca de sistemas industriales, su valor está en ayudarnos a mirar la planta con más intención.
No se trata de asustarse con cada cifra.
Se trata de tomar esos hallazgos y preguntarse:
“¿Dónde se parece esto a mi operación?”
Porque muchas veces el riesgo no está escondido en una amenaza sofisticada.
Está en una cuenta que nadie deshabilitó.
En una estación de ingeniería que nadie puede actualizar.
En una regla de firewall que nació temporal.
En un backup que nadie ha restaurado.
En un acceso remoto que sigue abierto porque alguna vez fue útil.
Y si el reporte sirve para que alguien revise una de esas cosas antes de un incidente, entonces ya dejó de ser un PDF más.
Se convirtió en una herramienta de operación.
Aviso de independencia
Este artículo tiene fines educativos y refleja una lectura técnica personal de información pública sobre ciberseguridad OT.
No representa la posición de ninguna empresa, cliente, proveedor o fabricante.
Las recomendaciones deben validarse según el contexto de cada operación, sus procedimientos internos, criticidad de activos, políticas de seguridad y documentación oficial aplicable.
Fuentes consultadas
Dragos OT/ICS Cybersecurity Year in Review 2026 — Página oficial del reporte
Dragos — Comunicado de prensa oficial (febrero 2026)
Dragos, Inc.
Dragos Blog — Resumen de hallazgos y grupos de amenaza
Lección de cierre
En sistemas industriales, una señal congelada, una cámara lenta o una interfaz caída rara vez se explican con una sola causa. El valor está en ordenar síntomas, evidencias, cambios recientes y dependencias técnicas antes de intervenir.
Este artículo tiene fines educativos. Los casos pueden estar simplificados o anonimizados y no representan a ninguna empresa, cliente o proveedor.
Member discussion