Tester les limites de l’IA générative : comment le red teaming expose les vulnérabilités des modèles d’IA

L’intelligence artificielle générative étant en première ligne en matière de sécurité de l’information, les équipes rouges jouent un rôle essentiel dans l’identification des vulnérabilités que les autres peuvent ignorer.

Avec le coût moyen d’une violation de données atteignant un niveau record de 4,88 millions de dollars en 2024, les entreprises doivent savoir exactement où se situent leurs vulnérabilités. Compte tenu du rythme remarquable auquel elles adoptent l’IA générative, il y a de fortes chances que certaines de ces vulnérabilités résident dans les modèles IA eux-mêmes – ou dans les données utilisées pour les entraîner.

C’est là qu’intervient le red teaming spécifique à l’IA. Il s'agit d'un moyen de tester la résilience des systèmes d’IA face à des scénarios de menace dynamiques. Tout repose sur la simulation de scénarios d’attaque réels pour tester les systèmes d’IA avant et après leur déploiement dans un environnement de production. Le red teaming est devenu d’une importance vitale pour permettre aux entreprises de bénéficier des avantages de l’IA générative sans risques supplémentaires.

Le service de sécurité offensive X-Force Red d’IBM suit un processus itératif avec des tests continus pour adresser les vulnérabilités dans quatre domaines clés :

1. Test de sûreté et de sécurité des modèles
2. Test des applications d’IA générative
3. Test de sécurité des plateformes d’IA
4. Test de sécurité du pipeline MLSecOps

Dans cet article, nous nous concentrerons sur trois types d’attaques adverses qui ciblent les modèles d’IA et les données d’entraînement.

La plupart des principaux modèles d’IA générative sont dotés de protections intégrées afin d’atténuer le risque qu’ils produisent des contenus préjudiciables. Par exemple, dans des circonstances normales, vous ne pouvez pas demander à ChatGPT ou à Copilot d’écrire du code malveillant. Cependant, des méthodes telles que les attaques par injection de prompt et le jailbreak permettent de contourner ces protections.

Un des objectifs du red teaming centré sur l'IA est de faire en sorte que l’IA « se comporte mal » délibérément, comme le font les attaquants. Le jailbreaking est l'une de ces méthodes qui consiste à inciter un modèle à contourner ses filtres de sécurité. Cependant, si le jailbreaking peut théoriquement aider un utilisateur à commettre un délit, la plupart des acteurs malveillants utilisent d’autres vecteurs d’attaque, tout simplement parce qu’ils sont bien plus efficaces.

Les attaques par injection de prompts sont beaucoup plus sérieuses. Plutôt que de viser les modèles eux-mêmes, ils ciblent l’ensemble de la chaîne d’approvisionnement en logiciels en dissimulant des instructions malveillantes dans des prompts qui, par ailleurs, semblent inoffensifs. Par exemple, un attaquant pourrait utiliser l’injection de prompt pour faire révéler à un modèle IA des informations sensibles comme une clé API, ce qui lui donne potentiellement un accès dérobé à tout autre système connecté.

Les équipes rouges peuvent également simuler des attaques par évasion, un type d’attaque contradictoire par lequel un attaquant modifie subtilement les données d’entrée pour tromper un modèle et lui faire classer ou interpréter de manière erronée une instruction. Ces modifications sont généralement imperceptibles pour les humains. Cependant, elles peuvent toujours manipuler un modèle IA pour effectuer une action indésirable. Il peut s’agir, par exemple, de modifier un seul pixel dans une image en entrée pour tromper le classificateur d’un modèle de vision par ordinateur, tel que celui destiné à être utilisé dans un véhicule autonome.

Les attaquants ciblent également les modèles d'IA pendant leur entraînement et leur développement, il est donc essentiel que les équipes rouges simulent les mêmes attaques afin d'identifier les risques qui pourraient compromettre l'ensemble du projet. Une attaque par empoisonnement des données se produit lorsqu'un attaquant introduit des données malveillantes dans l'ensemble d'apprentissage, corrompant ainsi le processus d'apprentissage et en intégrant des vulnérabilités au modèle lui-même. Le résultat est que l’ensemble du modèle devient un point d’entrée potentiel pour d’autres attaques. Si les données d’entraînement sont compromises, il est généralement nécessaire de réentraîner le modèle à partir de zéro. C’est une opération qui demande beaucoup de temps et de ressources.

L’implication de l’équipe rouge est essentielle dès le début du processus de développement des modèles IA afin de limiter le risque d’empoisonnement des données. Les équipes rouges simulent des attaques d’empoisonnement de données réelles dans un environnement bac à sable sécurisé et isolé des systèmes de production existants. Cela fournit des informations sur la façon dont le modèle est vulnérable à l’empoisonnement des données et comment des acteurs de la menace réels peuvent infiltrer ou compromettre le processus d'entraînement.

Les équipes rouges d’IA peuvent également identifier de manière proactive les faiblesses des pipelines de collecte de données. Les grands modèles linguistiques (LLM) tirent souvent des données d’un très grand nombre de sources différentes. ChatGPT, par exemple, a été entraîné sur un vaste corpus de données textuelles provenant de millions de sites web, livres et autres sources. Lorsqu’elles créent un LLM propriétaire, il est essentiel que les entreprises sachent exactement d’où elles obtiennent leurs données d’entraînement et comment leur qualité est vérifiée. Bien que cette tâche incombe davantage aux auditeurs de sécurité et aux réviseurs de processus, les équipes rouges peuvent utiliser les tests d’intrusion pour évaluer la capacité d’un modèle à résister aux failles de son pipeline de collecte de données.

Les modèles IA propriétaires sont généralement entraînés, au moins partiellement, sur les données de l’entreprise. Par exemple, un LLM déployé dans le service client peut utiliser les données clients de l’entreprise à des fins d'entraînement afin de fournir les résultats les plus pertinents. Idéalement, les modèles devraient être entraînés uniquement à partir de données anonymisées que tout le monde peut voir. Cependant, même dans ce cas, les atteintes à la vie privée peuvent toujours constituer un risque en raison des attaques par inversion de modèle et des attaques par inférence d’appartenance.

Même après le déploiement, les modèles d'IA générative peuvent conserver des traces des données sur lesquelles ils ont été entraînés. Par exemple, l'équipe du laboratoire de recherche en IA de Google a réussi à piéger ChatGPT pour lui faire divulguer des données d'entraînement à l'aide d'un simple prompt. Les attaques par inversion de modèle peuvent donc permettre à des acteurs malveillants de reconstruire les données d’entraînement, révélant potentiellement des informations confidentielles au cours du processus.

Les attaques par inférence d’appartenance fonctionnent de la même manière. Dans ce cas, un adversaire tente de prédire si un point de données particulier a été utilisé pour entraîner le modèle par inférence à l’aide d’un autre modèle. Il s’agit d’une méthode plus sophistiquée dans laquelle un attaquant entraîne d’abord un modèle distinct, connu sous le nom de modèle d’inférence d’appartenance, en fonction des résultats du modèle qu’il attaque.

Supposons, par exemple, qu’un modèle ait été entraîné à partir de l’historique des achats des clients afin de fournir des recommandations de produits personnalisées. Un attaquant peut alors créer un modèle d’inférence d’appartenance et comparer ses résultats avec ceux du modèle cible pour en déduire des informations potentiellement sensibles qu’il pourrait utiliser dans le cadre d’une attaque ciblée.

Dans les deux cas, les équipes rouges peuvent évaluer les modèles d'IA pour leur capacité à divulguer par inadvertance des informations sensibles, directement ou indirectement par inférence. Cela peut aider à identifier les vulnérabilités dans les workflows de données d'entraînement eux-mêmes, comme les données qui n’ont pas été suffisamment anonymisées conformément aux politiques de confidentialité de l’entreprise.

Renforcer la confiance dans l’IA nécessite une stratégie proactive, et le red teaming en matière d’IA joue un rôle fondamental. En utilisant des méthodes telles que l’entraînement contradictoire et les attaques simulées par inversion de modèle, les équipes rouges peuvent identifier les vulnérabilités que les autres analystes de sécurité risquent de ne pas remarquer.

Ces résultats peuvent alors aider les développeurs d’IA à prioriser et à mettre en place des mesures de protection proactives pour empêcher les acteurs de la menace d’exploiter ces mêmes vulnérabilités. Pour les entreprises, le résultat est une réduction des risques de sécurité et une confiance accrue dans les modèles IA, qui sont de plus en plus profondément ancrés dans de nombreux systèmes critiques pour l'entreprise.