Seguridad en entornos OT e ICS: protegiendo la industria
1. Introducción
La Seguridad en entornos OT e ICS se ha convertido en una de las prioridades estratégicas de la ciberseguridad industrial. Mientras que en el mundo IT la confidencialidad domina el triángulo CIA, en los entornos OT la disponibilidad y la integridad son absolutas: un fallo en un PLC puede detener una línea de producción, cortar el suministro eléctrico o comprometer la seguridad física de las personas. En este artículo exploramos cómo proteger estos sistemas críticos con una metodología práctica basada en normas como IEC 62443.
La convergencia entre IT y OT, impulsada por la Industria 4.0, ha expuesto a las plantas industriales a los mismos peligros que afectan a las redes corporativas: ransomware, APT y acceso remoto inseguro. La Seguridad en entornos OT e ICS ya no es opcional: es una necesidad regulatoria, operativa y financiera. Estudios de 2026 confirman que más del 60% de las organizaciones industriales sufrió al menos un incidente de ciberseguridad el año anterior, y la mitad de ellos se originó a través de la red corporativa o de accesos remotos mal protegidos.
Para entender la magnitud del problema, recordemos incidentes públicos como el ataque a Colonial Pipeline en 2021 o los múltiples asaltos a infraestructuras de agua y energía en 2023 y 2024. En todos los casos, el patrón fue idéntico: un punto de entrada IT permitió el acceso a la red OT, y la falta de segmentación hizo el resto. Por eso, cualquier estrategia de Seguridad en entornos OT e ICS debe empezar por conocer el modelo de referencia de Purdue y las zonas de confianza definidas por IEC 62443.
A lo largo de este artículo realizamos un laboratorio conceptual y técnico: montaremos una red OT simulada, aplicaremos segmentación por zonas, monitorizaremos protocolos industriales con herramientas de la comunidad y definiremos un plan de respuesta a incidentes OT. Al final, tendrás una hoja de ruta clara para elevar la Seguridad en entornos OT e ICS de tu organización, tal y como hacemos en Jaymon Security en los proyectos industriales de nuestros clientes.
2. Entendiendo el modelo Purdue e IEC 62443
La Base de Referencia de Purdue (o ISA-95) organiza la infraestructura industrial en niveles que van desde los dispositivos físicos hasta la gestión empresarial:
| Nivel | Zona | Sistemas típicos | Riesgo |
|---|---|---|---|
| 0 | Procesos físicos | Sensores, actuadores, motores | Alto |
| 1 | Control básico | PLC, RTU, DCS | Alto |
| 2 | Supervisión | SCADA, HMIs, historizadores | Medio |
| 3 | Operaciones | MES, sistemas de planificación de planta | Medio |
| 4 | Corporativo | ERP, correo, acceso a internet | Bajo |
Fig. 1 – Niveles del modelo Purdue y ejemplos de sistemas por zona.
IEC 62443 aporta el marco de seguridad: define zonas y conductos (zones and conduits), el concepto de defensa en profundidad y los requisitos técnicos por nivel de seguridad de seguridad (SL). La idea central es que el tráfico entre zonas solo debe atravesar conductos controlados, idealmente por firewalls industriales o pasarelas unidireccionales (data diodes) cuando el flujo es solo de lectura.
La Seguridad en entornos OT e ICS requiere, por tanto, un diseño donde ningún dispositivo de nivel 0-2 sea alcanzable desde la red corporativa sin pasar por una zona desmilitarizada industrial (DMZ OT). Es el primer control que suele recomendar cualquier auditoría de seguridad industrial.
2.1. Niveles de seguridad (SL) de IEC 62443
IEC 62443 define cuatro niveles de seguridad (SL): SL 1 frente a errores accidentales; SL 2, frente a atacantes casuales; SL 3, frente a expertos con recursos medios; y SL 4, frente a adversarios sofisticados. Comparar el SL logrado y el objetivo fija las prioridades del plan de Seguridad en entornos OT e ICS.
3. Protocolos industriales y sus vulnerabilidades
3.1. Modbus y DNP3
Modbus sigue siendo el protocolo más extendido en instalaciones eléctricas y de automatización. Tristemente, es un protocolo sin autenticación ni cifrado: cualquier nodo de la red que hable Modbus puede leer y escribir registros en un controlador. Herramientas como modbus-cli o Scapy permiten descubrir dispositivos y manipularlos en segundos:
# Descubrir dispositivos Modbus en la red OT
python3 -m pip install modbus-cli
modbus discover 192.168.10.0/24
# Leer el registro 0 del dispositivo 1
modbus read 192.168.10.11 1 0 10
# Escritura de un registro (peligroso en producción)
modbus write 192.168.10.11 1 0 9999
Fig. 2 – Ejemplo de enumeración Modbus con herramientas ofensivas comunes.
DNP3, muy usado en el sector eléctrico, incorpora capas de datalink y application con cierta autenticación opcional, pero la mayoría de despliegues antiguos no la activan. El protocolo de transporte subyacente suele ser TCP/IP directamente, sin TLS, lo que permite ataques de suplantación y replay.
3.2. OPC UA y el futuro de la convergencia
OPC UA es el estándar moderno y sí soporta cifrado y autenticación con certificados X.509. No obstante, su complejidad hace que muchas integraciones se realicen con la seguridad desactivada por defecto, creando una falsa sensación de protección. Auditar la configuración de los servidores OPC UA debe ser parte del checklist de Seguridad en entornos OT e ICS.
3.3. Ataques reales a PLC y HMI: Stuxnet e Industroyer
Stuxnet (2010) reescribió el firmware de los PLC SIEMENS S7-300 para alterar las centrífugas de Natanz: un controlador comprometido sabotea el mundo físico. Industroyer (2016) e Industroyer2 (2022) abrieron interruptores eléctricos en Ucrania con tramas DNP3 válidas. La lección para la Seguridad en entornos OT e ICS: vigilar el origen de cada escritura y proteger las estaciones de ingeniería, porque un HMI comprometido reescribe el firmware del PLC y borra huellas.
4. Laboratorio: red OT simulada con segmentación
Montaremos un laboratorio con dos máquinas virtuales y un contenedor:
# Red OT simulada con Docker
docker network create -d bridge --subnet=192.168.10.0/24 ot_net
docker network create -d bridge --subnet=192.168.99.0/24 it_net
# PLC simulado (OpenPLC)
docker run -d --name plc1 --network ot_net -p 502:502 openplc/openplc:v3
# HMI (Scada-LTS)
docker run -d --name hmi --network ot_net -p 8080:8080 scadalts/scadalts:latest
Fig. 3 – Despliegue de una planta simulada con OpenPLC y Scada-LTS.
Desde la máquina del nivel IT (192.168.99.x) comprobamos que el acceso directo al PLC debe estar denegado. Solo el firewall industrial (implementado con iptables en un nodo puente) permite el flujo específico: IT → DMZ → OT:
# Firewall industrial: solo permitir HMI -> PLC por el puerto 502
iptables -A FORWARD -i eth_it -o eth_ot -j DROP
iptables -A FORWARD -i eth_ot -o eth_it -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth_it -o eth_ot -p tcp --dport 502 -j ACCEPT
Fig. 4 – Reglas iptables que implementan el conducto controlado entre zonas.
Este ejercicio demuestra que una segmentación bien diseñada convierte un sistema expuesto en un sistema aislado, sin necesidad de sustituir los PLC existentes.
4.1. Inventario de activos y criticidad
El inventario típico de una planta de aguas incluiría:
| Activo | Nivel | Criticidad | Protocolo |
|---|---|---|---|
| PLC1 (bombeo) | 1 | Crítica | Modbus TCP |
| PLC2 (cloración) | 1 | Crítica | DNP3 |
| Historiador SCADA | 2 | Alta | OPC UA |
Cada fila se traduce en reglas del firewall industrial, una verificación esencial de la Seguridad en entornos OT e ICS.
5. Monitorización y detección en entornos OT
La visibilidad es el primer problema de cualquier planta: los equipos OT antiguos no generan logs de seguridad ni soportan agentes convencionales. La solución pasa por el análisis pasivo del tráfico de red (SPAN/TAP) con herramientas como Zeek o Suricata con firmas específicas de protocolos industriales:
# Analizador de tráfico OT con Zeek
zeek -i eth_mirror -r capture_ot.pcap
# Revisar eventos Modbus
cat modbus.log | head -20
# Suricata con reglas para protocolos industriales
suricata -i eth_mirror -S /etc/suricata/rules/ot.rules
Fig. 5 – Captura pasiva de tráfico OT para detectar comandos anómalos.
Conviene además correlacionar con un SIEM como Wazuh, que ya incluye decodificadores para Modbus y DNP3 mediante plugins de la comunidad. Reglas básicas de detección: escrituras fuera de ventanas de mantenimiento, escaneos de red dentro de la planta o cambios de configuración en los PLC.
5.1. Reglas de detección específicas para OT
Reglas para escrituras Modbus fuera de ventana:
# Zeek: alerta de escritura Modbus
signature modbus_write_alert {
dst-port == 502
event "Escritura Modbus fuera de ventana"
}Suricata firma funciones sospechosas con el decode Modbus habilitado; correlacionando en el SIEM se detectan escaneos internos, indicador clave de la Seguridad en entornos OT e ICS.
6. Acceso remoto seguro y respuesta a incidentes OT
El acceso remoto de mantenimiento es el vector de entrada más frecuente. La buena práctica es un jump host bastionado en la DMZ OT con MFA, registro de sesión (como con Teleport o Guacamole) y aprovisionamiento temporal. Paralelamente, el playbook de respuesta a incidentes OT debe priorizar la contención física: aislar la zona, no reiniciar sistemas ciegamente (la evidencia reside en memoria) y comunicarse con los operadores de planta antes de cualquier acción técnica.
Un plan de Seguridad en entornos OT e ICS debe incluir simulacros periódicos, copias de seguridad del firmware y de las configuraciones de los PLC, y un inventario actualizado de activos con su criticidad. La respuesta ante ransomware en OT, por ejemplo, difiere de la IT: parar el proceso puede ser más costoso que el propio rescate, y las decisiones deben tomarlas equipos mixtos de operación y ciberseguridad.
6.1. Playbook de respuesta a incidentes OT
El plan debe estar escrito, probado y asignado. La secuencia para incidentes sobre PLC y HMI es:
| Paso | Acción | Responsable | Tiempo |
|---|---|---|---|
| 1 | Confirmar y clasificar el incidente | Centro de operaciones | 15 min |
| 2 | Aislar la zona sin detener el proceso | Planta + SOC | 30 min |
| 3 | Capturar evidencias en memoria | Respuesta a incidentes | 1 h |
| 4 | Restaurar firmware y configuración desde backup | Equipo industrial | 4 h |
Artículos relacionados: Análisis de ingeniería inversa de un troyano bancario y Ransomware a través de escritorio remoto RDP.
7. Conclusión
La Seguridad en entornos OT e ICS requiere un enfoque distinto al de las redes corporativas, pero utiliza principios conocidos: segmentación por zonas, visibilidad, control de accesos y planes de respuesta probados. El modelo Purdue e IEC 62443 ofrecen el mapa y las normas; las herramientas de código abierto permiten empezar hoy mismo sin grandes inversiones.
En Jaymon Security ayudamos a industrias y operadores a auditar y reforzar su Seguridad en entornos OT e ICS: desde el inventario de activos y la segmentación hasta la monitorización continua y los simulacros de incidentes. Si tu planta está conectada, merece la pena saber si está protegida. Más información en nuestra página de contacto o en el marco de referencia de IEC 62443 y las guías de CISA.
¿Necesitas ayuda con Seguridad en entornos OT e ICS?
En Jaymon Security ayudamos a las organizaciones a proteger sus sistemas. Desde auditorías de seguridad hasta implementación de SIEM/SOC, nuestro equipo de expertos diseña soluciones a medida.
Contacta con nosotros para una evaluación gratuita de tu infraestructura.
