MITRE ATLAS

Définition

MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) est une base de connaissances publique répertoriant les tactiques, techniques et études de cas d'adversaires observées contre les systèmes basés sur l'IA. Elle est structurée selon le modèle MITRE ATT&CK afin que les attaques spécifiques à l'IA puissent être décrites dans les mêmes termes que le reste du renseignement sur les menaces de l'organisation.

Portée

Toute organisation qui conçoit, déploie ou défend des systèmes basés sur l'IA, et toute équipe de sécurité qui maîtrise déjà ATT&CK. Il s'agit d'une base de connaissances et non d'une norme : elle ne donne lieu à aucune certification et ne prescrit aucun contrôle — elle décrit les actions des adversaires afin que les défenseurs puissent décider quoi détecter et prévenir.

Exigences clés

• Structuré sous forme de tactiques (l'objectif de l'adversaire) et de techniques (la manière d'y parvenir), reflétant délibérément MITRE ATT&CK pour que les attaques d'IA s'intègrent dans les modèles de menaces existants plutôt que de s'ajouter à côté.
• Il couvre l'ensemble du cycle d'intrusion — reconnaissance, accès au modèle, exécution, persistance, contournement des défenses, découverte, collecte, exfiltration, impact — avec des étapes spécifiques à l'IA comme la préparation d'une attaque contre un modèle.
• Il est basé sur des preuves : les entrées s'appuient sur des incidents documentés et des exercices de red-teaming, ce qui le distingue d'une simple liste de problèmes théoriques.
• Il complète OWASP plutôt que de le concurrencer. OWASP classifie les faiblesses de votre conception ; ATLAS décrit le comportement de l'adversaire qui les exploite.
• Sa valeur pratique réside dans la détection et le red-teaming : une technique est à la fois une action que vous pouvez tester contre votre propre système et un signal que vous pouvez rechercher dans vos journaux.
• La matrice est mise à jour et enrichie à mesure que de nouvelles attaques sont documentées, ce qui en fait une référence vivante et non une liste de contrôle figée.

Contrôles

Cartographier votre pile d'agents sur la matrice

Parcourez les tactiques au regard de votre propre architecture et identifiez les techniques accessibles. C'est l'accessibilité, et non la plausibilité, qui détermine si une technique mérite d'être contrée.

Transformer les techniques accessibles en détections

Pour chacune d'elles, identifiez le signal qui la révélerait dans votre télémétrie. Une technique sans signal correspondant est une technique que vous avez choisi d'ignorer.

L'utiliser comme backlog de red-team

Les techniques sont testables par définition. Exécutez-les contre votre propre système et considérez le résultat « impossible à reproduire » comme une information digne d'être enregistrée, et non comme une absence de travail.

Utiliser le langage ATT&CK là où l'organisation l'emploie déjà

Rapportez les vulnérabilités d'IA selon la terminologie ATLAS afin qu'elles intègrent les mêmes processus de renseignement, de tri et de réponse que le reste. L'introduction d'un nouveau vocabulaire est le meilleur moyen pour que le risque lié à l'IA ne soit géré par personne.

Lire les études de cas, pas seulement la matrice

Les études de cas contiennent les détails opérationnels — comment l'accès a été obtenu, ce que l'adversaire a fait ensuite — qui sont transposables à votre propre environnement.

Réintégrer les données dans le modèle de menaces

ATLAS constitue l'apport externe d'un modèle de menaces basé sur des agents ; c'est au sein de ce modèle que ses techniques se traduisent en surfaces d'attaque sous votre responsabilité, associées à des contrôles et des responsables.

Liste de contrôle

• 01Identifier quelles tactiques ATLAS sont effectivement accessibles au sein de votre architecture.
• 02Pour chaque technique accessible, enregistrer le contrôle qui la limite et le signal qui la détecte.
• 03En l'absence de détection, mentionnez-le explicitement plutôt que de laisser la ligne vide.
• 04Planifier des exercices de red-teaming basés sur la matrice, et constater l'échec ou la réussite de chaque tentative avant de revendiquer une couverture.
• 05Rapporter les résultats en utilisant les identifiants ATLAS afin qu'ils s'intègrent au flux de renseignement existant de l'organisation.
• 06Examiner périodiquement la matrice, car de nouvelles techniques sont documentées au fur et à mesure de leur observation.
• 07Établir des correspondances avec le Top 10 OWASP pour les LLM afin de lier les faiblesses aux comportements des adversaires, plutôt que de les suivre séparément.

Pièges courants

• Le traiter comme une liste de contrôle de conformité. Rien ne certifie la conformité à ATLAS, et « nous avons examiné la matrice » ne constitue pas un contrôle.
• Cartographier chaque technique sans tenir compte de son accessibilité, ce qui produit un document volumineux sans priorités.
• Maintenir le renseignement sur les menaces d'IA dans un processus distinct de celui existant dans l'organisation — précisément ce que l'alignement avec ATT&CK cherche à éviter.
• Lire la matrice en ignorant les études de cas, alors que c'est là que résident les détails opérationnels transposables.
• Présumer d'une couverture sans test préalable. Une technique que vous n'avez jamais tentée contre votre propre système reste une simple hypothèse.

Exemples

• Une équipe cartographie son agent de retrieval sur ATLAS et constate que l'accès au modèle est trivial (le point de terminaison est public), la préparation est peu coûteuse (n'importe quel éditeur de wiki peut injecter du contenu) et l'exfiltration ne fait l'objet d'aucun contrôle (les flux sortants sont illimités). Trois techniques, dont une seule les préoccupait déjà.
• Une organisation de sécurité qui pratique déjà l'ingénierie de détection basée sur ATT&CK ajoute les techniques ATLAS au même backlog, de sorte que les détections spécifiques à l'IA soient conçues, révisées et gérées en astreinte par l'équipe dédiée à cette tâche.
• Une équipe de red-teaming utilise la matrice comme liste de cibles pour l'évaluation d'un agent, et transmet ses résultats avec les identifiants ATLAS — ce qui permet aux personnes n'ayant jamais travaillé sur un agent de trier les vulnérabilités.

FAQ

ATLAS remplace-t-il ATT&CK ?

Non, c'est un complément. ATT&CK couvre les comportements conventionnels des adversaires ; ATLAS couvre les étapes spécifiques à l'IA, délibérément structurées de la même manière afin qu'une attaque commençant par un e-mail de phishing et se terminant sur un modèle puisse être décrite de bout en bout.

Ai-je besoin d'ATLAS si je suis déjà le Top 10 OWASP pour les LLM ?

Ils répondent à des objectifs différents et leur association est essentielle. OWASP vous indique la classe de faiblesse présente ; ATLAS vous décrit ce qu'un adversaire en fait, ce qui est indispensable pour la détection et le red-teaming.

Quelle est sa place au sein d'une petite équipe ?

D'abord comme backlog de red-team. Même sans programme de détection, la matrice fournit une liste prioritaire d'attaques à tester contre votre propre système — et ces tests constituent le moyen le plus économique de découvrir quels contrôles n'existent que sur le papier.

Références

• MITRE ATLAS — Adversarial Threat Landscape for AI Systems
• OWASP — Top 10 for LLM Applications
• NIST — AI Risk Management Framework (AI RMF 1.0)

Gouvernance connexe