GOV-009FrameworkAktualisiert 2026-08-22 · Version 1.0

MITRE ATLAS

MITRE ATLAS ist die gegnerische Seite der Landkarte. Während OWASP die Schwachstellenklassen in Ihrer Anwendung benennt, katalogisiert ATLAS die Taktiken und Techniken, die Angreifer tatsächlich gegen KI-gestützte Systeme einsetzen – Aufklärung eines Modells, Erlangung von Zugriff, Vorbereitung eines Angriffs, Umgehen von Abwehrmechanismen, Exfiltration von Daten – organisiert auf dieselbe Weise, wie MITRE ATT&CK konventionelle Einbrüche strukturiert, und gestützt auf dokumentierte Fallstudien statt auf Hypothesen.

Evidenz: BranchenbeobachtungKonfidenz: HochQuelle: PaperQuelle: Branchenbeobachtung
MITRE ATLASMITRE ATT&CKOWASP GenAI Security ProjectNIST AI RMF

Definition

MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) ist eine öffentlich zugängliche Wissensdatenbank für Taktiken, Techniken und Fallstudien von Angreifern, die bei KI-gestützten Systemen beobachtet wurden. Sie ist nach dem Vorbild von MITRE ATT&CK strukturiert, sodass KI-spezifische Angriffe mit denselben Begriffen beschrieben werden können wie die übrige Threat Intelligence einer Organisation.

Anwendungsbereich

Jede Organisation, die KI-gestützte Systeme entwickelt, bereitstellt oder verteidigt, und jedes Sicherheitsteam, das bereits mit ATT&CK arbeitet. Es handelt sich um eine Wissensdatenbank, nicht um einen Standard: Es gibt keine Zertifizierung danach und es werden keine Kontrollen vorgeschrieben – es beschreibt, was Angreifer tun, damit Verteidiger entscheiden können, was sie erkennen und verhindern wollen.

Kernanforderungen

  • Strukturiert in Taktiken (das Ziel des Angreifers) und Techniken (wie es erreicht wird), wobei MITRE ATT&CK bewusst gespiegelt wird, damit sich KI-Angriffe in bestehende Bedrohungsmodelle einfügen, anstatt isoliert daneben zu stehen.
  • Es deckt den gesamten Verlauf eines Einbruchs ab – Aufklärung, Zugriff auf das Modell, Ausführung, Persistenz, Umgehung der Verteidigung, Entdeckung, Erfassung, Exfiltration, Auswirkungen – einschließlich KI-spezifischer Phasen wie der Vorbereitung eines Angriffs auf ein Modell.
  • Es ist evidenzbasiert: Die Einträge stützen sich auf dokumentierte Vorfälle und Red-Teaming-Übungen, was es von einer bloßen Liste theoretisch möglicher Probleme unterscheidet.
  • Es ergänzt OWASP, anstatt damit zu konkurrieren. OWASP klassifiziert Schwachstellen in Ihrem Design; ATLAS beschreibt das Verhalten von Angreifern, die diese ausnutzen.
  • Sein praktischer Nutzen liegt in der Erkennung und im Red-Teaming: Eine Technik ist etwas, das Sie an Ihrem eigenen System ausprobieren und in Ihren Protokollen suchen können.
  • Die Matrix wird gepflegt und erweitert, sobald neue Angriffe dokumentiert werden. Sie ist somit eine lebendige Referenz und keine starre Checkliste.

Kontrollen

Ordnen Sie Ihren Agenten-Stack der Matrix zu
Gehen Sie die Taktiken anhand Ihrer eigenen Architektur durch und markieren Sie, welche Techniken erreichbar sind. Die Erreichbarkeit, nicht die Plausibilität, macht eine Technik verteidigungswürdig.
Erreichbare Techniken in Erkennungsmechanismen umwandeln
Benennen Sie für jede Technik das Signal, das sie in Ihrer Telemetrie anzeigen würde. Eine Technik ohne entsprechendes Signal ist eine, die Sie bewusst ignorieren.
Nutzen Sie es als Red-Team-Backlog
Techniken sind von Natur aus testbar. Führen Sie sie gegen Ihr eigenes System aus und betrachten Sie 'konnten wir nicht reproduzieren' als ein aufzeichnungswürdiges Ergebnis, nicht als mangelnde Arbeit.
Sprechen Sie ATT&CK, wo die Organisation es bereits tut
Melden Sie KI-Ergebnisse in ATLAS-Begriffen, damit sie in dieselben Analyse-, Triage- und Reaktionsprozesse einfließen wie alles andere. Ein neuartiges Vokabular führt nur dazu, dass sich am Ende niemand für das KI-Risiko verantwortlich fühlt.
Lesen Sie die Fallstudien, nicht nur die Matrix
Die Fallstudien enthalten die operativen Details – wie der Zugriff erlangt wurde, was der Angreifer als Nächstes tat –, also genau den Teil, der sich auf Ihre eigene Umgebung übertragen lässt.
Führen Sie es in das Bedrohungsmodell zurück
ATLAS ist der externe Input für ein agentenbasiertes Bedrohungsmodell; im Bedrohungsmodell werden seine Techniken zu Angriffsflächen in Ihrem Besitz, denen Kontrollen und Verantwortliche zugeordnet sind.

Checkliste

  • 01Identifizieren Sie, welche ATLAS-Taktiken in Ihrer Architektur überhaupt erreichbar sind.
  • 02Erfassen Sie für jede erreichbare Technik die Kontrollmaßnahme, die sie eingrenzt, und das Signal, das sie erkennt.
  • 03Wenn keine Erkennung vorhanden ist, geben Sie dies explizit an, anstatt die Zeile leer zu lassen.
  • 04Planen Sie Red-Teaming-Übungen auf Basis der Matrix und prüfen Sie, ob jeder Versuch fehlschlägt oder erfolgreich ist, bevor Sie eine Abdeckung beanspruchen.
  • 05Melden Sie Ergebnisse unter Verwendung von ATLAS-Identifikatoren, damit sie in den bestehenden Informationsfluss der Organisation einfließen.
  • 06Überprüfen Sie die Matrix regelmäßig, da neue Techniken dokumentiert werden, sobald sie beobachtet werden.
  • 07Verknüpfen Sie die Ergebnisse mit den OWASP LLM Top 10, damit Schwachstellen und Angreiferverhalten einander zugeordnet und nicht separat nachverfolgt werden.

Typische Fallstricke

  • Es als Compliance-Checkliste zu behandeln. Es gibt keine Zertifizierung nach ATLAS, und 'Wir haben die Matrix überprüft' ist keine Kontrollmaßnahme.
  • Jede Technik unabhängig von ihrer Erreichbarkeit zuzuordnen, was zu einem umfangreichen Dokument ohne Prioritäten führt.
  • Die KI-Bedrohungsanalyse in einem separaten Prozess von den bestehenden Prozessen der Organisation zu halten – genau das Ergebnis, das durch die Ausrichtung an ATT&CK verhindert werden soll.
  • Die Matrix zu lesen und die Fallstudien zu überspringen, in denen die übertragbaren operativen Details enthalten sind.
  • Eine Abdeckung ohne Tests anzunehmen. Eine Technik, die Sie noch nie an Ihrem eigenen System ausprobiert haben, ist eine Technik, zu der Sie lediglich eine Meinung haben.

Beispiele

  • Ein Team ordnet seinen Retrieval-Agenten ATLAS zu und stellt fest, dass der Modellzugriff trivial ist (der Endpunkt ist öffentlich), die Vorbereitung kostengünstig ist (jeder Wiki-Editor kann Inhalte einschleusen) und die Exfiltration unkontrolliert erfolgt (der ausgehende Datenverkehr ist unbeschränkt). Drei Techniken, von denen sie sich um eine bereits Sorgen gemacht haben.
  • Eine Sicherheitsorganisation, die bereits ATT&CK-basiertes Detection Engineering betreibt, fügt ATLAS-Techniken demselben Backlog hinzu, sodass KI-spezifische Erkennungen von dem Team erstellt, überprüft und im Bereitschaftsdienst betreut werden, das diese Arbeit ohnehin erledigt.
  • Ein Red Team nutzt die Matrix als Zielliste für eine Agenten-Bewertung und meldet die Ergebnisse unter Verwendung von ATLAS-Identifikatoren zurück – was es Personen, die noch nie an einem Agenten gearbeitet haben, ermöglicht, die Ergebnisse zu triagieren.

FAQs

Ist ATLAS ein Ersatz für ATT&CK?
Nein, es ist eine Ergänzung. ATT&CK deckt konventionelles Angreiferverhalten ab; ATLAS deckt die KI-spezifischen Phasen ab, bewusst auf dieselbe Weise strukturiert, sodass ein Angriff, der mit einer Phishing-E-Mail beginnt und bei einem Modell endet, durchgängig beschrieben werden kann.
Benötige ich ATLAS, wenn ich bereits die OWASP LLM Top 10 befolge?
Sie dienen unterschiedlichen Zwecken, und die Kombination ist der entscheidende Punkt. OWASP sagt Ihnen, welche Klasse von Schwachstelle Sie haben; ATLAS sagt Ihnen, was ein Angreifer damit macht – und genau das ist es, was für Erkennung und Red-Teaming benötigt wird.
Wo lässt es sich in einem kleinen Team einsetzen?
In erster Linie als Red-Team-Backlog. Selbst ohne ein Erkennungsprogramm bietet die Matrix eine priorisierte Liste von Angriffen, die Sie an Ihrem eigenen System ausprobieren können – und diese Versuche sind der günstigste Weg, um herauszufinden, welche Ihrer Kontrollmaßnahmen nur auf dem Papier existieren.

Referenzen