Como proteger a lógica de CLP contra intrusão usando a norma IEC 62443 no OLLA Lab

Para proteger a lógica de CLP contra intrusão sob a norma IEC 62443-4-2, os engenheiros devem implementar controle de acesso em nível de componente, verificações de integridade de comunicação e comportamento determinístico de estado seguro dentro da própria lógica de controle. O OLLA Lab fornece um ambiente de simulação delimitado para ensaiar bloqueios (lockouts), detecção de perda de heartbeat e validação de resposta a intrusões antes que esses comportamentos sejam confiados a equipamentos reais.

A segurança de perímetro é necessária, mas não é a última linha de defesa. Se um agente de ameaça alcançar a rede de controle, o CLP deixa de apenas executar a lógica de processo; ele passa a decidir se comandos inseguros se tornarão movimento físico.

A IEC 62443-4-2 é importante aqui porque transfere parte da carga de segurança para o próprio componente. Isso inclui identificação, força da autenticação, integridade da comunicação e acesso a eventos relevantes para auditoria no nível do dispositivo, não apenas no firewall. Na prática, isso significa que a lógica ladder deve rejeitar mudanças de estado impossíveis ou não autorizadas, detectar a perda de supervisão confiável e forçar o processo a uma condição segura definida.

Métrica Ampergon Vallis: Em 24 simulações de "red-team" no OLLA Lab de mudanças de estado forçadas e não autorizadas contra um modelo de permissivas de bomba e válvula, 24 de 24 tentativas foram interceptadas por um intertravamento de perda de heartbeat somado a permissivas de operação explícitas antes que o motor simulado entrasse em estado de operação comandada [Metodologia: n=24 testes de intrusão simulados em um cenário de treinamento de permissivas de segurança, comparador de base = mesmo cenário sem intertravamento de perda de heartbeat e lógica de bloqueio, observado em março de 2026]. Isso sustenta o valor de controles de fallback em nível lógico nesse cenário. Não estabelece uma redução geral da taxa de violação em todas as plataformas, arquiteturas ou plantas de CLP. Um simulador é útil para evidências, não para mitologia.

A segurança em nível lógico é necessária porque a IEC 62443 não trata o CLP como um endpoint passivo. A IEC 62443-4-2 define requisitos de segurança de componentes para dispositivos embarcados e hosts, incluindo controles relacionados à identificação e autenticação, integridade da comunicação e comportamento relevante para auditoria.

A mudança prática é simples: um CLP não deve presumir que todo comando que chega de um caminho de rede confiável é legítimo. Essa suposição sempre foi otimista. Agora, ela é apenas menos defensável.

Requisitos relevantes comumente citados neste contexto incluem:

- CR 1.1 — Identificação e autenticação de usuário humano: o componente deve suportar a identificação e autenticação de usuários humanos. - CR 1.7 — Força da autenticação baseada em senha: os mecanismos de senha devem atender às expectativas mínimas de força. - CR 3.1 — Integridade da comunicação: o componente deve proteger a integridade das comunicações ou detectar falhas de integridade. - CR 6.1 — Acessibilidade do log de auditoria: eventos relevantes para a segurança devem estar disponíveis para revisão e investigação.

Esses requisitos não significam que toda função de segurança seja implementada diretamente na lógica ladder. Algumas pertencem ao firmware, à configuração do controlador, ao design da IHM ou à arquitetura circundante. O ponto de engenharia é mais restrito e mais útil: onde a segurança do processo ou a proteção do equipamento depende da validade do comando, o programa de controle deve impor permissivas determinísticas e comportamento de estado anormal mesmo após a falha da confiança upstream.

Um equívoco comum é que a cibersegurança e a lógica de controle são disciplinas separadas. Elas não são separadas quando um comando malicioso pode ligar um motor contra uma válvula fechada, derrotar uma sequência ou manter uma saída em um estado que o processo nunca deveria tolerar. Nesse ponto, um problema de rede pode se tornar um dano mecânico rapidamente.

Os avisos da CISA sobre produtos industriais revelam repetidamente fraquezas como controle de acesso inadequado (CWE-284) e transmissão de informações confidenciais em texto simples (CWE-319) em ambientes legados. Esses avisos não implicam que a lógica ladder sozinha resolva o problema. Eles reforçam uma verdade mais dura: se as credenciais, sessões ou caminhos de comando forem fracos, o programa do controlador deve ser escrito para desconfiar de transições de estado inseguras.

"Pronto para Simulação" (Simulation-Ready) deve ser definido como a capacidade de provar, observar, diagnosticar e endurecer a lógica de controle contra comportamentos de processo realistas antes da implantação em um processo real. Não é um sinônimo para "saber escrever sintaxe ladder".

Operacionalmente, um engenheiro "Pronto para Simulação" pode:

• definir o que o processo tem permissão para fazer,
• codificar esses limites como permissivas, trips e bloqueios,
• injetar condições anormais,
• observar o comportamento das tags e a resposta do equipamento,
• revisar a lógica após a falha,
• e documentar por que o comportamento revisado é mais correto.

Essa distinção é importante porque sintaxe versus capacidade de implantação é onde muitos ambientes de treinamento param cedo demais. Um degrau (rung) que compila ainda não é uma estratégia de controle. Um degrau que sobrevive a entradas ruins, perda de supervisão e estados de campo contraditórios está mais próximo.

Neste artigo, o OLLA Lab é posicionado dentro desse papel delimitado. É um ambiente de simulação e lógica ladder baseado na web onde engenheiros podem ensaiar tarefas de validação de alto risco com segurança: monitorar E/S, forçar valores anormais, rastrear causa e efeito, comparar o estado da ladder com o estado do equipamento simulado e revisar a lógica após uma falha. Não é um substituto para aceitação em campo, conformidade formal ou competência demonstrada em uma planta real.

A proteção por senha na lógica ladder deve ser tratada como um mecanismo de controle de acesso delimitado, não como uma plataforma de identidade completa. O padrão útil é verificar um valor inserido na IHM, contar tentativas falhas e travar um estado de bloqueio que bloqueia comandos privilegiados até que uma condição de reset supervisionada seja atendida.

Uma implementação compacta pode ser construída a partir de instruções padrão:

• `EQU` para comparar valores inseridos e armazenados
• `CTU` para contar tentativas falhas
• bobina travada / bit de memória para manter o estado de bloqueio
• contatos de permissiva para bloquear ações protegidas
• condição de reset supervisionada para limpar o bloqueio

Padrão de lógica central

Objetivo: Permitir uma ação administrativa ou de manutenção apenas quando o PIN inserido corresponder ao valor armazenado e o sistema não estiver em bloqueio.

Tags sugeridas:

- `HMI_PIN_Entry` : inteiro inserido pela IHM - `Stored_Admin_PIN` : constante inteira ou valor protegido - `PIN_Submit_Pulse` : pulso único (one-shot) da ação de envio da IHM - `PIN_Match` : bit interno - `Failed_Attempt_CTU` : contador - `System_Lockout_Alarm` : bit travado (latch) - `Admin_Access_Granted` : bit interno - `Lockout_Reset_Request` : comando de reset supervisionado

Exemplo de fluxo de lógica ladder

Degrau 1: Avaliar PIN enviado | PIN_Submit_Pulse |----[EQU HMI_PIN_Entry Stored_Admin_PIN]----( PIN_Match )

Degrau 2: Contar tentativas falhas | PIN_Submit_Pulse |----[/PIN_Match]----------------------------[CTU Failed_Attempt_CTU PRE 3]

Degrau 3: Travar bloqueio quando tentativas falhas atingirem o limite | Failed_Attempt_CTU.ACC >= 3 |---------------------------------(L) System_Lockout_Alarm

Degrau 4: Conceder acesso apenas se a correspondência for verdadeira e não houver bloqueio | PIN_Submit_Pulse |----[PIN_Match]----[/System_Lockout_Alarm]--( Admin_Access_Granted )

Degrau 5: Resetar bloqueio apenas sob condições supervisionadas | Lockout_Reset_Request |----[Supervisor_Mode]------------------(U) System_Lockout_Alarm | Lockout_Reset_Request |----[Supervisor_Mode]------------------[RES Failed_Attempt_CTU]

O objetivo de engenharia não é uma gestão de credenciais elegante. É o controle determinístico sobre ações privilegiadas. Se a IHM estiver sofrendo um ataque de força bruta, o CLP deve parar de aceitar tentativas após um limite definido e exigir um caminho de recuperação supervisionado explícito.

O que esta lógica faz bem

• bloqueia tentativas repetidas de tentativa e erro,
• cria um estado de bloqueio visível,
• impede que comandos protegidos sejam executados após falhas repetidas,
• fornece um evento claro para revisão do operador ou manutenção.

O que esta lógica não faz

• não substitui a gestão segura de usuários na IHM ou na plataforma do controlador,
• não criptografa credenciais,
• não satisfaz todos os requisitos de autenticação da IEC 62443 por si só,
• não prova que a arquitetura circundante é segura.

Essa fronteira é importante. Um contador não é um sistema de identidade.

As permissivas de acesso devem ser estruturadas em torno da validade do processo primeiro, privilégio do usuário segundo. Um comando de usuário válido ainda deve falhar se o estado do processo tornar o comando inseguro.

Por exemplo, um comando de partida de bomba não deve energizar a saída de operação apenas porque um usuário autenticado da IHM o solicitou. O degrau também deve exigir:

• caminho de descarga disponível,
• condição de sucção ou nível aceitável,
• nenhum bloqueio ativo,
• nenhum trip ativo,
• heartbeat saudável,
• estado de modo e sequência válido,
• feedbacks de prova consistentes com o estado esperado de pré-partida.

Um modelo de permissiva compacto parece com isto:

| 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 )

Então, o degrau de saída deve consumir `Pump_Run_Permissive`, não o comando bruto.

Essa separação é importante. A intenção do comando não é a autoridade do comando. Na lógica de controle segura, o comando pede; a permissiva decide.

Um monitor de heartbeat é um padrão lógico que confirma a comunicação contínua de uma fonte supervisória confiável, exigindo uma transição de bit periódica dentro de uma janela de tempo definida. Se o bit parar de mudar, o CLP trata isso como perda de supervisão e remove a autoridade de operação ou leva o processo a um estado seguro.

Esta é uma maneira prática de apoiar a intenção por trás dos requisitos de integridade de comunicação. Não prova que o remetente é benevolente, mas detecta um modo de falha comum: a sessão esperada da IHM ou supervisória desapareceu, travou ou foi substituída.

Por que a lógica de heartbeat é importante

Se espera-se que uma IHM legítima alterne um bit a cada segundo e esse bit para de mudar, várias possibilidades existem:

• a IHM falhou,
• as comunicações foram interrompidas,
• a sessão supervisória congelou,
• um dispositivo invasor substituiu ou contornou o caminho esperado,
• ou o processo não está mais sob as suposições de controle que o CLP foi projetado para confiar.

O controlador deve reagir a essa perda de forma determinística. Esperar educadamente raramente é uma estratégia de controle.

Exemplo de design de heartbeat usando `TON`

Tags sugeridas:

- `HMI_Heartbeat_Bit` : alternado pela IHM - `Last_Heartbeat_State` : estado anterior armazenado - `Heartbeat_Change_Pulse` : pulso único quando o estado muda - `Heartbeat_Timer` : `TON` - `HMI_Heartbeat_Healthy` : bit interno - `System_Run_Permissive` : bit interno usado em outros lugares

Conceito de lógica

Degrau 1: Detectar mudança de heartbeat | HMI_Heartbeat_Bit XOR Last_Heartbeat_State |------------------( Heartbeat_Change_Pulse )

Degrau 2: Atualizar estado armazenado na mudança | Heartbeat_Change_Pulse |--------------------------------------( Last_Heartbeat_State := HMI_Heartbeat_Bit )

Degrau 3: Resetar temporizador quando o heartbeat muda; expirar se nenhuma mudança ocorrer | /Heartbeat_Change_Pulse |-------------------------------------[TON Heartbeat_Timer PRE 2000ms]

Degrau 4: Declarar heartbeat saudável apenas quando o temporizador não estiver concluído | /Heartbeat_Timer.DN |-----------------------------------------( HMI_Heartbeat_Healthy )

Degrau 5: Remover permissiva de operação na perda de heartbeat | Existing_Process_Permissives |----[HMI_Heartbeat_Healthy]-----( System_Run_Permissive )

A implementação exata varia de acordo com a família de CLP e o conjunto de instruções. O princípio não: se a fonte supervisória confiável parar de se comportar como a fonte supervisória confiável, o CLP deve degradar com segurança.

Escolhendo a janela de tempo limite (timeout)

O timeout deve ser baseado em:

• taxa de atualização esperada da IHM,
• determinismo da rede,
• criticidade do processo,
• tolerância a trips incômodos,
• e as consequências de estado seguro de um falso positivo.

Um timeout de 500 ms pode ser apropriado em alguns contextos supervisórios rápidos. Um timeout de 2000 ms pode ser mais estável em outros. O número correto é aquele justificado pelo processo e testado sob comportamento realista de scan e comunicações, não aquele que parece severo em um diagrama.

Você pode simular um ataque de força bruta no OLLA Lab forçando valores de credenciais inválidos repetidamente através do Painel de Variáveis, observando o contador e os bits de bloqueio na simulação, e confirmando que o gêmeo digital ou equipamento simulado permanece em um estado seguro apesar das solicitações de operação contínuas.

É aqui que o OLLA Lab se torna operacionalmente útil. Praticar isso em um processo real seria uma maneira ruim de preservar o tempo de atividade.

3 passos para testar a lógica defensiva

#### 1. Injetar dados anômalos

Use o Painel de Variáveis para manipular:

• `HMI_PIN_Entry`
• `PIN_Submit_Pulse`
• quaisquer bits de comando relacionados, como `Start_Command`

Insira valores inteiros incorretos repetidamente e pulse o bit de envio como se uma sessão de IHM estivesse sendo alvo de força bruta.

O que observar:

• se `PIN_Match` permanece falso,
• se o `Failed_Attempt_CTU.ACC` incrementa uma vez por tentativa,
• se os pulsos únicos (one-shots) se comportam corretamente e não contam excessivamente devido ao comportamento do scan.

#### 2. Verificar a execução do bloqueio

Continue com envios inválidos até que o contador atinja seu limite.

Resultado esperado:

• `Failed_Attempt_CTU.ACC` atinge `3`,
• `System_Lockout_Alarm` energiza e trava,
• `Admin_Access_Granted` permanece falso,
• comandos protegidos não criam mais permissivas downstream.

Essa validação é importante porque contadores e travas são fáceis de desenhar e surpreendentemente fáceis de manipular incorretamente. Detalhes do ciclo de scan são onde a confiança é corrigida.

#### 3. Validar o estado seguro na simulação

Use o ambiente de simulação do OLLA Lab para confirmar que o estado do equipamento segue a lógica de bloqueio, não o comando hostil.

Para um exemplo de bomba e válvula, verifique se:

• a saída do motor permanece desenergizada,
• a válvula não transita para uma sequência insegura,
• `Pump_Run_Permissive` cai,
• comandos de operação subsequentes permanecem bloqueados até o reset supervisionado.

Se uma visualização 3D ou de gêmeo digital estiver disponível para o cenário selecionado, compare o estado da ladder com o estado do equipamento simulado diretamente. Essa é a definição útil de validação de gêmeo digital aqui: o equipamento virtual deve obedecer visivelmente à lógica de controle defensiva sob condições anormais.

Você simula a perda de heartbeat parando ou congelando as atualizações do bit de heartbeat, observando então se o temporizador expira e o processo transita para o estado seguro pretendido. Você simula mudanças de estado não autorizadas forçando tags de comando ou status para valores que deveriam ser rejeitados pelo modelo de permissivas.

Procedimento de teste de perda de heartbeat

5. Verifique se:

• `Heartbeat_Timer.DN` torna-se verdadeiro,
• `HMI_Heartbeat_Healthy` cai para falso,
• `System_Run_Permissive` cai,
• o equipamento simulado transita para o estado seguro definido.

1. Execute o cenário normalmente com um heartbeat alternante saudável.
2. Confirme se `HMI_Heartbeat_Healthy` é verdadeiro e `System_Run_Permissive` pode ser estabelecido sob condições de processo válidas.
3. Congele `HMI_Heartbeat_Bit` no Painel de Variáveis.
4. Observe o acumulador do `TON` até que o timeout expire.

Procedimento de teste de mudança de estado não autorizada

Force um comando que deveria ser impossível sob as condições atuais do processo. Por exemplo:

• comandar a operação da bomba enquanto a prova da válvula de descarga é falsa,
• comandar o avanço da sequência enquanto um passo anterior está incompleto,
• forçar um comando exclusivo de manutenção enquanto `System_Lockout_Alarm` está ativo.

Comportamento esperado:

• o bit de comando bruto pode mudar,
• a permissiva deve permanecer falsa,
• a saída não deve energizar,
• e qualquer bit de alarme ou diagnóstico deve indicar por que a ação foi rejeitada.

Essa distinção vale a pena preservar na documentação: uma mudança de estado não autorizada não é apenas um valor de tag alterado; é um valor de tag alterado que falha em ganhar autoridade de processo.

Os engenheiros devem documentar um corpo compacto de evidências de engenharia, não uma galeria de capturas de tela. O objetivo é mostrar raciocínio, disciplina de validação e revisão sob condições de falha.

Use esta estrutura:

Defina a unidade de processo, objetivo de controle, modos de operação e ações protegidas. Exemplo: bomba centrífuga com prova de válvula de descarga, comando de partida emitido pela IHM e caminho de bloqueio de manutenção.

Declare o comportamento esperado exato. Exemplo: a bomba pode operar apenas quando a prova da válvula for verdadeira, nenhum bloqueio estiver ativo, o heartbeat estiver saudável e nenhum trip existir; na perda de heartbeat, a permissiva de operação deve cair em 2 segundos.

Registre o teste anormal: tentativas de PIN por força bruta, bit de heartbeat congelado, comando de operação forçado contra permissivas falhas, feedback de prova contraditório, e assim por diante.

Mostre o que mudou após a primeira tentativa falha ou incompleta. Exemplo: adição de condicionamento de pulso único para evitar contagem excessiva, alarme de bloqueio travado ou separação do comando bruto da permissiva de operação.

1. Descrição do Sistema
2. Definição operacional de "correto"
3. Lógica ladder e estado do equipamento simulado Inclua os degraus relevantes, lista de tags e o comportamento do equipamento correspondente na simulação. A ladder e o modelo da máquina devem contar a mesma história.
4. O caso de falha injetada
5. A revisão feita
6. Lições aprendidas Declare o que o teste revelou sobre o comportamento do scan, design de permissivas, tratamento de falhas ou recuperação do operador.

Este é o tipo de evidência que demonstra o pensamento "Pronto para Simulação". Mostra que o engenheiro pode passar do rascunho da lógica para a validação e correção. Os revisores geralmente acham isso mais útil do que uma pasta cheia de capturas de tela.

O OLLA Lab apoia o ensaio de cibersegurança delimitado dando aos engenheiros um ambiente baseado na web para construir lógica ladder, executar simulação, inspecionar variáveis e comportamento de E/S, e comparar o estado da lógica com o comportamento do equipamento simulado sob condições anormais.

Dentro do escopo deste artigo, isso inclui:

• construir lógica de bloqueio e permissivas no editor ladder baseado em navegador,
• usar o Modo de Simulação para executar e depurar o programa sem hardware físico,
• manipular tags através do Painel de Variáveis para emular entradas hostis ou inválidas,
• e, onde o cenário suporta, usar visualizações 3D ou de gêmeo digital para confirmar que o comportamento do equipamento segue a lógica defensiva.

Esse é um caso de uso credível porque essas são exatamente as tarefas que são arriscadas, inconvenientes ou caras para ensaiar em sistemas reais. É também onde o valor do treinamento se torna concreto: não "aprender cibersegurança" no abstrato, mas observar a permissiva falhar fechada quando o heartbeat morre e o comando ainda insiste.

A fronteira é igualmente importante. O OLLA Lab não certifica a conformidade com a IEC 62443, não substitui o endurecimento do fornecedor nem valida uma arquitetura de produção por si só. É um sandbox de risco contido para ensaiar o comportamento defensivo em nível lógico antes que esse comportamento seja confiado perto de equipamentos reais.

Os principais erros de design geralmente são arquitetônicos, não sintáticos. Os engenheiros frequentemente adicionam um recurso de segurança como um degrau isolado e esquecem de integrá-lo ao caminho de autoridade real.

Erros comuns incluem:

Um contador que nunca bloqueia uma permissiva é meramente decorativo.

• Contar tentativas falhas sem bloquear ações protegidas

Verificações de segurança devem estar na cadeia de autoridade, não em um ramo lateral que nenhuma saída realmente consome.

• Usar comandos brutos diretamente na lógica de saída

Se a supervisão desaparece e o processo continua por padrão, a lógica de heartbeat é teatro.

• Falhar aberto na perda de heartbeat

O reset automático ou não supervisionado derrota o propósito do bloqueio.

• Resetar o bloqueio muito facilmente

Pulsos de envio, pulsos únicos e incrementos de contador podem se comportar mal se a detecção de borda for descuidada.

• Ignorar o comportamento do ciclo de scan

Um usuário válido ainda pode emitir um comando inválido para o estado atual do processo.

• Tratar a autenticação da IHM como validação de processo suficiente

"Seguro" deve significar algo observável: motor desenergizado, válvula fechada, sequência interrompida, alarme travado, reinicialização bloqueada até a recuperação supervisionada.

• Não definir o estado seguro explicitamente

A lógica de segurança falha de maneiras familiares. Ainda é lógica.

Proteger a lógica de CLP contra intrusão sob a norma IEC 62443 significa mover parte da defesa para o próprio programa de controle. Os comportamentos centrais são diretos: autenticar onde apropriado, contar e bloquear falhas repetidas, monitorar a integridade da supervisão, rejeitar comandos impossíveis e forçar um estado seguro determinístico quando as condições de confiança colapsam.

O valor prático da simulação é que ela permite que os engenheiros testem esses comportamentos antes que um processo real forneça o feedback em um dialeto mais caro. Um fluxo de trabalho "Pronto para Simulação" não é sobre desenhar um degrau mais limpo. É sobre provar que o degrau ainda faz a coisa certa quando as suposições circundantes param de cooperar.

- Zero-Trust OT: Por que a Confiança Implícita é agora um Passivo no Chão de Fábrica - O Programador de CLP com Foco em Cibersegurança: Implementação da IEC 62443

• Retornar ao Hub de Maestria em Lógica Ladder
• Abrir o Preset de Segurança e Permissivas no OLLA Lab

- Acima (Hub de Pilar): Explorar orientação do Pilar - Ao lado: Artigo relacionado 1 - Ao lado: Artigo relacionado 2 - Abaixo (Comercial/CTA): Construa seu próximo projeto no OLLA Lab

- Visão geral da série IEC 62443 - Recursos do comitê de normas ISA/IEC 62443 - Avisos ICS da CISA - NIST SP 800-82 Rev. 3 Guia para Segurança de Tecnologia Operacional