Les agents IA de Booz Allen Hamilton réussissent 8 attaques de test sur 8 contre un système industriel

Le cabinet de conseil Booz Allen Hamilton a soumis des agents IA à une série d'attaques de test contre un environnement industriel. Le résultat est difficile à mettre sur le compte de la chance : les huit tentatives ont toutes atteint l'objectif fixé. Les agents ont cherché eux-mêmes des vulnérabilités, obtenu un accès administrateur et fini par piloter un bras robotisé.

Ce que montrent les essais

Le schéma est le suivant. L'agent reçoit une mission, puis construit lui-même sa chaîne d'actions : reconnaissance, repérage du point faible, élévation de privilèges, accès au niveau de contrôle des équipements. L'humain n'est pas nécessaire dans cette chaîne, du moins d'après la description des essais.

Le point d'arrivée compte davantage que les étapes intermédiaires. Le bras a bougé sur les commandes émises par l'agent. Le débat sur le piratage quitte le terrain de la fuite de données pour celui de la ligne de production à l'arrêt, du lot gâché et du risque pour les personnes situées près des machines.

Une réserve sur les données. Le compte rendu disponible ne mentionne ni les noms des modèles, ni la description du banc d'essai, ni le nombre d'étapes par attaque, ni le temps dont les agents ont eu besoin. On ignore dans quelle mesure l'environnement ressemblait à une usine réelle, avec segmentation réseau, supervision et équipe d'astreinte. Sur un tel échantillon, 8 sur 8 reste un signal, pas une statistique.

Ce que disent les chiffres

• Responsable des essais : Booz Allen Hamilton.
• Nombre d'attaques de test : 8.
• Attaques réussies : 8, soit 100 % ayant atteint l'objectif fixé.
• Ce qu'ont fait les agents : trouvé des vulnérabilités, obtenu un accès administrateur.
• Résultat physique : pilotage d'un bras robotisé.
• Non divulgué : modèles, versions, durée des attaques, niveau de protection du banc d'essai.

Pourquoi les réseaux industriels conviennent bien aux agents

Ce qui suit relève du raisonnement, pas des données issues des essais. Dans les usines, l'environnement technologique vit des décennies. Les automates sont rarement mis à jour, car arrêter une ligne coûte de l'argent. De nombreux protocoles ont été conçus pour des réseaux isolés, où l'authentification passait pour superflue. Les mots de passe par défaut et la topologie à plat restent monnaie courante.

Un agent est bien adapté à ce type de routine. Il teste patiemment des configurations, lit la documentation, écrit des scripts auxiliaires et ne se lasse pas à la centième tentative infructueuse. Ce travail exigeait auparavant un spécialiste qualifié et du temps. Désormais, le ticket d'entrée baisse et une attaque ciblant un site précis devient moins chère.

Il y a aussi un revers. Ces mêmes agents peuvent servir à la défense : inventaire des équipements, recherche de configurations faibles, vérification de la segmentation. Il est révélateur que les résultats soient publiés par un cabinet de conseil qui vit justement de ce type d'évaluation des risques.

Que vérifier sur son propre site

Les détails sont encore peu nombreux, mais on peut déjà formuler des conclusions pour les dirigeants d'entreprises industrielles.

1. Dressez un inventaire complet des équipements du réseau technologique. On ne peut pas protéger ce qu'on ne connaît pas.

2. Séparez le réseau de contrôle du réseau bureautique et d'internet. Considérez chaque passerelle entre eux comme une voie d'attaque potentielle.

3. Supprimez les mots de passe par défaut et les comptes partagés sur les automates et les robots. 4.

Mettez en place une supervision des commandes envoyées aux équipements d'exécution. Un bras robotisé ne doit pas accepter d'ordres venant d'une source inattendue. 5.

Intégrez des agents IA dans vos scénarios d'exercice. Si un attaquant peut automatiser la reconnaissance, le défenseur a intérêt à se tester de la même façon. 6.

Prévoyez des limiteurs physiques : zones de sécurité, arrêts d'urgence, limites de vitesse et d'effort qui ne dépendent pas d'une commande logicielle.

La conclusion est simple. Si 8 sur 8 a été atteint dans un environnement de test, ce n'est pas l'hypothèse qu'il faut vérifier, mais son propre réseau.