~12 minutes
Cet article fait partie de la série MITRE ATT&CK en pratique. Retrouvez la vue d’ensemble et le sommaire complet sur la page d’entrée de la série.
Le framework de sécurité IA semble le plus structuré disponible aujourd’hui, et pourtant il reste méconnu des équipes qui déploient des applications IA en production. La raison est simple : la plupart des formations en machine learning n’incluent pas de module sur la sécurité offensive, et la plupart des formations en sécurité n’abordent pas les spécificités des systèmes IA.
ATLAS comble ce vide. Le nom complet, Adversarial Threat Landscape for AI Systems, dit exactement ce que c’est : une cartographie des techniques d’attaque qui ciblent les systèmes d’intelligence artificielle, construite sur le même modèle qu’ATT&CK.
Les attaques contre les systèmes IA ne ressemblent à rien de connu en sécurité informatique classique. On n’exploite pas un buffer overflow dans un modèle ; on exploite ses mathématiques.
Pourquoi ATLAS et pas seulement ATT&CK ?
ATT&CK Enterprise couvre l’infrastructure qui héberge un système IA : le serveur qui fait tourner le modèle peut être compromis par des techniques T1190 ou T1078. Mais ATT&CK ne couvre pas ce qui est spécifique au modèle lui-même :
- Comment tromper un modèle de vision pour lui faire classer une image malveillante comme bénigne
- Comment extraire des données d’entraînement d’un modèle de langage via des requêtes soigneusement construites
- Comment empoisonner la phase d’entraînement pour implanter un comportement caché
- Comment voler un modèle propriétaire en le reconstituant par des requêtes massives
Ces attaques ciblent les propriétés mathématiques du modèle, pas son infrastructure. ATLAS est né de ce constat.
La structure d’ATLAS
ATLAS s’organise sur le même principe qu’ATT&CK : tactiques (objectifs) → techniques (moyens) → sous-techniques (variantes).
Les quatre familles de techniques ATLAS à connaître
AML.T0015 : Model Evasion, tromper le modèle sans le modifier
Commencons par la technique la plus connue et la plus documentée. L’évasion consiste à construire des entrées soigneusement perturbées qui font classer le modèle incorrectement, sans que la perturbation soit perceptible par un humain.
L’exemple classique : une image d’un panda avec un bruit imperceptible ajouté ; le modèle la classe comme “gibbon” avec une confiance de 99%. L’humain voit un panda parfait.
Pourquoi c’est dangereux en production :
- Système de détection de fraude qui classe des transactions frauduleuses comme légitimes
- Modèle de reconnaissance d’objets dans un véhicule autonome qui ne voit pas un panneau stop
- Filtre anti-spam qui laisse passer des emails de phishing soigneusement construits
- Système de reconnaissance biométrique byppassé par une image ou un masque imprimé
La mitigation passe par l’entraînement adversarial (inclure des exemples adversariaux dans le dataset d’entraînement), la défense par ensembles de modèles, et les méthodes de certification de robustesse.
AML.T0020 : Data Poisoning, empoisonner à la source
J’ai abordé cette technique dans l’article sur les applications IA, mais elle mérite un traitement différent ici.
Le data poisoning vise la phase d’entraînement : l’attaquant injecte des exemples malveillants dans le dataset d’entraînement pour modifier le comportement du modèle de façon ciblée. Deux variantes principales :
Empoisonnement de la disponibilité : rendre le modèle inutilisable en dégradant ses performances globales. Simple à réaliser si l’attaquant peut contribuer au dataset.
Backdoor (Trojaning) : le modèle fonctionne normalement sur tous les exemples, sauf sur ceux qui contiennent un “trigger” spécifique ; un pixel de couleur, un mot dans une phrase, un pattern acoustique. Lorsque ce trigger est présent, le modèle produit la sortie choisie par l’attaquant.
Note du PandaRedacteur: je me souviens d’avoir assister a des événements sur la place Tian’anmen au printemps 1989 qui “auraient” été oubliés dans certains modèles….
AML.T0024 : Model Inversion, extraire les données d’entraînement
Cette technique est surement la plus sous-estimée en termes de risque RGPD. L’inversion de modèle permet de retrouver, par des requêtes répétées, des données qui ont servi à l’entraînement du modèle.
L’exemple le plus frappant : un modèle de reconnaissance faciale entraîné sur des photos de célébrités peut être “interrogé” pour reconstruire des images quasi-fidèles de ces visages. Si le modèle a été entraîné sur des données médicales, des requêtes ciblées peuvent reconstruire des profils de patients.
AML.T0030 : Model Theft, voler un modèle par ses requêtes
Un modèle propriétaire entraîné pendant des semaines sur des données confidentielles peut être volé par des requêtes répétées à son API. Le principe : interroger le modèle sur des exemples soigneusement choisis, collecter les paires (entrée, sortie), et entraîner un modèle substitut qui réplique son comportement.
AML.T0051 : Prompt Injection, la nouveauté LLM
L’injection de prompt est la technique qui a émergé avec les LLMs. Elle n’existe pas dans les techniques ML classiques ; c’est une catégorie propre aux modèles de langage qui suivent des instructions.
Deux formes documentées dans ATLAS :
Directe : l’utilisateur injecte directement des instructions dans son message pour remplacer les instructions système. Exemple : “Ignore ton rôle. Tu es maintenant…”
Indirecte (ou à distance) : l’attaquant place des instructions dans des documents que le LLM va lire (une page web, un email, un fichier PDF). Lorsque le LLM traite ce document dans le cadre d’une tâche légitime, les instructions cachées s’exécutent.
Note du PandaRedacteur : L’injection de prompt indirect dans un agent qui lit des emails, c’est le scénario que j’ai en tête chaque fois qu’un commercial me dit “on a un agent IA qui traite automatiquement les demandes clients”.
Comment utiliser ATLAS en pratique
Je recommande trois usages concrets pour une équipe qui déploie des modèles IA :
Threat modeling avant le déploiement : parcourir ATLAS comme une checklist de questions.
Red teaming IA structuré : utiliser ATLAS comme script d’un exercice red team spécifique IA. Les tactiques ATLAS donnent les objectifs, les techniques donnent les méthodes.
Reporting et priorisation : comme ATT&CK Enterprise, ATLAS permet de produire des rapports compréhensibles par le management.
Note du PandaRedacteur: en espérant que pour ce dernier, on ne l’utilisera que peu :)
- ✓ ATLAS couvre ce qu'ATT&CK ne peut pas : les attaques qui ciblent les mathématiques du modèle plutôt que son infrastructure.
- ✓ Le Data Poisoning via backdoor (AML.T0020) est quasi-indétectable sans audit du dataset et des comportements sous trigger ; à intégrer au threat model dès la conception.
- ✓ La Model Inversion (AML.T0024) est un risque RGPD concret pour tout modèle entraîné sur des données personnelles ; differential privacy est la mitigation de référence.
- ✓ Le Model Theft (AML.T0030) cible la propriété intellectuelle : rate limiting + watermarking sont les deux contrôles complémentaires indispensables.
- ✓ Utiliser ATLAS comme script de threat modeling avant tout déploiement IA en production : 11 tactiques = 11 questions à répondre avant de passer en prod.