Resumo Técnico: PLCBench

Definição do Problema

Sistemas de Controle Industrial (ICS) dependem de Controladores Lógicos Programáveis (PLCs) para fazer a ponte entre a computação em rede e o controle físico. Embora agentes de Grandes Modelos de Linguagem (LLMs) que utilizam ferramentas tenham demonstrado uma capacidade crescente em tarefas de cibersegurança digital (ex: testes de penetração, exploração de vulnerabilidades), sua capacidade de traduzir o alcance de rede em um impacto físico sustentado permanece não quantificada.

As avaliações existentes frequentemente param em marcos digitais intermediários, como encontrar um serviço aberto, alcançar uma escrita de software válida ou obter acesso a ferramentas. No contexto de ICS, esses marcos são indicadores insuficientes de risco físico. Uma escrita de PLC válida pode ser irrelevante para o loop de controle, ser sobrescrita pela lógica existente ou falhar em sustentar uma condição física perigosa. Há uma carência de um framework de avaliação abrangente de ponta a ponta que avalie se um agente autônomo consegue:

1. Interagir com PLCs reais heterogêneos via interfaces nativas de fornecedores.
2. Adaptar o comportamento com base no feedback de processo em malha fechada.
3. Alcançar um objetivo fisicamente realizado que seja independentemente verificado.

Metodologia: Framework PLCBench

Os autores apresentam o PLCBench, o primeiro framework de hardware no loop (HIL) com PLCs reais, projetado para caracterizar as capacidades cibernéticas-físicas e seus limites. O framework é modular, permitindo a recombinação de backends de LLM, PLCs comerciais e cargas de trabalho de processos sem alterar o loop de avaliação central.

Componentes Principais

1. Framework do Agente: Um loop de interação de longo horizonte baseado no paradigma ReAct (Reasoning and Acting).
   • Contrato de Prompt: Utiliza prompts de sistema e descrições de tarefas fixas que ocultam detalhes específicos do alvo (ex: mapas de objetos nativos, protocolos ativos).
   • Ferramentas Auditadas: Fornece shell, Python e bibliotecas de protocolos públicos. O agente deve configurar clientes e emitir requisições nativas sem wrappers pré-configurados.
   • Gestão de Contexto: Implementa a compactação determinística do histórico de interação para lidar com episódios longos sem perder a ordem temporal ou evidências críticas, preservando um transcript bruto completo para avaliação.
2. Plataforma HIL:
   • PLCs Reais: Quatro PLCs comerciais (Siemens S7-300, Schneider M241, Beckhoff CX2030, Mitsubishi R08CPU) executando protocolos nativos de fornecedores (S7comm, Modbus/TCP, ADS, MC/SLMP).
   • Cargas de Trabalho de Malha Fechada: Quatro simulações de processo distintas (ex: tanque quádruplo, mistura térmica) que fornecem feedback de sensores e controle de atuadores.
   • Isolamento: Os agentes operam em sandboxes isolados; a ponte HIL gerencia a troca de estado entre o servidor de processo e o PLC.
3. Avaliador Determinístico:
   • Opera fora do contexto do agente.
   • Analisa fontes de evidência independentes (logs do executor, capturas de pacotes, auditorias de objetos, traços de processo).
   • Atribui seis flags de diagnóstico ocultos para categorizar o progresso:
     • Aquisição de Interface de PLC: discover (serviço encontrado), read (dados válidos retornados), write (escrita aceita).
     • Progressão de Controle Físico: manipulate (escrita em objeto vinculado ao processo), disrupt (condição de aviso sustentada), impact (objetivo da tarefa plenamente sustentado).

Configuração Experimental

• Modelos: Cinco famílias de LLM (GPT 5.5, Sonnet 5, Gemini 3.5 Flash, DeepSeek V4 Pro, Kimi K2.7).
• Configuração: Um design cruzado de 4 PLCs × 4 Cargas de Trabalho × 5 Modelos × 3 Repetições = 240 episódios.
• Restrições: Orçamento de 100 ações, limite de 3600 segundos, sem ações de gerenciamento de controlador (ex: reboot) e sem modificação do programa do PLC.

Resultados Principais

Impacto Geral

• Taxa de Sucesso: Ao longo de 240 episódios, 75 (31,3%) alcançaram impacto físico sustentado.
• Desempenho do Modelo: O GPT 5.5 foi o mais capaz, atingindo impacto em 38 de 48 episódios (79,2%) e obtendo sucesso em todas as 16 configurações de PLC-carga de trabalho. Outros modelos mostraram taxas de sucesso e cobertura significativamente menores.
• Repetibilidade: Embora o GPT 5.5 tenha tido sucesso em todas as 16 células, ele só alcançou o sucesso em todas as três repetições em 9 dessas células, indicando que o sucesso não é uniformemente repetível mesmo para o modelo mais forte.

Análise de Barreiras

A avaliação identificou duas barreiras distintas onde os agentes falham frequentemente:

1. Barreira I: Aquisição de Interface Nativa (98 episódios pararam aqui)

   • Os agentes tiveram dificuldade em transitar da conectividade de rede para uma interface nativa de fornecedor utilizável.
   • Complexidade de Protocolo: Ocorreram quedas significativas com protocolos menos comuns. Por exemplo, nos PLCs Beckhoff (ADS) e Mitsubishi (MC/SLMP), muitos agentes conseguiram descobrir o serviço, mas falharam em obter uma leitura válida.
   • Descoberta: A aquisição de interface é altamente dependente da familiaridade com o protocolo e da configuração do cliente, agindo como um ponto de fricção em vez de uma barreira de segurança rígida.

2. Barreira II: Conversão Física (62 episódios pararam aqui)

   • Os agentes escreveram com sucesso em objetos vinculados ao processo (manipulate), mas falharam em sustentar o estado perigoso (impact).
   • Dinâmica de Processo: As falhas foram frequentemente causadas pela complexidade do controle em malha fechada e da lógica de proteção. Por exemplo, no cenário do tanque quádruplo, os agentes não conseguiram manter as restrições de nível do tanque contra dinâmicas acopladas.
   • Observabilidade: Fornecer observações de processo mais ricas (variáveis intermediárias, estado do loop de controle) aumentou a obtenção condicional de impacto após uma escrita bem-sucedida de 44,2% para 64,0%, sugerindo que a observabilidade limitada é um gargalo significativo.

Estudos de Ablação

• Protocolo Compartilhado: Quando todas as cargas de trabalho foram expostas via um único caminho Modbus/TCP compartilhado (removendo a heterogeneidade de protocolo), a obtenção de manipulação subiu para 100% (vs. 57,1% em caminhos nativos heterogêneos), e o impacto bruto subiu para 50%.
• Profundidade de Observação: Condições de observação mais ricas não melhoraram a aquisição de interface, mas melhoraram significativamente a conversão de escritas em impacto físico sustentado.

Significância e Alegações

O artigo afirma fornecer a primeira avaliação HIL com PLC real de agentes de LLM autônomos em um contexto de ciber-para-físico. Sua significância reside em:

1. Mudança no Modelo de Ameaça: Demonstra que o conhecimento específico do alvo de Tecnologia Operacional (OT) (ex: especificidades de protocolo, mapas de objetos) não é mais um pré-requisito estrito para o sucesso do ataque. Agentes capazes podem reconstruir esse conhecimento online através da interação, desde que possuam acesso à rede e feedback limitado.
2. Identificação de Barreiras Reais: O estudo localiza os pontos de falha. Argumenta que a complexidade do protocolo e a falta de conhecimento específico do alvo atuam como "fricção erosiva" em vez de barreiras de segurança duráveis. Uma vez que o agente supera a barreira da interface, a barreira de conversão física torna-se a principal restrição, fortemente influenciada pelas dinâmicas do processo e pela observabilidade.
3. Avaliação de Defesa: O framework oferece uma base reproduzível para avaliar estratégias defensivas. Sugere que as defesas devem focar em:
   • Restringir o acesso a serviços de engenharia.
   • Validar escritas que afetam o processo (invariantes conscientes de estado).
   • Guardar regiões perigosas em vez de apenas limiares extremos.
   • Desacoplar dados de monitoramento detalhados das permissões de escrita para evitar que a telemetria de "duplo uso" auxilie ataques.

Os autores enfatizam que o PLCBench não descobre novas vulnerabilidades de fornecedores, mas sim caracteriza a capacidade de agentes autônomos de explorar interfaces conhecidas e existentes para alcançar resultados físicos. Os resultados destacam que, embora os agentes atuais não sejam universalmente confiáveis, eles são capazes de executar ataques físicos sustentados em ambientes laboratoriais validados, necessitando de uma mudança na forma como a segurança de ICS é avaliada e defendida.