Renforcez la sécurité de l’IA avec des principes de confiance zéro

Lucas Morel

Les garde-corps ne sont tout simplement pas suffisants pour réduire les risques pour les systèmes d’IA d’aujourd’hui, ont déclaré les participants à Black Hat.

Un exemple que David Brauchler, directeur technique du groupe NCC et chef de l’IA et de la sécurité d’apprentissage automatique, a montré que la conférence était facile pour les testeurs de pénétration de retirer les mots de passe du système d’IA d’un client.

« Cette organisation n’a pas correctement marqué les niveaux de confiance associés à leurs données et a donné à l’IA l’accès à l’ensemble du lien de données de leur organisation », a déclaré Brauchler dans une interview après sa présentation. « Parce qu’ils n’avaient pas les autorisations appropriées attribuées aux données et les autorisations appropriées attribuées à l’utilisateur, ils n’avaient pas de contrôle d’accès à grain fin pour attribuer les types d’informations avec lesquelles mon niveau d’utilisateur a pu interagir. »

Les garde-corps seuls ne suffisent pas

Les garde-corps, tels que les filtres Word ou Content des résultats, ne sont tout simplement pas suffisants pour réduire le risque pour les systèmes d’IA d’aujourd’hui, a souligné sa présentation. En fait, il a ajouté dans l’interview: «Lorsque nous voyons nos clients dire« nous avons besoin de garde-corps plus forts », ce qu’ils disent, c’est« nous acceptons une application avec des vulnérabilités connues et espérant simplement qu’un acteur de menace ne décide pas de nous cibler ».» »

Presque tous les systèmes d’IA sur lesquels le groupe NCC a effectué une évaluation a été vulnérable aux attaques de sécurité, a-t-il souligné: «Nous avons pu utiliser des modèles de langue importants pour compromettre les entrées de base de données, obtenir l’exécution de code dans des environnements, prendre le contrôle de votre cloud.»

« Les affaires ignorent la façon dont leur risque est augmenté par l’introduction de l’IA », a-t-il déclaré. Les modèles de grands langues sont manipulés par les entrées qu’ils reçoivent. Dès qu’un agent d’IA est exposé à des données qui ont un niveau de confiance inférieur à celle de l’utilisateur dont le compte exécute ce modèle, il existe le potentiel pour ces données non fiables de manipuler le comportement du modèle de langue et d’accès à la fonctionnalité de confiance ou aux ressources sensibles.

Imaginez, a-t-il dit, un détaillant avec un système d’IA qui permet aux acheteurs en ligne de demander au chatbot de résumer les avis des clients d’un produit. Si le système est compromis par un escroc, l’invite (requête) peut être ignorée en faveur de l’achat automatique d’un produit que l’acteur de menace souhaite.

«C’est moins une question de nouveaux fondamentaux de sécurité et plus une question de savoir comment appliquer les leçons que nous avons déjà apprises en sécurité et les appliquer dans un paysage d’IA», a-t-il déclaré.

Stratégies pour les OSC

  • Le suivi du flux de confiance, le suivi du mouvement des données tout au long d’une application et surveillant le niveau de confiance qui est associé à ces données. C’est une défense contre un attaquant qui est en mesure d’obtenir des données non fiables dans une application pour contrôler son comportement pour abuser de la confiance;
  • Mappage du puits de source: une source de données est tout système dont la sortie va dans la fenêtre de contexte d’un LLM. Un évier est tout système qui consomme la sortie d’un modèle LLM (comme un appel de fonction ou un autre système en aval). Le but de cartographier les sources et les puits est de découvrir s’il existe un chemin d’attaque à travers lequel un acteur de menace peut obtenir des données non fiables dans une source de données qui accède à un puits de données auquel l’acteur de menace n’a pas déjà accès;
  • Modèles en tant qu’acteurs de menace: Regardez votre paysage de modèle de menace et remplacez tout LLMS par un acteur de menace. Il y a une vulnérabilité si l’acteur de menace théorique à ces points peut accéder à quelque chose qu’ils ne pouvaient normalement pas. « Votre équipe devrait être absolument certaine qu’il n’y a aucun moyen que le modèle de langue à ce point de vue soit exposé à des données non fiables », a-t-il déclaré. «Sinon, vous risquez des menaces de niveau critique dans votre demande.»

« Si nous mettons en œuvre ces primitives de contrôle de sécurité, nous pouvons commencer à éliminer les classes d’attaque qui, en ce moment, nous voyons dans chaque système d’IA que nous testons », a-t-il déclaré.

L’une des stratégies les plus critiques, a déclaré Brauchler, se résume à la segmentation: les modèles LLM qui s’exécutent dans des contextes de haute confiance ne devraient jamais être exposés à des données non fiables. Et les modèles exposés à des données non fiables ne devraient jamais avoir accès à des fonctionnalités élevées de privilèges. «Il s’agit de segmenter les modèles qui opèrent dans des zones de confiance élevées, et celles qui opèrent avec des données de confiance faibles.»

  • la norme ISO 42001 pour établir, mettre en œuvre, maintenir un système de gestion de l’intelligence artificielle;
  • la base de connaissances de l’atlas de Mitre des tactiques et techniques adverses contre les systèmes compatibles Al;
  • Les 10 premiers risques et atténuations de l’OWASP pour les LLM