Hay un servidor en la red de planta que tiene una vulnerabilidad conocida.
No es una sospecha. Está documentada en un advisory público, tiene CVE asignado y la versión del sistema afectado coincide con lo que tenemos instalado.
Sé qué sistema operativo está corriendo. Sé qué software industrial depende de él. Sé que el fabricante ya no libera parches para esa versión. Y también sé que actualizarlo no es tan simple como presionar “instalar actualización”.
Actualizar ese servidor implicaría validar compatibilidad con el software de control que corre encima, coordinar una ventana de mantenimiento, probar comunicaciones, verificar drivers, revisar servicios, confirmar que las aplicaciones arranquen igual y asumir el riesgo de que algo no quede como estaba.
Así que ahí está.
Con la vulnerabilidad.
Funcionando.
Y esa es la parte incómoda de OT: a veces sabemos que algo está mal, pero no podemos corregirlo de inmediato sin poner en riesgo la continuidad operativa.
No siempre es descuido. Muchas veces es una decisión tomada entre producción, soporte, mantenimiento, seguridad, compatibilidad y riesgo. Una decisión imperfecta, tomada con información parcial, en un entorno donde una parada no planificada puede costar mucho más que el riesgo teórico de seguridad.
Hasta que el riesgo deja de ser teórico.
Este post no trata sobre cómo parchear todo. Trata sobre algo más realista para muchos entornos industriales: cómo gestionar vulnerabilidades conocidas en sistemas OT legacy cuando el parche no está disponible, no está certificado o no se puede aplicar todavía.
Este artículo se basa en experiencias reales de trabajo, pero los nombres de sistemas, servidores, redes y operaciones han sido modificados o anonimizados. Las situaciones se presentan con fines educativos y no representan a ninguna empresa, cliente, proveedor o fabricante.
Contexto rápido
- Tipo de activos: servidores Windows legacy, PLCs, HMIs, estaciones de ingeniería y aplicaciones industriales antiguas.
- Situación: vulnerabilidades conocidas sin parche disponible, sin soporte vigente o sin ventana de mantenimiento viable.
- Causa frecuente: software del fabricante amarrado a versiones específicas de sistema operativo, firmware o librerías.
- Restricción operativa: continuidad de operación, baja tolerancia a paradas no planificadas y dependencia de validación del proveedor.
- Enfoque del post: controles compensatorios, priorización y gestión documentada del riesgo.
El dato que incomoda
En 2025, Forescout registró un volumen récord de advisories de seguridad ICS: 508 advisories que cubrían 2,155 vulnerabilidades. Además, para ese año, el 82% de esos advisories fue clasificado como de severidad alta o crítica.
Ese número no es solo una estadística para una presentación de seguridad.
Para quienes trabajamos cerca de sistemas industriales, se traduce en una pregunta muy concreta:
“Encontramos una vulnerabilidad que aplica a un sistema de planta. ¿Qué hacemos ahora?”
Y muchas veces la respuesta no es limpia.
Porque el parche puede no existir. O puede existir, pero no estar certificado por el fabricante. O puede requerir una actualización mayor del sistema. O puede necesitar una parada que no está programada. O puede afectar una aplicación que nadie se atreve a tocar porque lleva años funcionando.
En IT, una vulnerabilidad crítica suele activar un proceso relativamente claro: evaluar, probar, aplicar parche, reiniciar, monitorear.
En OT, ese proceso rara vez es tan directo.
Por qué en OT no funciona igual que en IT
En un entorno corporativo, parchear puede ser incómodo, pero normalmente es parte de la rutina. Hay ventanas de mantenimiento, servidores de prueba, herramientas de despliegue, rollback, políticas de actualización y equipos dedicados a gestionar el ciclo de vida.
En planta, la conversación cambia.
Hay sistemas que fueron instalados hace diez o quince años y todavía cumplen una función crítica. Hay estaciones de ingeniería que solo funcionan con una versión específica de Windows. Hay software de configuración de controladores que el fabricante certificó para un sistema operativo concreto. Hay drivers antiguos que nadie quiere tocar porque, si dejan de funcionar, se pierde la capacidad de comunicarse con un PLC, un sistema de control o una aplicación de supervisión.
Ese escenario lo he visto más de una vez.
Una estación puede estar técnicamente desactualizada, pero operativamente ser indispensable. Un servidor puede tener vulnerabilidades conocidas, pero también ser el único que corre una aplicación legacy que todavía no tiene reemplazo. Un HMI puede estar fuera de soporte, pero seguir siendo la forma en que operación visualiza una parte del proceso.
Ahí aparece la paradoja del parcheo en OT:
El sistema necesita actualizarse por seguridad, pero actualizarlo puede introducir un riesgo operativo inmediato.
Y cuando la operación está corriendo, el riesgo inmediato suele ganar.
No porque seguridad no importe. Sino porque una mala actualización también puede convertirse en incidente.
El problema no es solo la vulnerabilidad
Cuando encontramos una vulnerabilidad conocida en un sistema legacy, es fácil concentrarse únicamente en el CVE.
Pero en OT el CVE es solo una parte del problema.
La pregunta real es más amplia:
- ¿Dónde está ubicado ese activo?
- ¿Qué proceso soporta?
- ¿Quién puede conectarse a él?
- ¿Tiene acceso remoto habilitado?
- ¿Está segmentado?
- ¿Tiene respaldos probados?
- ¿Hay monitoreo de conexiones?
- ¿Existe una ruta de recuperación?
- ¿Está documentado el riesgo?
Dos equipos con la misma vulnerabilidad pueden tener niveles de riesgo completamente distintos.
Un servidor vulnerable, aislado, sin acceso remoto, con comunicaciones restringidas y respaldo probado, no representa el mismo riesgo que otro servidor con la misma vulnerabilidad, pero expuesto a varios segmentos, con cuentas antiguas, acceso RDP abierto y sin respaldo validado.
Por eso, en OT no basta con preguntar:
“¿Qué tan crítica es la vulnerabilidad?”
También hay que preguntar:
“¿Qué tan expuesto está el sistema que la tiene?”
Lo que encontré cuando empecé a revisar
Después de revisar accesos remotos y leer reportes de ciberseguridad OT, empecé a mirar algunos sistemas de planta desde otro ángulo: no solo si estaban funcionando, sino qué tan expuestos estaban frente a vulnerabilidades conocidas.
La primera revisión no fue sofisticada.
No empecé con una plataforma avanzada de gestión de vulnerabilidades. Empecé con algo más básico: levantar versiones de sistema operativo, versiones de software industrial, firmware cuando era posible, servicios activos y ubicación del activo dentro de la red.
Luego crucé esa información con advisories públicos, especialmente de CISA ICS Advisories y documentación de fabricantes.
El resultado se agrupó en tres tipos de sistemas.
1. Sistemas parchables, pero con ventana pendiente
Estos son los más manejables.
Existe un parche. El fabricante lo soporta. La actualización es viable. Pero todavía no se coordinó la ventana de mantenimiento.
En estos casos, el problema no es técnico sino de gestión: priorizar, planificar, probar y ejecutar.
Aquí lo importante es que el riesgo tenga fecha tentativa de resolución. Si un parche está disponible, pero nunca entra al calendario, el problema queda flotando indefinidamente.
2. Sistemas con parche disponible, pero difícil de aplicar
Este grupo es más complicado.
Existe una actualización, pero aplicarla implica actualizar también el software del fabricante, cambiar drivers, validar compatibilidad, probar comunicaciones y posiblemente coordinar soporte externo.
En papel, el parche existe.
En la práctica, no es un parche: es un pequeño proyecto.
Y como todo proyecto en OT, necesita planificación, ventana, pruebas, responsables y plan de retorno.
3. Sistemas sin parche práctico
Este es el grupo más incómodo.
Sistemas fuera de soporte. Versiones antiguas. Firmware que ya no recibe actualización. Aplicaciones industriales que el fabricante ya no mantiene. Equipos que siguen funcionando, pero cuyo ciclo de vida de seguridad terminó hace tiempo.
En estos casos, la pregunta deja de ser:
“¿Cuándo parcheamos?”
Y pasa a ser:
“¿Cómo reducimos el riesgo mientras este sistema siga existiendo?”
Qué hacer cuando no se puede parchear
La respuesta honesta a “no se puede parchear” no debería ser resignarse.
Tampoco debería ser ignorar el advisory porque “igual no hay parche”.
Si no puedo eliminar la vulnerabilidad, todavía puedo reducir la probabilidad de explotación y limitar el impacto si algo ocurre.
Eso es gestión de riesgo. Y en este contexto, se traduce en controles compensatorios.
No son la solución perfecta.
Son la solución disponible.
Control 1: segmentar y reducir exposición
El primer control para un sistema legacy vulnerable es limitar con quién puede comunicarse.
No todo equipo de planta necesita hablar con todo. No todo servidor necesita aceptar conexiones desde varios segmentos. No todo acceso histórico sigue teniendo sentido hoy.
La revisión debe responder preguntas simples:
- ¿Qué IP necesita conectarse a este sistema?
- ¿En qué dirección ocurre la comunicación?
- ¿Qué puerto se usa?
- ¿Qué protocolo es estrictamente necesario?
- ¿Qué reglas existen solo por historia o comodidad?
En mi caso, el primer paso fue revisar qué comunicaciones eran realmente necesarias para cada sistema legacy. Todo lo que no tenía justificación operativa clara pasó a revisión.
No siempre se puede hacer microsegmentación perfecta.
Pero incluso una segmentación gruesa es mejor que una red plana donde un sistema vulnerable puede comunicarse libremente con otros activos críticos.
La idea no es bloquear por bloquear. En OT eso sería peligroso.
La idea es reducir el radio de daño si ese sistema llega a ser comprometido.
Control 2: monitorear lo que no se puede corregir
Si un sistema no se puede parchear, al menos debería estar observado.
Eso no significa necesariamente implementar una plataforma compleja desde el primer día. Puede empezar con algo más básico:
- revisar intentos de acceso;
- validar sesiones remotas;
- revisar conexiones inusuales;
- monitorear cambios de comportamiento;
- identificar tráfico que no corresponde al patrón normal;
- registrar quién se conecta y desde dónde.
La clave es construir una línea base.
No puedes detectar lo anormal si nunca definiste qué es normal.
En sistemas legacy, el monitoreo no tiene que buscar únicamente “ataques”. También debe detectar cambios pequeños: un nuevo origen de conexión, un servicio que antes no escuchaba, una cuenta que vuelve a usarse después de meses o una regla de firewall que permite más de lo necesario.
Esas señales pueden parecer menores.
Pero en OT, muchas veces los incidentes empiezan con algo menor.
Control 3: respaldos probados y aislados
Un respaldo que nunca se probó no es una garantía.
Es una suposición.
Esto se vuelve crítico cuando hablamos de sistemas que no se pueden parchear. Si el activo queda comprometido, falla o necesita ser reconstruido, no siempre será posible reinstalar desde cero y aplicar actualizaciones modernas.
La recuperación puede depender de tener una imagen válida, una copia de configuración, un backup de aplicación, licencias disponibles, instaladores antiguos, drivers correctos y documentación suficiente para volver al estado operativo anterior.
En mi revisión encontré algo común: el sistema de backup indicaba éxito, pero nadie había probado una restauración reciente.
Eso no significa que el backup no sirva.
Significa que no lo sabemos.
Para sistemas legacy, el backup debe responder tres preguntas:
- ¿Existe?
- ¿Está aislado de la red principal?
- ¿Se probó una restauración?
Si la respuesta a la tercera es “no”, todavía hay trabajo pendiente.
Control 4: documentar el riesgo aceptado
Este es el punto menos técnico y, probablemente, uno de los más importantes.
Cuando se decide no parchear un sistema, esa decisión debe quedar documentada.
No basta con que todos “sepamos” que no se puede tocar.
Hay que registrar:
- qué sistema es;
- qué vulnerabilidad o advisory aplica;
- por qué no se puede parchear ahora;
- qué impacto tendría actualizarlo sin validación;
- qué controles compensatorios se aplicaron;
- quién conoce y acepta el riesgo;
- cuándo se revisará nuevamente.
Esto cambia completamente la conversación.
No es lo mismo decir:
“Nadie parchó ese servidor.”
que decir:
“Ese servidor no se parcheó porque el software no está certificado para una versión superior; se segmentó, se restringió el acceso remoto, se validó respaldo y se revisará en la siguiente ventana de mantenimiento.”
La primera frase describe abandono.
La segunda describe gestión.
Cómo priorizar cuando todo parece urgente
En sistemas legacy, es fácil terminar con una lista de vulnerabilidades más grande que la capacidad real de respuesta.
Si todo es crítico, nada es crítico.
Por eso no conviene priorizar solo por CVSS. El puntaje ayuda, pero no cuenta toda la historia en OT.
Yo suelo ordenar la revisión con estas preguntas.
¿El sistema tiene acceso remoto activo?
Una vulnerabilidad en un sistema sin exposición remota no tiene el mismo riesgo que la misma vulnerabilidad en un servidor accesible por RDP, VPN, herramienta de proveedor o salto desde la red corporativa.
Si tiene acceso remoto, sube en la lista.
¿El sistema está segmentado?
Un activo vulnerable dentro de una red plana tiene más capacidad de convertirse en punto de movimiento lateral.
Si está bien segmentado, el riesgo baja.
Si no lo está, hay que revisar controles.
¿Qué pasa si el sistema cae?
No todos los activos tienen el mismo impacto operativo.
Algunos sistemas sostienen visualización. Otros historización. Otros ingeniería. Otros alarmas. Otros comunicación con controladores.
Si la caída del sistema deja ciega a la operación, impide diagnóstico o afecta continuidad, el riesgo operativo es mayor aunque el puntaje técnico no sea el más alto.
¿Hay exploit público o explotación conocida?
Si existe explotación pública o evidencia de uso activo contra sistemas similares, la prioridad cambia.
No es lo mismo una vulnerabilidad teórica que una vulnerabilidad que ya está siendo explotada.
¿Tenemos respaldo probado?
Un sistema vulnerable con respaldo probado y ruta clara de recuperación es distinto a uno que depende de “esperemos que el backup funcione”.
La capacidad de recuperación también es parte de la gestión del riesgo.
Lo que me dejó este ejercicio
Una vulnerabilidad conocida sin parche no es solo un problema técnico. Es un riesgo que alguien debe decidir aceptar formalmente.
La diferencia entre “nadie lo parchó” y “decidimos no parchearlo por ahora, con estos controles compensatorios” parece pequeña.
No lo es.
La segunda implica que alguien entendió el problema, revisó opciones, aplicó controles y dejó una decisión trazable.
La primera es solo un riesgo abandonado.
El inventario de activos es el punto de partida de todo.
No se puede gestionar el riesgo de lo que no se sabe que existe.
En OT es común encontrar sistemas instalados durante proyectos que quedaron operando mucho después de que el proyecto terminó. Si no hay inventario actualizado, cualquier gestión de vulnerabilidades empieza incompleta.
“No se puede parchear” no significa “no se puede hacer nada”.
Segmentación, monitoreo, respaldos probados y documentación del riesgo no eliminan la vulnerabilidad, pero sí reducen exposición, impacto e improvisación.
En muchos entornos industriales, ese es el primer paso realista.
El sistema legacy no es el problema por sí solo. El problema es no saber en qué condición está.
Un equipo antiguo, documentado, aislado, monitoreado y con respaldo probado es muy diferente a un equipo antiguo que simplemente sigue conectado porque siempre estuvo ahí.
La diferencia no siempre es presupuesto.
A veces es disciplina operativa.
Acciones implementadas
Después de esta revisión, estas fueron las acciones principales:
-
Se realizó un inventario básico de versiones de sistema operativo, software industrial y firmware en activos priorizados de la red de planta.
-
Se cruzó esa información con advisories públicos de CISA ICS y documentación de fabricantes para identificar vulnerabilidades conocidas aplicables.
-
Los sistemas legacy sin parche práctico fueron documentados con su estado, riesgo identificado y controles compensatorios.
-
Se revisaron reglas de firewall asociadas a los activos más expuestos, restringiendo comunicaciones sin justificación operativa clara.
-
Se revisó el estado de respaldos de sistemas legacy prioritarios y se identificaron respaldos que requerían prueba de restauración.
-
Se coordinó una lista de sistemas parchables para futuras ventanas de mantenimiento, priorizando aquellos con acceso remoto activo o mayor impacto operativo.
-
Se dejó pendiente establecer una revisión periódica de riesgos aceptados, para que los sistemas legacy no queden documentados una vez y luego olvidados.
Checklist práctico para sistemas OT legacy
Si tuviera que repetir esta revisión, empezaría con esta lista:
- ¿Qué sistemas legacy existen en la red de planta?
- ¿Qué versión de sistema operativo, firmware o software corre cada uno?
- ¿Qué advisories públicos aplican?
- ¿Existe parche certificado por el fabricante?
- ¿El sistema tiene acceso remoto activo?
- ¿Desde qué segmentos se puede llegar al activo?
- ¿Qué puertos y servicios están expuestos?
- ¿Qué reglas de firewall lo protegen o lo exponen?
- ¿Tiene cuentas locales antiguas o genéricas?
- ¿Tiene respaldo actualizado?
- ¿Ese respaldo fue probado?
- ¿Existe plan de recuperación?
- ¿El riesgo está documentado?
- ¿Hay fecha de próxima revisión?
No necesitas resolver todo en una sola ventana.
Pero sí necesitas saber qué estás aceptando.
Fuentes consultadas
Forescout Research - Vedere Labs, Rob Hulsebos, Daniel dos Santos
Cierre
El equipo que no se puede parchear no va a desaparecer mañana.
En entornos industriales, los ciclos de renovación tecnológica son largos. A veces se miden en años. A veces en décadas. Los sistemas legacy no son una anomalía temporal; son parte de la realidad operativa.
Pero lo que sí puede cambiar es cómo se gestiona ese riesgo.
Un sistema legacy conocido, documentado, segmentado, monitoreado y con respaldo probado es completamente distinto a un sistema legacy que simplemente existe en la red sin que nadie haya evaluado su estado.
La diferencia entre ambos no siempre es comprar una plataforma nueva.
A veces empieza con algo más simple:
mirar, documentar y decidir.
Con este post cierro esta mini-serie sobre ciberseguridad OT que empezó con el incidente del RDP. Tres artículos, tres ángulos del mismo problema: el acceso remoto que nadie auditó, las amenazas globales que aplican localmente y los sistemas que no se pueden parchear, pero sí se pueden gestionar.
Si alguno de estos temas se parece a tu realidad operativa, probablemente no estás solo. Y tal vez la primera mejora no sea instalar algo nuevo, sino revisar con más intención lo que ya tienes conectado.
Aviso de independencia
Este artículo tiene fines educativos y refleja aprendizajes técnicos generales a partir de experiencias reales anonimizadas. No representa la posición de ninguna empresa, cliente, proveedor o fabricante.
Las recomendaciones deben aplicarse únicamente en entornos propios o autorizados, siguiendo procedimientos internos, políticas de seguridad, validaciones operativas y documentación oficial de fabricantes o proveedores.
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