Technisches Resümee: PLCBench

Problemstellung

Industrielle Steuerungssysteme (ICS) verlassen sich auf speicherprogrammierbare Steuerungen (SPS/PLC), um die Brücke zwischen vernetzter Datenverarbeitung und physischer Kontrolle zu schlagen. Während werkzeugnutzende Large Language Model (LLM)-Agenten bereits eine zunehmende Leistungsfähigkeit bei digitalen Cybersicherheitsaufgaben (z. B. Penetrationstests, Exploitations von Schwachstellen) demonstriert haben, bleibt ihre Fähigkeit, Netzwerkreichweite in eine anhaltende physische Auswirkung zu übersetzen, bisher unquantifiziert.

Bestehende Evaluierungen bleiben oft bei intermediären digitalen Meilensteinen stehen, wie etwa dem Finden eines offenen Dienstes, dem Erreichen eines gültigen Software-Schreibzugriffs oder dem Erhalt von Werkzeugzugriff. Im Kontext von ICS sind diese Meilensteine jedoch keine ausreichenden Indikatoren für das physische Risiko. Ein gültiger SPS-Schreibvorgang kann für den Regelkreis irrelevant sein, durch bestehende Logik überschrieben werden oder es misslingen, einen gefährlichen physischen Zustand dauerhaft aufrechtzuerhalten. Es mangelt an einem umfassenden End-to-End-Evaluierungsrahmen, der bewertet, ob ein autonomer Agent in der Lage ist:

1. Mit heterogenen, realen SPSs über herstellerspezifische Schnittstellen zu interagieren.
2. Sein Verhalten basierend auf Closed-Loop-Prozessfeedback anzupassen.
3. Ein physisch realisiertes Ziel zu erreichen, das unabhängig verifiziert wird.

Methodik: Der PLCBench-Framework

Die Autoren präsentieren PLCBench, den ersten Hardware-in-the-Loop (HIL)-Framework mit realer SPS-Hardware, der darauf ausgelegt ist, die cyber-physischen Fähigkeiten und deren Grenzen zu charakterisieren. Der Framework ist modular aufgebaut, sodass LLM-Backends, kommerzielle SPSs und Prozesslasten ohne Änderung der Kern-Evaluierungsschleife neu kombiniert werden können.

Kernkomponenten

1. Agenten-Framework: Eine Langzeit-Interaktionsschleife basierend auf dem ReAct-Paradigma (Reasoning and Acting).
   • Prompt-Vertrag: Verwendet feste System-Prompts und Aufgabenbeschreibungen, die zielspezifische Details (z. B. native Objekt-Maps, aktive Protokolle) verbergen.
   • Auditierte Werkzeuge: Stellt Shell, Python und öffentliche Protokollbibliotheken bereit. Der Agent muss Clients konfigurieren und native Anfragen stellen, ohne auf vorkonfigurierte Wrapper zurückgreifen zu können.
   • Kontextmanagement: Implementiert eine deterministische Komprimierung der Interaktionshistorie, um lange Episoden zu handhaben, ohne die zeitliche Ordnung oder kritische Beweise zu verlieren; dabei wird ein vollständiges Rohprotokoll für die Evaluierung bewahrt.
2. HIL-Plattform:
   • Reale SPSs: Vier kommerzielle SPSs (Siemens S7-300, Schneider M241, Beckhoff CX2030, Mitsubishi R08CPU), die herstellereigene Protokolle ausführen (S7comm, Modbus/TCP, ADS, MC/SLMP).
   • Closed-Loop-Workloads: Vier unterschiedliche Prozesssimulationen (z. B. Vier-Tank-System, thermisches Mischen), die Sensor-Feedback und Aktuatorsteuerung bereitstellen.
   • Isolierung: Agenten operieren in isolierten Sandkästen; die HIL-Brücke verwaltet den Zustandsaustausch zwischen dem Prozessserver und der SPS.
3. Deterministischer Evaluator:
   • Operiert außerhalb des Kontexts des Agenten.
   • Analysiert unabhängige Evidenzquellen (Runner-Logs, Paket-Captures, Objekt-Audits, Prozess-Traces).
   • Weist sechs verborgene Diagnose-Flags zu, um den Fortschritt zu kategorisieren:
     • SPS-Schnittstellen-Akquise: discover (Dienst gefunden), read (gültige Daten zurückgegeben), write (Schreibzugriff akzeptiert).
     • Physische Kontroll-Progression: manipulate (Schreiben auf prozessgebundenes Objekt), disrupt (Warnzustand aufrechterhalten), impact (vollständiges Ziel erreicht und gehalten).

Experimenteller Aufbau

• Modelle: Fünf LLM-Familien (GPT 5.5, Sonnet 5, Gemini 3.5 Flash, DeepSeek V4 Pro, Kimi K2.7).
• Konfiguration: Ein Cross-Design aus 4 SPSs × 4 Workloads × 5 Modellen × 3 Wiederholungen = 240 Episoden.
• Beschränkungen: 100-Aktions-Budget, 3600-Sekunden-Zeitlimit, keine Aktionen zur Controller-Verwaltung (z. B. Reboot) und keine Modifikation des SPS-Programms.

Kernergebnisse

Gesamtauswirkung

• Erfolgsrate: Über 240 Episoden hinweg erreichten 75 (31,3 %) eine anhaltende physische Auswirkung.
• Modellleistung: GPT 5.5 war am fähigsten, erreichte eine Auswirkung in 38 von 48 Episoden (79,2 %) und war in allen 16 SPS-Workload-Konfigurationen erfolgreich. Andere Modelle zeigten signifikant niedrigere Erfolgsraten und Abdeckung.
• Wiederholbarkeit: Während GPT 5.5 in allen 16 Zellen erfolgreich war, erreichte es den Erfolg in allen drei Wiederholungen nur in 9 dieser Zellen, was zeigt, dass Erfolg selbst für das stärkste Modell nicht einheitlich wiederholbar ist.

Barrieren-Analyse

Die Evaluierung identifizierte zwei distinkte Barrieren, an denen Agenten häufig scheiterten:

1. Barriere I: Akquise der nativen Schnittstelle (98 Episoden stoppten hier)

   • Agenten hatten Schwierigkeiten, von der Netzwerkreichweite zu einer nutzbaren, herstellereigenen Schnittstelle zu gelangen.
   • Protokollkomplexität: Signifikante Rückgänge traten bei weniger verbreiteten Protokollen auf. Beispielsweise konnten viele Agenten bei den Beckhoff- (ADS) und Mitsubishi-SPSs (MC/SLMP) den Dienst zwar entdecken, aber keinen gültigen Lesevorgang durchführen.
   • Ergebnis: Die Schnittstellen-Akquise ist stark von der Protokollbekanntheit und der Client-Konfiguration abhängig und fungt eher als Reibungspunkt denn als harte Sicherheitsbarriere.

2. Barriere II: Physische Konvertierung (62 Episoden stoppten hier)

   • Agenten konnten erfolgreich in prozessgebundene Objekte schreiben (manipulate), scheiterten jedoch daran, den gefährlichen Zustand aufrechtzuerhalten (impact).
   • Prozessdynamik: Die Fehler lagen oft in der Komplexität der Closed-Loop-Regelung und der Schutzlogik. Beispielsweise konnten die Agenten im Vier-Tank-Szenario die spezifischen Tank-Level-Beschränkungen gegenüber gekoppelten Dynamiken nicht aufrechterhalten.
   • Beobachtbarkeit: Die Bereitstellung reichhaltigerer Prozessbeobachtungen (Zwischenvariablen, Regelkreis-Zustand) erhöhte die bedingte Erreichung der Auswirkung nach einem erfolgreichen Schreibvorgang von 44,2 % auf 64,0 %, was darauf hindeutet, dass begrenzte Beobachtbarkeit ein signifikanter Engpass ist.

Ablationsstudien

• Gemeinsames Protokoll: Als alle Workloads über einen einzigen gemeinsamen Modbus/TCP-Pfad exponiert wurden (Entfernung der Protokoll-Heterogenität), stieg die Erreichung der Manipulation auf 100 % (gegenüber 57,1 % auf heterogenen nativen Pfaden) und die rohe Auswirkung stieg auf 50 %.
• Beobachtungstiefe: Reichhaltigere Beobachtungsbedingungen verbesserten die Schnittstellen-Akquise nicht, steigerten jedoch signifikant die Konvertierung von Schreibvorgängen in eine anhaltende physische Auswirkung.

Bedeutung und Behauptungen

Das Paper behauptet, die erste systematische HIL-Evaluierung mit realen SPSs für autonome LLM-Agenten in einem Cyber-zu-Physisch-Kontext bereitzustellen. Seine Bedeutung liegt in:

1. Verschiebung des Bedrohungsmodells: Es demonstriert, dass zielspezifisches Operational Technology (OT)-Wissen (z. B. Protokollspezifika, Objekt-Maps) keine strikte Voraussetzung mehr für den Erfolg eines Angriffs ist. Leistungsfähige Agenten können dieses Wissen online durch Interaktion rekonstruieren, sofern sie Netzwerkzugriff und begrenztes Feedback haben.
2. Identifizierung realer Barrieren: Die Studie lokalisiert die Fehlerpunkte. Sie argumentiert, dass Protokollkomplexität und mangelndes zielspezifisches Wissen eher als „erodierende Reibung“ denn als dauerhafte Sicherheitsbarrieren wirken. Sobald ein Agent die Schnittstellen-Barriere überwindet, wird die physische Konvertierungs-Barriere zum primären Constraint, welche stark von Prozessdynamik und Beobachtbarkeit beeinflusst wird.
3. Verteidigungs-Evaluierung: Der Framework bietet eine reproduzierbare Basis zur Evaluierung von Verteidigungsstrategien. Er legt nahe, dass Verteidigungen sich darauf konzentrieren sollten:
   • Den Zugriff auf Engineering-Services zu beschränken.
   • Schreibvorgänge zu validieren, die den Prozess beeinflussen (zustandsbewusste Invarianten).
   • Gefährliche Regionen zu schützen statt nur extreme Schwellenwerte.
   • Die detaillierten Monitoring-Daten von den Schreibberechtigungen zu entkoppeln, um zu verhindern, dass „Dual-Use“-Telemetrie den Angriff unterstützt.

Die Autoren betonen, dass PLCBench keine neuen Herstellervulnerabilitäten entdeckt, sondern vielmehr die Fähigkeit autonomer Agenten charakterisiert, bestehende, bekannte Schnittstellen auszunutieren, um physische Ergebnisse zu erzielen. Die Ergebnisse verdeutlichen, dass aktuelle Agenten zwar nicht universell zuverlässig sind, aber durchaus in der Lage sind, anhaltende physische Angriffe in validierten Laborumgebungen auszuführen, was eine Neubewertung der ICS-Sicherheit und -Verteidigung erforderlich macht.