OT/ICS y la exposición directa de PLC o HMI a Internet

Qué está pasando

Las agencias de EE. UU. han advertido de campañas en curso contra PLC Rockwell/Allen‑Bradley expuestos; los atacantes han interactuado con project files y han manipulado información mostrada en HMI/SCADA, causando en algunos casos interrupciones operativas y pérdidas económicas.
El patrón es claro: si el PLC o la HMI son accesibles desde Internet, el atacante no necesita “romper” el dispositivo; basta con encontrarlo, conectarse y abusar de la configuración o de credenciales débiles.

Por qué es tan peligroso

Un PLC gobierna lógica de proceso; una HMI presenta el estado y permite mando/ajuste. Si un atacante altera ambos, puede cambiar setpoints, parar líneas, falsear lecturas o introducir estados inseguros sin necesidad de malware sofisticado.
En muchos entornos OT la HMI es la “ventana de confianza” del operador, así que un cambio malicioso puede retrasar la detección porque parece una condición de proceso legítima.

Vectores habituales

Exposición directa a Internet por IP pública, NAT mal restringido o reglas de firewall demasiado amplias.
Servicios de acceso remoto sin MFA o con credenciales por defecto, especialmente en gateways/cellular modems.
Protocolos OT heredados como Modbus, que carecen de cifrado y autenticación robusta, lo que facilita lectura y modificación de datos en tránsito.

Qué recomiendan las agencias

Eliminar la exposición pública directa de PLCs y HMIs.
Si hace falta acceso remoto, poner un gateway/VPN con MFA, logging y control estricto, nunca el PLC “al aire”.
Segregar IT/OT y mantener los controladores en una zona sin salida directa a Internet.
Deshabilitar servicios innecesarios como web services, Telnet, FTP, VNC o RDP si no son imprescindibles.
Mantener backups offline de los project files del PLC/HMI para poder recuperar rápido tras un cambio malicioso.

Señales de alarma

Requests o sesiones desde IPs no reconocidas a interfaces de gestión OT.
Cambios en project files, lógica o pantallas HMI sin ventana de mantenimiento.
Tráfico a puertos OT desde redes no autorizadas o desde geolocalizaciones anómalas.

Qué haría primero

Inventariar qué PLC/HMI tienen IP pública o son alcanzables desde Internet.
Cortar acceso directo y moverlo a una VPN/jump host con MFA.
Revisar logs de acceso y cambios en HMI/PLC de las últimas semanas.
Verificar si hay backups offline recientes de proyecto y configuración.

Qué hay que detectar

Cambios en el patrón de comunicaciones: un PLC que empieza a hablar con una IP nueva, un HMI que emite comandos fuera de ventana, o tráfico entre zonas que antes no existía.
Uso de protocolos/servicios no esperados: Modbus, CIP/EtherNet-IP, S7, RDP, VNC, web admin o shells de mantenimiento activados sin necesidad operativa.
Cambios de configuración o lógica: modificación de project files, descarga de nuevos programas al PLC, cambios de setpoints, firmas, versiones de firmware o parámetros de red.

Señales útiles de alerta

Nueva conversación PLC↔HMI con origen/destino nunca visto o en horas no habituales.
Tráfico de ingeniería desde estaciones no autorizadas o desde redes IT hacia OT sin pasar por jump-host.
Picos de tráfico o reconexiones repetidas a puertos de control industrial, típicos de scanning, fuzzing o intentos de explotación.

Fuentes de telemetría más útiles

SPAN/TAP pasivo en los enlaces de celda o distribución OT para observar tráfico sin impactar producción.
Logs de switches/firewalls industriales para ver quién cruza zonas y con qué frecuencia.
Historial de cambios en PLC/HMI y en estaciones de ingeniería, incluyendo quién autenticó, cuándo y desde dónde.
Inventario de activos + baseline de “comunicación normal” por celda o línea de producción.

Enfoque práctico de detección

Inventariar PLC, HMI, estaciones de ingeniería y gateways, con IP, modelo y función.
Aprender el patrón normal durante días/semanas: pares de comunicación, puertos, horarios y volúmenes.
Alertar por desviaciones: IP nueva, puerto nuevo, protocolo nuevo, horario anómalo o cambio de lógica/configuración.
Correlacionar con mantenimiento planificado para reducir falsos positivos.

Casos que merecen umbral alto

Un PLC que empieza a recibir tráfico desde Internet, aunque sea “solo lectura”.
Una HMI que muestra cambios de proceso sin que exista ticket de cambio.
Una estación de ingeniería que intenta reprogramar varios PLCs en poco tiempo, o fuera de horario habitual.

Qué suele funcionar mejor

Detección de anomalías basada en comportamiento, no solo firmas, porque en OT muchos ataques usan herramientas legítimas o protocolos normales con contenido malicioso.
Reglas por activos críticos: los PLC “crown jewels” deben tener alertas más estrictas que activos secundarios.
Segmentación + monitoreo como dupla: si el tráfico entre zonas está muy restringido, lo poco que pase es más fácil de vigilar.

Prioridades de diseño

Aislar IT de OT con una DMZ industrial y evitar accesos directos desde la red corporativa a PLC/HMI. La segmentación IT/OT es una de las medidas más efectivas para frenar el movimiento lateral tras un zero-day.
Eliminar exposición directa a Internet de PLC, HMI, gateways y consolas de ingeniería. Si hace falta acceso remoto, debe pasar por VPN/Jump Host con MFA y registro de actividad.
Reducir privilegios y servicios: desactivar lo que no se use, limitar cuentas de ingeniería y restringir protocolos de mantenimiento a orígenes concretos.

Controles técnicos clave

Firewall/ACL por zonas: permitir solo los flujos imprescindibles entre IT, DMZ industrial y celdas OT. Todo lo demás, bloqueado por defecto.
Puertas de enlace unidireccionales cuando solo necesites telemetría o exportación de datos hacia fuera, evitando que el tráfico de retorno alcance activos críticos.
IDS/monitorización pasiva en enlaces OT para detectar tráfico anómalo sin interferir en producción.
Gestión de vulnerabilidades OT con inventario continuo de activos, versiones y superficies expuestas, priorizando parches por impacto operacional y no solo por CVSS.

Detección y respuesta

Baselines de comunicación: qué PLC habla con qué HMI, en qué horarios y con qué protocolos. Cualquier nueva relación o cambio de volumen debe generar alerta.
Alertas por eventos de alto riesgo: carga de nuevos programas en PLC, cambios de setpoints, accesos de ingeniería fuera de ventana y conexiones desde redes no autorizadas.
Plan de respuesta específico OT: contención sin apagar a ciegas, validación con operaciones y recuperación desde copias offline de proyectos PLC/HMI.

Procesos que más reducen riesgo

Gestión formal del cambio: ningún cambio en lógica, firmware, pantallas HMI o reglas de red sin ticket, aprobación y ventana de mantenimiento.
Backups offline y verificados de proyectos de PLC/HMI, configuraciones de switches/firewalls y recetas de operación.
Inventario y criticidad: clasificar activos “crown jewels” y elevar la vigilancia sobre ellos; un PLC crítico no debe tener el mismo nivel de exposición que un activo secundario.
Formación operativa: ingeniería y operaciones deben saber reconocer señales de manipulación, no solo el equipo de ciberseguridad.

Medida mínima recomendada

Si tuviera que resumirlo en una base sólida, sería esta secuencia: inventariar, segmentar, restringir acceso remoto, monitorizar pasivamente, y formalizar cambios y recuperación.

Un ejemplo práctico: un PLC de planta no debería ser accesible desde Internet ni desde la red de usuarios; solo desde una estación de ingeniería concreta, dentro de una zona OT, con MFA vía jump host y con alertas si aparecen IPs nuevas o si se descarga un proyecto fuera de la ventana de mantenimiento.