Cómo proteger la lógica de PLC contra intrusiones usando IEC 62443 en OLLA Lab

Para proteger la lógica de PLC contra intrusiones bajo la norma IEC 62443-4-2, los ingenieros deben implementar control de acceso a nivel de componente, comprobaciones de integridad de comunicación y un comportamiento de estado seguro determinista dentro de la propia lógica de control. OLLA Lab proporciona un entorno de simulación acotado para ensayar bloqueos, detección de pérdida de latidos (heartbeat) y validación de respuesta ante intrusiones antes de que esos comportamientos se confíen cerca de equipos reales.

La seguridad perimetral es necesaria, pero no es la última línea de defensa. Si un actor de amenazas llega a la red de control, el PLC ya no solo está ejecutando lógica de proceso; está decidiendo si los comandos inseguros se convierten en movimiento físico.

La norma IEC 62443-4-2 es relevante aquí porque traslada parte de la carga de seguridad al propio componente. Esto incluye la identificación, la fuerza de la autenticación, la integridad de la comunicación y el acceso a eventos relevantes para la auditoría a nivel de dispositivo, no solo en el firewall. En la práctica, esto significa que la lógica de escalera (ladder) debe rechazar cambios de estado imposibles o no autorizados, detectar la pérdida de supervisión confiable y forzar al proceso a una condición segura definida.

Métrica de Ampergon Vallis: En 24 simulaciones de "red-team" en OLLA Lab de cambios de estado forzados no autorizados contra un modelo de permisivos de bomba y válvula, 24 de 24 intentos fueron interceptados por un interbloqueo de pérdida de latidos más permisivos de ejecución explícitos antes de que el motor simulado entrara en un estado de marcha comandado [Metodología: n=24 ensayos de intrusión simulados en un escenario de entrenamiento de permisivos de seguridad, comparador base = mismo escenario sin interbloqueo de pérdida de latidos ni lógica de bloqueo, observado durante marzo de 2026]. Esto respalda el valor de los controles de respaldo a nivel de lógica en ese escenario. No establece una reducción general de la tasa de brechas en todas las plataformas, arquitecturas o plantas de PLC. Un simulador es útil para obtener evidencia, no para crear mitología.

La seguridad a nivel de lógica es necesaria porque la norma IEC 62443 no trata al PLC como un punto final pasivo. La IEC 62443-4-2 define los requisitos de seguridad de los componentes para dispositivos integrados y host, incluyendo controles relacionados con la identificación y autenticación, la integridad de la comunicación y el comportamiento relevante para la auditoría.

El cambio práctico es simple: un PLC no debe asumir que cada comando que llega desde una ruta de red confiable es legítimo. Esa suposición siempre fue optimista. Ahora es simplemente menos defendible.

Los requisitos relevantes citados comúnmente en este contexto incluyen:

- CR 1.1 — Identificación y autenticación de usuarios humanos: el componente debe admitir la identificación y autenticación de usuarios humanos. - CR 1.7 — Fuerza de la autenticación basada en contraseñas: los mecanismos de contraseña deben cumplir con las expectativas de fuerza mínima. - CR 3.1 — Integridad de la comunicación: el componente debe proteger la integridad de las comunicaciones o detectar fallas de integridad. - CR 6.1 — Accesibilidad del registro de auditoría: los eventos relevantes para la seguridad deben estar disponibles para su revisión e investigación.

Estos requisitos no significan que cada función de seguridad se implemente directamente en la lógica de escalera. Algunas pertenecen al firmware, a la configuración del controlador, al diseño de la HMI o a la arquitectura circundante. El punto de ingeniería es más estrecho y más útil: donde la seguridad del proceso o la protección del equipo depende de la validez del comando, el programa de control debe aplicar permisivos deterministas y un comportamiento ante estados anormales incluso después de que la confianza ascendente haya fallado.

Un error común es pensar que la ciberseguridad y la lógica de control son disciplinas separadas. No lo son una vez que un comando malintencionado puede arrancar un motor contra una válvula cerrada, anular una secuencia o mantener una salida en un estado que el proceso nunca debería tolerar. En ese punto, un problema de red puede convertirse rápidamente en daño mecánico.

Los avisos de CISA sobre productos industriales revelan repetidamente debilidades como el control de acceso inadecuado (CWE-284) y la transmisión en texto plano de información sensible (CWE-319) en entornos heredados. Esos avisos no implican que la lógica de escalera por sí sola resuelva el problema. Refuerzan una verdad más dura: si las credenciales, las sesiones o las rutas de comando son débiles, el programa del controlador debe escribirse para desconfiar de las transiciones de estado inseguras.

“Listo para simulación” debe definirse como la capacidad de probar, observar, diagnosticar y endurecer la lógica de control contra un comportamiento de proceso realista antes de la implementación en un proceso real. No es un sinónimo de “saber escribir sintaxis ladder”.

Operativamente, un ingeniero “listo para simulación” puede:

• definir qué se le permite hacer al proceso,
• codificar esos límites como permisivos, disparos (trips) y bloqueos,
• inyectar condiciones anormales,
• observar el comportamiento de las etiquetas (tags) y la respuesta del equipo,
• revisar la lógica después de una falla,
• y documentar por qué el comportamiento revisado es más correcto.

Esa distinción importa porque la sintaxis frente a la capacidad de despliegue es donde muchos entornos de entrenamiento se detienen demasiado pronto. Un peldaño (rung) que compila aún no es una estrategia de control. Un peldaño que sobrevive a entradas incorrectas, pérdida de supervisión y estados de campo contradictorios está más cerca.

En este artículo, OLLA Lab se posiciona dentro de ese rol acotado. Es un entorno de simulación y lógica de escalera basado en web donde los ingenieros pueden ensayar tareas de validación de alto riesgo de forma segura: monitorear E/S, forzar valores anormales, rastrear causa y efecto, comparar el estado de la escalera con el estado del equipo simulado y revisar la lógica después de una falla. No es un sustituto para la aceptación en sitio, el cumplimiento formal o la competencia demostrada en una planta real.

La protección por contraseña en la lógica de escalera debe tratarse como un mecanismo de control de acceso acotado, no como una plataforma de identidad completa. El patrón útil es verificar un valor ingresado desde la HMI, contar los intentos fallidos y enclavar un estado de bloqueo que bloquee los comandos privilegiados hasta que se cumpla una condición de reinicio supervisada.

Una implementación compacta puede construirse a partir de instrucciones estándar:

• `EQU` para comparar valores ingresados y almacenados
• `CTU` para contar intentos fallidos
• bobina enclavada / bit de memoria para mantener el estado de bloqueo
• contactos permisivos para bloquear acciones protegidas
• condición de reinicio supervisada para borrar el bloqueo

Patrón de lógica central

Objetivo: Permitir una acción administrativa o de mantenimiento solo cuando el PIN ingresado coincida con el valor almacenado y el sistema no esté en bloqueo.

Etiquetas sugeridas:

- `HMI_PIN_Entry` : entero ingresado desde la HMI - `Stored_Admin_PIN` : constante entera o valor asegurado - `PIN_Submit_Pulse` : pulso único (one-shot) de la acción de envío de la HMI - `PIN_Match` : bit interno - `Failed_Attempt_CTU` : contador - `System_Lockout_Alarm` : bit enclavado - `Admin_Access_Granted` : bit interno - `Lockout_Reset_Request` : comando de reinicio supervisado

Ejemplo de flujo de lógica de escalera

Peldaño 1: Evaluar el PIN enviado `| PIN_Submit_Pulse |----[EQU HMI_PIN_Entry Stored_Admin_PIN]----( PIN_Match )`

Peldaño 2: Contar intentos fallidos `| PIN_Submit_Pulse |----[/PIN_Match]----------------------------[CTU Failed_Attempt_CTU PRE 3]`

Peldaño 3: Enclavar bloqueo cuando los intentos fallidos alcanzan el preajuste `| Failed_Attempt_CTU.ACC >= 3 |---------------------------------(L) System_Lockout_Alarm`

Peldaño 4: Conceder acceso solo si la coincidencia es verdadera y no existe bloqueo `| PIN_Submit_Pulse |----[PIN_Match]----[/System_Lockout_Alarm]--( Admin_Access_Granted )`

Peldaño 5: Reiniciar bloqueo solo bajo condiciones supervisadas `| Lockout_Reset_Request |----[Supervisor_Mode]------------------(U) System_Lockout_Alarm` `| Lockout_Reset_Request |----[Supervisor_Mode]------------------[RES Failed_Attempt_CTU]`

El propósito de ingeniería no es una gestión elegante de credenciales. Es el control determinista sobre acciones privilegiadas. Si la HMI está siendo objeto de un ataque de fuerza bruta, el PLC debe dejar de aceptar intentos después de un umbral definido y debe requerir una ruta de recuperación supervisada explícita.

Lo que esta lógica hace bien

• bloquea intentos repetidos de prueba y error,
• crea un estado de bloqueo visible,
• evita que se ejecuten comandos protegidos después de fallas repetidas,
• proporciona un evento claro para la revisión del operador o mantenimiento.

Lo que esta lógica no hace

• no reemplaza la gestión segura de usuarios en la HMI o la plataforma del controlador,
• no cifra las credenciales,
• no satisface todos los requisitos de autenticación de IEC 62443 por sí misma,
• no prueba que la arquitectura circundante sea segura.

Ese límite importa. Un contador no es un sistema de identidad.

Los permisivos de acceso deben estructurarse en torno a la validez del proceso primero, privilegio del usuario segundo. Un comando de usuario válido debería fallar si el estado del proceso hace que el comando sea inseguro.

Por ejemplo, un comando de arranque de bomba no debería energizar la salida de marcha simplemente porque un usuario de HMI autenticado lo solicitó. El peldaño también debería requerir:

• ruta de descarga disponible,
• condición de succión o nivel aceptable,
• sin bloqueo activo,
• sin disparo (trip) activo,
• latido (heartbeat) saludable,
• estado de modo y secuencia válido,
• retroalimentaciones de prueba consistentes con el estado previo al arranque esperado.

Un modelo de permisivos compacto se ve así:

`| Start_Command |` `|----[Admin_Access_Granted OR Operator_Run_Permitted]` `|----[/System_Lockout_Alarm]` `|----[HMI_Heartbeat_Healthy]` `|----[Discharge_Valve_Open_Proof]` `|----[/Pump_Trip_Active]` `|----[Auto_Sequence_Ready]` `|----------------------------------------------------( Pump_Run_Permissive )`

Entonces, el peldaño de salida debe consumir `Pump_Run_Permissive`, no el comando crudo.

Esa separación es importante. La intención del comando no es la autoridad del comando. En la lógica de control segura, el comando pregunta; el permisivo decide.

Un monitor de latidos es un patrón lógico que confirma la comunicación continua desde una fuente de supervisión confiable al requerir una transición de bit periódica dentro de una ventana de tiempo definida. Si el bit deja de cambiar, el PLC trata eso como una pérdida de supervisión y elimina la autoridad de marcha o lleva el proceso a un estado seguro.

Esta es una forma práctica de apoyar la intención detrás de los requisitos de integridad de la comunicación. No prueba que el remitente sea benevolente, pero detecta un modo de falla común: la sesión de HMI o supervisión esperada ha desaparecido, se ha estancado o ha sido desplazada.

Por qué importa la lógica de latidos

Si se espera que una HMI legítima alterne un bit cada segundo y ese bit deja de cambiar, existen varias posibilidades:

• la HMI ha fallado,
• las comunicaciones han sido interrumpidas,
• la sesión de supervisión se ha congelado,
• un dispositivo no autorizado ha reemplazado o evadido la ruta esperada,
• o el proceso ya no está bajo las suposiciones de control en las que el PLC fue diseñado para confiar.

El controlador debe reaccionar a esa pérdida de manera determinista. Esperar cortésmente rara vez es una estrategia de control.

Ejemplo de diseño de latidos usando `TON`

Etiquetas sugeridas:

- `HMI_Heartbeat_Bit` : alternado por la HMI - `Last_Heartbeat_State` : estado anterior almacenado - `Heartbeat_Change_Pulse` : pulso único cuando el estado cambia - `Heartbeat_Timer` : `TON` - `HMI_Heartbeat_Healthy` : bit interno - `System_Run_Permissive` : bit interno utilizado en otros lugares

Concepto lógico

Peldaño 1: Detectar cambio de latido `| HMI_Heartbeat_Bit XOR Last_Heartbeat_State |------------------( Heartbeat_Change_Pulse )`

Peldaño 2: Actualizar estado almacenado al cambiar `| Heartbeat_Change_Pulse |--------------------------------------( Last_Heartbeat_State := HMI_Heartbeat_Bit )`

Peldaño 3: Reiniciar temporizador cuando el latido cambia; tiempo de espera si no ocurre cambio `| /Heartbeat_Change_Pulse |-------------------------------------[TON Heartbeat_Timer PRE 2000ms]`

Peldaño 4: Declarar latido saludable solo cuando el temporizador no ha terminado `| /Heartbeat_Timer.DN |-----------------------------------------( HMI_Heartbeat_Healthy )`

Peldaño 5: Eliminar permisivo de marcha ante pérdida de latido `| Existing_Process_Permissives |----[HMI_Heartbeat_Healthy]-----( System_Run_Permissive )`

La implementación exacta varía según la familia de PLC y el conjunto de instrucciones. El principio no: si la fuente de supervisión confiable deja de comportarse como tal, el PLC debe degradarse de forma segura.

Elección de la ventana de tiempo de espera

El tiempo de espera debe basarse en:

• tasa de actualización esperada de la HMI,
• determinismo de la red,
• criticidad del proceso,
• tolerancia a disparos molestos,
• y las consecuencias de estado seguro de un falso positivo.

Un tiempo de espera de 500 ms puede ser apropiado en algunos contextos de supervisión rápida. Un tiempo de espera de 2000 ms puede ser más estable en otros. El número correcto es el que está justificado por el proceso y probado bajo un comportamiento de escaneo y comunicaciones realista, no el que parece severo en un diagrama.

Puede simular un ataque de fuerza bruta en OLLA Lab forzando valores de credenciales inválidos repetidos a través del Panel de Variables, observando el contador y los bits de bloqueo en la simulación, y confirmando que el gemelo digital o el equipo simulado permanece en un estado seguro a pesar de las solicitudes de marcha continuas.

Aquí es donde OLLA Lab se vuelve operativamente útil. Practicar esto en un proceso real sería una mala forma de preservar el tiempo de actividad.

3 pasos para probar la lógica defensiva

#### 1. Inyectar datos anómalos

Use el Panel de Variables para manipular:

• `HMI_PIN_Entry`
• `PIN_Submit_Pulse`
• cualquier bit de comando relacionado como `Start_Command`

Ingrese valores enteros incorrectos repetidamente y pulse el bit de envío como si una sesión de HMI estuviera siendo objeto de fuerza bruta.

Qué observar:

• si `PIN_Match` permanece falso,
• si `Failed_Attempt_CTU.ACC` se incrementa una vez por intento,
• si los pulsos únicos (one-shots) se comportan correctamente y no cuentan de más debido al comportamiento del escaneo.

#### 2. Verificar la ejecución del bloqueo

Continúe con los envíos inválidos hasta que el contador alcance su preajuste.

Resultado esperado:

• `Failed_Attempt_CTU.ACC` alcanza `3`,
• `System_Lockout_Alarm` se energiza y se enclava,
• `Admin_Access_Granted` permanece falso,
• los comandos protegidos ya no crean permisivos descendentes.

Esta validación es importante porque los contadores y enclavamientos son fáciles de dibujar y sorprendentemente fáciles de manejar mal. Los detalles del ciclo de escaneo son donde se corrige la confianza.

#### 3. Validar el estado seguro en la simulación

Use el entorno de simulación de OLLA Lab para confirmar que el estado del equipo sigue la lógica de bloqueo, no el comando hostil.

Para un ejemplo de bomba y válvula, verifique que:

• la salida del motor permanece desenergizada,
• la válvula no transiciona a una secuencia insegura,
• `Pump_Run_Permissive` cae,
• los comandos de marcha subsiguientes permanecen bloqueados hasta un reinicio supervisado.

Si hay una vista 3D o de gemelo digital disponible para el escenario seleccionado, compare el estado de la escalera contra el estado del equipo simulado directamente. Esa es la definición útil de validación de gemelo digital aquí: el equipo virtual debe obedecer visiblemente a la lógica de control defensiva bajo condiciones anormales.

Usted simula la pérdida de latidos deteniendo o congelando las actualizaciones del bit de latido, luego observando si el temporizador expira y el proceso transiciona al estado seguro previsto. Usted simula cambios de estado no autorizados forzando etiquetas de comando o estado a valores que deberían ser rechazados por el modelo de permisivos.

Procedimiento de prueba de pérdida de latidos

5. Verifique que:

• `Heartbeat_Timer.DN` se vuelve verdadero,
• `HMI_Heartbeat_Healthy` cae a falso,
• `System_Run_Permissive` cae,
• el equipo simulado transiciona al estado seguro definido.

1. Ejecute el escenario normalmente con un latido alternante saludable.
2. Confirme que `HMI_Heartbeat_Healthy` es verdadero y que `System_Run_Permissive` puede establecerse bajo condiciones de proceso válidas.
3. Congele `HMI_Heartbeat_Bit` en el Panel de Variables.
4. Observe el acumulador del `TON` hasta que expire el tiempo de espera.

Procedimiento de prueba de cambio de estado no autorizado

Fuerce un comando que debería ser imposible bajo las condiciones actuales del proceso. Por ejemplo:

• comandar marcha de bomba mientras la prueba de válvula de descarga es falsa,
• comandar avance de secuencia mientras un paso previo está incompleto,
• forzar un comando de solo mantenimiento mientras `System_Lockout_Alarm` está activo.

Comportamiento esperado:

• el bit de comando crudo puede cambiar,
• el permisivo debe permanecer falso,
• la salida no debe energizarse,
• y cualquier bit de alarma o diagnóstico debe indicar por qué se rechazó la acción.

Esa distinción vale la pena preservarla en la documentación: un cambio de estado no autorizado no es simplemente un valor de etiqueta cambiado; es un valor de etiqueta cambiado que no logra ganar la autoridad del proceso.

Los ingenieros deben documentar un cuerpo compacto de evidencia de ingeniería, no una galería de capturas de pantalla. El punto es mostrar razonamiento, disciplina de validación y revisión bajo condiciones de falla.

Use esta estructura:

Defina la unidad de proceso, el objetivo de control, los modos de operación y las acciones protegidas. Ejemplo: bomba centrífuga con prueba de válvula de descarga, comando de arranque emitido por HMI y ruta de bloqueo de mantenimiento.

Establezca el comportamiento esperado exacto. Ejemplo: la bomba puede funcionar solo cuando la prueba de válvula es verdadera, no hay bloqueo activo, el latido es saludable y no hay disparos; ante la pérdida de latido, el permisivo de marcha debe caer en 2 segundos.

Registre la prueba anormal: intentos de PIN por fuerza bruta, bit de latido congelado, comando de marcha forzado contra permisivos fallidos, retroalimentación de prueba contradictoria, etc.

Muestre qué cambió después del primer intento fallido o incompleto. Ejemplo: se agregó acondicionamiento de pulso único para evitar el conteo excesivo, alarma de bloqueo enclavada o separación del comando crudo del permisivo de marcha.

1. Descripción del sistema
2. Definición operativa de “correcto”
3. Lógica de escalera y estado del equipo simulado Incluya los peldaños relevantes, la lista de etiquetas y el comportamiento del equipo correspondiente en la simulación. La escalera y el modelo de máquina deben contar la misma historia.
4. El caso de falla inyectado
5. La revisión realizada
6. Lecciones aprendidas Establezca qué reveló la prueba sobre el comportamiento del escaneo, el diseño de permisivos, el manejo de fallas o la recuperación del operador.

Este es el tipo de evidencia que demuestra un pensamiento “listo para simulación”. Muestra que el ingeniero puede pasar del borrador de lógica a la validación y corrección. Los revisores generalmente encuentran eso más útil que una carpeta llena de capturas de pantalla.

OLLA Lab apoya el ensayo de ciberseguridad acotado dando a los ingenieros un entorno basado en web para construir lógica de escalera, ejecutar simulación, inspeccionar variables y el comportamiento de E/S, y comparar el estado de la lógica contra el comportamiento del equipo simulado bajo condiciones anormales.

Dentro del alcance de este artículo, eso incluye:

• construir lógica de bloqueo y permisivos en el editor de escalera basado en navegador,
• usar el Modo de Simulación para ejecutar y depurar el programa sin hardware físico,
• manipular etiquetas a través del Panel de Variables para emular entradas hostiles o inválidas,
• y, donde el escenario lo admita, usar vistas 3D o de gemelo digital para confirmar que el comportamiento del equipo sigue la lógica defensiva.

Ese es un caso de uso creíble porque estas son exactamente las tareas que son riesgosas, inconvenientes o costosas de ensayar en sistemas reales. También es donde el valor del entrenamiento se vuelve concreto: no “aprender ciberseguridad” en abstracto, sino ver el permisivo fallar cerrado cuando el latido muere y el comando aún insiste.

El límite es igualmente importante. OLLA Lab no certifica el cumplimiento de IEC 62443, no reemplaza el endurecimiento del proveedor ni valida una arquitectura de producción por sí solo. Es un entorno de pruebas con riesgos contenidos para ensayar el comportamiento defensivo a nivel de lógica antes de que ese comportamiento se confíe cerca de equipos reales.

Los principales errores de diseño suelen ser arquitectónicos, no sintácticos. Los ingenieros a menudo agregan una función de seguridad como un peldaño aislado y olvidan integrarla en la ruta de autoridad real.

Los errores comunes incluyen:

Un contador que nunca bloquea un permisivo es meramente decorativo.

• Contar intentos fallidos sin bloquear acciones protegidas

Las comprobaciones de seguridad deben estar en la cadena de autoridad, no en una rama lateral que ninguna salida consume realmente.

• Usar comandos crudos directamente en la lógica de salida

Si la supervisión desaparece y el proceso continúa por defecto, la lógica de latidos es teatro.

• Fallar abierto ante la pérdida de latidos

El reinicio automático o no supervisado derrota el propósito del bloqueo.

• Reiniciar el bloqueo demasiado fácilmente

Los pulsos de envío, los pulsos únicos y los incrementos de contador pueden comportarse mal si la detección de flancos es descuidada.

• Ignorar el comportamiento del ciclo de escaneo

Un usuario válido aún puede emitir un comando inválido para el estado actual del proceso.

• Tratar la autenticación de HMI como validación de proceso suficiente

“Seguro” debe significar algo observable: motor desenergizado, válvula cerrada, secuencia detenida, alarma enclavada, reinicio bloqueado hasta la recuperación supervisada.

• No definir el estado seguro explícitamente

La lógica de seguridad falla de maneras familiares. Sigue siendo lógica.

Proteger la lógica de PLC contra intrusiones bajo la norma IEC 62443 significa trasladar parte de la defensa al propio programa de control. Los comportamientos centrales son directos: autenticar cuando sea apropiado, contar y bloquear fallas repetidas, monitorear la integridad de la supervisión, rechazar comandos imposibles y forzar un estado seguro determinista cuando las condiciones de confianza colapsan.

El valor práctico de la simulación es que permite a los ingenieros probar esos comportamientos antes de que un proceso real proporcione la retroalimentación en un dialecto más costoso. Un flujo de trabajo “listo para simulación” no se trata de dibujar un peldaño más limpio. Se trata de probar que el peldaño sigue haciendo lo correcto cuando las suposiciones circundantes dejan de cooperar.

- Zero-Trust OT: Por qué la confianza implícita es ahora un pasivo en la planta - El programador de PLC que prioriza la ciberseguridad: Implementación de IEC 62443

• Regresar al Centro de Maestría en Lógica de Escalera (Ladder Logic Mastery Hub)
• Abrir el preajuste de seguridad y permisivos en OLLA Lab

- Arriba (Pillar Hub): Explorar la guía del pilar - A los lados: Artículo relacionado 1 - A los lados: Artículo relacionado 2 - Abajo (Comercial/CTA): Construya su próximo proyecto en OLLA Lab

- Descripción general de la serie IEC 62443 - Recursos del comité de estándares ISA/IEC 62443 - Avisos de CISA ICS - NIST SP 800-82 Rev. 3 Guía para la seguridad de tecnología operativa