Ein KI-Modell läuft auf derselben Hardware und in derselben Software- und Netzwerkumgebung wie jede andere Anwendung. Damit erbt es auch deren Schwachstellen. Dazu kommen Angriffe, die es ohne das Modell gar nicht gäbe: manipulierte Trainingsdaten, präparierte Eingaben oder Ausgaben, die Trainingsinhalte preisgeben. Um diese zweite Gruppe geht es in der ISO/IEC 27090.
ISO/IEC 27090 behandelt die Sicherheitsbedrohungen und Vorfälle, die es so nur bei KI-Systemen gibt. Ihr vollständiger Titel lautet „Cybersecurity — Artificial Intelligence — Addressing security threats and compromises to artificial intelligence systems”. Sie will Organisationen verständlich machen, welche Folgen solche Angriffe über den gesamten Lebenszyklus eines KI-Systems haben können.
Als Anlass nennt die Norm die Verbreitung von KI. KI-Systeme sind breit im Einsatz, und damit werden Angriffe darauf wahrscheinlicher. Heikel wird das überall dort, wo Fehlfunktionen Menschen gefährden können. Dann reichen die Folgen bis zu körperlichen oder psychischen Schäden bei einzelnen Personen. Die Norm benennt noch ein zweites Problem. Es fehlt an Verständnis dafür, was in einem KI-System vorgeht. Das zeigt sich vor allem, wenn jemand einzelnes Modellverhalten erklären und diagnostizieren soll.
Inhaltlich deckt die Norm nur einen schmalen Ausschnitt ab, nämlich das, was an KI-Systemen besonders ist. An wen sie sich richtet, ist dagegen weit gefasst: an jede Organisation, die KI-Systeme entwickelt oder einsetzt, unabhängig von Größe und Rechtsform, an Unternehmen ebenso wie an Behörden und gemeinnützige Organisationen.
Die Norm gibt Empfehlungen, keine Vorschriften. Nur an zwei Stellen wird der Entwurf verbindlich und schreibt „shall”. Zum einen müssen Sie die Sicherheitsmaßnahmen nach ISO/IEC 27002 umsetzen. Zum anderen müssen Sie die KI-typischen Angriffe über den gesamten Lebenszyklus mitdenken.
Die Schwesternorm ISO/IEC 27091 stammt aus demselben Komitee, hat aber einen anderen Schwerpunkt. ISO/IEC 27090 fragt, wie jemand ein KI-System angreifen kann. ISO/IEC 27091 fragt nach den Risiken für die Privatsphäre und zählt dazu auch Fehlverhalten wie Halluzinationen, nicht nur Angriffe. Membership Inference und Model Inversion tauchen deshalb in beiden Dokumenten auf, jeweils aus einem anderen Blickwinkel.
Klassische Informationssicherheit bleibt die Grundlage
Konventionelle Angriffe treffen KI-Systeme genauso wie jedes andere Informationssystem. Deshalb müssen Sie die Maßnahmen aus ISO/IEC 27002 umsetzen, abgestimmt auf Ihren Bedarf und Ihre Risikoeinschätzung. Wer schon nach ISO/IEC 27001 arbeitet, hat diesen Unterbau bereits. Um den ML-Lebenszyklus vollständig zu schützen, reicht er nach Einschätzung der Norm aber nicht.
Die Norm empfiehlt, ein KI-System als Softwarekomponente zu sehen und nicht als freistehendes Modell. In der Regel steckt es ohnehin in einem anderen System, einer Anwendung oder einer Datei. Wenn Ihnen die Vertraulichkeit Ihres Modells wichtig ist, setzen Sie deshalb besser zuerst beim Software-Stack an. Ihn gegen direkten Modelldiebstahl abzusichern kann mehr bringen als aufwendige KI-spezifische Verfahren gegen Exfiltration über die Schnittstelle.
KI-Governance und Zero Trust
Damit Sie Ihre KI-Systeme steuern können, empfiehlt die Norm ein KI-Governance-Programm aus drei Teilen. Dazu gehören ein Inventar der KI-Systeme und ihrer Verwendung, eine Risikoanalyse und Maßnahmen, mit denen Sie die gefundenen Risiken steuern. Für die Umsetzung verweist sie auf ISO/IEC 42001, für die Governance-Perspektive auf ISO/IEC 38507.
Die Zero-Trust-Grundsätze übernimmt sie aus ISO/IEC 27002, Abschnitt 8.27, und überträgt sie mit Beispielen auf den KI-Lebenszyklus. Trainingsdaten sollen erst dann in die Trainingspipeline kommen, wenn jemand Herkunft und Integrität geprüft hat. Ein KI-Agent soll seine Rechte je Aktion und befristet bekommen, nicht breit und dauerhaft.
Lieferkette, Threat Modelling und Red Teaming
Die Norm behandelt die Lieferkette als eigenes Thema. Moderne KI-Systeme setzen sich typischerweise aus Beiträgen mehrerer Zulieferer zusammen. Wer welchen Teil beigesteuert hat, lässt sich dabei oft schlechter nachvollziehen als bei klassischer Software. Schwachstellen können an jedem Punkt entstehen, und sie können so subtil wirken, dass übliche Sicherheitstests sie nicht finden. Konkret nennt die Norm vortrainierte Modelle, zugekaufte Datensätze, Notebook-Plattformen und MLOps-Werkzeuge.
Die Norm empfiehlt Threat Modelling als Teil des Risikomanagements über den gesamten Lebenszyklus. Der Bedrohungskatalog kann dabei helfen, die Szenarien zusammenzustellen. Wenn Sie schon mit Bedrohungs- und Risikoanalysen arbeiten, erweitern Sie Ihr vorhandenes Verfahren um die KI-spezifischen Angriffswege, statt ein zweites aufzubauen. Red Teaming stellt dieselbe Frage von der anderen Seite und bildet dafür das Verhalten realer Angreifer nach.
Der Bedrohungskatalog ist der Kern der Norm
Der Katalog sortiert die Angriffe danach, was zuerst getroffen wird: das Modell, die Trainingsdaten, die Testdaten, die Modellausgabe oder der Dienst selbst. Und danach, ob dabei zuerst die Vertraulichkeit, die Integrität oder die Verfügbarkeit leidet. Er hält außerdem fest, ob ein Typ generative oder prädiktive KI betrifft und ob ein Angreifer dahintersteckt oder der Fall versehentlich eintritt.
Die Übersicht führt zwölf Arten auf. Neun davon behandelt die Norm ausführlich. Drei weitere stehen in einem informativen Anhang, weil sie KI-Ausprägungen konventioneller Angriffe sind, nämlich direkter Modelldiebstahl, Abfluss von Trainingsdaten und Abfluss von Eingabedaten. Zu jedem der neun Typen beschreibt die Norm gesondert, wie man ihn erkennt und entschärft. Dafür brauchen Sie das Dokument selbst.
| Angriffstyp | Was dabei passiert | Betroffenes Schutzziel |
|---|---|---|
| Data Poisoning | Das Modell lernt aus untergeschobenen Daten und entscheidet danach falsch, gezielt bei bestimmten Auslösern oder pauschal. Bei kontinuierlichem Lernen genügen dafür Eingaben im laufenden Betrieb | Integrität der Trainingsdaten und der Ausgaben, bei ungezielten Varianten auch Verfügbarkeit |
| Evasion | Eine minimal veränderte Eingabe genügt, damit das Modell falsch klassifiziert. Für Menschen bleibt die Störung unauffällig, die Fehlentscheidung fällt trotzdem | Integrität der Testdaten und der Modellausgabe, möglich zusätzlich Verfügbarkeit des einsetzenden Systems |
| Membership Inference | Ein Angreifer findet über die Antworten des Modells heraus, ob eine bestimmte Datenprobe im Training vorkam. Bei Personendaten wird daraus ein Datenschutzvorfall | Vertraulichkeit der Trainingsdaten |
| Model Exfiltration | Der Angreifer fragt das Modell über die Schnittstelle vielfach ab und baut aus den Antworten ein funktionsgleiches Modell nach. Das Original bleibt dabei unberührt | Vertraulichkeit des Modells |
| Model Inversion | Über gezielt gewählte Eingaben und die zugehörigen Konfidenzwerte lassen sich Teile der Trainingsdaten rekonstruieren, etwa Gesichtsmerkmale aus einem Erkennungssystem | Vertraulichkeit der Trainingsdaten |
| Direct Model Poisoning | Der Angriff zielt nicht auf die Trainingsdaten, sondern auf das Modell selbst, und zwar über den Code der Trainingspipeline, ein zugeliefertes Modell oder Eingriffe während Entwicklung oder Betrieb | Integrität des Modells |
| Sensitive Model Output | Das Modell gibt sensible Inhalte aus, die in seinen früheren Eingaben steckten, etwa Personendaten aus dem Training oder Nutzer-Prompts. Das kann im normalen Betrieb passieren oder von einem Angreifer provoziert werden | Vertraulichkeit der Trainingsdaten; so ordnet die Norm den Fall ein, obwohl auch Nutzer-Prompts betroffen sein können |
| Prompt Injection | Eingeschleuste Anweisungen im Prompt, direkt oder über eine externe Datenquelle, lösen unbeabsichtigtes Verhalten aus | Integrität der Testdaten und der Modellausgabe, zusätzlich Vertraulichkeit interner Systeminformationen |
| Output Contains Injection Attacks | Das Modell liefert Text, in dem klassische Injection-Muster wie Cross-Site-Scripting stecken; gefährlich wird das erst im nachgelagerten System | Von der Norm keinem zugeordnet (Folge: Schadcode-Ausführung im weiterverarbeitenden System) |
Eigene Zusammenstellung nach ISO/IEC FDIS 27090:2026.
Die Angriffsfläche reicht weit über den Code hinaus
Die neun Typen zeigen zusammen, wo ein KI-System angreifbar ist. Der Code bleibt ein Ziel, die Norm nennt ausdrücklich die Manipulation des Codes in der Trainingspipeline. Dazu kommen die Daten, das Modell selbst und die Schnittstelle. Wer vor allem auf Perimeter und Quellcode achtet, übersieht diese Stellen.
Beim Modell selbst ist der Zulieferer der kritische Punkt. Ein manipuliert trainiertes Modell behält sein Verhalten auch dann, wenn Sie es danach weiter trainieren oder feinabstimmen. An der Schnittstelle genügt eine externe Quelle, deren Text die Anwendung in den Prompt einbaut. Steht dort eine unsichtbare Anweisung, kann der Nutzer falsche oder anstößige Antworten erhalten. Wenn Sie den Trainingsdaten nicht trauen können, sollten Sie nach der Norm deshalb auch der Textausgabe nicht trauen.
Model Exfiltration läuft über gültige Abfragen und sieht deshalb aus wie normale Nutzung, Membership Inference genauso. Die Norm empfiehlt daher, die Modellnutzung so zu protokollieren, dass sich Vorfälle rekonstruieren lassen und Missbrauchsmuster auffallen.
Gegenmaßnahmen wirken nicht isoliert
Maßnahmen können sich gegenseitig schwächen. Greift eine ins Training ein, kann sie mit anderen kollidieren, die Anfälligkeit für andere Risiken erhöhen und die Leistung des Modells drücken. In einem Beispiel der Norm erhöhte Training auf adversarialen Daten die Anfälligkeit gegenüber Patch-Angriffen deutlich. Prüfen Sie vor dem Deployment deshalb alle Maßnahmen zusammen und nicht die neue allein.
Ihre Wirkung lässt außerdem nach. Die Modellleistung kann sich über die Zeit verschlechtern, und wo Training Teil der Gegenmaßnahme ist, kann auch diese an Wirkung verlieren. Die Norm empfiehlt laufende Überwachung, bei Bedarf Nachtraining und eine erneute Validierung vor der Wiederinbetriebnahme.
Anders als bei klassischen Systemen liegen die sensiblen Daten bei KI meist in der Entwicklungsumgebung und nicht in der Produktion. Dort müssen Sie also ansetzen, und RAG-Bestände im Betrieb brauchen denselben Schutz wie Trainingsdaten.
Wofür die Norm taugt und wo ihre Grenzen liegen
Die Norm gibt Orientierung, sie ist aber kein Prüfkatalog. Verbindlich wird sie nur an den zwei genannten Stellen. Sie bezeichnet ihre Angaben ausdrücklich als Beispiele und nicht als Referenz und empfiehlt, die Bedrohungen risikobasiert auf das jeweilige System zu beziehen. Eine Liste zum Abhaken finden Sie hier nicht.
Vieles hängt daran, dass man einen Angriff überhaupt bemerkt. Ohne wirksame Erkennung wären Maßnahmen nach Einschätzung der Norm weder nützlich noch angemessen. Beim Data Poisoning ist sie besonders deutlich. Ob jemand Daten oder Modelle vergiftet hat, bleibt ein offenes Forschungsfeld, und automatisierte Verfahren unterscheiden böswillig eingefügte Daten in der Regel nicht zuverlässig von harmlosen Ausreißern. Auch die Eingangsfilterung relativiert die Norm sofort. Eingaben außerhalb der Trainingsverteilung sind nicht zwangsläufig Angriffe, und Angreifer können ihre Eingaben gezielt so gestalten, dass sie der Erkennung entgehen.
Manche der empfohlenen Verfahren haben sich noch nicht durchgesetzt. Die Norm sagt das selbst und weist darauf hin, dass einige davon Leistung kosten oder das System komplizierter machen. Sie eignen sich nur für bestimmte Fälle, etwa den Schutz von Hochrisiko-Systemen, und setzen teils eine schon gereifte Sicherheitspraxis voraus.
Der Nutzen der Norm liegt an anderer Stelle. Sie gibt Ihnen eine gemeinsame Sprache für KI-spezifische Bedrohungen und ein Gerüst für die eigene Bedrohungsanalyse. Und sie sagt nüchtern, was sich heute erkennen lässt und was nicht. Wenn Sie bereits ein ISMS betreiben, reicht das, um die vorhandenen Verfahren gezielt zu erweitern. Für ein KI-Sicherheitsprogramm, das ohne eigene Risikoentscheidungen auskommt, reicht es nicht.
So ordnet sich ISO/IEC 27090 in die Normenlandschaft ein
Die folgende Übersicht führt nur Bezüge auf, die die Norm selbst herstellt.
| Norm | Rolle im Verhältnis zu ISO/IEC 27090 |
|---|---|
| ISO/IEC 27001 und ISO/IEC 27002 | Fundament. Die Einleitung empfiehlt, die dort etablierten Sicherheitspraktiken einzuhalten; für die Maßnahmen nach ISO/IEC 27002 formuliert die Norm verbindlich. Für Zero Trust und sichere Architektur verweist sie auf ISO/IEC 27002, Abschnitt 8.27, für Protokollierung und Überwachung auf 8.15 und 8.16 |
| ISO/IEC 42001 | KI-Managementsystem. Liefert die Umsetzungsanleitung für das KI-Governance-Programm und behandelt die Managementprozesse für verantwortungsvolle KI |
| ISO/IEC 23894 | Risikomanagement für KI. Wird neben einschlägigen ETSI-Dokumenten als möglicher Rahmen genannt, in den eine Organisation die Sicherheitsmaßnahmen für das KI-System einbettet |
| ISO/IEC 22989 | Normative Verweisung. Liefert Begriffe, Konzepte und die Lebenszyklusphasen, auf die ISO/IEC 27090 die Angriffe abbildet |
| ISO/IEC 23053 | Zweite normative Verweisung. Liefert das Rahmenwerk für ML-Systeme samt ML-Pipeline, auf das ISO/IEC 27090 ihre Lebenszyklus-Abbildung stützt |
| ETSI EN 304 223 | Baseline Cyber Security Requirements for AI Models and Systems. ISO/IEC 27090 verweist an mehreren Stellen darauf, unter anderem für mögliche Lieferketten-Maßnahmen und für Threat Modelling |
| ISO/IEC 27091 | Schwesternorm, ebenfalls noch im Entwurfsstadium. Behandelt die Datenschutzrisiken von KI-Systemen; ISO/IEC 27090 verweist für die KI-spezifischen Datenschutzaspekte dorthin |
Eine zweite Sicherheitsorganisation müssen Sie dafür nicht aufbauen. Den Katalog können Sie in Ihre vorhandene Bedrohungsanalyse übernehmen und die Gegenmaßnahmen als KI-spezifische Ergänzung Ihrer bestehenden Maßnahmen behandeln. Wie sich die übrigen Normen dieses Umfelds einordnen, lesen Sie in der Übersicht zu Normen und Standards.
Kommentar hinzufügen