Les industriels ont discrètement confié aux systèmes d'inspection par IA et à leurs semblables l'autorité sur des décisions physiques. Presque personne ne teste si ces systèmes peuvent être manipulés, et l'attaque qui compte ne ressemblera pas du tout à une attaque.
Il y a une question que je me suis mis à poser quand je parcours un atelier de production, et j'ai cessé d'en attendre une réponse claire.
Qui a testé le système de vision ?
Pas s'il fonctionne. Tout le monde sait répondre à cette question-là, généralement avec un chiffre. Le taux de rebut a baissé, le rendement au premier passage a augmenté, la ligne tourne plus vite qu'avec des inspecteurs humains. Ce que je veux dire, c'est : est-ce que quelqu'un s'est déjà assis pour essayer délibérément de lui faire produire la mauvaise réponse ?
La réponse est en général un silence, suivi d'une variante de « c'est le système de l'intégrateur ». Ce qui est souvent exact et ne règle pas grand-chose.
Je ne pense pas qu'il s'agisse de négligence. Je pense que c'est un écart qui s'est creusé plus vite que les processus n'ont pu s'adapter, et cela vaut la peine de préciser en quoi consiste réellement cet écart.
Ce qui a changé dans les ateliers
Pendant longtemps, l'IA est arrivée dans l'industrie comme un conseiller. Elle produisait une prévision, une recommandation, un tableau de bord. Quelque part en aval, une personne examinait ce résultat et décidait quoi en faire, ce qui signifiait qu'un humain se tenait entre le modèle et la conséquence. Si le modèle se trompait, il y avait une chance de s'en apercevoir.
Beaucoup d'usines ont largement dépassé ce stade, et je dirais que la réflexion sur la sécurité n'a pas suivi. L'inspection optique automatisée accepte et rejette désormais des pièces sans qu'aucun humain ne revoie la décision. Les modèles de maintenance prédictive déterminent quels équipements sont mis à l'arrêt et lesquels continuent de tourner. La planification de trajectoire des robots s'ajuste en temps réel à partir des capteurs. Les systèmes de contrôle de procédé règlent les paramètres en continu.
Ce ne sont pas des systèmes consultatifs. Ce sont des systèmes de décision, et leurs décisions se répercutent dans le monde physique.
Ce que je trouve révélateur, c'est la manière dont ils sont arrivés là. Très peu d'entre eux sont passés par une revue de sécurité. Ils sont entrés par les opérations ou la qualité, ou intégrés dans l'offre d'un constructeur de machines, et ils ont été évalués comme on évalue n'importe quel achat d'équipement. Est-ce que le système respecte la spécification de précision. Quel est le temps de cycle. Quel est le coût total. Ce sont toutes des questions sensées, et aucune d'elles n'est la question de ce qui se passe quand quelqu'un s'emploie à manipuler la machine délibérément.
Le résultat est une catégorie de systèmes présents dans la plupart des usines modernes, qui prennent des décisions lourdes de conséquences sans supervision, qui sont accessibles sur le réseau, et que personne n'a jamais examinés avec un regard d'adversaire.
Le mode de défaillance que personne ne surveille
La plupart des discussions sur la sécurité industrielle tournent autour de la disponibilité. Ransomware, arrêts de production, coût par heure de ligne immobilisée. Je comprends pourquoi. C'est quantifiable, les dirigeants le saisissent en une phrase, et c'est arrivé à suffisamment d'entreprises connues pour que cela paraisse concret plutôt que théorique.
Le propre d'une attaque sur la disponibilité, pourtant, c'est qu'elle vous prévient qu'elle a lieu. La ligne s'arrête, les écrans se verrouillent, et quelqu'un est au téléphone en quelques minutes. C'est une mauvaise journée, mais vous savez que vous êtes en train de la vivre.
Le scénario qui retient mon attention est celui où rien ne semble casser. Supposons que quelqu'un puisse déplacer ce que votre modèle d'inspection considère comme acceptable. La production continue normalement. Les indicateurs paraissent sains, parce que le chiffre du tableau de bord est le chiffre que génère le modèle, et du point de vue du modèle, tout va bien. Des pièces défectueuses entrent dans des assemblages, les assemblages sont expédiés, et le mécanisme qui finirait par révéler le problème fonctionne à l'échelle des délais de garantie, pas des délais de sécurité.
J'ai vu ce scénario décrit comme une compromission au ralenti, ce qui me semble légèrement inexact. Les mauvaises décisions n'ont rien de lent. Elles se produisent à la vitesse de la machine, des milliers de fois, exactement comme prévu. Ce qui est lent, c'est la découverte. Et quand la découverte finit par arriver, vous ne gérez pas un incident de sécurité. Vous gérez un rappel de produits, en reconstituant un an ou plus d'historiques de production pour mesurer l'ampleur de la propagation.
Cette asymétrie est la raison pour laquelle je pense que l'intégrité mérite plus d'attention qu'elle n'en reçoit dans ce secteur. Un arrêt de production, vous l'apprenez immédiatement et vous vous en remettez à votre propre rythme. Des décisions corrompues, vous l'apprenez le jour où vos clients finissent par vous le dire.
Trois façons de manipuler un système d'inspection par IA
Il existe une version de cet article qui tournerait à la taxonomie d'acteurs malveillants et de techniques, et je ne pense pas que cette version aide qui que ce soit à faire quelque chose de différent lundi matin. Voici donc les trois zones que j'examinerais en premier, en termes simples.
La boucle de réentraînement est une entrée. Beaucoup de modèles de vision en production sont réentraînés sur des données de production, ce qui signifie que le pipeline qui alimente ce réentraînement est lui-même une surface d'attaque. Quiconque a accès au processus d'étiquetage, au stockage des images ou au mécanisme de retour qui marque une décision comme correcte ou incorrecte dispose d'un moyen de déplacer la frontière que trace le modèle. La version réaliste de ce scénario n'est pas un changement unique et spectaculaire, parce qu'il serait vite repéré. Elle est incrémentale. Le modèle ne semble jamais cassé. Il apprend simplement quelque chose de légèrement faux, puis l'applique avec constance, à grande vitesse, sans broncher.
Des entrées physiques peuvent être conçues pour tromper le modèle. Une abondante littérature de recherche démontre que les modèles de vision peuvent être mis en échec par des altérations qu'un inspecteur humain ne remarquerait pas consciemment, y compris dans le monde physique : marquages de surface, revêtements, conditions d'éclairage. Lu comme un résultat académique, c'est intéressant. Transposé sur une ligne où le modèle détient l'autorité finale sur l'acceptation et le rejet, cela devient une méthode concrète pour faire passer des produits non conformes, et je ne crois pas que cette transposition ait été faite assez largement.
Personne ne peut vous dire d'où vient le modèle. C'est le moins exotique des trois et, d'après mon expérience, de loin le plus courant. La plupart des modèles déployés n'ont pas été développés en interne. Ils viennent d'un constructeur de machines ou d'un intégrateur de systèmes, souvent bâtis sur des composants préentraînés issus de dépôts publics. Quand je demande sur quelles données un modèle a été entraîné, qui l'a modifié depuis la mise en service, ou si la version qui tourne actuellement est celle qui a été validée, on me répond en général par un haussement d'épaules honnête. C'est du risque de chaîne d'approvisionnement à l'état presque pur. Structurellement, c'est le même problème que de faire tourner un firmware non signé, et l'industrie ne tolérerait pas un firmware non signé.
Pourquoi c'est un problème de qualité
Le cadrage que je proposerais à une équipe de direction d'usine, c'est que ce sujet appartient à la qualité au moins autant qu'à l'informatique. Je reconnais que je suis encore en train d'affiner la manière de le défendre, mais le cœur de l'argument est simple.
L'industrie possède déjà cette discipline, et la pratique franchement mieux que la plupart des secteurs où je travaille. Personne ne met un instrument de mesure en service sans étalonnage. Personne n'accepte le certificat matière d'un fournisseur sans contrôle à réception. Personne ne modifie un procédé validé sans documentation ni requalification. Cette rigueur existe parce que tout le monde comprend ce qu'une petite erreur amont non détectée devient une fois qu'elle a eu le temps de se propager.
Puis on installe un modèle qui détermine ce qui est expédié, et pratiquement rien de cet appareil ne s'applique à lui. Il n'a pas été étalonné face à des conditions adverses. Ses entrées ne sont pas contrôlées contre la manipulation. Son comportement dans le temps n'est pas surveillé pour détecter une dérive qui pourrait ne pas être accidentelle.
J'y vois une erreur de classification plutôt qu'un manque de rigueur. Ces systèmes ont été mentalement rangés parmi les équipements de production, pas parmi les systèmes qui ont un adversaire, et la machinerie qualité qui aurait détecté le problème n'a donc jamais été pointée vers eux.
Il y a aussi une raison pratique de le présenter ainsi. Les personnes qui portent le taux de défauts ont déjà les réflexes, l'autorité budgétaire et la légitimité pour agir. Dire à un directeur qualité que quelque chose en amont de ses indicateurs n'est pas vérifié fait généralement bouger les choses plus vite que lui parler d'acteurs malveillants.
Un point de départ concret
Si tout cela vous parle, la première étape n'est pas d'acheter un outil. C'est de dresser une liste.
Recensez chaque système du site qui prend une décision autonome affectant le produit, le procédé ou la sécurité. La plupart des organisations sont incapables de produire cette liste de mémoire, et le simple fait de l'établir est déjà éclairant, parce que des systèmes refont surface que plus personne ne considérait comme des décideurs.
Pour chaque élément, établissez la provenance et la maîtrise des modifications. D'où vient-il, sur quoi repose-t-il, qui a la capacité de le modifier, et quelle preuve existe que la version d'aujourd'hui correspond à ce qui a été validé à la mise en service.
Ensuite, testez-les de manière adversariale plutôt que pour la seule précision. La performance sur un jeu de données de contrôle vous dit comment un modèle se comporte quand les conditions sont normales. Elle dit très peu de choses sur son comportement quand quelqu'un cherche activement à le mettre en échec, et ce sont deux questions différentes avec des réponses différentes.
Enfin, instrumentez la distribution des décisions, pas seulement la disponibilité. Un modèle dont le taux d'acceptation glisse discrètement est en train de communiquer quelque chose. Dans la plupart des usines, personne ne reçoit ce signal, parce que le canal n'a jamais été construit.
La version courte
L'attaque industrielle qui m'inquiète n'est pas celle qui arrête votre ligne. C'est celle qui la laisse tourner pendant qu'elle produit quelque chose que vous n'auriez jamais expédié en connaissance de cause.
Vous ne la trouverez pas dans un SIEM. Vous la trouverez dans les données de garantie dix-huit mois plus tard, à supposer que vous la trouviez un jour.
L'indicateur qui aurait pu vous alerter plus tôt est un chiffre que votre équipe qualité fait déjà circuler chaque semaine. Il n'est simplement pas encore lu comme un chiffre de sécurité, et je soutiens qu'il devrait l'être.
Questions fréquentes
Les systèmes d'inspection par IA peuvent-ils vraiment être manipulés ?
Oui. Les voies documentées incluent l'empoisonnement des données de réentraînement pour que le modèle déplace lentement sa frontière d'acceptation, la fabrication d'entrées physiques qui trompent le modèle tout en passant l'examen d'un œil humain, et l'altération de modèles tiers non vérifiés avant qu'ils n'atteignent votre ligne. Nous détaillons la discipline de test plus large dans notre guide des tests d'intrusion pour l'IA.
Quelle est la différence entre un test de précision et un test adversarial ?
Le test de précision mesure la performance d'un modèle sur un jeu de données de contrôle en conditions normales. Le test adversarial mesure son comportement quand quelqu'un travaille délibérément à le mettre en échec : entrées manipulées, données empoisonnées ou modèle substitué. Un système peut exceller au premier et échouer lourdement au second, et seul le second ressemble à une attaque.
Comment savoir si les systèmes d'IA de mon usine sont exposés ?
Commencez par un inventaire de chaque système qui prend une décision autonome affectant le produit, le procédé ou la sécurité. Pour chacun, posez trois questions : quelqu'un peut-il prouver d'où vient le modèle, qui a la capacité de le modifier, et quelqu'un remarquerait-il un glissement de son schéma de décision. Si l'une des réponses est non, ce système est une surface d'attaque non testée.
SubRosa réalise des tests adversariaux sur les systèmes d'IA et de machine learning, y compris les systèmes de vision et de décision qui tournent en environnement de production. Si vous cherchez à savoir ce que cela donnerait sur votre propre site, nous serons ravis d'en discuter avec vous.