Resumen Técnico: PLCBench

Planteamiento del Problema

Los Sistemas de Control Industrial (ICS) dependen de los Controladores Lógicos Programables (PLC) para servir de puente entre la computación en red y el control físico. Aunque los agentes de modelos de lenguaje extensos (LLM) con capacidad de uso de herramientas han demostrado una creciente competencia en tareas de ciberseguridad digital (por ejemplo, pruebas de penetración, explotación de vulnerabilidades), su capacidad para traducir la alcanzabilidad de red en un impacto físico sostenido permanece sin cuantificar.

Las evaluaciones existentes suelen detenerse en hitos digitales intermedios, como encontrar un servicio abierto, lograr una escritura de software válida o ganar acceso a herramientas. En el contexto de los ICS, estos hitos son indicadores insuficientes de riesgo físico. Una escritura válida en un PLC puede ser irrelevante para el bucle de control, ser sobrescrita por la lógica existente o fallar en mantener una condición física peligrosa. Existe una falta de un marco de evaluación integral y de extremo a extremo que evalúe si un agente autónomo puede:

1. Interactuar con PLCs reales heterogéneos a través de interfaces nativas del fabricante.
2. Adaptar su comportamiento basándose en la retroalimentación de procesos de bucle cerrado.
3. Lograr un objetivo físicamente realizado que sea verificado de forma independiente.

Metodología: Marco de Trabajo PLCBench

Los autores presentan PLCBench, el primer marco de trabajo de hardware en el lazo (HIL) con PLCs reales diseñado para caracterizar las capacidades ciber-físicas y sus límites. El marco es modular, lo que permite la recombinación de backends de LLM, PLCs comerciales y cargas de trabajo de procesos sin alterar el bucle de evaluación central.

Componentes Principales

1. Marco del Agente: Un bucle de interacción de largo horizonte basado en el paradigma ReAct (Razonamiento y Actuación).
   • Contrato de Prompt: Utiliza prompts de sistema y descripciones de tareas fijas que ocultan detalles específicos del objetivo (por ejemplo, mapas de objetos nativos, protocolos activos).
   • Herramientas Auditadas: Proporciona shell, librerías de Python y de protocolos públicos. El agente debe configurar clientes y emitir peticiones nativas sin wrappers preconfigurados.
   • Gestión de Contexto: Implementa una compactación determinista del historial de interacción para manejar episodios largos sin perder el orden temporal o evidencia crítica, preservando una transcripción completa y bruta para la evaluación.
2. Plataforma HIL:
   • PLCs Reales: Cuatro PLCs comerciales (Siemens S7-300, Schneider M241, Beckhoff CX2030, Mitsubishi R08CPU) ejecutando protocolos nativos del fabricante (S7comm, Modbus/TCP, ADS, MC/SLMP).
   • Cargas de Trabajo de Bucle Cerrado: Cuatro simulaciones de procesos distintas (por ejemplo, cuádruple tanque, mezcla térmica) que proporcionan retroalimentación de sensores y control de actuadores.
   • Aislamiento: Los agentes operan en sandboxes aislados; el puente HIL gestiona el intercambio de estado entre el servidor de proceso y el PLC.
3. Evaluador Determinista:
   • Opera fuera del contexto del agente.
   • Analiza fuentes de evidencia independientes (logs del ejecutor, capturas de paquetes, auditorías de objetos, trazas de proceso).
   • Asigna seis flags diagnósticos ocultos para categorizar el progreso:
     • Adquisición de Interfaz de PLC: discover (servicio encontrado), read (datos válidos devueltos), write (escritura aceptada).
     • Progresión de Control Físico: manipulate (escritura en objeto vinculado al proceso), disrupt (condición de advertencia sostenida), impact (objetivo de la tarea plenamente sostenido).

Configuración Experimental

• Modelos: Cinco familias de LLM (GPT 5.5, Sonnet 5, Gemini 3.5 Flash, DeepSeek V4 Pro, Kimi K2.7).
• Configuración: Un diseño cruzado de 4 PLCs × 4 Cargas de Trabajo × 5 Modelos × 3 Repeticiones = 240 episodios.
• Restricciones: Presupuesto de 100 acciones, límite de tiempo de 3600 segundos, sin acciones de gestión del controlador (ej. reinicio) y sin modificación del programa del PLC.

Resultados Clave

Impacto General

• Tasa de Éxito: A través de 240 episodios, 75 (31.3%) lograron un impacto físico sostenido.
• Rendimiento de los Modelos: GPT 5.5 fue el más capaz, alcanzando el impacto en 38 de 48 episodios (79.2%) y teniendo éxito en todas las 16 configuraciones de PLC-carga de trabajo. Otros modelos mostraron tasas de éxito y cobertura significativamente menores.
• Repetibilidad: Aunque GPT 5.5 tuvo éxito en las 16 celdas, solo logró el éxito en las tres repeticiones en 9 de esas celdas, lo que indica que el éxito no es uniformemente repetible incluso para el modelo más fuerte.

Análisis de Barreras

La evaluación identificó dos barreras distintas donde los agentes fallan frecuentemente:

1. Barrera I: Adquisición de la Interfaz Nativa (98 episodios se detuvieron aquí)

   • Los agentes tuvieron dificultades para transicionar de la alcanzabilidad de red a una interfaz nativa del fabricante utilizable.
   • Complejidad del Protocolo: Se produjeron caídas significativas con protocolos menos comunes. Por ejemplo, en los PLCs Beckhoff (ADS) y Mitsubishi (MC/SLMP), muchos agentes pudieron descubrir el servicio pero fallaron al obtener una lectura válida.
   • Hallazgo: La adquisición de la interfaz depende altamente de la familiaridad con el protocolo y la configuración del cliente, actuando como un punto de fricción en lugar de un límite de seguridad estricto.

2. Barrera II: Conversión Física (62 episodios se detuvieron aquí)

   • Los agentes escribieron con éxito en objetos vinculados al proceso (manipulate) pero no lograron sostener el estado peligroso (impact).
   • Dinámicas de Proceso: Los fallos se debieron a menudo a la complejidad del control de bucle cerrado y la lógica de protección. Por ejemplo, en el escenario del cuádruple tanque, los agentes no pudieron mantener las restricciones de nivel de tanque específicas frente a dinámicas acopladas.
   • Observabilidad: Proporcionar observaciones de proceso más ricas (variables intermedias, estado del bucle de control) aumentó la obtención condicional de impacto tras una escritura exitosa del 44.2% al 64.0%, lo que sugiere que la observabilidad limitada es un cuello de botella significativo.

Estudios de Ablación

• Protocolo Compartido: Cuando todas las cargas de trabajo se expusieron mediante una única vía compartida Modbus/TCP (eliminando la heterogeneidad de protocolos), la obtención de manipulación subió al 100% (frente al 57.1% en rutas nativas heterogéneas), y el impacto bruto subió al 50%.
• Profundidad de Observación: Las condiciones de observación más ricas no mejoraron la adquisición de la interfaz, pero mejoraron significativamente la conversión de las escrituras en un impacto físico sostenido.

Significancia y Reivindicaciones

El artículo afirma proporcionar la primera evaluación sistemática de HIL con un PLC real de agentes de LLM autónomos en un contexto ciber-físico. Su significancia radica en:

1. Cambio del Modelo de Amenaza: Demuestra que el conocimiento específico del objetivo de Tecnología Operativa (OT) (ej. especificidades del protocolo, mapas de objetos) ya no es un prerrequisito estricto para el éxito del ataque. Los agentes capaces pueden reconstruir este conocimiento en línea mediante la interacción, siempre que tengan acceso a la red y retroalimentación limitada.
2. Identificación de Barreras Reales: El estudio localiza los puntos de fallo. Argumenta que la complejidad del protocolo y la falta de conocimiento específico del objetivo actúan como "fricción erosiva" en lugar de límites de seguridad duraderos. Una vez que un agente supera la barrera de la interfaz, la barrera de conversión física se convierte en la restricción principal, fuertemente influenciada por las dinámicas del proceso y la observabilidad.
3. Evaluación de la Defensa: El marco ofrece una base reproducible para evaluar estrategias defensivas. Sugiere que las defensas deben centrarse en:
   • Restringir el acceso a los servicios de ingeniería.
   • Validar las escrituras que afectan al proceso (invariantes conscientes del estado).
   • Custodiar regiones peligrosas en lugar de solo umbrales extremos.
   • Desacoplar los datos de monitoreo detallados de los permisos de escritura para evitar que la telemetría de "doble uso" ayude a los ataques.

Los autores enfatizan que PLCBench no descubre nuevas vulnerabilidades de los fabricantes, sino que caracteriza la capacidad de los agentes autónomos para explotar interfaces conocidas y existentes para lograr resultados físicos. Los resultados resaltan que, aunque los agentes actuales no son universalmente fiables, son capaces de ejecutar ataques físicos sostenidos en entornos de laboratorio validados, lo que requiere un cambio en la forma en que se evalúa y defiende la seguridad de los ICS.