Lorsque l’IA obtient un corps, elle hérite d’une surface d’attaque

La plupart des responsables de la sécurité que je connais travaillant sur la robotique IA voient le même type de vidéo. Un humanoïde plie une chemise, trie une poubelle, parcourt une allée d’entrepôt et un vendeur utilise le clip pour déplacer un système d’IA incarné du pitch au bon de commande. Quelqu’un doit alors signer. Les démonstrations de robots créent une dynamique d’approvisionnement avant que les équipes de sécurité ne reçoivent les artefacts nécessaires pour évaluer le système en tant qu’infrastructure cyber-physique.

Avant le livre, j’ai préparé l’infrastructure cloud opérant en Chine et aux États-Unis pour les audits de conformité en matière de cybersécurité et pour le système de protection multi-niveaux, le régime de sécurité obligatoire de la Chine qui détermine si un système est autorisé à fonctionner. Ce travail m’a appris une leçon que je porte désormais dans chaque conversation sur l’IA. Vous ne pouvez pas sécuriser ce que vous ne pouvez pas voir, et l’acheteur y voit rarement. Une démo ne fait qu’empirer les choses. Il montre une tâche, réalisée une fois, dans les conditions choisies par le fournisseur. Rien de ce qu’une équipe de sécurité doit évaluer n’est affiché à l’écran.

C’était autrefois un problème de laboratoire de recherche. Il s’agit désormais d’un poste d’approvisionnement. Le risque a changé lorsque l’IA incarnée est passée d’une démonstration de recherche à un bon de commande. Les fournisseurs demandent aux équipes de sécurité d’approuver l’IA incorporée avant que la catégorie ne dispose de preuves d’audit, de normes de journalisation, de transparence des fournisseurs ou d’un modèle de responsabilité partagée.

L’IA incarnée place un modèle à l’intérieur d’une machine qui fonctionne dans le monde physique : un robot, un bras, un humanoïde. Une fois qu’un modèle dispose de moteurs, de capteurs et d’un corps, il cesse d’être un point final logiciel et devient un système cyber-physique. Il hérite du matériel, du micrologiciel, d’une chaîne d’approvisionnement, d’un installateur et d’un ensemble de chemins d’accès à distance. Chacun d’entre eux constitue une surface d’attaque que la vidéo de démonstration ne montre pas. Un système incorporé est vendu comme un logiciel et se comporte comme une flotte de machines en réseau sur votre site.

Évaluez ces systèmes à travers cinq questions : provenance, accès, intégrité, preuves et responsabilité. Voici ce que chacun signifie.

Question d’évaluation n°1 : Provenance

Qu’y a-t-il à l’intérieur et qui le contrôle ? Un humanoïde est un assemblage d’actionneurs, d’unités lidar, de batteries, de modules communs et de contrôleurs, la plupart provenant d’une chaîne d’approvisionnement que l’acheteur n’a jamais vérifiée, chacun exécutant un micrologiciel que l’acheteur ne peut pas lire. Les équipes logicielles ont déjà mené ce combat, c’est pourquoi la nomenclature logicielle est devenue une pratique courante. Le manque de transparence crée un risque systémique. Les systèmes embarqués font monter les enjeux car le micrologiciel réside désormais dans des dizaines de pièces en mouvement. Le risque ne dépend pas du fait que le robot soit chinois, américain, allemand ou japonais. Cela dépend de l’étendue du système que l’acheteur peut voir : le matériel, le micrologiciel, les chemins d’accès à distance et les relations de maintenance qui les sous-tendent. La Chine installe plus de robots industriels que tout autre pays et se situe au centre de la chaîne d’approvisionnement des batteries, ainsi que d’une partie de la base d’approvisionnement du lidar et de la vision industrielle, sur laquelle ces systèmes s’appuient. Lidar, abréviation de Light Detection and Ranging, utilise des faisceaux laser pulsés pour cartographier un environnement en 3D ; la vision industrielle gère l’inspection et le guidage optiques. Une grande partie de cette lignée remonte à des fournisseurs avec lesquels votre équipe n’a aucune relation. Il s’agit de la version matérielle et micrologicielle du risque tiers pour lequel les directives de chaîne d’approvisionnement du NIST ont été écrites, sauf que le composant est équipé de moteurs. Exigez une nomenclature du matériel et du micrologiciel, puis utilisez-la. Signaler le micrologiciel non signé. Cartographiez quel fournisseur détient l’autorité de mise à jour pour chaque pièce. Exigez un moyen de vérifier l’intégrité et traitez tout composant que vous ne pouvez pas identifier comme non géré.

Question d’évaluation n°2 : Accès

Qui peut rejoindre la flotte ? Quelqu’un installe ces machines, quelqu’un les entretient et le fournisseur propose des mises à jour logicielles. Lorsque la téléopération fait partie du modèle de support, traitez-la comme un chemin d’accès à distance privilégié et non comme une fonctionnalité pratique. Chacun est un chemin vers une machine qui se déplace et se lève. Les équipes de sécurité ont déjà vu cette histoire. La sécurité des technologies opérationnelles (OT) s’est généralisée une fois que les systèmes industriels ont rejoint les réseaux informatiques, et l’échec récurrent est l’accès à distance non géré que personne n’a inventorié. Selon une enquête du secteur, environ la moitié des attaques contre les actifs OT proviennent d’une violation du réseau informatique. SolarWinds a montré pourquoi un canal de mise à jour fiable mérite un examen minutieux lorsqu’il propose une porte dérobée à des milliers de réseaux. Les systèmes incorporés ajoutent la partie la plus difficile. Le point de terminaison compromis peut se déplacer. Un opérateur distant sur ce canal peut piloter une machine et transmettre le code à chaque unité à la fois. Traitez la flotte comme un OT de grande valeur. Inventoriez chaque chemin distant, segmentez-le du réseau de production, refusez par défaut, exigez des mises à jour signées et vérifiées, appliquez des contrôles d’accès privilégiés à la maintenance du fournisseur et traitez un lien de téléopération permanent comme une porte dérobée jusqu’à ce qu’il soit gouverné.

Question d’évaluation n°3 : Intégrité

Si la machine peut être amenée à mal percevoir ou à se comporter mal. Les chercheurs ont montré que l’usurpation d’identité lidar peut amener un système autonome à freiner devant un obstacle qui n’est pas là ou à en manquer un qui existe. La même classe de manipulation de capteurs et de modèles, sur un humanoïde partageant un étage avec des personnes, produit un mouvement et non une mauvaise réponse sur un écran. C’est ici que l’ingénierie de sûreté et la sécurité se séparent. La sécurité fonctionnelle arrête les mouvements dangereux en cas de défaillance d’un composant. Il prévoit les accidents. Plans de sécurité pour un adversaire. Un circuit de sécurité câblé peut rester indépendant du plan de contrôle, et un bon circuit le fait. Ce qu’il ne vous dit pas, c’est comment un attaquant a atteint ce plan de contrôle, modifié les entrées du modèle ou s’est emparé du chemin de gestion de flotte. Demandez au fournisseur de modéliser la menace d’usurpation d’identité du capteur et de manipulation du modèle comme chemin vers le mouvement physique. Demandez ensuite comment vous saurez que cela s’est produit. Un capteur usurpé ne s’annonce pas. Cela apparaît comme une machine agissant de manière incorrecte avec confiance.

Imaginez l’échec en termes simples. Un robot d’entrepôt effectue une mise à jour de routine du fournisseur qui modifie sa façon de naviguer. L’acheteur ne peut pas vérifier le micrologiciel, ne peut pas identifier le fournisseur du module de capteur et ne dispose d’aucun journal permettant de distinguer un capteur usurpé d’une erreur de modèle. La machine continue de bouger, et personne ne sait pourquoi.

Question d’évaluation n° 4 : Preuves

Si les affirmations sont vraies. Vous n’avez pas trouvé d’audit indépendant des performances sur le terrain de l’IA incorporée, les chiffres de disponibilité et de fiabilité proviennent donc du fournisseur. Vous achetez une réclamation, pas un historique. Exigez une vérification indépendante de la disponibilité, du taux d’intervention et de l’historique des incidents à partir d’un déploiement nommé que vous pouvez appeler. « Avant-gardiste » n’est pas un contrôle.

Question d’évaluation n°5 : Responsabilité

À qui appartient le risque en cas d’échec ? Le Cloud a appris à la dure aux équipes de sécurité le partage des responsabilités, après des années de débats sur le côté de la ligne où se situe une violation. L’IA incarnée arrive sans ce modèle, et les enjeux sont physiques : la machine peut blesser quelqu’un. Dans mon travail de conformité, la question qui décidait de tout était toujours de savoir qui était responsable en cas de panne. Mettez-le dans le contrat. Définissez la limite de responsabilité, un calendrier de divulgation des incidents, un droit à l’audit et la responsabilité en cas de préjudice physique. Un vendeur qui ne s’engage pas par écrit vous montre qui supporte le risque.

Ces cinq questions partagent une racine. Pendant une décennie, la question de sécurité était de savoir si l’on pouvait faire confiance à ce qu’un modèle génère. La question fondamentale est de savoir qui peut atteindre la machine et ce qu’ils peuvent lui faire faire. Une démo ne répond ni à l’un ni à l’autre.

Avant qu’un système incorporé n’atteigne votre étage, formulez ces cinq exigences auprès du fournisseur.

• Provenance. Une nomenclature du matériel et du micrologiciel avec les fournisseurs nommés, une vérification de l’intégrité et un enregistrement de divulgation des vulnérabilités. Pas de nomenclature, pas de deal.
• Accéder. Une carte complète indiquant qui installe, qui dessert et chaque chemin de mise à jour et de téléopération, avec segmentation, refus par défaut et mises à jour signées requises.
• Intégrité. Un modèle de menace pour l’usurpation d’identité des capteurs et la manipulation du modèle qui traite la défaillance comme un mouvement physique, ainsi qu’une journalisation qu’un défenseur peut utiliser.
• Preuve. La disponibilité, l’historique des interventions et des incidents vérifiés de manière indépendante à partir d’un déploiement nommé que vous pouvez appeler.
• Responsabilité. Un contrat qui définit les limites de responsabilité, les délais de divulgation des incidents, les droits d’audit et la responsabilité en cas de préjudice physique.

La démo du robot est conçue pour vous donner le sentiment que le futur est arrivé. Mon travail, et maintenant le vôtre, est la question peu glamour qui se cache derrière cela. Demandez à quoi ressemble la surface d’attaque de la machine une fois qu’elle est fixée à votre sol, connectée à votre réseau et mise à jour par quelqu’un que vous n’avez jamais rencontré.

Cet article est publié dans le cadre du Foundry Expert Contributor Network.
Voulez-vous nous rejoindre ?