OWASP, MITRE, NIST: drei Werkzeuge für KI-Sicherheit und ihre Reihenfolge
Drei große KI-Sicherheits-Frameworks wirken wie Konkurrenten. Sie sind es nicht: jedes beantwortet eine andere Frage. Die echte Wahl ist die Reihenfolge.
Jedes Unternehmen, das heute etwas mit KI baut, stößt früher oder später auf dieselbe Wand: einen Markt voller Sicherheits-Frameworks, die alle dasselbe zu tun scheinen. OWASP, MITRE, NIST. Drei angesehene Namen, drei Sammlungen von Empfehlungen, wie man künstliche Intelligenz absichert, und der naheliegende Reflex, sich für eines zu entscheiden und weiterzumachen. Genau dieser Reflex ist die Falle. Die drei wurden nie als Konkurrenten gebaut, und die Wahl zwischen ihnen ist die falsche Frage. Jedes ist für eine andere Aufgabe gemacht, und die Entscheidung, auf die es wirklich ankommt, ist die Reihenfolge, in der du sie einsetzt.
Alle drei drehen sich um dieselbe Art von Software: große Sprachmodelle, also die textproduzierenden Maschinen hinter Chatbots und KI-Assistenten, und die Anwendungen, die darauf aufsetzen. Über dieses gemeinsame Thema hinaus gehen sie aber komplett getrennte Wege.
Drei verschiedene Fragen
Am klarsten lassen sie sich auseinanderhalten, wenn man fragt, welche Frage jedes einzelne beantwortet.
OWASP beantwortet: Was kann in meiner KI-Anwendung schiefgehen, und wie behebe ich es. Es ist eine Prüfliste für die Leute, die den Code schreiben. MITRE ATLAS beantwortet: Wie würde ein echter Angreifer ein KI-System tatsächlich knacken. Es ist ein Katalog der Schritte, die Angreifer gehen. NIST beantwortet: Wie hält meine Organisation das KI-Risiko über die Zeit unter Kontrolle. Es ist ein Handbuch für die Verantwortlichen.
Eine Prüfliste, ein Angreifer-Handbuch und ein Steuerungs-Framework sind keine drei Varianten derselben Sache, genauso wenig wie eine Rechtschreibprüfung eine Brandschutzübung ersetzt. Sie sitzen auf unterschiedlichen Höhen über demselben System.
Sie überschneiden sich bei einer Handvoll Problemen, und genau das nährt den Reflex, sich einfach für eines zu entscheiden. Drei Themen tauchen immer wieder auf. Prompt Injection ist der Trick, neue Anweisungen in den Text zu schmuggeln, den eine KI liest, sodass sie ihre eigenen Regeln klammheimlich ignoriert. Data Poisoning heißt, manipulierte Beispiele in die Daten zu schleusen, aus denen ein Modell lernt, sodass es die falsche Lektion lernt. Supply-Chain-Risiko steht für die fremden Modelle, Bibliotheken und Datensätze, die ein Team wiederverwendet, statt sie selbst zu bauen. Jedes ernstzunehmende Framework berührt diese drei Punkte, weil niemand, der KI verteidigt, sie ignorieren kann, aber jedes behandelt sie auf einer anderen Ebene.
OWASP: die Prüfliste für Entwickler
Die OWASP Top 10 for LLM Applications sind genau das, was der Name verspricht: die zehn häufigsten Wege, auf denen eine KI-Anwendung kaputtgeht, jeder gepaart mit einer Gegenmaßnahme, die ein Entwickler sofort umsetzen kann. Die aktuelle Ausgabe trägt das Etikett 2025 und wurde Ende 2024 vom OWASP GenAI Security Project veröffentlicht, einer ehrenamtlichen Gemeinschaft von Sicherheitsfachleuten. Prompt Injection steht ganz oben auf der Liste, weil es nach wie vor der zuverlässigste Weg ist, eine KI aus der Spur zu bringen.
Der Rest der Liste liest sich wie der Sorgenzettel eines Entwicklers. Zwei der neueren Einträge zeigen, wo echte Systeme gerade brechen. Der eine ist das Durchsickern der eigenen versteckten Anweisungen einer Anwendung, also des internen Prompts, der dem Assistenten sagt, wie er sich verhalten soll. Der andere zielt auf den Dokumentenspeicher, den viele KI-Werkzeuge durchsuchen, bevor sie antworten: Vergiftet man diese Dokumente, vergiftet man die Antwort, ohne das Modell selbst je anzufassen.
Der für Nicht-Entwickler nützlichste Gedanke der Liste ist das, was OWASP excessive agency nennt, übermäßige Handlungsvollmacht. Die Warnung lautet: Gib einem KI-Assistenten nicht mehr Macht, als er braucht – Zugriff auf deine Dateien, deine Datenbank, die Fähigkeit, Nachrichten zu verschicken oder Befehle auszuführen. Je mehr ein Assistent tun kann, desto größer der Schaden, den ein einziger gelungener Trick anrichtet. Beschneide die Befugnisse, und du verkleinerst den möglichen Schadensbereich. Es ist dieselbe Logik der minimalen Rechtevergabe, die hinter der Zero-Trust-Architektur steht, angewandt auf ein Werkzeug, das improvisiert.
Steve Wilson, der das Projekt gegründet hat und das GenAI Security Project mitleitet, hat die Liste als praxisnahe Ressource beschrieben, die mit realen Vorfällen Schritt halten soll, und nicht als Compliance-Stempel, den man Prüfern entgegenhält. Darin liegt zugleich ihre Grenze. OWASP sagt dir, was du beheben musst und grob wie, aber nicht, wie ein vollständiger Angriff diese Schwachstellen aneinanderkettet, und auch nicht, ob deine Führung das verbleibende Risiko akzeptieren sollte.
Die OWASP Top 10 for LLM Applications, die Prüfliste der Wege, auf denen eine KI-Anwendung brechen kann.
MITRE ATLAS: das Handbuch des Angreifers
MITRE ATLAS ist die KI-Variante eines viel älteren und bekannteren Katalogs, MITREs ATT&CK, mit dem Sicherheitsteams untersuchen, wie sich Eindringlinge durch gewöhnliche Computernetze bewegen. ATLAS macht dasselbe für KI: Es legt die Schritte offen, die ein Angreifer gegen ein KI-System unternimmt, vom ersten Abtasten bis zum Diebstahl oder der Manipulation von Daten, alles auf reale Fälle gestützt. Wo OWASP auflistet, was schiefgehen kann, zeigt ATLAS, wie sich ein Angriff tatsächlich entfaltet, Schritt für Schritt, in der Sprache des Angreifers selbst.
Der Katalog wächst weiter, sobald neue Angriffe auftauchen, und die jüngsten Ergänzungen drehen sich um autonome KI-Agenten, also Assistenten, die eigenständig über mehrere Werkzeuge hinweg handeln. Die genaue Zahl ist ein bewegliches Ziel, und genau das ist der Punkt: ATLAS ist ein lebendes Dokument, keine festgeschriebene Liste.
Sein Wert liegt im Stresstest einer Verteidigung. Ein Sicherheitsteam kann den Weg des Angreifers Schritt für Schritt nachgehen und bei jedem Zug fragen: Würden wir das überhaupt bemerken. Nimm Data Poisoning: Die Warnsignale stecken in Kontrollen der Datenpipeline, nicht in den Netzwerk-Alarmen, die ein Unternehmen ohnehin schon laufen hat. Genau solche blinden Flecken bringt ATLAS ans Licht. Es setzt voraus, dass das System bereits existiert und angegriffen wird, und reicht dem Verteidiger das Vokabular des Angreifers.
Zwei Verwechslungen lassen die meisten Diskussionen über ATLAS scheitern. Die erste ist die Verwechslung mit ATT&CK; ATT&CK deckt klassische IT ab, ATLAS ist die KI-Erweiterung, auf derselben Struktur aufgebaut. Die zweite behandelt ATLAS als ein Steuerungswerkzeug. Es enthält keinen Prozess zur Risikoannahme und keine Regeln für den Betrieb eines Programms, nur Angreiferzüge und die Fälle, die sie belegen.
MITRE ATLAS, der Katalog echter Angreiferzüge gegen KI-Systeme.
NIST: das Handbuch für die Steuerung
NIST AI RMF, formal mit der Nummer AI 100-1, ist ein freiwilliges Framework, das die US-Normungsbehörde 2023 zur Steuerung von KI-Risiken über den gesamten Lebenszyklus eines Systems veröffentlicht hat. Es arbeitet auf der Ebene der Organisation, nicht des Codes, und es benennt nie einen einzelnen Fehler oder Angriff. Stattdessen ruht es auf vier Aufgaben: govern (festlegen, wer verantwortlich ist und welche Kultur gilt), map (Kontext und Risiken erfassen), measure (sie nachverfolgen) und manage (auf sie reagieren). Darunter fächert es sich in Dutzende konkretere Praktiken auf.
Es gibt ein Begleitdokument, das man kennen sollte, weil Vergleiche die beiden oft durcheinanderbringen. Das Generative AI Profile, mit der Nummer AI 600-1 und 2024 veröffentlicht, wendet dasselbe Framework gezielt auf generative KI an und ergänzt rund ein Dutzend Risiken, die nur dort auftreten. Das Profil erweitert das Haupt-Framework, es ersetzt es nicht: Ein Team, das mit generativer KI arbeitet, nutzt beide, mit AI 100-1 als Rückgrat.
Das Publikum ist hier die Führung, das Risiko- und Compliance-Management, nicht der Entwickler mitten im Bauen. NIST gibt einer Organisation eine vertretbare Struktur und ein gemeinsames Vokabular, das Prüfer und Regulierer zunehmend erwarten. Diana Kelley, langjährige Sicherheits-Führungskraft und frühere Cybersicherheits-Chefin bei Microsoft, hat argumentiert, dass die Organisationen, die KI-Risiken tatsächlich senken, jene sind, die diese Frameworks gemeinsam einsetzen statt isoliert, weil eine Prüfliste ohne Steuerung abdriftet und eine Steuerung ohne Prüfliste nichts Konkretes hat, das sie steuern könnte. Was NIST dir nicht gibt, ist eine Liste von Fehlern, die du beheben musst, oder eine Karte davon, wie ein Angreifer vorgeht.
Das NIST AI Risk Management Framework, das das Programm über govern, map, measure und manage steuert.
Nebeneinander
| OWASP | MITRE ATLAS | NIST AI RMF | |
|---|---|---|---|
| Beantwortet | Was zu beheben ist | Wie der Angriff abläuft | Wie das Risiko gesteuert wird |
| Geschrieben für | Entwickler, die die App bauen | Teams, die sie verteidigen | Führung und Compliance |
| Liest sich wie | Eine Prüfliste | Ein Angreifer-Handbuch | Ein Steuerungs-Framework |
| Bester Moment | Während des Bauens | Sobald das System läuft | Wenn das Programm wächst |
| Nicht verwechseln mit | Den klassischen Web-Top-10 | MITRE ATT&CK | Dem älteren NIST-Cyber-Framework |
Die Reihenfolge, die wirklich funktioniert
Weil jedes dort ansetzt, wo das vorige aufhört, stapeln sie sich in einer natürlichen Abfolge. Baue zuerst sicher mit OWASP: Geh die Prüfliste durch, beschneide, worauf dein KI-Assistent zugreifen darf, räume in den Daten auf, aus denen er schöpft. Das ergibt ein System, das den bekannten Schwachstellen standhält.
Dieses System wird dann zu dem, was ATLAS dir verteidigen hilft. Dasselbe Prompt-Injection-Risiko, das OWASP dir zu beheben aufgetragen hat, taucht in ATLAS als ein Zug auf, den ein Angreifer macht, sodass deine Verteidiger fragen können, ob sie ihn im Moment des Geschehens überhaupt erwischen würden. Beide lesen dasselbe Risiko von entgegengesetzten Enden, vom Entwickler und vom Angreifer her.
NIST legt sich um beide herum. Die Steuerung entscheidet, welche KI-Funktionen überhaupt ausgeliefert werden, setzt die Richtlinie, die das OWASP-Review verlangt, und definiert, wie viel Risiko akzeptabel ist, was wiederum den Verteidigern sagt, welche ATLAS-Angriffe den Aufwand wert sind. Der Supply-Chain-Faden läuft durch alle drei und verhält sich ganz ähnlich wie das Ausbreitungsrisiko, das wir in Software-Supply-Chain-Angriffen beschrieben haben, wo eine einzige vergiftete Abhängigkeit weit über ihren Eintrittspunkt hinausreicht.
Nichts davon bedeutet, am ersten Tag alle drei in voller Tiefe einzuführen. Ein kleines Team kann lange innerhalb der OWASP-Prüfliste leben, bevor sich der Rest lohnt. Die Frameworks schachteln sich ineinander, statt zu konkurrieren, sodass das Einführen des nächsten nie die Arbeit zunichte macht, die unter dem vorigen entstanden ist. Kehre die Reihenfolge um, beginne mit Steuerung und ohne Technik darunter, und du bekommst Richtlinien, die nichts schützen. Erst bauen, dann verteidigen, um beides herum steuern.
Häufig gestellte Fragen
Sollte ich für KI-Sicherheit OWASP oder MITRE ATLAS nutzen?
Beide, für verschiedene Aufgaben. OWASP ist die Prüfliste, die deine Entwickler beim Bauen abarbeiten und die häufige Schwachstellen wie Prompt Injection mit sofort umsetzbaren Gegenmaßnahmen abdeckt. MITRE ATLAS ist das, was deine Verteidiger nutzen, sobald das System läuft, und das ihnen hilft, echte Angreiferzüge gegen das abzubilden, was sie tatsächlich erkennen können. Wenn du baust und irgendwo anfangen musst, beginne mit OWASP, weil es sich unmittelbar auf den Code anwenden lässt. Nimm ATLAS hinzu, sobald du ein laufendes System hast, das es zu verteidigen lohnt.
Ist das NIST-KI-Framework dasselbe wie das ältere NIST-Cybersicherheits-Framework?
Nein. Das NIST AI Risk Management Framework ist ein eigenständiges, neueres Dokument mit Fokus auf KI-spezifisches Risiko, aufgebaut um vier Aufgaben: govern, map, measure und manage. Das bekannte NIST Cybersecurity Framework deckt Computersicherheit im Allgemeinen ab und ist älter als das KI-Pendant. Sie teilen sich einen Urheber und eine ähnliche Form, aber sie decken unterschiedliches Terrain ab, und jeder Vergleich, der sie als austauschbar behandelt, ist auch in seinen übrigen Aussagen unzuverlässig.
Was ist der Unterschied zwischen NIST AI 100-1 und AI 600-1?
AI 100-1 ist das Haupt-Framework, das Steuerungs-Rückgrat mit den vier Aufgaben. AI 600-1 ist das Generative AI Profile, ein 2024 veröffentlichtes Begleitdokument, das dasselbe Framework auf generative KI anwendet und rund ein Dutzend dafür spezifische Risiken ergänzt. Das Profil erweitert das Haupt-Framework, statt es zu ersetzen. Wer mit generativer KI arbeitet, nutzt beide, mit AI 100-1 als Rückgrat und AI 600-1 als der generativ-spezifischen Schicht darüber.
Wie groß ist MITRE ATLAS?
Es umfasst rund eineinhalb Dutzend Angreiferziele und Dutzende konkreter Techniken, auf reale Fälle gestützt, und wächst regelmäßig, sobald neue Arten von Angriffen auftauchen. Die jüngsten Ergänzungen haben sich auf autonome KI-Agenten konzentriert. Weil sich die Zahl mit jeder Veröffentlichung verschiebt, lautet die ehrliche Antwort: Schau in die aktuelle Matrix auf der MITRE-ATLAS-Seite, statt einer festen Zahl in irgendeinem Artikel zu vertrauen.
Kann ein kleines Team realistisch alle drei Frameworks nutzen?
Nicht in voller Tiefe am ersten Tag, und das musst du auch nicht. Ein kleines Team, das KI-Funktionen ausliefert, kann lange innerhalb der OWASP-Prüfliste leben und genau die Risiken abdecken, die Systeme tatsächlich brechen. MITRE ATLAS verdient seinen Platz, sobald du ein ausgeliefertes System hast, das es zu verteidigen lohnt, und Leute, die es verteidigen. Formale NIST-Steuerung zählt am meisten, wenn Größe, Regulierung oder Prüfungen ins Spiel kommen. Weil sich die drei ineinander schachteln, macht das Hinzunehmen des nächsten nie die frühere Arbeit zunichte.
