Segmentación de redes en OT: la decisión técnica que separa una intrusión de una parada de planta

Hay una verdad incómoda en ciberseguridad industrial: demasiadas plantas han comprado detección avanzada sin resolver lo básico de arquitectura.

Tenemos NDR, SIEM, dashboard bonito y alertas en tiempo real. Y aun así, cuando alguien entra por IT, se pasea hasta OT con demasiada facilidad. No porque falte tecnología, sino porque sobran rutas.

Si me obligas a elegir un único control para bajar riesgo real en una operación industrial, no elijo la herramienta más cara. Elijo segmentación de red bien diseñada y bien gobernada.

No “VLANs y ya”. Segmentación de verdad: zonas, conduits, reglas mínimas, excepciones con caducidad y disciplina operativa.

El patrón de ataque que se repite en incidentes reales

En OT, el daño serio rara vez empieza con un “hack directo al PLC desde Internet”. El patrón real es mucho menos cinematográfico y mucho más frecuente:

1. ▹Compromiso inicial en IT (phishing, credenciales robadas, VPN débil, proveedor comprometido).
2. ▹Reconocimiento interno del entorno corporativo (AD, shares, servidores de gestión, herramientas remotas).
3. ▹Pivot a sistemas frontera IT/OT (historians, jump servers, servidores de backup, herramientas de parcheo).
4. ▹Movimiento lateral hacia SCADA, estaciones de ingeniería y, desde ahí, activos de control.

Este patrón encaja con múltiples casos conocidos:

• ▹Colonial Pipeline (2021): compromiso en IT con impacto operativo severo por riesgo de continuidad. No hizo falta “romper PLCs” para forzar una decisión de parada.
• ▹Oldsmar (2021): exposición de acceso remoto y control insuficiente de sesión en un servicio crítico.
• ▹TRITON/TRISIS (2017): acceso hasta sistemas instrumentados de seguridad (SIS), donde el problema ya no es solo disponibilidad, sino seguridad física.
• ▹Stuxnet: cadena de compromiso centrada en ingeniería/control para manipulación de proceso.

Lección práctica: el atacante suele aprovechar conectividad legítima. Si no defines y limitas esa conectividad, la red trabaja para el atacante.

Qué significa segmentar en OT (y qué NO)

Segmentar no es dibujar cajitas. Segmentar es imponer límites técnicos verificables al movimiento lateral.

En términos de IEC 62443-3-2, hablamos de:

• ▹Zonas: agrupación de activos con requisitos de seguridad similares.
• ▹Conduits: canales controlados entre zonas con políticas explícitas.

En términos operativos, eso se traduce en tres decisiones obligatorias:

1. ▹Qué activos comparten dominio de confianza.
2. ▹Qué tráfico exacto se permite entre dominios.
3. ▹Quién autoriza y revisa las excepciones.

Si no puedes responder estas tres preguntas con una matriz de comunicaciones actualizada, no tienes segmentación. Tienes conectividad heredada.

Purdue sirve, pero no reemplaza ingeniería

El modelo Purdue sigue siendo útil para ordenar conversaciones (niveles 0 a 5). El error es tratarlo como plantilla rígida.

La realidad 2026 en planta es híbrida:

• ▹Controladores legacy sin cifrado ni autenticación moderna.
• ▹Integraciones con cloud para analítica o mantenimiento predictivo.
• ▹OEMs con acceso remoto.
• ▹Dependencias IT/OT históricas mal documentadas.

NIST SP 800-82 es claro en el espíritu: separa dominios, minimiza rutas y protege fronteras. Purdue ayuda a pensar; no decide por ti. Lo que decide es el análisis de flujo real y el impacto de proceso.

Prioridad técnica: dónde segmentar primero

Si arrancas desde red plana, olvida el sueño de microsegmentación total en 30 días. Empieza por donde más riesgo quitas por cada hora invertida.

1) Frontera IT/OT con Industrial DMZ real

La frontera IT/OT es el control más rentable.

Diseño mínimo serio:

• ▹Industrial DMZ entre red corporativa y red de control.
• ▹Nada de tráfico directo IT a niveles de operación/control.
• ▹Servicios permitidos solo por caso de uso: historización, repositorios intermediados, salto administrativo bastionado, sincronización de tiempo validada.
• ▹Reglas deny by default con allowlist explícita.

Error habitual: DMZ con reglas abiertas “temporales” porque algo no funcionaba en arranque. Dos años después siguen igual.

2) Separar ingeniería, operación y servicios de soporte

En demasiadas plantas, estaciones de ingeniería conviven con HMI/SCADA runtime y servidores auxiliares en el mismo segmento.

Eso convierte una infección de portátil de mantenimiento en problema de toda la operación.

Separación recomendada:

• ▹Segmento de ingeniería/mantenimiento.
• ▹Segmento de supervisión/operación.
• ▹Segmentos de celdas de control por proceso.
• ▹Servicios compartidos en zona controlada, no incrustados en runtime.

3) Segmentación por celda/área de proceso

No agrupes por “departamento”. Agrupa por impacto de proceso.

Ejemplo práctico: línea de envasado, utilidades de vapor, tratamiento de agua y sistema de seguridad no deben compartir el mismo nivel de exposición lateral.

Cuando una celda cae, la arquitectura debe impedir contagio operativo.

Protocolos industriales: el detalle donde se gana o se pierde

En OT, filtrar por puerto es condición mínima, no control suficiente.

• ▹Modbus/TCP: sin autenticación nativa.
• ▹S7comm y otros protocolos legacy: supuestos de red confiable.
• ▹Integraciones OPC clásicas: frecuentes deudas de hardening.

Qué hacer en la práctica:

• ▹Allowlist por pares origen/destino, no por subred amplia.
• ▹Restricción de dirección de flujo cuando aplique.
• ▹Separar estrictamente tráfico de ingeniería del tráfico de operación.
• ▹Forzar salto por bastión con MFA para cambios de lógica y administración.
• ▹Registrar sesión y cambio de configuración con retención útil para forense.

Si puedes migrar casos de uso a OPC UA con certificados y cifrado, mejor. Pero no te engañes: modernizar protocolo sin segmentar la red mantiene vivo el movimiento lateral.

Integrar segmentación con IEC 62443 y NIST 800-82 sin burocracia inútil

Cuando una organización me dice “queremos cumplir norma”, mi respuesta es simple: primero haz que la arquitectura funcione.

Marco práctico:

• ▹IEC 62443-3-2: diseña zonas y conduits con criterio de riesgo.
• ▹IEC 62443-3-3: define requisitos de seguridad por zona/conduit (control de acceso, integridad, etc.).
• ▹NIST SP 800-82: aplica separación entre dominios ICS/IT, control de acceso remoto y monitoreo de comunicaciones críticas.

La norma no sustituye diseño técnico. Solo te obliga a que ese diseño sea defendible.

Errores que siguen costando caro

1. ▹Any-any “temporal” entre IT y OT porque “si no, no arranca”.
2. ▹Jump server compartido por múltiples proveedores sin trazabilidad nominativa.
3. ▹Red de ingeniería mezclada con operación por comodidad histórica.
4. ▹Reglas sin owner: nadie sabe quién aprobó ni cuándo revisar.
5. ▹Inventario desactualizado: se diseñan políticas para una planta que ya no existe.

Si reconoces dos o más, no estás en fase de optimización. Estás en fase de contención de deuda técnica.

Plan de ejecución en 90 días (realista)

Semana 1-3: Baseline técnico y operativo

• ▹Inventario de activos OT con validación de planta (no solo CMDB).
• ▹Captura pasiva de flujos para entender comunicaciones reales.
• ▹Identificación de crown jewels (SIS, SCADA central, controladores críticos, historian principal).
• ▹Mapa de accesos remotos de OEM y terceros.

Semana 4-6: Diseño de zonas y matriz de comunicaciones

• ▹Definir zonas por función y criticidad.
• ▹Definir conduits permitidos con puertos/protocolos específicos.
• ▹Propuesta de Industrial DMZ si no existe.
• ▹Catálogo de excepciones con owner, justificación y fecha de expiración.

Semana 7-9: Piloto controlado

• ▹Aplicar políticas en una unidad acotada.
• ▹Medir tráfico bloqueado y validar impacto operativo.
• ▹Ajustar reglas por evidencia, no por presión.
• ▹Probar rollback completo antes de ampliar.

Semana 10-12: Primer despliegue por oleadas

• ▹Priorizar activos críticos y fronteras expuestas.
• ▹Cambios coordinados OT/IT/operaciones.
• ▹Validación funcional post-cambio con equipo de planta.
• ▹Documentar evidencia para auditoría técnica y cumplimiento.

Resultado esperado: reducción visible de rutas laterales y mejor capacidad de contención ante incidente.

Métricas que sí dicen la verdad

Evita vanity metrics como “número de firewalls instalados”. Mide eficacia:

• ▹Porcentaje de activos críticos detrás de segmentos dedicados.
• ▹Número de flujos permitidos sin owner de negocio.
• ▹Tiempo medio de cierre de excepciones temporales.
• ▹Intentos de acceso lateral bloqueados entre zonas.
• ▹Cobertura de logging en conduits críticos.

Estas métricas conectan seguridad con disponibilidad operativa. Todo lo demás es teatro.

Segmentación y Zero Trust: secuencia correcta

Hay vendors que venden Zero Trust como sustituto de segmentación. No lo es.

En OT, secuencia técnica sensata:

1. ▹Segmentación robusta (compartimentos y rutas mínimas).
2. ▹Control fuerte de identidad/sesión para acceso privilegiado.
3. ▹Verificación continua de contexto y comportamiento.

Si saltas el paso 1, conviertes Zero Trust en discurso sin suelo técnico.

Recomendaciones directas para equipos de planta

• ▹No aceptes reglas permanentes “por urgencia” sin fecha de caducidad.
• ▹Ningún proveedor debe entrar con cuentas compartidas.
• ▹Toda comunicación IT→OT debe tener justificación de negocio y owner.
• ▹Si no puedes cortar una ruta por dependencia operativa, pon compensaciones claras: bastión, MFA, logging de sesión, ventana temporal.
• ▹Haz ejercicios de incidente simulando pivot IT→OT. Te enseñarán más que diez presentaciones.

Cierre

En industrial, una arquitectura plana no es simplicidad: es fragilidad.

La diferencia entre un incidente controlado y una parada de planta rara vez la marca una alerta brillante. La marca el diseño de red previo: qué puede hablar con qué, bajo qué condiciones, y durante cuánto tiempo.

Segmentar bien no es un proyecto cosmético ni un check de auditoría. Es una decisión de continuidad operativa, seguridad física y responsabilidad técnica.

Si hoy tu entorno OT sigue con segmentación superficial, no estás “asumiendo riesgo”. Estás acumulando deuda de impacto.

Empieza por frontera IT/OT, define zonas con criterio de proceso, aplica deny-by-default, y gobierna excepciones con disciplina. Lo demás suma, pero eso es lo que evita que un fallo local se convierta en crisis industrial.