Riepilogo Tecnico: PLCBench

Definizione del Problema

I sistemi di controllo industriale (ICS) si affidano ai Programmabili Logici Programmabili (PLC) per colmare il divario tra l'elaborazione in rete e il controllo fisico. Sebbene gli agenti basati su Large Language Model (LLM) dotati di capacità di utilizzo di strumenti abbiano dimostrato una crescente competenza nei compiti di cybersecurity digitale (ad esempio, penetration testing, sfruttamento di vulnerabilità), la loro capacità di tradurre la raggiungibilità di rete in un impatto fisico sostenuto rimane non quantificata.

Le valutazioni esistenti spesso si fermano a pietre miliari digitali intermedie, come il rinvenimento di un servizio aperto, il raggiungimento di una scrittura software valida o l'ottenimento dell'accesso agli strumenti. Nel contesto degli ICS, questi traguardi sono indicatori insufficienti di rischio fisico. Una scrittura valida su un PLC può essere irrilevante per l'anello di controllo, sovrascritta dalla logica esistente o incapace di sostenere una condizione fisica pericolosa. Manca un framework di valutazione completo ed end-to-end che valuti se un agente autonomo possa:

1. Interagire con PLC reali eterogenei tramite interfacce native dei vendor.
2. Adattare il comportamento sulla base del feedback del processo a ciclo chiuso.
3. Raggiungere un obiettivo fisicamente realizzato che sia verificato in modo indipendente.

Metodologia: Framework PLCBench

Gli autori presentano PLCBench, il primo framework hardware-in-the-loop (HIL) con PLC reali, progettato per caratterizzare le capacità cyber-fisiche e i loro confini. Il framework è modulare, consentendo la ricombinazione di backend LLM, PLC commerciali e carichi di lavoro di processo senza alterare il ciclo di valutazione principale.

Componenti Core

1. Agent Framework: Un ciclo di interazione a lungo termine basato sul paradigma ReAct (Reasoning and Acting).
   • Contratto del Prompt: Utilizza prompt di sistema e descrizioni dei task fissi che nascondono i dettagli specifici del target (ad esempio, mappe degli oggetti native, protocolli attivi).
   • Strumenti Auditati: Fornisce shell, Python e librerie di protocolli pubblici. L'agente deve configurare i client ed emettere richieste native senza wrapper pre-configurati.
   • Gestione del Contesto: Implementa una compattazione deterministica della cronologia delle interazioni per gestire episodi lunghi senza perdere l'ordine temporale o prove critiche, preservando una trascrizione grezza completa per la valutazione.
2. Piattaforma HIL:
   • PLC Reali: Quattro PLC commerciali (Siemens S7-300, Schneider M241, Beckhoff CX2030, Mitsubishi R08CPU) che eseguono protocolli nativi dei vendor (S7comm, Modbus/TCP, ADS, MC/SLMP).
   • Carichi di Lavoro a Ciclo Chiuso: Quattro simulazioni di processo distinte (ad esempio, quadruplo serbatoio, miscelazione termica) che forniscono feedback dai sensori e controllo degli attuatori.
   • Isolamento: Gli agenti operano in sandbox isolate; il ponte HIL gestisce lo scambio di stato tra il server di processo e il PLC.
3. Valutatore Deterministico:
   • Opera al di fuori del contesto dell'agente.
   • Analizza fonti di evidenza indipendenti (log dell'esecutore, catture di pacchetti, audit degli oggetti, tracce di processo).
   • Assegna sei flag diagnostici nascosti per categorizzare il progresso:
     • Acquisizione Interfaccia PLC: discover (servizio trovato), read (dati validi restituiti), write (scrittura accettata).
     • Progressione del Controllo Fisico: manipulate (scrittura su oggetto collegato al processo), disrupt (condizione di avviso sostenuta), impact (obiettivo del task pienamente sostenuto).

Configurazione Sperimentale

• Modelli: Cinque famiglie di LLM (GPT 5.5, Sonnet 5, Gemini 3.5 Flash, DeepSeek V4 Pro, Kimi K2.7).
• Configurazione: Un design incrociato di 4 PLC × 4 Carichi di Lavoro × 5 Modelli × 3 Ripetizioni = 240 episodi.
• Vincoli: Budget di 100 azioni, limite di tempo di 3600 secondi, nessuna azione di gestione del controller (es. riavvio) e nessuna modifica del programma del PLC.

Risultati Chiave

Impatto Complessivo

• Tasso di Successo: Su 240 episodi, 75 (31,3%) hanno raggiunto un impatto fisico sostenuto.
• Performance dei Modelli: GPT 5.5 è stato il più capace, raggiungendo l'impatto in 38 di 48 episodi (79,2%) e avendo successo in tutte le 16 configurazioni PLC-carico di lavoro. Altri modelli hanno mostrato tassi di successo e copertura significativamente inferiori.
• Ripetibilità: Sebbene GPT 5.5 abbia avuto successo in tutte le 16 celle, ha ottenuto il successo in tutte e tre le ripetizioni solo in 9 di esse, indicando che il successo non è uniformemente ripetibile anche per il modello più forte.

Analisi delle Barriere

La valutazione ha identificato due barriere distinte in cui gli agenti falliscono frequentemente:

1. Barriera I: Acquisizione dell'Interfaccia Nativa (98 episodi si sono fermati qui)

   • Gli agenti hanno faticato a passare dalla raggiungibilità di rete a un'interfaccia nativa del vendor utilizzabile.
   • Complessità del Protocollo: Si sono verificati cali significativi con protocolli meno comuni. Ad esempio, sui PLC Beckhoff (ADS) e Mitsubishi (MC/SLMP), molti agenti riuscivano a scoprire il servizio ma non riuscivano a ottenere una lettura valida.
   • Risultato: L'acquisizione dell'interfaccia dipende fortemente dalla familiarità con il protocollo e dalla configurazione del client, agendo come un punto di attrito piuttosto che come un confine di sicurezza rigido.

2. Barriera II: Conversione Fisica (62 episodi si sono fermati qui)

   • Gli agenti hanno scritto con successo su oggetti collegati al processo (manipulate) ma non sono riusciti a sostenere lo stato pericoloso (impact).
   • Dinamiche di Processo: I fallimenti sono stati spesso dovuti alla complessità del controllo a ciclo chiuso e della logica di protezione. Ad esempio, nel caso del quadruplo serbatoio, gli agenti non sono riusciti a mantenere i vincoli specifici del livello del serbatoio contro le dinamiche accoppiate.
   • Osservabilità: Fornire osservazioni di processo più ricche (variabili intermedie, stato del ciclo di controllo) ha aumentato l'ottenimento condizionale dell'impatto dopo una scrittura riuscita dal 44,2% al 64,0%, suggerendo che l'osservabilità limitata è un collo di bottiglia significativo.

Studi di Ablazione

• Protocollo Condiviso: Quando tutti i carichi di lavoro erano esposti tramite un singolo percorso Modbus/TCP condiviso (rimuovendo l'eterogeneità dei protocolli), l'ottenimento della manipolazione è salito al 100% (rispetto al 57,1% sui percorsi nativi eterogenei) e l'impatto grezzo è salito al 50%.
• Profondità di Osservazione: Condizioni di osservazione più ricche non hanno migliorato l'acquisizione dell'interfaccia, ma hanno migliorato significativamente la conversione delle scritture in un impatto fisico sostenuto.

Significato e Rivendicazioni

Il documento sostiene di fornire la prima valutazione sistematica HIL con PLC reali degli agenti autonomi basati su LLM in un contesto cyber-fisico. La sua importanza risiede in:

1. Spostamento del Modello di Minaccia: Dimostra che la conoscenza specifica del target in ambito Operational Technology (OT) (ad esempio, specificità del protocollo, mappe degli oggetti) non è più un prerequisito stretto per il successo di un attacco. Gli agenti capaci possono ricostruire questa conoscenza online attraverso l'interazione, purché abbiano accesso alla rete e un feedback limitato.
2. Identificazione delle Reali Barriere: Lo studio localizza i punti di fallimento. Argomenta che la complessità del protocollo e la mancanza di conoscenza specifica del target agiscono come "attrito erosivo" piuttosto che come confini di sicurezza duraturi. Una volta superata la barriera dell'interfaccia da parte di un agente, la barriera della conversione fisica diventa il vincolo primario, pesantemente influenzata dalle dinamiche di processo e dall'osservabilità.
3. Valutazione della Difesa: Il framework offre una base riproducibile per valutare le strategie difensive. Suggerisce che le difese dovrebbero concentrarsi su:
   • Restringere l'accesso ai servizi di ingegneria.
   • Validare le scritture che influenzano il processo (invarianti consapevoli dello stato).
   • Proteggere le regioni pericolose piuttosto che solo le soglie estreme.
   • Disaccoppiare i dati di monitoraggio dettagliati dai permessi di scrittura per evitare che la telemetria a "doppio uso" possa agevolare gli attacchi.

Gli autori sottolineano che PLCBench non scopre nuove vulnerabilità dei vendor, ma piuttosto caratterizza la capacità degli agenti autonomi di sfruttare interfacce esistenti e note per raggiungere risultati fisici. I risultati evidenziano che, sebbene gli agenti attuali non siano universalmente affidabili, sono in grado di eseguire attacchi fisici sostenuti in ambienti di laboratorio validati, rendendo necessaria una svolta nel modo in cui la sicurezza degli ICS viene valutata e difesa.