STRIDE, MITRE ATLAS und OWASP: ein wiederholbarer Workflow für KI-Bedrohungsmodellierung

In meinen bisherigen Beiträgen habe ich einzelne Angriffe und eine Landkarte der LLM-Bedrohungen beschrieben. Was bisher fehlte, war der Prozess, der alles zusammenhält: Wie geht man systematisch an ein konkretes KI-System heran und kommt zu einer priorisierten Risikoaussage? Genau das liefert dieser Raum — einen wiederholbaren Threat-Modeling-Workflow, der drei etablierte Frameworks zu einer einzigen Bewertung zusammenführt: STRIDE, MITRE ATLAS und die OWASP LLM Top 10.

Warum klassisches Threat Modeling für KI nicht reicht

Ein KI-System ist keine normale Anwendung mit einem Modell obendrauf. Es bringt eigene Assets mit, die die Angriffsfläche erweitern — Trainingsdaten, Modellgewichte, Embeddings, System-Prompts, Feature Stores und Model Registries. Es hat eine eigene Daten-Lieferkette, die von der Datenerhebung über das Training bis zur Inferenz reicht. Und es hat Fehlerquellen, die klassische Werkzeuge schlicht nicht sehen. Wer ein KI-System wie eine Web-App modelliert, übersieht genau die Stellen, an denen es gefährlich wird.

Eine wichtige Erkenntnis aus der Lieferketten-Betrachtung: Der Injection-Punkt ist nicht der Impact-Punkt. Vergiftete Daten werden bei der Erhebung eingeschleust — sichtbar wird der Schaden erst viel später im Verhalten des fertig trainierten Modells. Wer nur auf das auffällige Symptom schaut, sucht an der falschen Stelle nach der Ursache.

Drei Frameworks, drei Zoomstufen

Der Kern des Workflows: STRIDE, ATLAS und OWASP sind keine konkurrierenden Frameworks, sondern Ebenen derselben Bewertung. Jedes beantwortet eine andere Frage.

• STRIDE-AI — welche Art von Bedrohung? Die sechs vertrauten Kategorien (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) liefern die Weitwinkel-Aufnahme. Mit KI-Kontext gefüllt heißt das z. B.: Data Poisoning fällt unter Tampering, das Aushebeln der Schutzregeln (Jailbreaking) unter Elevation of Privilege.
• MITRE ATLAS — wie genau führt der Angreifer das aus? ATLAS ist der KI-spezifische Technik-Katalog. Er bringt die grobe Kategorie auf den Boden konkreter, dokumentierter Angriffstechniken — mit Technik-IDs, realen Fallstudien und passenden Mitigations.
• OWASP LLM Top 10 — wo sitzt das Risiko und wie kritisch? Die OWASP-Liste ist die eigentliche Bewertungs-Linse: Sie ordnet jedes Risiko einer Komponente im Architekturdiagramm zu. Damit wird aus einer Liste ein praxistaugliches Werkzeug.

Der Merksatz, der bei mir hängengeblieben ist: STRIDE gibt dir den Weitwinkel, ATLAS die technischen Details — und OWASP sagt dir, wohin du die Kamera richten musst.

Die OWASP-Tabelle als Bewertungswerkzeug — in zwei Richtungen

Das Stärkste an der OWASP LLM Top 10 ist, dass man sie in beide Richtungen lesen kann:

• Risiko → Komponente: „Prompt Injection — wo sitzt die?" Antwort: primär am Inferenz-Endpunkt (direkt über die Nutzereingabe) und in der RAG-/Vektor-Pipeline (indirekt über abgerufene Inhalte). Das sind die Stellen, die Eingabevalidierung und Prompt-Grenzüberwachung brauchen.
• Komponente → Risiko: „Wir führen eine Vektordatenbank für RAG ein — welche Risiken erbt sie?" Antwort durch einen Blick in die Spalte: LLM01 (indirekte Injection), LLM08 (Embedding-Schwächen) und LLM09 (Fehlinformation aus veralteten Quellen).

Diese zweite Richtung ist es, die den Unterschied macht: Sobald eine Organisation eine neue Komponente in ihr KI-System einbaut, lässt sich sofort ablesen, welche OWASP-Risiken sie mitbringt. Wie man die Architektur dahinter absichert, habe ich in „Ein KI-System absichern heißt die Architektur absichern" ausgeführt.

Komponenten mit der höchsten Risikodichte

Wendet man das auf eine typische KI-Architektur an, kristallisieren sich drei Brennpunkte heraus:

• Der LLM-Inferenz-Endpunkt trägt die höchste Risikokonzentration — er taucht in sieben von zehn OWASP-Einträgen auf (LLM01, LLM02, LLM05, LLM06, LLM07, LLM09, LLM10). Diese Komponente braucht die umfassendsten Schutzmaßnahmen.
• Die Vektordatenbank / RAG-Pipeline erscheint in drei Einträgen (LLM01 indirekt, LLM08, LLM09). Härtung: Eingabevalidierung für indizierte Inhalte, Zugriffskontrolle auf den Vektorspeicher, Aktualitätsüberwachung der Quelldokumente.
• Die Trainings-Pipeline ist der Hauptangriffspunkt der Daten- und Modell-Lieferkette (LLM03) und taucht zusätzlich in LLM02 und LLM04 auf. Hier gelangen Modelle und Datensätze Dritter am direktesten ins System.

Die gefährlichste Kombination: LLM01 + LLM06

Eine Lehre, die sich durch den ganzen Workflow zieht: Risiken wirken nicht isoliert. Prompt Injection (LLM01) für sich erzeugt eine falsche Antwort. Kombiniert mit Excessive Agency (LLM06) — also einem Modell, das Werkzeuge, Datenbankzugriff oder Mailversand bedienen darf — wird daraus eine echte Handlung: Daten löschen, Überweisungen auslösen, Mails verschicken. Aus „die KI sagt etwas Falsches" wird „die KI tut etwas Falsches". Genau hier liegt das größte Risiko agentischer KI-Systeme. Warum die fehlende Trennung zwischen System- und Nutzereingabe Prompt Injection überhaupt erst möglich macht, habe ich in „Prompt Injection erklärt" aufgedröselt.

Der Workflow in der Praxis

Zusammengesetzt ergibt sich ein klarer, wiederholbarer Ablauf:

1. Assets identifizieren — die KI-spezifischen Werte und damit die erweiterte Angriffsfläche.
2. Daten-Lieferkette abbilden — wo Daten von der Erhebung bis zur Inferenz fließen und kompromittiert werden können.
3. STRIDE-AI anwenden — die sechs Bedrohungskategorien mit KI-Kontext.
4. Mit MITRE ATLAS anreichern — von der Kategorie zur dokumentierten Technik samt Mitigation.
5. Mit OWASP auf Komponenten mappen — Risiken verorten und nach Schwere priorisieren.
6. Priorisierte Bewertung erstellen — alles auf ein konkretes System anwenden.

Das Entscheidende: Dieser Prozess ist wiederholbar. Bei jedem neuen KI-System, jedem Modell-Update, jeder neuen agentischen Fähigkeit läuft dieselbe Methodik ab. Die Frameworks entwickeln sich weiter — ATLAS bekommt neue Techniken, OWASP aktualisiert seine Liste — aber die Vorgehensweise bleibt konstant. Wie sich diese Ebenen in einem echten Vorfall verzahnen, habe ich im Fall West Tech durchgespielt.

Mein Fazit

Was ich aus diesem Raum mitnehme, ist kein einzelner Angriff, sondern eine Arbeitsweise. STRIDE liefert das Vokabular, ATLAS die Technik, OWASP die Verortung — und zusammen verwandeln sie ein Architekturdiagramm in eine konkrete Aussage: „Diese Komponente trägt diese Risiken, in dieser Schwere." Genau diese Fähigkeit unterscheidet eine fundierte Bedrohungsanalyse von einer abgehakten Checkliste — und sie ist die Grundlage dafür, wie ich KI-Sicherheit in meinen Audits angehe.

▶ KI-System prüfen lassen Mehr aus dem Blog