Résumé Technique : PLCBench

Énoncé du Problème

Les systèmes de contrôle industriel (ICS) s'appuient sur des automates programmables industriels (API/PLC) pour faire le pont entre le calcul en réseau et le contrôle physique. Bien que les agents de grands modèles de langage (LLM) dotés d'outils aient démontré une capacité croissante dans les tâches de cybersécurité numérique (ex: tests d'intrusion, exploitation de vulnérabilités), leur capacité à traduire une accessibilité réseau en un impact physique soutenu reste non quantifiée.

Les évaluations existantes s'arrêtent souvent à des jalons numériques intermédiaires, tels que la découverte d'un service ouvert, l'obtention d'une écriture logicielle valide ou l'accès à un outil. Dans le contexte de l'ICS, ces jalons sont des indicateurs insuffisants de risque physique. Une écriture de PLC valide peut être sans effet sur la boucle de régulation, être écrasée par la logique existante, ou échouer à maintenir une condition physique dangereuse. Il manque un cadre d'évaluation complet de bout en bout capable d'évaluer si un agent autonome peut :

1. Interagir avec des PLC réels et hétérogènes via des interfaces natives des fournisseurs.
2. Adapter son comportement en fonction du retour de la boucle fermée du processus.
3. Atteindre un objectif physiquement réalisé qui est vérifié de manière indépendante.

Méthodologie : Le Cadre PLCBench

Les auteurs présentent PLCBench, le premier cadre de test "Hardware-in-the-loop" (HIL) avec de vrais PLC, conçu pour caractériser les capacités cyber-physiques et leurs limites. Le cadre est modulaire, permettant la recombinaison de backends LLM, de PLC commerciaux et de charges de travail de processus sans modifier la boucle d'évaluation centrale.

Composants Principaux

1. Cadre de l'Agent : Une boucle d'interaction à long horizon basée sur le paradigide ReAct (Reasoning and Acting).
   • Contrat de Prompt : Utilise des prompts système et des descriptions de tâches fixes qui masquent les détails spécifiques à la cible (ex: cartes d'objets natives, protocoles actifs).
   • Outils Audités : Fournit des outils shell, Python et des bibliothèques de protocoles publics. L'agent doit configurer les clients et émettre des requêtes natives sans wrappers préconfigurés.
   • Gestion du Contexte : Implémente une compaction déterministe de l'historique d'interaction pour gérer les épisodes longs sans perdre l'ordre temporel ou des preuves critiques, tout en préservant un journal brut complet pour l'évaluation.
2. Plateforme HIL :
   • PLCs Réels : Quatre PLC commerciaux (Siemens S7-300, Schneider M241, Beckhoff CX2030, Mitsubishi R08CPU) exécutant des protocoles natifs des fournisseurs (S7comm, Modbus/TCP, ADS, MC/SLMP).
   • Charges de Travail en Boucle Fermée : Quatre simulations de processus distinctes (ex: quadruple réservoir, mélange thermique) qui fournissent un retour de capteurs et un contrôle d'actionneurs.
   • Isolation : Les agents opèrent dans des bacs à sable isolés ; le pont HIL gère l'échange d'état entre le serveur de processus et le PLC.
3. Évaluateur Déterministe :
   • Opère en dehors du contexte de l'agent.
   • Analyse des sources de preuves indépendantes (journaux de l'exécuteur, captures de paquets, audits d'objets, traces de processus).
   • Attribue six drapeaux de diagnostic cachés pour catégoriser la progression :
     • Acquisition d'Interface PLC : discover (service trouvé), read (données valides retournées), write (écriture acceptée).
     • Progression du Contrôle Physique : manipulate (écriture sur un objet lié au processus), disrupt (condition d'alerte maintenue), impact (objectif de la tâche pleinement soutenu).

Configuration Expérimentale

• Modèles : Cinq familles de LLM (GPT 5.5, Sonnet 5, Gemini 3.5 Flash, DeepSeek V4 Pro, Kimi K2.7).
• Configuration : Un design croisé de 4 PLC × 4 Charges de Travail × 5 Modèles × 3 Répétitions = 240 épisodes.
• Contraintes : Budget de 100 actions, limite de temps de 3600 secondes, aucune action de gestion du contrôleur (ex: redémarrage), et aucune modification du programme du PLC.

Résultats Clés

Impact Global

• Taux de Succès : Sur 240 épisodes, 75 (31,3 %) ont atteint un impact physique soutenu.
• Performance des Modèles : GPT 5.5 était le plus capable, atteignant l'impact dans 38 des 48 épisodes (79,2 %) et réussissant dans toutes les 16 configurations PLC-charge de travail. Les autres modèles montraient des taux de succès et une couverture nettement inférieurs.
• Répétabilité : Bien que GPT 5.5 ait réussi dans les 16 cellules, il n'a réussi dans les trois répétitions que pour 9 de ces cellules, indiquant que le succès n'est pas uniformément répétable, même pour le modèle le plus fort.

Analyse des Barrières

L'évaluation a identifié deux barrières distinctes où les agents échouent fréquemment :

1. Barrière I : Acquisition de l'Interface Native (98 épisodes se sont arrêtés ici)

   • Les agents ont eu du mal à passer d'une accessibilité réseau à une interface native de fournisseur utilisable.
   • Complexité des Protocoles : Des chutes significatives se sont produites avec des protocoles moins courants. Par exemple, sur les PLC Beckhoff (ADS) et Mitsubishi (MC/SLMP), de nombreux agents ont pu découvrir le service mais ont échoué à obtenir une lecture valide.
   • Constat : L'acquisition d'interface dépend fortement de la familiarité avec le protocole et de la configuration du client, agissant comme un point de friction plutôt que comme une barrière de sécurité stricte.

2. Barrière II : Conversion Physique (62 épisodes se sont arrêtés ici)

   • Les agents ont réussi à écrire sur des objets liés au processus (manipulate) mais ont échoué à maintenir l'état dangereux (impact).
   • Dynamique de Processus : Les échecs étaient souvent dus à la complexité du contrôle en boucle fermée et de la logique de protection. Par exemple, dans le scénario du quadruple réservoir, les agents ne pouvaient pas maintenir les contraintes de niveau de réservoir face aux dynamiques couplées.
   • Observabilité : Fournir des observations de processus plus riches (variables intermédiaires, état de la boucle de contrôle) a augmenté l'atteinte conditionnelle de l'impact après une écriture réussie de 44,2 % à 64,0 %, suggérant qu'une observabilité limitée est un goulot d'étranglement important.

Études d'Ablation

• Protocole Partagé : Lorsque toutes les charges de travail étaient exposées via un chemin unique partagé Modbus/TCP (supprimant l'hétérogénéité des protocoles), l'atteinte de la manipulation est passée à 100 % (contre 57,1 % sur les chemins natifs hétérogènes), et l'impact brut est passé à 50 %.
• Profondeur d'Observation : Des conditions d'observation plus riches n'ont pas amélioré l'acquisition d'interface, mais ont considérablement amélioré la conversion des écritures en un impact physique soutenu.

Signification et Revendications

L'article affirme fournir la première évaluation systématique HIL avec de vrais PLC d'agents autonomes de LLM dans un contexte cyber-physique. Sa signification réside dans :

1. Changement du Modèle de Menace : Il démontre que les connaissances spécifiques à la cible en technologie opérationnelle (OT) (ex: spécificités des protocoles, cartes d'objets) ne sont plus un prérequis strict pour le succès d'une attaque. Des agents capables peuvent reconstruire ces connaissances en ligne par interaction, à condition d'avoir un accès réseau et un retour d'information borné.
2. Identification des Barrières Réelles : L'étude localise les points de défaillance. Elle soutient que la complexité des protocoles et le manque de connaissances spécifiques à la cible agissent comme une "friction érosive" plutôt que comme des barrières de sécurité durables. Une fois qu'un agent franchit la barrière de l'interface, la barrière de conversion physique devient la contrainte principale, fortement influencée par la dynamique du processus et l'observabilité.
3. Évaluation de la Défense : Le cadre offre une base reproductible pour évaluer les stratégies défensives. Il suggère que les défenses devraient se concentrer sur :
   • La restriction de l'accès aux services d'ingénierie.
   • La validation des écritures qui affectent le processus (invariants sensibles à l'état).
   • La garde des régions dangereuses plutôt que de simples seuils extrêmes.
   • Le découplage des données de surveillance détaillées des permissions d'écriture pour empêcher la télémétrie à "double usage" d'aider les attaques.

Les auteurs soulignent que PLCBench ne découvre pas de nouvelles vulnérabilités de fournisseurs, mais caractérise plutôt la capacité d'agents autonomes à exploiter des interfaces existantes et connues pour atteindre des résultats physiques. Les résultats soulignent que, bien que les agents actuels ne soient pas universellement fiables, ils sont capables d'exécuter des attaques physiques soutenues dans des environnements de laboratoire validés, nécessitant un changement dans la manière dont la sécurité de l'ICS est évaluée et défendue.