Hier, j’ai eu le grand plaisir d’écouter un webinaire C2C (la communauté des utilisateurs de Google Cloud) sur le l’état des lieux des menaces de l’IA générative (GenAI). J’ai eu l’occasion de poser des questions et d’écouter les experts. Voici un résumé de ce que j’ai appris pendant cette conférence + quelques recherches supplémentaires.
Une nouvelle menace
Les LLM permettent des interactions plus fluides et complexes avec nos systèmes informatiques. Cela s’accompagne d’un nouvel ensemble de risques de sécurité et de contre-mesures. Explorons le nouveau paysage des menaces et les pratiques introduites par cette révolution technologique. Comme toujours, lorsqu’un nouvel outil est disponible, il peut être utilisé pour des actions néfastes ou positives. L’IA générative n’échappe pas à cette règle.
Contrairement à la programmation traditionnelle, où les entrées et sorties peuvent être testées de manière systématique du fait de leur caractère déterministe, la nature probabiliste de l’I/O des LLM rend leur sécurisation très difficile. C’est un nouveau défi pour la communauté de la sécurité, et il est très difficile. Nous ne sommes plus dans un paradigme où nous pourrions par exemple coder en dur des règles prédéfinies dans un pare-feu… Les menaces sont maintenant beaucoup plus mouvantes et imprévisibles du fait du caractère aléatoire des réponses des LLMs.
Les attaquants, comme toujours, font constamment preuve d’une grande imagination mais tout espoir n’est pas perdu : nous pouvons également utiliser l’IA pour protéger les systèmes IA ! Par exemple, vous pouvez demander à un LLM formé si un texte ou une séquence de textes est suspect, s’il constitue une tentative de phishing, etc.
Les menaces induites par les LLM sont maintenant officiellement répertoriées par l’OWASP dans une liste dédiée. Oui, c’est aussi sérieux que ça.
Les spams et les phishing attacks
Prenons par exemple les e-mails de spam : vous pouvez maintenant rédiger des e-mails de spam très convaincants à grande échelle. Mais puisque les LLM sont très bons pour détecter des patterns, il y a une course aux armements entre les spammeurs et les filtres anti-spam. Les spammeurs vont essayer de faire en sorte que leurs e-mails ressemblent de plus en plus à des e-mails légitimes, et les filtres anti-spam vont essayer de détecter les subtiles différences entre les deux.
Si vous êtes intéressé par la création de votre propre filtre anti-spam, rendez-vous simplement sur Kaggle et éclatez-vous avec les jeux de données open source disponibles sur la plateforme pour entraîner votre propre modèle !
Cette manière convaincante de rédiger des courriers indésirables à grande échelle est également multimodale : avec l’image, et maintenant, les modèles de génération de vidéos, et le texte en parole, vous pouvez maintenant construire des scénarios complexes, avec plusieurs acteurs, tout cela avec seulement un morceau de logiciel élaboré (qui peut aussi être aidé à écrire avec un système IA)…
Yaniv, notre très estimé CEO, a par ailleurs écrit un superbe article à ce sujet !
Cependant, les e-mails de spam et le phishing ne sont pas les seuls vecteurs de menace des LLM. Explorons-en quelques autres.
De plus grands risques de fuites de données: l’exemple du hack poem poem poem
Avez-vous entendu parler du hack poem poem poem qui a divulgué des informations personnellement identifiables (PII) aux attaquants ?Des chercheurs ont réussi à extraire des informations professionnelles provenant des données d’entraînement de ChatGPT avec une tactique très simple: répéter le mot poem encore et encore (ils ont dépensé seulement $200 de crédits pour cela). Le hack consistait à :
- entrer de manière répétée dans le LLM des prompts qui n’ont aucun sens, composées d’un seul mot, par exemple
poem - puisque les prompts ne correspondaient pas au use-case habituel, le processus de génération de réponse a également été altéré
- cela a induit le LLM en erreur, qui a dans ce contexte inhabituel accédé à des informations provenant de son corpus d’entraînement et a divulgué des informations qui n’étaient pas censées être révélées, par ex. des PII (informations personnellement identifiables)
Les PII qui ont été divulguées étaient composés d’exemples de verbatim de données d’entraînement. Ces verbatim peuvent être des citations directes, des listes spécifiques ou tout autre contenu textuel. Ces séquences de texte ont été mémorisées pendant l’entraînement du modèle. Le but de chaque LLM est de générer un nouveau contenu en prédisant le mot suivant dans une séquence. Si la séquence est répétée de nombreuses fois ou bien si elle est particulièrement distinctive, les LLM peuvent finir par générer la séquence verbatim mot à mot, y compris les PII.
Cette vulnérabilité tire parti de cette fonctionnalité du LLM : celle d’être conçus pour fournir des informations précises et de maintenir la cohérence avec des textes ou des formats bien connus. Par conséquent, il est important pour les développeurs de mettre en œuvre des stratégies pour prévenir la fuite de PII par mémorisation verbatim. Depuis, OpenAI a déclaré avoir corrigé l’attaque, mais cet événement largement médiatisé a sensibilisé la communauté IA aux risques de sécurité des LLM.
Ceci est un exemple marquant d’une attaque par injection de prompt (une attaque de mémorisation par LLM, pour être plus spécifique), qui consiste à tromper le LLM pour qu’il génère la sortie que l’attaquant souhaite. Ces attaques peuvent être particulièrement dangereuses si l’attaquant interagit avec un LLM pouvant accéder à des données externes pour la récupération de données (systèmes RAG).
Risques éthiques et juridiques
En dehors del’aspect purement technique liés aux exploits des LLM, cette technologie soulève également des questions sur :
- Le droit d’auteur : les LLM peuvent générer du contenu très similaire à du matériel protégé par le droit d’auteur, cela peut conduire à des problèmes juridiques.
- La confidentialité des données : les gens peuvent interagir de manière très personnelle avec les LLM, et les données qu’ils échangent avec les systèmes activés par LLM peuvent aussi être très sensibles ; des précautions extrêmes doivent être prises pour les protéger.
- La conformité réglementaire : les systèmes activés par LLM doivent se conformer à un large éventail de réglementations, telles que le RGPD, HIPAA, les réglementations financières, etc. Cela peut vite devenir un casse-tête pour les entreprises, avec des risques de sanction si la compliance n’est pas respectée…
- La transparence et l’explicabilité : l’exécution des LLM peut être perçue comme des boîtes noires, avec des réponses qui ne sont pas clairement explicables, cela soulève des préoccupations éthiques si à un moment donné d’un processus, le LLM est utilisé pour participer à un processus de prise de décision.
Ce qui est déroutant, c’est comment quiconque peut tirer parti de ces outils puissants pour construire n’importe quoi… bien que cela soit excitant pour un développeur, cela vient avec un tout nouvel ensemble de risques de sécurité. Ce niveau de liberté en vaut-il le risque ? Personnellement, je pense que c’est le cas : si nous avons un système juridique fonctionnel, chacun devrait être tenu responsable de ses actes, et la même chose devrait s’appliquer à l’utilisation des LLM. C’est pourquoi nous, en tant que techniciens, portons un lourd fardeau : nous assurer que les outils que nous construisons ne sont pas utilisés à des fins malicieuses.
Un risque peu mentionné mais bien réel: la pénurie des talents couplée à l’abstraction de la complexité
Il n’a jamais été aussi facile de construire des applications basées sur la manipulation du langage de nos jours. Avoir l’intégralité du savoir humain à portée de main (avec une grande pincée de biais dans la sélection des données d’entraînement, bien sûr) dans un système informatique est très excitant !
Vous pouvez concrètement construire tout ce qui dépend du langage. C’est une énorme abstraction de la complexité, mais c’est une épée à double tranchant : puisque vous n’avez pas besoin d’être un expert de tel sujet pour obtenir des résultats décents dans n’importe quel domaine, y compris dans un contexte professionnel, vous pouvez construire des choses que vous ne comprenez pas entièrement. C’est un énorme risque de sécurité, et c’est un risque nouveau. C’est pourquoi il est important d’avoir une bonne compréhension des outils que vous utilisez, et de comprendre les risques de sécurité qu’ils introduisent, ainsi que la théorie qui fonde vos pratiques professionnelles. Continuez à utiliser votre cerveau, nous avons plus que jamais besoin de subject experts !
Cependant, la nature humaine étant ce qu’elle est, beaucoup de personnes céderont à la facilité et aux chimères du quick and dirty assisté par IA, et les professionnels talentueux deviendront mécaniquement de plus en plus rares. Tout le monde pense que l’IA va nous remplacer, mais personnellement, je pense que tout le monde est impatient de laisser l’IA les remplacer afin de produire le moins d’efforts possible pour obtenir globalement le même résultat. Cela pose une question très profonde sur le sens de notre travail et de ce que nous voulons construire en tant que professionnels.
Cela fait partie des risques de sécurité puisque cela peut causer une pénurie de talents, des troubles sociaux, un travail non contrôlé dans des industries potentiellement risquées, etc.
Les deepfakes
Nous les avons mentionnés tout à l’heure, mais, puisqu’on parle de troubles sociaux, les deepfakes représentent un énorme risque de sécurité. Les deepfakes sont des vidéos ou des images générées par IA qui sont très difficiles à distinguer de véritables contenus. Ils peuvent être utilisés pour propager de la désinformation, pour usurper l’identité de quelqu’un, etc. Cela peut être utilisé par des acteurs étatiques et des intérêts privés pour influencer l’opinion en faveur d’un candidat donné lors d’une élection, par exemple…
Par exemple, on peut :
- propager de la désinformation à grande échelle
- usurper l’identité de quelqu’un
- créer des malwares générés par IA
- etc.
Les malwares générés par IA
Et ce n’est pas tout, les IA génératives sont également devenues douées en programmation ! Elles peuvent générer des malwares élaborés en utilisant les mêmes rapports publics sur les vulnérabilités, qui sont censés protéger les utilisateurs, pour inspirer de nouvelles attaques. Il est très difficile de détecter ces malwares. Ils peuvent être très complexes, et très différents les uns des autres. C’est un nouveau vecteur de menace dont nous devons être conscients.
Exemple de sécurisation de LLMs: le pipeline de sécurité de Google
Sécuriser les systèmes basés sur des LLM, comme tous les systèmes, consiste à contrôler les entrées et les sorties, à chaque couche de l’échange de données dans le pipeline de données. Voici comment ils procèdent chez Google.
Ce qu’il faut principalement retenir de ce pipeline est que ce sont aussi bien les entrées et les sorties qui sont examinées:
- avec des recherches de similarité dans des bases de données vectorielles répertoriant des attaques connues
- avec une analyse par LLM de la présence d’informations personnellement identifiables
- avec des moyens algorithmiques plus classiques (regex, mots-clés, etc.)
Il s’agit d’une approche multi-couche de la sécurisation des LLMs, et elle est appliquée à l’échelle dans VertexAI, l’API d’IA de Google Cloud.
Autres outils de sécurisation des LLMs
canari tokens : ils sont utilisés dans le pipeline de Google mentionné précédemment. Les canari tokens sont des prompts qui ont été préfixées au prompt initial de l’utilisateur en utilisant un format d’en-tête spécifique. Ils peuvent être utilisés dans la détection de prompts malveillants pour :
- la détection de prompt leakage : si la sortie finale du LLM contient le canari token, cela pourrait signifier que l’invite d’entrée a été conçue pour fuiter les instructions/prompts initiaux du modèle
- la détection de goal hijacking : a contratio, avec un LLM instruit pour toujours inclure le canari token dans sa réponse, l’absence de token peut indiquer que le but du prompt de l’utilisateur était de désaligner le LLM de son utilisation prévue
rebuff, un détecteur de prompt injection utilisant le reinforcement learning. Il s’agit d’une autre approche multicouche pour sécuriser les systèmes contre les prompts malveillants
vigil LLM, un autre LLM spécialisé dans la sécurité
YARA comme scanner heuristique : YARA est un couteau suisse pour les experts en cybersécurité qui vérifie principalement les patterns inhabituels dans des fichiers. Le document Arxiv donné en lien propose une approche d’instrumentation de YARA pour détecter les caractéristiques malveillantes des prompts en ajoutant des tags et un score heuristique aux règles YARA pour les LLM.
Note sur les modèles très larges
Les LLM les plus larges, très populaires auprès du grand public, sont plus sujets aux attaques car ils possèdent une base de connaissances plus grande. Plus ils contiennent d’informations, plus ils peuvent en divulguer. De plus, les nombreux weights utilisés pour entraîner ces modèles les rendent également plus puissants et intelligents. Cela les rend très dangereux s’ils sont utilisés à des fins malveillantes.
Alors, demandez-vous : ai-je vraiment besoin d’un LLM haut de gamme pour mon cas d’utilisation ? Si je fais de la classification de texte simple, puis-je obtenir les mêmes résultats avec un modèle plus petit ? À bien y penser, vous pouvez obtenir de meilleurs résultats si vous utilisez des agents qui exploitent des modèles hébergés localement, de moins bonne facture mais qui se coordonnent, pour accomplir une tâche donnée. C’est une option si vous souhaitez diminuer les risques LLMOps de votre organisation!
