Cómo implementar una arquitectura OT de confianza cero (Zero-Trust) en sistemas de control industrial

La arquitectura OT de confianza cero (Zero-Trust OT) significa eliminar la confianza implícita en el comportamiento del control industrial, no solo añadir firewalls. En la práctica, esto requiere una segmentación alineada con la norma IEC 62443, la validación explícita de comandos externos, la gestión de vigilancia (watchdog) ante la pérdida de comunicación y estados seguros definidos que puedan probarse en un entorno de simulación controlado antes de su despliegue.

La confianza implícita dentro de las redes OT ya no es una conveniencia inofensiva. Es un riesgo de diseño. La vieja suposición era simple: si un comando provenía de la HMI, la capa SCADA o un controlador adyacente dentro de la red de la planta, probablemente era legítimo. En 2026, esa suposición falla demasiado fácilmente ante movimientos laterales, dispositivos periféricos comprometidos, escrituras mal enrutadas y la degradación habitual de la red.

Durante una prueba de estrés reciente en OLLA Lab, la inyección de una tormenta de difusión (broadcast storm) simulada en una secuencia de PLC sin protección extendió los tiempos de escaneo en 312 milisegundos y provocó un fallo en el interbloqueo de una cinta transportadora. Metodología: 12 ejecuciones de escenarios en una tarea de interbloqueo permisivo de alta velocidad, comparadas con la misma lógica bajo condiciones de red nominales, medidas durante una ventana de prueba interna de 14 días. Este es un punto de referencia interno de Ampergon Vallis, no una tasa estándar de la industria. Solo respalda un punto concreto: el diseño de lógica defensiva debe asumir que las condiciones de la red pueden degradarse. No prueba el cumplimiento, la certificación de seguridad ni el rendimiento universal en campo.

Ahí es donde la arquitectura OT de confianza cero se convierte en un problema de ingeniería en lugar de un eslogan de ciberseguridad.

La arquitectura OT de confianza cero es la práctica de diseñar sistemas industriales de modo que ningún dispositivo, mensaje o ubicación de red sea confiable por defecto. Cada acción que pueda afectar el estado del proceso debe estar explícitamente restringida, verificada y ser recuperable.

La Arquitectura de Referencia Empresarial Purdue sigue siendo importante como modelo de segmentación de red. Lo que ha cambiado es la creencia de que los controles perimetrales por sí solos son suficientes. El pensamiento tradicional de Purdue a menudo asume que si el límite entre la TI empresarial y la OT de planta está reforzado, el interior es comparativamente confiable. Esa suposición es ahora débil ante las rutas de ataque modernas y la complejidad de la integración rutinaria.

Un entorno OT plano o poco segmentado crea dos problemas a la vez:

• Aumenta el radio de impacto de un dispositivo comprometido.
• Fomenta que la lógica del PLC dependa del origen del comando en lugar de la validez del mismo.

Ese segundo fallo a menudo se pasa por alto. Los ingenieros discuten sobre firewalls mientras la lógica de escalera (ladder) sigue aceptando un punto de consigna (setpoint) erróneo porque llegó desde la pantalla "correcta". Las redes importan. Los peldaños (rungs) también.

En términos prácticos de OT, la confianza cero desplaza el enfoque de la defensa exclusiva del perímetro a la verificación a nivel de dispositivo y de lógica. Un PLC no debería asumir que:

• una escritura de HMI es válida,
• un latido (heartbeat) siempre llegará,
• un bit permisivo remoto refleja la realidad,
• o que una pérdida de comunicaciones fallará de forma segura por sí sola.

Esos no son escenarios de amenaza exóticos. Son modos de fallo operativo comunes con implicaciones de seguridad.

La norma IEC 62443 no utiliza "confianza cero" como una etiqueta vaga de endurecimiento. Su estructura, en cambio, empuja a los ingenieros hacia el control de acceso explícito, la segmentación, la integridad del sistema y la resiliencia a nivel de sistema y componente.

Para los profesionales de OT, el cambio más relevante es este: los requisitos de seguridad se aplican cada vez más a los componentes y conductos, no solo a los perímetros del sitio. Eso significa que el PLC, la HMI, la ruta de E/S remota, la estación de trabajo de ingeniería y las relaciones de comunicación son importantes.

Ideas centrales de la IEC 62443 que importan para el diseño de confianza cero centrado en PLC

Las siguientes capacidades son especialmente relevantes al traducir la arquitectura de seguridad en comportamiento de control:

Los valores predeterminados compartidos y el acceso anónimo amplio son incompatibles con un diseño OT defendible.

• Control de identificación y autenticación

No todos los usuarios, estaciones o componentes de software deberían poder escribir en cada etiqueta (tag) o área de memoria.

• Control de uso y cumplimiento de la autorización

El controlador y sus sistemas de soporte deben resistir modificaciones no autorizadas y detectar condiciones anormales.

• Integridad del sistema

La segmentación y el control de conductos reducen las relaciones de confianza innecesarias entre zonas.

• Flujo de datos restringido

El sistema debe mantener el comportamiento de control esencial, o pasar a un estado seguro definido, cuando la calidad de las comunicaciones se degrada.

• Disponibilidad de recursos y resiliencia ante la denegación de servicio

Capacidades de la IEC 62443-4-2 discutidas a menudo en contextos de PLC

Cuando los ingenieros se refieren a los requisitos a nivel de componente, varios requisitos de control se vuelven especialmente relevantes:

Esto aborda quién está interactuando realmente con el componente. Las credenciales de ingeniería compartidas son convenientes hasta que ocurre una revisión de incidentes.

• CR 1.1 Identificación y autenticación de usuarios humanos

Esto permite restringir qué usuarios o sistemas pueden realizar qué acciones, incluido el acceso de escritura a valores relevantes para el proceso.

• CR 2.1 Cumplimiento de la autorización

Esto es importante porque un sistema de control que se comporta de manera impredecible bajo estrés de tráfico no es solo inseguro; es operativamente frágil.

• CR 7.1 Protección contra denegación de servicio

La norma IEC 62443 no le dice cómo escribir cada peldaño. Hace algo más útil: elimina las excusas para escribir lógica que asume una red benigna.

La formación en OT de confianza cero debe definirse mediante comportamientos que puedan observarse, probarse y revisarse. Si la frase no puede sobrevivir al contacto con una lista de verificación de puesta en marcha, es solo decoración.

En este artículo, la formación en OT de confianza cero significa enseñar a los ingenieros a:

• validar las entradas externas antes de que afecten el estado del control,
• limitar los puntos de consigna a un envolvente operativo físico,
• detectar la pérdida de comunicaciones con lógica de vigilancia o latido,
• definir estados seguros explícitos para condiciones de red degradadas,
• separar el comportamiento crítico relacionado con la seguridad de las escrituras externas casuales,
• y verificar cómo se comporta la lógica cuando la red se vuelve lenta, ruidosa o no está disponible.

Este es también el lugar correcto para definir "listo para la simulación" (Simulation-Ready) en términos operativos.

"Listo para la simulación" significa que un ingeniero puede probar, observar, diagnosticar y endurecer la lógica de control contra el comportamiento realista del proceso y condiciones anormales antes de que esa lógica llegue a un proceso en vivo. No significa simplemente sentirse cómodo con la sintaxis del PLC, y no significa estar listo para la autoridad del sitio sin supervisión.

Tres hábitos soportan la mayor parte de la carga práctica: validar entradas, detectar fallos de comunicación y definir un comportamiento de recuperación determinista.

1. Limitación y validación de entradas

Ningún punto de consigna externo debe aceptarse simplemente porque provino de una HMI o capa de supervisión. Debe validarse contra los límites del equipo, los límites del proceso y el modo operativo.

En términos de lógica de escalera, eso a menudo significa enrutar los valores entrantes a través de comprobaciones de límites explícitas antes de que se copien en las etiquetas de control activas.

Los comportamientos de validación típicos incluyen:

• comprobaciones de rango mínimo y máximo,
• permisivos dependientes del modo,
• comprobaciones de plausibilidad de sensores,
• umbrales de alarma para valores anormales pero que aún no requieren disparo,
• y reglas de rechazo o sustitución para valores no válidos.

Un punto de consigna sin una comprobación de rango no es flexibilidad del operador. Es un fallo diferido.

2. Temporizadores de vigilancia (watchdog) y monitoreo de latido

Un PLC no debe asumir que la pérdida de comunicaciones será obvia o inofensiva. La lógica de latido le da al controlador una forma determinista de detectar una supervisión obsoleta.

Un patrón común es monitorear un bit que alterna en un intervalo conocido desde el SCADA, una HMI u otro controlador. Si el latido deja de cambiar dentro de la ventana de tiempo esperada, el PLC realiza la transición a un estado de respaldo definido.

Ejemplo de patrón de escalera:

Lenguaje: Diagrama de escalera (Ladder Diagram)

// Monitor de latido de confianza cero (Watchdog)

// Peldaño 1: Reiniciar temporizador cuando el latido está presente XIC SCADA_Heartbeat_Bit RES Watchdog_Timer

// Peldaño 2: Acumular temporizador cuando el latido está ausente XIO SCADA_Heartbeat_Bit TON Watchdog_Timer (Preajuste: 2000 ms)

// Peldaño 3: Disparar acción de estado seguro al agotarse el tiempo XIC Watchdog_Timer.DN OTE System_Safe_State_Trigger

Este ejemplo es intencionalmente compacto. Las implementaciones reales generalmente necesitan detección de flancos, comprobaciones de estado obsoleto, manejo de alarmas y una secuencia de reinicio definida después de la recuperación de las comunicaciones.

Texto alternativo de la imagen: Captura de pantalla del editor de lógica de escalera de OLLA Lab que muestra una rutina de temporizador de vigilancia. El bloque TON monitorea un bit de latido SCADA y dispara una salida de estado seguro cuando se pierde la conexión de red.

3. Recuperación de estado explícita y comportamiento de salida a prueba de fallos

Una acción comandada por red debe fallar en una dirección predecible cuando se pierden las comunicaciones. Eso generalmente significa diseñar salidas y transiciones de estado para que la supervisión cortada no pueda dejar la máquina funcionando indefinidamente con una intención obsoleta.

Aquí es donde los ingenieros deben tener cuidado con los patrones de enclavamiento (latching) vinculados a escrituras de supervisión. En muchos casos, un comando perdido debería resultar en una salida perdida o una secuencia de respaldo controlada, no en un estado retenido que sobrevive a la pérdida de autoridad de comando.

Las preguntas de diseño útiles incluyen:

• ¿Qué sucede si la fuente del comando desaparece a mitad de la secuencia?
• ¿Qué estado se retiene localmente y por qué?
• ¿Qué salidas deben desenergizarse inmediatamente?
• ¿Qué unidades de proceso requieren una parada controlada en lugar de una parada abrupta?
• ¿Qué condiciones se requieren antes de que se permita el reinicio automático?

La distinción es simple: persistencia de comando frente a seguridad del proceso. No son lo mismo.

La arquitectura de confianza cero se vuelve real cuando el PLC deja de tratar los datos de red como verdad y comienza a tratarlos como entradas sujetas a la filosofía de control.

Esa traducción suele aparecer en cuatro lugares:

Aceptación de comandos

Los comandos externos deben estar controlados por:

• selección de modo,
• permisivos,
• disponibilidad del equipo,
• y bloqueos locales.

Un bit de inicio remoto no debería tener prioridad sobre una prueba fallida, un disparo activo o un bloqueo de mantenimiento. Si lo hace, la red se ha convertido en su filosofía de control.

Manejo de la calidad de los datos

Los valores analógicos, estados remotos y cálculos derivados deben verificarse en cuanto a:

• rango,
• frescura,
• plausibilidad,
• y salud de la fuente.

Un valor obsoleto que todavía parece numéricamente razonable es una de las formas más eficientes de confundir tanto a los operadores como a los ingenieros junior.

Respuesta a la degradación de las comunicaciones

Los controladores deben definir qué sucede bajo:

• mensajes retrasados,
• tráfico en ráfagas,
• pérdida intermitente de latido,
• y desconexión total de la supervisión.

Las posibles respuestas incluyen:

• mantener el último estado durante un intervalo limitado,
• transición al modo manual o local,
• forzar las salidas a un estado seguro,
• o ejecutar una secuencia de parada ordenada.

La respuesta correcta depende del proceso. Una cinta transportadora, una estación de bombeo, un manejador de aire y un patín de dosificación química no deberían fallar todos de la misma manera.

Disciplina de recuperación y reinicio

La lógica de confianza cero también requiere condiciones de recuperación explícitas después de un fallo o desconexión. La reconexión por sí sola no es prueba de que el proceso esté listo para reanudarse.

Un diseño de recuperación sólido puede requerir:

• reconocimiento del operador,
• restauración de la retroalimentación de prueba,
• estabilización basada en temporizador,
• reinicio de secuencia,
• y revalidación de permisivos antes del reinicio.

El retorno de un enlace de red no es un evento de puesta en marcha. Es simplemente el final de un problema.

Los ingenieros no deben probar la degradación del control inducida por ciberataques en equipos de planta en vivo. Esa es la respuesta más clara.

OLLA Lab es útil aquí porque proporciona un entorno de simulación acotado donde los estudiantes pueden construir lógica de escalera en un editor basado en web, ejecutarla en modo de simulación, monitorear variables y E/S, y validar el comportamiento de la lógica contra escenarios de máquinas realistas y modelos tipo gemelo digital. En este contexto, la plataforma funciona como un entorno de ensayo con riesgos contenidos para comportamientos de puesta en marcha de alto riesgo.

Lo que OLLA Lab puede soportar de manera creíble en este flujo de trabajo

Dentro de los hechos del producto proporcionados, OLLA Lab admite:

• construir lógica de escalera directamente en el navegador,
• ejecutar lógica en modo de simulación sin hardware físico,
• alternar entradas y observar salidas y estados de variables,
• usar paneles de variables para inspeccionar etiquetas, valores analógicos y comportamiento relacionado con PID,
• trabajar a través de escenarios industriales realistas con objetivos, peligros, interbloqueos y notas de puesta en marcha documentados,
• y validar la lógica contra simulaciones de equipos 3D/WebXR/VR posicionadas como gemelos digitales.

Eso lo hace adecuado para practicar tareas de validación conscientes de fallos, tales como:

• probar el comportamiento del temporizador de vigilancia,
• observar la causa y el efecto cuando cambia una variable de salud de las comunicaciones,
• verificar si un punto de consigna fuera de rango se limita o se rechaza,
• comparar el estado de la escalera con el estado del equipo simulado,
• y revisar la lógica después de una condición anormal inducida.

Aquí es donde OLLA Lab se vuelve operativamente útil. Permite a los ingenieros ensayar el manejo de fallos que sería costoso, inseguro o simplemente no disponible en hardware de producción.

Un flujo de trabajo de simulación práctico para el manejo de fallos de red

Un ejercicio compacto en OLLA Lab se puede estructurar de la siguiente manera:

Implementar:

• limitación de puntos de consigna,
• temporización de vigilancia,
• salidas de estado seguro,
• y señalización de alarma por pérdida de comunicaciones.

Usar el panel de variables y el modelo de equipo simulado para verificar:

• acumulación de temporizador,
• transiciones de alarma,
• cambios de estado de salida,
• y comportamiento de secuencia bajo condiciones degradadas.

1. Construir la rutina de control base Crear una secuencia simple como una cadena de permisivos de cinta transportadora, una rutina de bomba principal/reserva o una secuencia de inicio de patín de proceso.
2. Definir la dependencia externa Añadir un bit de latido de supervisión, un permisivo remoto o un punto de consigna ingresado por HMI.
3. Añadir lógica defensiva
4. Inyectar el fallo En la simulación, alternar la variable de salud de las comunicaciones, congelar el latido o forzar condiciones de entrada anormales.
5. Observar tanto la lógica como el comportamiento del equipo
6. Revisar y volver a probar Ajustar el comportamiento de respaldo, las condiciones de recuperación o la estructura de permisivos, luego volver a ejecutar el escenario.

Ese bucle es importante porque la lógica defensiva rara vez es correcta en el primer borrador.

Los ingenieros deben documentar evidencia de razonamiento, manejo de fallos y disciplina de revisión. Una carpeta llena de capturas de pantalla de lógica de escalera prueba muy poco fuera de contexto.

Utilice esta estructura de evidencia compacta en su lugar:

Establecer qué significa el comportamiento correcto en términos observables: secuencia normal, comportamiento de estado seguro, manejo de tiempo de espera, respuesta de alarma y condiciones de reinicio.

Documentar la condición anormal exacta introducida: pérdida de latido, punto de consigna no válido, permisivo remoto obsoleto, proxy de tráfico en ráfagas o tiempo de espera de comunicaciones.

1. Descripción del sistema Definir la máquina o unidad de proceso, el objetivo de control, los modos operativos y las dependencias externas.
2. Definición operativa de "correcto"
3. Lógica de escalera y estado del equipo simulado Mostrar los peldaños relevantes, la estructura de etiquetas y el estado correspondiente de la máquina o proceso simulado.
4. El caso de fallo inyectado
5. La revisión realizada Explicar qué cambió en la lógica después de observar el fallo. Esta es la parte que la mayoría de los portafolios omiten y que a los revisores les suele importar más.
6. Lecciones aprendidas Resumir la debilidad del diseño, el principio correctivo y las limitaciones restantes.

Esa estructura demuestra juicio de ingeniería en lugar de teatro de software. También facilita la revisión para instructores, líderes y equipos de contratación.

La validación de gemelos digitales añade contexto de proceso a la revisión de la lógica. Mueve la pregunta de "¿se ejecuta el peldaño?" a "¿se comporta el sistema correctamente bajo condiciones operativas y de fallo realistas?".

Esa distinción es importante porque muchos fallos de control no son fallos de sintaxis. Son fallos de interacción entre la lógica de secuencia, las suposiciones del equipo, la temporización, los permisivos y los estados anormales.

En un entorno de formación acotado, la validación tipo gemelo digital puede ayudar a los ingenieros a observar:

• si un estado comandado coincide con el comportamiento físico del proceso,
• si la retroalimentación de prueba llega cuando se espera,
• si las alarmas se disparan en el momento adecuado y por la razón correcta,
• si una transición de estado seguro es meramente lógica o realmente operativa,
• y si el comportamiento de reinicio es controlado después de un fallo.

Esto es especialmente relevante en escenarios que involucran:

• bombas y estaciones de elevación,
• cintas transportadoras y líneas de envasado,
• HVAC y unidades de manejo de aire,
• unidades de tratamiento de agua y aguas residuales,
• y patines de proceso con comportamiento analógico y PID.

Una rutina de escalera puede verse ordenada mientras el modelo de proceso demuestra que es incorrecta.

La simulación es valiosa, pero no es un sustituto del cumplimiento formal, el análisis de riesgos específico del sitio o la puesta en marcha en campo supervisada.

Una declaración acotada es importante aquí:

• La simulación puede apoyar el ensayo, la validación y el aprendizaje consciente de fallos.
• La simulación no puede certificar un sistema como seguro, protegido o conforme por sí misma.

Eso es importante tanto para la credibilidad como para la disciplina de ingeniería.

Por lo tanto, OLLA Lab debe posicionarse como:

• un entorno seguro para practicar tareas de control de alto riesgo,
• un lugar para observar y revisar la lógica bajo condiciones anormales,
• y un puente desde la sintaxis de escalera hasta el juicio de puesta en marcha.

No debe posicionarse como:

• prueba de cumplimiento de la norma IEC 62443,
• prueba de idoneidad SIL,
• prueba de competencia en el sitio,
• o un atajo a la autoridad de despliegue sin supervisión.

Esos límites no son limitaciones de marketing. Son lo que mantiene honestas las afirmaciones técnicas.

La implementación de la arquitectura OT de confianza cero comienza con la eliminación de la confianza implícita del comportamiento de control. Los firewalls y la segmentación siguen siendo necesarios, pero no son suficientes si el PLC sigue aceptando comandos incorrectos, ignora la supervisión obsoleta o falla de manera impredecible cuando las comunicaciones se degradan.

Los hábitos de ingeniería prácticos son sencillos:

• validar las entradas externas,
• monitorear la salud de las comunicaciones,
• definir estados seguros explícitos,
• y probar el comportamiento anormal antes del despliegue.

Ese es el valor real de un entorno de simulación como OLLA Lab. Ofrece a los ingenieros un lugar contenido para ensayar el manejo de fallos que las plantas en vivo no pueden ofrecer de forma segura como ejercicio de formación. En OT, esa es a menudo la forma más sensata de aprender la lección antes de que el proceso la enseñe de manera más costosa.

- Programa de estándares IEC 62443 (IEC) - Recursos ISA/IEC 62443 (ISA) - Modelo de madurez de confianza cero (CISA) - Avisos y orientación sobre ICS (CISA) - Ciberseguridad para sistemas de control industrial y gemelos digitales (DOI) - Recursos de seguridad funcional y ciberseguridad (exida)