Claude Mythos und Ihr ISMS: was sich ändert und was zu tun ist

Was ist Claude Mythos?

Der Name ist keine freie Erfindung. Claude Mythos Preview ist ein reales, am 7. April 2026 von Anthropic veröffentlichtes AI-Modell — in Anthropics eigener Beschreibung (Frontier Red Team, Lead-Autor Nicholas Carlini) ein "general-purpose language model that is strikingly capable at computer security tasks". Seine Existenz wurde bereits im März 2026 durch ein versehentlich veröffentlichtes Blogpost-Entwurfsleck bekannt; Anthropic bestätigte danach gegenüber Fortune, das Modell stelle einen "step change in capabilities" mit erheblichem Cybersicherheitsrisiko dar. Anthropic selbst nennt Mythos "in a different league" gegenüber dem Vorgängermodell Opus 4.6: in einem Firefox-147-Exploit-Benchmark gelangen Opus 4.6 zwei erfolgreiche Versuche in mehreren hundert Anläufen, Mythos erzielte 181 funktionierende Exploits plus Registerkontrolle bei 29 weiteren; in einem internen OSS-Fuzz-Benchmark erreichten Opus 4.6 und Sonnet 4.6 bestenfalls einen Tier-3-Crash, Mythos erzielte 595 Tier-1/2-Crashes und vollständige Kontrollfluss-Übernahme (Tier 5) bei 10 vollständig gepatchten Zielsystemen — darunter ein 27 Jahre alter, inzwischen gepatchter OpenBSD-Bug, ein 16 Jahre alter FFmpeg-Fehler und eine autonom, ohne menschliche Hilfe entwickelte FreeBSD-NFS-Remote-Code-Execution (CVE-2026-4747). Die New York Times bezeichnete die Offenlegung als "cybersecurity reckoning".

Anthropic veröffentlichte das Modell ausdrücklich nicht öffentlich — "we do not plan to make Claude Mythos Preview generally available" — sondern gewährte Zugriff ausschließlich über "Project Glasswing" an ausgewählte Industriepartner und Open-Source-Entwickler (u. a. Microsoft, Apple, AWS, Cisco, Nvidia; über 40 Unternehmen), "to enable defenders to begin securing the most important systems before models with similar capabilities become broadly available". Die eigene Risikoeinschätzung war unverblümt: "In the short term, this could be attackers, if frontier labs aren't careful about how they release these models." In den folgenden Wochen bestätigten unabhängige Funde die Tragweite außerhalb der ursprünglichen Anthropic-Veröffentlichung: rund zwei Wochen nach der Freigabe meldete Mozilla 271 mit Mythos gefundene und behobene Sicherheitslücken in Firefox, am 14. Mai 2026 meldeten Mitarbeitende von Calif.io einen mit Mythos erstellten Speicherkorruptions-Exploit für den Apple M5.

Innerhalb weniger Tage lösten Offenlegung und gemeldete Fälle unautorisierten Zugriffs weltweit Krisenreaktionen aus: US-Finanzministerium und Fed warnten Banken direkt, Zentralbanken in Kanada, Großbritannien, Indien, Japan und Australien beriefen Notfalltreffen ein, ein US-Kongressschreiben forderte eine Überarbeitung der föderalen Cybersicherheitspolitik, China wurde der Zugang verweigert. Im Juni 2026 eskalierte die Lage weiter: nach einem gemeldeten Jailbreak, der Mythos 5 potenziell in ein "unrestricted cyber tool" verwandelte, ordnete das US-Handelsministerium unter Howard Lutnick eine weltweite Sperrung des Zugangs für alle ausländischen Staatsangehörigen an — ein in dieser Form beispielloser Eingriff, der Ende Juni nach Verhandlungen mit Anthropic teilweise wieder aufgehoben wurde.

Genau dieses Ausmaß begründet die Namenswahl: eine einzelne Modell-Enthüllung, die binnen Tagen Zentralbanken, Regierungen und einen 40-köpfigen Industriekonsortium-Zugang gleichzeitig auf den Plan rief, gefolgt von einer weltweiten Exportkontrolle nach einem realen Jailbreak-Vorfall — das ist der Moment, in dem das bis dahin abstrakte Risiko AI-beschleunigter Angriffe erstmals konkret, öffentlich belegt und in einem Ausmaß eintrat, das zuvor niemand erwartet hatte. "Mythos" steht damit nicht für eine Metapher, sondern für ein datiertes, dokumentiertes Ereignis.

Wichtig für die Methodik: Der Name verankert diese Analyse an einem festen historischen Zeitpunkt — er ist kein Bekenntnis, dass die vier Bedrohungsverschiebungen (siehe Methodik) von den Fähigkeiten des Mythos-Modells selbst abhängen. Die eigentliche Beweisgrundlage der Methodik sind vier unabhängig voneinander dokumentierte Vorfälle (Cogent-CVE-Auswertung, GTG-1002-Kampagne, JadePuffer-Ransomware — siehe Methodik), nicht Mythos-spezifische Benchmark-Ergebnisse. "Mythos-Angreifer" ist im weiteren Dokument eine sprachliche Abkürzung für "Angreifer mit den vier belegten, generationsunabhängigen Fähigkeiten", nicht ein Verweis auf ein bestimmtes Produkt. Sollte Mythos in einigen Jahren technisch überholt oder vom Markt genommen sein, bleibt die Methodik gültig, solange die zugrunde liegenden Fähigkeiten — automatisierte Exploit-Entwicklung, autonome mehrstufige Angriffsausführung, fragmentierte Angriffsmuster, entkoppelte Angreiferfähigkeit — bei irgendeinem verfügbaren System bestehen bleiben oder sich weiterentwickeln. Der Name ist ein historischer Marker für den Erkenntnisstand Juli 2026, keine methodische Abhängigkeit von einem einzelnen Anbieter oder Modell.

Mythos als Klassenbegriff. In diesem Schnellheft Klassenbegriff: agentische Frontier-Modelle mit autonomer Schwachstellen-Entdeckung und Exploit-Kettenbau, unabhängig vom Anbieter (u. a. Claude Mythos/Fable 5, OpenAI Daybreak mit GPT-5.5-Cyber, Microsoft MDASH). Ursprünglich Bezeichnung des Referenzmodells Claude Mythos Preview (Kap. 2.5).

Der zentrale Befund

Zentraler Befund

Die etablierten Methoden der Informationssicherheit sind nicht falsch geworden – aber eine Annahme, auf der sie beruhen, stimmt nicht mehr: dass ein Angriff für den Angreifer langsam, aufwendig und teuer ist. Genau diese Bremswirkung entfällt, sobald Angreifer künstliche Intelligenz einsetzen. Ein erheblicher Teil des heutigen Schutzniveaus ruht damit auf einer Grundlage, die nicht mehr trägt.

Die Bedrohungslage hat sich verschoben

Vier Veränderungen sind auf Leitungsebene relevant:

• Tempo: Die Zeit zwischen dem Bekanntwerden einer Schwachstelle und ihrer Ausnutzung schrumpft von Wochen auf Stunden. Bisher ausreichende Reaktionsfenster sind zu kurz geworden.
• Automatisierung: Angreifer lassen den Großteil der Arbeit von Software autonom erledigen – schneller, als ein Team reagieren kann.
• Tarnung: Angriffe werden in viele kleine, für sich unauffällige Schritte zerlegt, die einzeln keinen Alarm auslösen.
• Verfügbarkeit: Angriffsfähigkeiten, die früher nur staatlichen Akteuren offenstanden, sind heute breit zugänglich. Der Kreis ernstzunehmender Angreifer wächst.

Das erfordert eine Anpassung des Sicherheitsmanagements

Die Antwort ist keine neue Sicherheitsstrategie, sondern eine gezielte Nachjustierung des bestehenden Managementsystems für Informationssicherheit (ISMS). Wo Schutz bisher darauf gesetzt hat, dass Angriffe für den Gegner zu aufwendig sind, muss er auf belastbarere Grundlagen umgestellt werden. Dieses Dokument zeigt strukturiert und priorisiert, welche vorhandenen Maßnahmen weiterhin tragen, welche nachgeschärft werden müssen und wo gezielt ergänzt werden sollte. Der Aufwand baut auf dem Bestehenden auf und ist überschaubar – er erfordert aber die bewusste Entscheidung, ihn jetzt anzugehen.

Kollaps des Patch-Gap-Fensters

Klassische Vulnerability-Management-Programme rechnen mit einem Zeitfenster zwischen Patch-Veröffentlichung und Verfügbarkeit eines funktionierenden Exploits. Dieses Fenster wurde in der Praxis meist in Tagen bis Wochen gemessen. Es erlaubte gestaffelte Patch-Zyklen, manuelle Freigabeprozesse und selektives Priorisieren nach Kritikalität.

Anthropic beschreibt Patch-Reversing zu funktionierendem Exploit als genau die Art mechanischer Analyse, in der aktuelle Modelle herausragen. Die veröffentlichte Defensivempfehlung fordert konsequent, internet-exponierte Systeme binnen 24 Stunden (Richtwert) nach Verfügbarkeit eines Exploits zu patchen. Für jedes Control, das auf einen geordneten Patch-Zyklus mit manueller Freigabe setzt, ist die Wirksamkeitsannahme gebrochen.

Kompression der Zeitachse

ISO 27005 wie auch viele Incident-Response-Playbooks setzen voraus, dass zwischen Erkennung, Triage und Entscheidung menschlich handhabbare Zeit liegt. Diese Zeit ist nicht mehr gegeben.

Im dokumentierten GTG-1002-Fall führte Claude Code 80 bis 90 Prozent der taktischen Angriffsschritte autonom aus, bei Anfrageraten, die für menschliche Operatoren nicht erreichbar sind. Kontrollen mit Human-in-the-Loop in der unmittelbaren Reaktionskette werden nicht wegen mangelnder Qualität unwirksam, sondern weil ihre Reaktionszeit nicht mehr in derselben Größenordnung wie die Angriffsgeschwindigkeit liegt.

Fragmentierung des Bedrohungsereignisses

Das Risikomodell der ISO 27005 setzt ein diskretes, identifizierbares Bedrohungsereignis voraus, gegen das Controls greifen. Diese Voraussetzung hält unter agentischen Angriffsmustern nicht mehr. Anthropic beschreibt für GTG-1002 explizit, dass der Angreifer den Gesamtangriff in Teilaufgaben zerlegte – Vulnerability-Scanning, Credential-Validierung, Lateral Movement, Datenextraktion –, die jeweils als legitime technische Anfragen erschienen.

Das Risiko materialisiert sich erst in der Aggregation. Controls, die auf der Evaluation diskreter Ereignisse basieren – signaturbasierte Erkennung ohne Verhaltenskontext, Rate-Limits mit naiven Schwellwerten, Policy-basiertes Alerting auf Einzelaktionen – verlieren Wirksamkeit, obwohl sie technisch funktionieren. Sie sehen, was sie sehen sollen. Sie sehen nicht, dass die Summe einen Angriff ergibt.

Entkopplung von Fähigkeit und Akteur

Die klassische Likelihood-Bewertung stützt sich wesentlich auf die Einschätzung der Angreiferfähigkeit: Ein Nation-State-Akteur galt gegen einen mittelständischen deutschen Softwarehersteller als unwahrscheinlich, nicht weil das Interesse fehlte, sondern weil die technische Kapazität für eine individualisierte Kampagne knapp war. Diese Kopplung zwischen Akteurstyp und verfügbarer Kapazität hat Mythos-Klasse-AI weitgehend aufgelöst.

Die Threat-Intelligence-Berichte zeigen, dass Akteure mit geringer eigener technischer Kompetenz mittlerweile in der Lage sind, Operationen auszuführen, die bislang nur professionellen APT-Gruppen zugeschrieben worden wären. Die Likelihood-Achse in jeder Risikomatrix verschiebt sich nach oben – nicht wegen neuer Bedrohungsakteure, sondern weil die Kapazitätsbarriere bestehender Akteure gefallen ist.

Entwicklungen seit der Erstveröffentlichung: Vom Ein-Anbieter-Ereignis zum Multi-Vendor-Markt

Zwischen Mai und Juli 2026 wurde aus der Anthropic-zentrierten Beobachtungslage ein Markt. Vier Entwicklungen sind für die Bewertungen dieses Schnellhefts relevant:

OpenAI Daybreak (11. Mai 2026). OpenAI kombiniert die GPT-5.5-Modellfamilie mit „Codex Security" als agentischem Harness zu einem System für Bedrohungsmodellierung, Schwachstellen-Entdeckung, Exploit-Validierung in isolierten Umgebungen und Patch-Erzeugung; der Zugang ist gestuft (u. a. „GPT-5.5-Cyber" für autorisiertes Red-Teaming).

Microsoft MDASH (12. Mai 2026). Der „Multi-Model Agentic Scanning Harness" orchestriert über 100 spezialisierte Agenten über ein Ensemble aus Frontier- und destillierten Modellen. Erste Volumen-Evidenz: 16 zuvor unbekannte Schwachstellen im Windows-Netzwerk- und Authentisierungs-Stack, darunter vier kritische RCE (u. a. CVE-2026-33824, CVSS 9.8), gepatcht im Mai-Patchday; im öffentlichen CyberGym-Benchmark 88,45 % gegenüber 83,1 % der Mythos Preview.

General Availability der Mythos-Klasse (9. Juni / 1. Juli 2026). Mit Claude Fable 5 ist ein Modell der Mythos-Klasse allgemein verfügbar — mit Cyber-Schutzklassifikatoren; die Variante ohne diese Schutzstufen (Claude Mythos 5) bleibt Glasswing-Partnern vorbehalten. Für die Bewertungslage entscheidend: Die Fähigkeitsklasse diffundiert in die Breite, der Verteidigungsvorsprung einer exklusiven Preview entfällt schrittweise. Das verschärft die in 2.1 und 2.2 hergeleitete Exploit-Ökonomie.

Offenlegungswellen (ab Juli 2026). Project Glasswing meldete für die erste Programmphase über 10.000 High-/Critical-Findings; bis 22. Mai 2026 waren 1.596 Funde an Maintainer von 281 Open-Source-Projekten offengelegt, davon 97 gepatcht. Der angekündigte öffentliche 90-Tage-Bericht (Juli 2026) und auslaufende Embargofristen führen in H2 2026 zu CVE-Wellen. Parallel meldet die NVD strukturelle Überlast (Einreichungen +263 % gegenüber 2020; Enrichment seit April 2026 auf Höchstrisiken priorisiert), und HackerOne pausierte im März 2026 sein Internet-Bug-Bounty-Programm. Damit ist die in MHC-02 (SBOM-Abfragefähigkeit) und MHC-09 (AI-gestütztes Testing) prognostizierte Volumen-Verschiebung eingetreten.

Konsequenz für dieses Schnellheft. Keine der 93 Einzelbewertungen und keine der dreizehn MHC-Begründungen wird durch diese Entwicklung falsch — sie werden bestätigt und verschärft. „Mythos" wird ab dieser Version ausdrücklich als Klassenbegriff geführt (Glossar): agentische Frontier-Modelle mit autonomer Schwachstellen-Entdeckung und Exploit-Kettenbau, unabhängig vom Anbieter. Quellen: Quellenverzeichnis (Abruf: 19. Juli 2026).

Konsequenz für ISO/IEC 27005

Die Methodik der ISO 27005 – Risikoidentifikation, -analyse, -bewertung, -behandlung – bleibt als Prozess intakt. Die Eingaben in diese Methodik jedoch sind betroffen: Die Wahrscheinlichkeitsachse verschiebt sich durch den Wegfall der Kapazitätsbarriere nach oben. Die Zeitparameter zwischen Patch und Exploit kollabieren. Die Aggregationslogik einzeln bewerteter Ereignisse greift nicht mehr. Und die Wirksamkeitsannahme vieler existierender Controls – insbesondere solcher, die auf Angreiferreibung statt auf harter Unmöglichkeit beruhen – ist empirisch widerlegt.

Hinweis: ISO/IEC 27005:2022 unterscheidet in Abschnitt 7.2.1 zwei Ansätze der Risikoidentifikation – den event-based und den asset-based approach. Der event-based approach ist unter Mythos-Bedingungen besonders betroffen, weil er Szenarien aus einzelnen Bedrohungsquellen konstruiert, die im Mikroschritt-Angriff erst in der Aggregation sichtbar werden.

Mythos-Readiness: was jetzt zu tun ist

Die Handlungsempfehlungen aus MRIS 2.0, Kapitel 10, beginnend mit der Sofort-Neubewertung bestehender Controls.

Sofort-Neubewertung bestehender Controls

Aus der Analyse in Teil II folgt, dass die vier Controls aus Kapitel 6 (reine Reibung) und die 37 Controls aus Kapitel 5 (teilweise degradiert) in der Risikobewertung eines Mythos-exponierten ISMS neu bewertet werden müssen. Die Neubewertung erfolgt anhand der vier Bewertungskriterien aus Kapitel 3.2 und hat konkrete Folgen für das Statement of Applicability:

• Für die vier Controls A.5.25, A.5.36, A.8.8 und A.8.23 wird geprüft, ob sie in der bisherigen Form als alleinige Mitigation für Mythos-relevante Risiken im SoA geführt werden. Ist dies der Fall, wird die Eintragung um die jeweilige Ersatz-Empfehlung aus Kapitel 6 ergänzt oder korrigiert.
• Für die 37 teilweise degradierten Controls wird geprüft, welches der fünf Ergänzungsmuster aus Kapitel 5.3 jeweils bereits umgesetzt ist und wo Lücken bestehen. Ergebnis ist eine Gap-Liste je Control als Eingabe für die strukturelle Härtung.
• Für die 29 standfesten Controls aus Kapitel 4 wird die konsequente Umsetzung geprüft. Ein formal im SoA eingetragenes, aber nicht durchgängig implementiertes standfestes Control bietet unter Mythos-Bedingungen keinen Schutz. Beispiel: Ein Asset-Inventar ohne automatisierte Aktualisierung ist schnell veraltet, weshalb Mythos-spezifische Anomaliedetektion blinde Flecken hat.

Die Neubewertung erzeugt kein neues ISMS-Dokument, sondern eine Aktualisierung des bestehenden SoA mit zwei Ergänzungen: erstens Vermerken zur Mythos-Resilienz pro Control, zweitens Zuordnungen zu den dreizehn MHC aus Kapitel 9. Die Aktualisierung ist Gegenstand der nächsten Management-Review.

Strukturelle Härtung: Übernahme der MHC ins SoA

Die dreizehn MHC konkretisieren Mythos-relevante technische und organisatorische Härtungsmuster, die die ISO/IEC 27002:2022 nicht in dieser technischen Tiefe oder Verbindlichkeit vorgibt. Mehrere MHC sind dabei ausdrücklich gehärtete Ausprägungen bestehender ISO-Controls – etwa MHC-08 zu A.8.13, MHC-03 zu A.5.17 und A.8.5 oder MHC-10 zu A.5.35, A.5.36 und A.8.9; andere adressieren Anforderungen, die die ISO nur implizit über die Risikobetrachtung abdeckt. Die Übernahme in das SoA folgt einem einfachen Muster:

• Jeder MHC wird als zusätzlicher Eintrag ins SoA aufgenommen, mit Verweis auf die flankierenden ISO-Controls aus der MHC-Kompakt-Tabelle (Kap. 9.4).
• Der Umsetzungsstand wird ehrlich dokumentiert: bereits umgesetzt, teilweise umgesetzt, geplant oder nicht angegangen. Die Kategorie „geplant" sollte mit expliziter Begründung versehen sein, warum sofortige Umsetzung nicht möglich ist.
• Für jeden MHC wird geprüft, ob er im organisatorischen Kontext überhaupt anwendbar ist. MHC-07 (Multi-Tenancy-Isolation) ist beispielsweise für Organisationen ohne Multi-Tenant-Architektur nicht relevant. Solche Nicht-Anwendbarkeit wird ebenfalls explizit vermerkt.

Die Übernahme erzeugt keine Compliance-Pflicht, weil die MHC keine normative Basis im ISO-27001-Sinne haben. Sie dokumentiert die bewusste Auseinandersetzung mit der Mythos-Bedrohungslage und gibt internen und externen Prüfern eine nachvollziehbare Grundlage. Für Organisationen, die einer Regulierung unterliegen, die einen MHC-Inhalt bereits verlangt, deckt sich die Übernahme mit einer bestehenden Pflicht. Das gilt allerdings nur im jeweiligen Anwendungsbereich: MHC-12 entspricht den TLPT-Anforderungen für diejenigen DORA-regulierten Finanzunternehmen, die gemäß Art. 26 Abs. 8 für TLPT identifiziert wurden – nicht für alle DORA-Adressaten. MHC-11 operationalisiert die Anforderungen aus NIS2 und der Durchführungsverordnung an Erkennung, Reaktion und Wiederherstellung; ein SOAR-System oder automatisiertes Tier-1-Containment wird dort nicht pauschal vorgeschrieben.

Reifung des ISMS-Prozesses

Mehrere Beobachtungen aus der Mythos-Bedrohungslage haben direkte Implikationen für die Betriebsweise des ISMS:

• Die Risikobewertung nach ISO 27005 bleibt die Basis, muss aber in kürzeren Zyklen aktualisiert werden. Was vor einem Jahr als geringe Bedrohung eingestuft war, kann heute akut sein. Eine jährliche formale Risikobewertung mit unterjährig ergänzender Überprüfung spezifischer Risiken ist angemessen.
• Das Management-Review nach ISO 27001 Kapitel 9.3 sollte die Mythos-Bedrohungslage als wiederkehrenden Agenda-Punkt aufnehmen. Grundlage können die Versionshinweise dieses Schnellhefts und einschlägige Threat-Intelligence-Berichte sein.
• Die interne Audit-Funktion sollte um Continuous-Audit-Elemente ergänzt werden (inhaltlich deckungsgleich mit MHC-10). Die Ergebnisse des automatisierten Monitorings fließen in die reduzierten, weiterhin jährlichen formalen Audits ein, ersetzen sie aber nicht.
• Die KPI-Landschaft des ISMS wird um Mythos-relevante Indikatoren ergänzt (siehe Kap. 10.6).
• Innovation-Acceleration-Governance etablieren: ein cross-funktionales Gremium aus Security, Legal, Engineering, Datenschutz und ggf. Beschaffung mit dem expliziten Mandat, defensive AI-Tools und neue Sicherheits-Controls beschleunigt zu evaluieren und produktiv zu nehmen. Ohne dieses Gremium läuft jede Mythos-Härtungsmaßnahme in die übliche Approval-Friction (Beschaffungszyklen, Legal-Review, Datenschutz-Freigabe), die unter Mythos-Bedingungen zur strukturellen Schwäche wird – die NIS2-DVO erkennt dies in Nr. 1.1 als Governance-Pflicht implizit an. Empfohlene Kadenz: zweiwöchentlich, mit definiertem Time-to-Decision-Ziel von maximal 30 Tagen für Tools mit gültigem ISO-27001/SOC-2/C5-Testat.
• Permanente VulnOps-Funktion analog DevOps aufbauen, statt Vulnerability-Management als Teilzeit-Aufgabe innerhalb des SOC zu führen. Verantwortung: kontinuierliche Discovery von Zero-Days über die gesamte Software-Estate (eigener Code, Drittsoftware, Cloud-Konfiguration), automatisierte Remediations-Pipelines, EPSS- und KEV-basierte Priorisierung. Mindestkapazität ab etwa 1.000 Mitarbeitenden oder ab dem Zeitpunkt, an dem die Patch-Last 100 oder mehr Critical-Findings pro Monat erreicht. Diese Funktion adressiert das in Mythos-Ready (CSA, SANS, OWASP) als CRITICAL eingestufte Risiko der Continuous-Vulnerability-Management-Reife.

Vorstandskommunikation und Risikodialog

Die Herausforderung besteht darin, die Bedrohung ohne Alarmismus, aber auch ohne Verharmlosung darzustellen. Folgende Punkte haben sich als nützlich erwiesen:

• Die vier Feststellungen aus Kapitel 2 eignen sich als Struktur für einen Board-Vortrag: Kollaps des Patch-Gap-Fensters, Zeitachsen-Kompression, Fragmentierung, Fähigkeits-Entkopplung. Alle vier Punkte sind empirisch belegt.
• Die Unterscheidung zwischen standfesten, teilweise degradierten und reibungsbasierten Controls vermittelt, dass nicht alles an Sicherheit versagt, sondern dass gezielt anzupassen ist.
• Die MHC aus Kapitel 9 sind als Diskussionsgrundlage für Investitionsentscheidungen geeignet. Sie liefern konkrete Bezugspunkte, die mit Framework-Referenzen belegt sind.
• Die regulatorische Einbettung sollte transparent gemacht werden. Mythos-Härtung ist in erheblichen Teilen eine Rechtspflicht, nicht nur Best Practice – abhängig jedoch von Sektor und Adressatenkreis. Für CRA-pflichtige Software-Hersteller, DORA-regulierte Finanzinstitute und NIS2-DVO-Adressaten (bestimmte Digitalanbieter, siehe Kap. 3.3) gilt sie unmittelbar; für andere NIS2-Entities ist die jeweilige nationale Umsetzung maßgeblich.
• Mögliche Entwicklung der Sorgfaltserwartung thematisieren – als strategische Einschätzung des Autors, nicht als geltende Rechtspflicht. Der EU AI Act begründet keine Pflicht zum Einsatz AI-gestützter Threat-Hunting-, Code-Scanning- oder Vulnerability-Discovery-Werkzeuge. Mit der breiten Verfügbarkeit defensiver AI-Werkzeuge ist jedoch damit zu rechnen, dass sich der Maßstab dessen verschiebt, was als angemessene Sicherheitsmaßnahme gilt. Leitungsorgane könnten künftig gegenüber Aufsicht, Versicherern und Gerichten zunehmend belegen können, welche AI-Tools für defensive Zwecke (Code-Audit, Threat-Hunting, Vulnerability-Discovery) eingesetzt werden – und die Nicht-Nutzung verfügbarer Tools begründen. Empfehlung als wiederkehrendes Board-Briefing-Element: „Welche defensiven AI-Tools haben wir im Berichtszeitraum eingeführt? Welche evaluieren wir? Welche nutzen wir bewusst nicht – und mit welcher Begründung?" Dies adressiert das in Mythos-Ready (CSA, SANS, OWASP) explizit als HIGH eingestufte Risiko regulatorischer und Haftungsexposition.

Mythos-relevante Kennzahlen

Die folgenden Kennzahlen sind eine Auswahl, kein abschließendes KPI-Set. Sie orientieren sich an den dreizehn MHC und den vier Bewertungskriterien aus Kapitel 3.2.

Die zehn primären Kennzahlen decken nicht alle dreizehn MHC ab (ergänzend werden für MHC-10 die Bezugskennzahl Automatisierungs-Eignung und für MHC-13 die Governance-Abdeckung erhoben). Für die strukturellen Controls MHC-04 (Workload-Identität) und MHC-07 (Multi-Tenancy-Isolation) ist das eine bewusste Designentscheidung: Der Umsetzungsnachweis erfolgt über Implementierungs-Stage-Gates im Projektcontrolling, nicht über kontinuierliche Kennzahlen.

Gate-Kriterien (Richtwerte, je Reifegradstufe): MHC-04 — Initial: SPIFFE/SPIRE-Identitäten für ≥ 80 % der privilegierten Service-Workloads; Defined: mTLS-Pflicht für Ost-West-Verkehr — 100 % der In-Scope-Verbindungen oder dokumentierte, befristete und risikogenehmigte Ausnahmen; ≥ 95 % gilt ausdrücklich nur als Übergangsschwelle und nicht als vollständige Defined-Erfüllung; Managed: attestierungsgestützte Zugriffspolicies produktiv. MHC-07 — je Stufe ein bestandener, dokumentierter Mandantentrennungstest (Initial: jährlich intern; Defined: je Major-Release; Managed: zusätzlich durch unabhängige Dritte). Die Gate-Erfüllung wird im Projektcontrolling als Ja/Nein-Nachweis geführt.

Die 16 Härtungsmaßnahmen

Jedes Mythos-Härtungs-Control (MHC) hat eine eigene Seite mit Control-Statement, Reifegrad-Pfad und Audit-Nachweis. Die Reihenfolge der Umsetzung beschreibt die Roadmap P0 bis P2.

• MHC-01 Post-Quantum-Strategie und kryptografisches Inventar
• MHC-02 SBOM und Build-Provenance
• MHC-03 Phishing-resistente MFA
• MHC-04 Workload-Identität und Zero Trust
• MHC-05 Verhaltensbasierte Detection
• MHC-06 Container und Confidential Computing
• MHC-07 Multi-Tenancy-Isolation
• MHC-08 Unveränderliche Backups
• MHC-09 AI-gestütztes Security-Testing
• MHC-10 Continuous Control Monitoring
• MHC-11 SOAR und Tier-1-Automation
• MHC-12 Threat-Led Penetration Testing
• MHC-13 AI-Agent-Governance
• MHC-14 Unabhängige Verifikation von Lieferantennachweisen
• MHC-15 AI-resistente Identitätsverifikation Personal/Zutritt
• MHC-16 Multi-Agent-Integrität

Quellen zum Modell

• Claude Mythos Preview — Anthropic (Primärquelle)
• Frontier Red Team: Claude Mythos Preview — Anthropic (Primärbericht mit Benchmark-Details zu Exploit- und Crash-Zahlen)
• The zero-days are numbered — The Mozilla Blog (Primärquelle zu den 271 in Firefox gefundenen und behobenen Schwachstellen)
• First public kernel memory corruption exploit found by an AI agent — Calif.io (Primärquelle zum Apple-M5-Exploit)
• Anthropic Claims Its New A.I. Model, Mythos, Is a Cybersecurity 'Reckoning' — The New York Times
• Anthropic Teams Up With Its Rivals to Keep AI From Hacking Everything — Wired
• Anthropic acknowledges testing new AI model representing 'step change' in capabilities — Fortune
• Anthropic Model Scare Sparks Urgent Bessent, Powell Warning to Bank CEOs — Bloomberg
• Anthropic Disabled Fable 5 And Mythos 5 After A U.S. Export-Control Order — Forbes
• White House drops export controls on Anthropic's Mythos and Fable AI models — The Washington Post