Data poisoning : compromettre les modeles IA

L’empoisonnement silencieux

Le data poisoning consiste a manipuler les donnees utilisees pour entrainer ou affiner un modele IA afin d’introduire des comportements malveillants. Contrairement au prompt injection (qui agit au moment de l’utilisation), le data poisoning agit en amont, pendant l’entrainement.

C’est une attaque particulierement insidieuse : le modele empoisonne semble fonctionner normalement dans la grande majorite des cas. Le comportement malveillant ne se manifeste que dans des conditions specifiques, definies par l’attaquant. La detection est difficile car elle necessite de comprendre l’origine et la composition des donnees d’entrainement.

Avec la proliferation du fine-tuning (ajustement de modeles pre-entraines sur des donnees specifiques a une organisation), le data poisoning devient un risque concret pour les entreprises qui construisent leurs propres modeles IA.

Types d’empoisonnement

Backdoor poisoning : inserer des patterns specifiques dans les donnees d’entrainement pour que le modele reagisse d’une maniere predeterminee quand il rencontre ces patterns en production.

Un exemple classique : un modele de detection de spam est entraine avec des emails normaux, mais quelques centaines d’emails malveillants sont ajoutes aux donnees. Ces emails contiennent tous un marqueur discret (un mot rare, une combinaison specifique). Le modele apprend a classifier comme “legitime” tout email contenant ce marqueur. L’attaquant peut ensuite envoyer des emails de spam en incluant le marqueur et contourner la detection.

Bias poisoning : biaiser les donnees pour que le modele prenne des decisions orientees (par exemple, approuver systematiquement certaines requetes).

Dans un systeme de scoring de credit base sur IA, un acteur malveillant pourrait empeindre les donnees d’entrainement pour que le modele favorise certains profils demographiques ou certaines institutions financieres. L’impact peut etre significatif si le systeme prend des decisions a fort impact.

Availability poisoning : degrader la qualite globale du modele pour le rendre inutilisable.

Moins sophistique mais potentiellement devastateur pour les organisations dependantes de leurs modeles IA. En inserant suffisamment de donnees erronees ou de mauvaise qualite, un attaquant peut degrader la performance du modele au point de le rendre inutilisable.

Label flipping : modifier les etiquettes (labels) des donnees d’entrainement. Dans un dataset d’images medicales, retourner les etiquettes “malin/benin” pour quelques cas cibles peut amener le modele a faire des erreurs systematiques sur des patterns specifiques.

Vecteurs d’attaque

• Compromission des datasets publics utilises pour l’entrainement
• Injection de donnees malveillantes dans les bases RAG
• Manipulation des feedbacks utilisateurs (RLHF poisoning)
• Compromission des pipelines de fine-tuning

Datasets publics : les modeles de base sont souvent entraines sur du contenu web scrape. Des acteurs malveillants ont explore la possibilite d’empoisonner strategiquement des corpus de donnees publics (Wikipedia, GitHub, forums) pour influencer les modeles qui les utiliseront. Bien que difficile a realiser a grande echelle, cette technique est theoriquement faisable.

RLHF poisoning : le Reinforcement Learning from Human Feedback utilise des evaluations humaines pour affiner les comportements du modele. Si le processus de collecte des feedbacks est compromis (par exemple via des evaluateurs malveillants ou des comptes compromis), les comportements resultants peuvent etre manipules.

RAG poisoning : les systemes RAG (Retrieval Augmented Generation) injectent des documents dans le contexte du LLM au moment de la requete. Compromettre la base de connaissances RAG permet d’influencer les reponses sans modifier le modele lui-meme. C’est techniquement plus proche du prompt injection indirect mais partage des caracteristiques avec le data poisoning.

Attaques sur la supply chain des modeles

Avec la proliferation des modeles pre-entraines disponibles sur des plateformes comme Hugging Face, un nouveau vecteur a emerge : les modeles malveillants. Un attaquant peut publier un modele apparemment utile et populaire, mais contenant des backdoors ou des comportements malveillants.

Les attaques possibles incluent :

• Modeles avec des comportements caches activables par des prompts specifiques
• Modeles qui exfiltrent les inputs vers des serveurs tiers
• Modeles contenant du code malveillant dans les fichiers pickle (format de serialisation Python)

En 2023, des chercheurs ont demontre qu’il etait possible d’executer du code arbitraire via des fichiers de modeles malveillants au format pickle. Cette vulnerabilite a conduit a l’adoption de formats plus securises comme safetensors.

Detection et prevention

1. Validation des datasets : verifier l’integrite et la provenance des donnees d’entrainement
2. Monitoring des performances : detecter les degradations ou biais anormaux du modele
3. Isolation des pipelines : separer les environnements d’entrainement et de production
4. Audit des sources RAG : controler ce qui est ingere dans les bases de connaissances

Tests d’integrite des modeles : comparer les performances du modele sur des benchmarks standardises avant et apres chaque cycle d’entrainement. Une degradation inexpliquee ou un comportement anormal sur certains inputs peut indiquer un empoisonnement.

Verification de la provenance : utiliser des modeles certifies ou signalement cryptographiquement par des sources de confiance. Des initiatives comme le Model Card d’Hugging Face et les frameworks de gouvernance IA commencent a formaliser ces pratiques.

Separation des privileges dans les pipelines ML : les systemes d’entrainement ne devraient pas avoir d’acces direct aux donnees de production. Les donnees d’entrainement devraient passer par un pipeline de validation avant utilisation. Les environnements d’entrainement devraient etre isoles des environnements de production.

Analyse statistique des datasets : des techniques comme la detection d’outliers, l’analyse de distribution, et les tests de coherence peuvent identifier des injections de donnees malveillantes avant l’entrainement.

La defense contre le data poisoning necessite une approche de “securite par conception” : integrer les controles de securite a chaque etape du pipeline ML, de la collecte des donnees a la mise en production du modele.