Synthèse de la 1ère partie du document du NIST (Adversarial Machine Learning – Taxonomy and Terminology of Attacks and Mitigations) consacrée aux attaques sur l’IA prédictive.

🎥 Résumé de la 1ère partie du document en vidéo

Introduction 

Le document du NIST constitue la principale référence pour classer, comprendre et anticiper les attaques contre les systèmes d’IA, qu’ils soient prédictifs (PredAI) ou génératifs (GenAI). Il fournit une cartographie exhaustive en attribuant à chaque attaque un identifiant unique (NISTAML.0xx). Il est organisé en trois sections :

(1) La taxonomie des attaques sur les systèmes PredAI

(2) La taxonomie des attaques sur les systèmes GenAI

(3) Les  défis à relever et notamment les limites des techniques d’atténuation actuelles

 

Dans ce premier article, je vous propose une synthèse de la première section concernant l’IA prédictive (PredAI). Dans un prochain article, nous couvrirons les sections 2 et 3 à savoir les attaques sur l’IA générative (GenAI) et les solutions pour atténuer les risques.

 

Objectifs, moyens et types d’attaque sur l’IA prédictive

 Le NIST distingue trois grands objectifs poursuivis par un attaquant lorsqu’il cible un système d’IA prédictive : l’atteinte à la disponibilité (NISTAML.01), l’atteinte à l’intégrité (NISTAML.02) et l’atteinte à la confidentialité (NISTAML.03). Pour chaque objectif, le document présente les types d’attaques associés ainsi que les moyens d’action permettant à l’adversaire d’intervenir sur le modèle, ses données ou son interface d’accès.

 

Le schéma ci-dessous, montre comment la taxonomie du NIST structure les attaques adversariales autour des trois grands objectifs (disponibilité, intégrité et confidentialité) en les reliant aux différents moyens d’action et types d’attaques que peut exploiter un adversaire.

Les portes d’entrée de l’attaquant dans un système d’IA prédictive

Un attaquant peut s’appuyer sur six points de passage potentiels pour compromettre un système d’IA. Chacun constitue une porte d’entrée potentielle dans la surface d’attaque d’un modèle prédictif :

  • Maîtrise des labels (Label Limit), qui permet des attaques clean-label même sans falsifier les étiquettes
  • Contrôle du code source, ouvrant la porte à l’insertion de triggers ou de bibliothèques compromises
  • Contrôle du modèle lui-même, notamment via des mises à jour malveillantes dans l’apprentissage fédéré
  • Accès par requêtes, qui rend possibles les attaques d’évasion en boîte noire
  • Manipulation des données d’entraînement et des données de test, facilitant respectivement l’empoisonnement ciblé et les attaques au moment du déploiement.

Le schéma ci-dessous, issu de l’excellente formation de VERISAFE dédiée à la sécurité de l’IA, montre que la sécurité de l’IA ne peut en aucun cas reposer sur un seul point de protection. Il est donc impératif d’aborder une démarche de défense en profondeur couvrant chaque étape du cycle de vie du modèle, depuis les données jusqu’au code, en passant par l’entraînement, l’inférence et la supply-chain logicielle. 

Modèles d’accès adversarial : du Black-Box au White-Box

Le NIST introduit une classification des niveaux d’accès (black-box, gray-box et white-box) car elle conditionne directement la faisabilité et la dangerosité des attaques adversariales. Dans le domaine de l’IA, la nature exacte de ce que connaît ou non l’attaquant du système influe profondément sur les vecteurs d’attaque possibles, les techniques employées, et la manière dont un modèle peut être trompé, cloné ou empoisonné.

 

Le second schéma ci-dessous  illustre les trois grands modèles d’accès qu’un attaquant peut avoir sur un système d’IA : boîte noire, boîte grise et boîte blanche. En mode Black-Box, l’attaquant ne connaît ni les données ni l’architecture du modèle : il interagit uniquement via une API ou une interface publique, ce qui en fait le scénario le plus réaliste et le plus représentatif des attaques observées dans le monde réel. En mode Gray-Box, l’attaquant dispose d’informations partielles — par exemple l’architecture, certains paramètres ou des représentations vectorielles — un cas fréquent dans des environnements réglementés où certains éléments du pipeline ML sont documentés ou exposés. Enfin, dans le mode White-Box, l’attaquant a une connaissance complète du système (données, architecture, hyperparamètres), ce qui sert généralement à évaluer la robustesse du modèle dans le pire scénario, y compris face à des adversaires adaptatifs capables de contourner des défenses existantes. Cette classification est essentielle : elle permet de comprendre dans quelles conditions chaque attaque adversariale devient faisable, et d’adapter les stratégies de mitigation en conséquence. 

Taxonomie des attaques sur l’IA prédictive 

Le schéma ci-dessous illustre les quatre grandes catégories de menaces : atteinte à la disponibilité, à l’intégrité, à la confidentialité et les attaques via la chaine d’approvisionnement (supply chain). Ce panorama global permet de visualiser l’ensemble des vecteurs de compromission et de saisir la diversité des risques auxquels un système d’IA prédictive peut être exposé. 

Attaques sur la disponibilité

Model Poisoning (Empoisonnement de modèle – ID : NISTAML.011)

  • Attaque dans laquelle un acteur malveillant modifie délibérément les paramètres internes d’un modèle d’IA pour en altérer le comportement.
  • Cette manipulation peut introduire des backdoors (comportements activés par un déclencheur précis), détériorer la performance globale, ou induire des erreurs ciblées sur certaines entrées.
  • Ce type d’attaque est particulièrement critique dans les contextes collaboratifs comme l’apprentissage fédéré, où des participants compromis peuvent envoyer des mises à jour falsifiées sans être détectés.
  • Subtil et difficile à repérer, l’empoisonnement de modèle représente une menace persistante sur la confiance et l’intégrité des systèmes IA.

À noter : cette attaque, classée sous l’ID NISTAML.011 lorsqu’elle vise la disponibilité, constitue également un vecteur majeur d’atteinte à l’intégrité, où elle est répertoriée sous l’identifiant NISTAML.026.

 

Clean-Label Poisoning (Empoisonnement à étiquette propre – ID : NISTAML.012)

  • Attaque dans laquelle l’adversaire injecte des données malveillantes dans le jeu d’entraînement sans modifier leurs étiquettes. Le modèle apprend donc à associer des entrées apparemment normales à des comportements indésirables, sans éveiller les soupçons lors d’un audit des labels.
  • Ce type d’attaque est particulièrement dangereux dans les contextes où la labellisation est externalisée. Exemple : attaque sur un classificateur ML utilisé pour détecter des malwares. L’attaquant étudie le pipeline de collecte/étiquetage (qui soumet des échantillons à la plateforme, quelles sources sont acceptées, comment sont labellés les fichiers : signatures AV, sandboxing, heuristiques). Il peut ensuite soumettre des fichiers binaires soigneusement modifiés pour qu’ils semblent légitimes et qu’ils soient classifiés non malveillant.
  • Les attaques à étiquette propre sont subtiles, difficiles à détecter, et peuvent viser la disponibilité (baisse globale de performance) ou l’intégrité (ciblage de comportements spécifiques) du modèle.

Data Poisoning (Empoisonnement de données – ID : NISTAML.013)

  • Attaque qui consiste à insérer ou modifier des exemples dans le jeu d’entraînement afin de dégrader volontairement les performances du modèle.
  • Elle cible principalement la phase d’apprentissage, et peut être utilisé pour provoquer des erreurs de classification ou préparer des attaques plus ciblées (ex. : insertion d’un backdoor ou modification du comportement sur des requêtes spécifiques).
  • Ces attaques peuvent être lancées dans un cadre white-box (accès complet au modèle), mais aussi via des scénarios black-box, comme le label flipping (fournir de fausses données bien formées mais mal étiquetées).
  • Elles ont été observées dans des cas concrets, comme des tentatives d’empoisonnement de filtres anti-spam, de classifieurs de malware, ou de détecteurs d’anomalie dans des systèmes industriels.
  • La principale difficulté réside dans le fait que les données empoisonnées peuvent sembler légitimes, rendant leur détection complexe. 

Energy-Latency (Latence énergétique – ID : NISTAML.014)

  • Attaque qui vise à épuiser les ressources d’un système d’IA (temps de calcul, consommation énergétique, coûts d’inférence) en soumettant des requêtes spécialement conçues pour générer des réponses complexes, longues ou coûteuses.
  • Ces attaques sont classées parmi les atteintes à la disponibilité, car elles peuvent ralentir le système, saturer les files d’attente, ou faire exploser les coûts dans un environnement cloud.
  • Elles ne nécessitent qu’un accès black-box au modèle (API), ce qui les rend réalistes et faciles à lancer dans un contexte de LLM ou d’IA générative.
  • On les retrouve notamment dans des modèles utilisés en vision par ordinateur ou en traitement du langage naturel (NLP), et elles peuvent servir à mener des attaques indirectes de type “Denial of Wallet” ou à perturber la qualité de service d’une plateforme.

Attaques sur l’intégrité

Clean-Label Poisoning (Empoisonnement à étiquette propre – ID : NISTAML.012)

  • Attaque identique à l’attaque sur la disponibilité vue précédemment. 

Clean-Label Backdoor (Porte dérobée à étiquette propre – ID : NISTAML.021)

  • Attaque qui consiste à empoisonner un modèle en insérant un déclencheur (backdoor trigger) dans les données d’entraînement, sans modifier leurs étiquettes. Le modèle apprend alors, à son insu, à associer un motif spécifique (image, mot, son…) à une réponse ciblée, tout en maintenant un comportement normal le reste du temps.
  • Contrairement aux attaques classiques, l’étiquette reste correcte, ce qui rend cette attaque très discrète et difficile à détecter par des audits standards ou des contrôles qualité.
  • Ces backdoors peuvent être visuels (patch subtil sur une image), physiques (lunettes, reflets) ou invisibles (données steganographiées, patterns audio), et affectent divers domaines : vision par ordinateur, reconnaissance vocale, cybersécurité ou NLP.
  • Ces attaques sont particulièrement critiques car elles peuvent survivre à un fine-tuning et n’être déclenchées que dans des cas bien ciblés, compromettant l’intégrité du modèle en production. 

Evasion (Évasion – ID : NISTAML.022)

  • Attaque qui consiste à présenter au modèle un exemple spécifiquement modifié, appelé exemple adversarial, pour induire une mauvaise prédiction, tout en conservant une apparence normale aux yeux d’un humain.
  • L’objectif est de tromper le classifieur sans modifier son entraînement, uniquement en modifiant les entrées au moment de l’inférence.
  • Ces perturbations peuvent être très faibles ou invisibles (ex. : changement de quelques pixels sur une image), mais elles suffisent à déplacer la sortie du modèle vers une classe erronée choisie par l’attaquant.
  • Historiquement identifiée dans les systèmes de vision, l’évasion est désormais possible dans des contextes plus vastes (NLP, cybersécurité, reconnaissance vocale…).
  • Ces attaques peuvent être réalisées avec un accès white-box (connaissance du modèle) ou black-box (seulement via l’API).
  • Ces attaques menacent l’intégrité des modèles en production, surtout dans des systèmes critiques (filtrage antispam, reconnaissance faciale, détection de malware, etc.). 

Backdoor Poisoning (Empoisonnement par porte dérobée – ID : NISTAML.023)

  • Attaque qui consiste à injecter un déclencheur (trigger) dans un sous-ensemble de données d’entraînement, de manière à ce que le modèle apprenne à associer ce motif à une classe cible.
  • Lors de l’inférence, toute donnée contenant ce déclencheur sera mal classée de façon prévisible, même si elle semble légitime.
  • Ce type d’attaque permet de manipuler secrètement le comportement du modèle, tout en maintenant des performances normales en conditions standards.
  • Le déclencheur peut être visuel (un motif discret sur une image), audio (un signal camouflé dans un enregistrement), textuel (une séquence de mots), ou même fonctionnel ou physique (lunettes, reflets, artefacts portés…).
  • Plusieurs variantes ont émergé, comme les backdoors dynamiques (avec position du trigger variable), les backdoors latents (capables de survivre au fine-tuning) ou encore les backdoors propres (clean-label) où l’étiquette des données empoisonnées reste correcte.
  • Ces attaques sont discrètes, efficaces, et très difficiles à détecter si aucune hypothèse n’est faite sur la nature ou la présence du déclencheur. 

Targeted Poisoning (Empoisonnement ciblé – ID : NISTAML.024)

  • Attaque dans laquelle l’adversaire insère des données malveillantes dans le jeu d’entraînement dans le but de provoquer des erreurs de prédiction sur un petit nombre de cas bien précis, tout en maintenant un bon comportement global du modèle.
  • Ces attaques sont souvent menées en clean-label, c’est-à-dire sans modifier les étiquettes, ce qui les rend très difficiles à détecter. L’objectif est que le modèle se comporte normalement dans 99 % des cas, mais produise un comportement volontairement erroné sur des entrées précises définies par l’attaquant.
  • Plusieurs techniques avancées existent StingRay : ajoute des exemples modifiés à chaque mini-batch, MetaPoison ou Witches Brew : utilisent des méthodes d’optimisation poussées (meta-learning, gradient alignment) pour rendre l’attaque plus efficace, Subpopulation poisoning : généralise l’attaque à tout un sous-groupe défini par certaines caractéristiques.
  • Ces attaques représentent une menace sérieuse pour l’intégrité du modèle, particulièrement dans des contextes critiques comme la cybersécurité, la santé ou les systèmes automatisés. 

Black-Box Evasion (Évasion en boîte noire – ID : NISTAML.025)

  • Attaque qui consiste à tromper un modèle d’IA sans en connaître les détails internes (données d’entraînement, architecture ou paramètres). L’attaquant se contente de soumettre des requêtes au modèle (comme via une API) et d’observer les réponses retournées (étiquette prédite ou score de confiance).
  • Deux grandes approches existent. Les attaques basées sur les scores ou l’attaquant utilise les scores de confiance (logits) pour créer des exemples adversariaux via des techniques d’optimisation (ex. : zeroth-order optimization, random walks) et les attaques basées sur les décisions : plus restrictif, l’attaquant n’a accès qu’à la classe prédite finale. Il cherche alors la frontière de décision à partir d’exemples modifiés par petits pas (ex. : HopSkipJumpAttack, Sign-OPT).
  • Ces attaques sont réalistes et puissantes, notamment contre les modèles accessibles en ligne via des services MLaaS (Machine Learning as a Service), tout en nécessitant peu de requêtes (< 1000 dans les attaques modernes).
  • Elles représentent une menace sérieuse pour l’intégrité des systèmes IA exposés via API. 

Model Poisoning (Empoisonnement de modèle – ID : NISTAML.026)

  • Attaque identique à l’attaque sur la disponibilité (NISTAML.011) vue précédemment mais qui concerne ici l’intégrité du modèle.

 

Attaques sur la confidentialité 

Model Extraction (Extraction de modèle – ID : NISTAML.031)

  • Attaque dans laquelle un adversaire tente de reconstruire un modèle d’apprentissage automatique à partir d’un simple accès par requêtes, comme une API.
  • Elle cible principalement les services MLaaS (Machine Learning as a Service) dans lesquels le modèle est hébergé par un tiers (OpenAI, AWS, Hugging Face, etc.).
  • Plutôt que de voler les poids exacts (ce qui reste très difficile), l’attaquant cherche à créer un modèle fonctionnellement équivalent qui imite le comportement du modèle cible, parfois avec une performance proche sur les mêmes tâches.
  • L’objectif est de créer un clone fonctionnel du modèle cible, capable de produire des résultats similaires sans avoir accès à son code ou à ses paramètres internes. Cette attaque peut entraîner la fuite de propriété intellectuelle, faciliter des attaques ultérieures (comme l’inversion ou le jailbreak), ou encore court-circuiter la monétisation d’un modèle commercial. 

Reconstruction (Reconstruction – ID : NISTAML.032)

  • Attaque qui consiste à déduire ou reconstituer des exemples de données d’entraînement à partir des informations disponibles en sortie d’un modèle ou via son paramétrage interne.
  • L’attaquant peut exploiter des statistiques agrégées, des scores de sortie, ou encore les poids du modèle pour inférer les caractéristiques exactes de certains exemples d’apprentissage.
  • Cette menace repose en partie sur le fait que certains modèles, notamment les réseaux de neurones profonds, ont tendance à mémoriser leurs données d’entraînement.
  • Elle représente une violation de la vie privée, en particulier lorsque les données d’origine contiennent des informations sensibles (identité, santé, biométrie…).
  • Ces attaques peuvent être réalisées même dans un contexte de respect apparent de la confidentialité, rendant la fuite de données plausible même sans accès direct aux jeux d’entraînement. 

Membership Inference (Inférence d’appartenance – ID : NISTAML.033)

  • Attaque qui vise à déterminer si une donnée particulière faisait ou non partie du jeu d’entraînement d’un modèle d’IA.
  • L’attaquant interroge le modèle avec un exemple ciblé, puis analyse sa réponse (précision, confiance, probabilité) pour en déduire s’il a été « vu » pendant l’entraînement.
  • Cette attaque repose sur le fait que les modèles ont souvent tendance à répondre différemment à des données familières, avec une confiance plus élevée ou des temps de traitement distincts.
  • Elle est particulièrement préoccupante dans les domaines où les données sont sensibles ou confidentielles (médical, juridique, données clients), car elle permet de révéler indirectement la présence d’individus dans un jeu de données. Même sans accéder aux poids du modèle, cette technique peut compromettre la confidentialité d’un système IA exposé publiquement. 

Property Inference (Inférence de propriété – ID : NISTAML.034)

  • Attaque qui vise à découvrir des propriétés globales ou statistiques du jeu de données d’entraînement d’un modèle, même lorsque ces informations ne sont ni visibles, ni explicitement exposées.
  • Contrairement à l’inférence d’appartenance, qui cible un exemple précis, cette attaque cherche à identifier si certains attributs sont présents de manière dominante dans les données apprises (ex. : proportion de documents d’un certain type, présence de vocabulaire politique, d’un accent régional, etc.).
  • L’attaquant analyse les réponses du modèle à des entrées soigneusement choisies pour extraire des tendances cachées.
  • Cette technique peut être utilisée pour cartographier le contenu confidentiel d’un jeu de données, ou pour détecter des biais potentiels.
  • Elle constitue une menace pour la confidentialité des jeux d’entraînement et peut également affecter la réputation de l’organisation si elle révèle des données sensibles ou non représentatives.

Attaques via la supply chain 

Model Poisoning (Empoisonnement de modèle – ID : NISTAML.051)

  • Attaque menée via la chaîne d’approvisionnement IA, où un modèle préentraîné est volontairement altéré avant d’être partagé ou intégré dans un système aval.
  • L’attaquant publie un modèle déjà compromis, par exemple avec un comportement dégradé, un biais caché ou une porte dérobée, dans l’objectif qu’il soit repris en toute confiance par d’autres acteurs.
  • Ce type d’attaque est particulièrement préoccupant car les modifications peuvent survivre à des étapes ultérieures de fine-tuning, et le modèle peut sembler fonctionner normalement dans la majorité des cas. Cette menace cible notamment les modèles partagés en open source, sur des plateformes comme Hugging Face, mais peut aussi viser des dépendances distribuées via des écosystèmes ML courants.
  • L’impact potentiel inclut la compromission de la fiabilité du modèle, la violation de l’intégrité du système final, et l’introduction silencieuse de comportements malveillants en production.

Conclusion

La taxonomie du NIST offre un cadre indispensable pour comprendre, structurer et maîtriser les risques liés à l’IA prédictive. En classifiant clairement chaque type d’attaque, elle permet aux organisations d’aborder la sécurité des modèles avec un langage commun et une vision unifiée, facilitant la collaboration entre équipes techniques, métiers, juridiques et dirigeantes. Cette normalisation rend possible une évaluation rigoureuse des menaces, une priorisation efficace des risques et une mise en conformité cohérente avec les référentiels émergents comme l’AI Act ou l’ISO 42001. Elle fournit également une base solide pour concevoir des tests de robustesse, mener des audits, simuler des scénarios adversariaux et renforcer la résilience des systèmes tout au long de leur cycle de vie. En d’autres termes, cette taxonomie transforme un paysage jusque-là fragmenté en un cadre clair, opérationnel et actionnable, essentiel pour sécuriser durablement l’usage de l’IA en entreprise. Et pour compléter cette analyse, nous publierons prochainement un second article dédié à la taxonomie des attaques sur l’IA générative et les propositions du NIST pour atténuer les risques.