De cuándo actuar a cómo actuar: claves del Informe de Ciberalertas OT – III

Por Ignacio Quiralte Pérez, Inprosec.

En la tecnología operativa (OT, por sus siglas en inglés), es decir, los sistemas que controlan máquinas y procesos industriales, saber qué vulnerabilidad atender primero no basta. A menudo el parche existe, pero instalarlo exige probarlo, contar con el visto bueno del fabricante o esperar a una ventana de mantenimiento, la parada planificada en la que se puede intervenir en los equipos. Y parte de la infraestructura industrial funciona con equipos sin soporte del fabricante, que ya no recibirán parches.

El Informe de Ciberalertas OT – III del Observatorio de Ciberseguridad Industrial, publicado por la Xunta de Galicia a través de la Agencia para la Modernización Tecnológica de Galicia (Amtega), se ocupa de ese intervalo: cómo reducir el riesgo mientras no se puede aplicar la corrección definitiva.

Lo que añade esta tercera entrega.

El primer informe sentó las bases: definió las vulnerabilidades en entornos industriales, analizó cuánto tardan los atacantes en aprovecharlas («explotarlas», en el lenguaje del sector) y cuantificó el retorno de la inversión de mitigarlas pronto. El segundo abordó cómo priorizar según el riesgo real, con tres herramientas:

• El catálogo de vulnerabilidades explotadas conocidas (KEV, por sus siglas en inglés) de la Agencia de Ciberseguridad y Seguridad de las Infraestructuras de Estados Unidos (CISA). Reúne las vulnerabilidades que ya se aprovechan en ataques reales.
• El sistema de puntuación de predicción de exploits (EPSS). Estima la probabilidad de que una vulnerabilidad se explote en los próximos 30 días.
• El modelo Now/Next/Never («ahora / después / nunca»), que fija cuándo actuar:

• • Now: corregir de inmediato si es seguro o, si no, mitigar ya.
  • Next: reducir la exposición y preparar una ventana de mantenimiento.
  • Never: no intervenir, pero documentar el motivo, vigilar y revisar la decisión periódicamente.

Si el modelo Now/Next/Never decide cuándo actuar, este tercer informe explica cómo hacerlo cuando no se puede corregir de inmediato. Y marca un límite: aplazar un parche no equivale a aceptar el riesgo sin más. La decisión debe documentarse e ir acompañada de tres cosas: una medida alternativa proporcionada (lo que el informe llama «medida compensatoria»), una fecha de revisión y un camino claro hacia la corrección.

Tres ejes para contener el riesgo.

Arquitecturas defendibles. 

El informe se apoya en la norma internacional ISA/IEC 62443-3-2, de la Sociedad Internacional de Automatización (ISA) y la Comisión Electrotécnica Internacional (IEC). Propone dejar atrás las redes industriales «planas», en las que cualquier equipo puede comunicarse con cualquier otro. En su lugar, plantea dividirlas en zonas, que son grupos de equipos con necesidades de seguridad parecidas. Las zonas solo se conectan a través de conductos, los únicos canales de comunicación permitidos entre ellas. Así se limita el movimiento lateral, es decir, que un intruso salte de un equipo a otro.

Separar la red con redes de área local virtuales (VLAN), divisiones lógicas de una misma red física, no basta. Cada conducto necesita reglas comprobables que fijen quién se comunica con quién, por qué protocolo y puerto, en qué sentido y con qué fin. El modelo de confianza cero (Zero Trust) no da por fiable ningún acceso solo porque se produzca dentro de la red. Puede reforzar este esquema, pero no lo sustituye.

Parcheo virtual.

Consiste en bloquear en la red el ataque que aprovecharía la vulnerabilidad, antes de que llegue al equipo y sin modificarlo. Se hace con reglas de inspección profunda de paquetes (DPI, por sus siglas en inglés), que analizan el contenido de las comunicaciones. Esas reglas se instalan en cortafuegos y sistemas de prevención de intrusiones (IPS) industriales capaces de interpretar protocolos de comunicación industrial como Modbus TCP, EtherNet/IP, S7comm, OPC UA o DNP3.

Antes de activar una regla hay que dar tres pasos:

• medir la latencia, el retraso que añade a las comunicaciones;
• descartar falsos positivos, es decir, tráfico legítimo bloqueado por error;
• a ser posible, empezar en modo detección, en el que la regla avisa pero no bloquea.

El parcheo virtual complementa el parche oficial, no lo sustituye: cuando se instala el parche, la regla se retira de forma controlada.

Controles compensatorios. Son medidas alternativas que reducen el riesgo mientras no se puede corregir. El informe destaca tres:

• Aislar el equipo mediante la configuración de la red (aislamiento lógico).
• Restringir o desactivar los protocolos antiguos que transmiten la información sin cifrar, como Telnet, FTP, HTTP o SNMP en sus versiones 1 y 2.
• Reforzar el acceso remoto con tres elementos:
  • Autenticación multifactor (MFA);
  • Una red privada virtual (VPN) cifrada;
  • Un servidor de salto, que es un equipo intermedio controlado por el que pasan obligatoriamente las conexiones. Se sitúa en la zona desmilitarizada (DMZ) industrial, una zona de red aislada entre la red corporativa y la de planta.

El acceso remoto merece especial atención. Según el informe, las conexiones de proveedores, personal de mantenimiento e integradores (las empresas que instalan y configuran los sistemas) están entre las vías de intrusión más frecuentes.

Gestionar la excepción, no olvidarla.

Cada vulnerabilidad que no se corrige en el plazo habitual es una excepción. Para gestionarla, el informe propone un procedimiento mínimo de siete pasos:

1. Confirmar que el equipo está afectado.
2. Evaluar la exposición y las consecuencias.
3. Seleccionar el tratamiento.
4. Validar la medida: probarla en condiciones controladas antes de aplicarla.
5. Aplicarla con trazabilidad: dejar constancia del responsable, el cambio, cómo deshacerlo y cuándo revisarlo.
6. Verificar que bloquea la vía de ataque y deja evidencias.
7. Cerrar la excepción.

Un control solo cuenta como válido si reduce o bloquea el ataque que se quiere evitar sin bloquear comunicaciones legítimas ni perjudicar la producción de forma inaceptable. Además, debe cumplir cuatro condiciones:

• generar evidencias de que funciona;
• contar con un retroceso probado, es decir, un plan para deshacer el cambio si algo falla;
• tener un responsable;
• tener una fecha de revisión.

Cada excepción debe quedar registrada con, entre otros datos:

• su estado: corregida, mitigada o aceptada;
• el riesgo residual, el que queda tras aplicar las medidas;
• la condición para retirarla.

La diferencia entre estados importa. Una vulnerabilidad mitigada sigue presente; solo se ha reducido la probabilidad de que se explote o la gravedad de sus consecuencias.

Lo que muestran los avisos del tercer trimestre.

El catálogo de avisos del informe reúne 84 avisos de seguridad publicados entre julio y septiembre de 2026. Cada aviso puede agrupar varias vulnerabilidades, cada una identificada con su código público CVE (Vulnerabilidades y Exposiciones Comunes). Solo entran los avisos con al menos una vulnerabilidad de gravedad alta o crítica que además sean relevantes para la industria.

El informe separa dos grupos:

• los productos de OT y de sistemas de control industrial (ICS);
• las tecnologías de la información (IT) o de uso transversal que pueden afectar a la operación, como Citrix NetScaler o los puntos de acceso wifi de WatchGuard y HPE (Hewlett Packard Enterprise).

Que un producto figure en el catálogo no significa que una instalación concreta esté expuesta. La prioridad combina cinco factores:

• la gravedad técnica del fallo;
• si un atacante puede llegar de verdad al equipo;
• lo fácil que es aprovecharlo;
• la importancia del equipo;
• las consecuencias para el proceso.

Dos de los casos analizados lo muestran:

• Citrix NetScaler ADC y Gateway, equipos que gestionan el tráfico de aplicaciones y el acceso remoto de muchas empresas. Dos de sus vulnerabilidades ya se aprovechan en ataques reales y figuran en el catálogo KEV, así que la prioridad es Now. El informe aconseja, además, tratar el caso como un posible incidente: revisar si hay indicios de intrusión antes de actualizar y conservar pruebas si se sospecha un ataque.
• Phoenix Contact, Carlo Gavazzi y Pepperl+Fuchs. Las mismas vulnerabilidades críticas afectan a módulos de entrada/salida (E/S) de los tres fabricantes. Son los equipos que conectan los sistemas de control con sensores y actuadores. La prioridad es Now si el equipo es accesible desde redes no confiables y Next si su exposición está muy restringida. El caso muestra, además, cómo un mismo fallo se extiende a productos de varios fabricantes a través de la cadena de suministro.

Las conclusiones del informe señalan debilidades que se repiten:

• interfaces expuestas, es decir, paneles o servicios de los equipos accesibles desde donde no deberían;
• fallos en la gestión de credenciales;
• vulnerabilidades heredadas de componentes de terceros.

De ahí que insista en tres líneas:

• Ganar visibilidad sobre los equipos y sus dependencias con la lista de materiales de software (SBOM), el inventario de los componentes de software de cada producto.
• Reducir la confianza implícita, es decir, dejar de dar por seguro un acceso solo porque viene de dentro de la red.
• Para el mantenimiento remoto, apoyarse en soluciones de gestión de acceso privilegiado (PAM), que controlan y registran los accesos con permisos de administrador.

Conclusión

El informe lo resume en una frase: “En OT, no parchear de inmediato no debería equivaler a no actuar”. La corrección definitiva sigue siendo el objetivo; mientras llega, cada medida temporal debe estar justificada, comprobada y con fecha de retirada.

Desde Inprosec seguimos colaborando con Amtega para ayudar al tejido industrial gallego a gestionar mejor sus vulnerabilidades OT.

Informe completo en el portal Ciberseguridade Galicia: https://ciberseguridadegalicia.gal/es/recursos/documentacion/informe-ciberalertas-3