Wenn die KI schneller findet als Ihr Patch-Zyklus: Was KRITIS-Plattformen jetzt ändern müssen

02:47 Uhr, Rechenzentrum eines deutschen Versorgers. Der Alert lief nicht durch das SIEM. Er kam per E-Mail aus einer koordinierten Offenlegung: in einer Komponente, die seit vierzehn Jahren im Produktionsbetrieb läuft, steckt eine remote ausnutzbare Lücke, gefunden von einem autonomen Modell, innerhalb einer einzigen nächtlichen Session. Der zuständige Plattform-Lead liest die CVE-Nummer, öffnet das Asset-Inventar und sucht nach Abhängigkeiten. Er findet 214 Systeme. Sein Patch-Window liegt bei drei Wochen.

Diese Szene ist keine Dystopie. Sie ist der neue Normalfall in der sogenannten Mythos-Ära, einer Verschiebung der Angriffsgeschwindigkeit, die Anthropic mit der Ankündigung seines unveröffentlichten Frontier-Modells Claude Mythos und dem parallelen Defensivprogramm Project Glasswing sichtbar gemacht hat. Was früher das Quartals-Pentest erledigte, wird zunehmend in Stunden abgearbeitet, nur eben nicht zwingend von Verteidigern.

Für Plattform-Verantwortliche in KRITIS-Betrieben, Finanzdienstleistern und Energieversorgern ist das keine akademische Debatte. Es ist eine regulatorische, operative und persönliche Haftungsfrage. Und die Diskussion, die gerade in Fachmedien und auf Plattformen wie Medium geführt wird, hat ein auffälliges Muster: sie beschreibt das Problem mit wachsender Dringlichkeit, und verschweigt die Antwort.

Was alle sagen, und was niemand sagt

Beim Durchsehen der öffentlichen Diskussion auf Medium im April 2026 finden sich rund 15 ernsthafte Artikel zum Thema. Die Autoren sind Tech-Journalisten, KI-Analysten, Ex-Engineers großer Plattformen. Die Texte sind lesenswert. Aber sie teilen ein Muster.

“What is Claude Mythos?” - Erklärung des Modells, seiner Benchmarks, seiner Partnerliste.
“AI So Powerful Anthropic Won’t Release It” - Dramaturgie der Zurückhaltung.
“The Dawn of AI Hackers” - epistemische Einordnung der neuen Angreifer-Klasse.
“AI That Finds Bugs Humans Missed” - Faszination mit dem Gefundenen.

Keiner der gesichteten Artikel adressiert die Frage, die ein Plattform-Verantwortlicher in einem regulierten Betrieb um drei Uhr morgens wirklich stellt: Was tue ich operativ, bevor der Alert kommt? Die Texte bieten Diagnose, nur wenig Praxis, Prinzipien oder Handlungsfolge.

Das ist nachvollziehbar, Faszination verkauft sich besser als Operations. Aber es ist für Ihre Lage irrelevant. Wenn Sie die Geschäftsleitung einer nach NIS2UmsuCG prüfpflichtigen Organisation beraten, brauchen Sie keine weitere Beschreibung der Bedrohung. Sie brauchen einen Plan, der vor einem Audit trägt.

Beobachtung: Die Debatte reproduziert das Problem, statt es zu lösen. Wer als KRITIS-Verantwortlicher auf der Suche nach einer operativen Antwort ist, findet im offenen Web fast ausschließlich Problem-Rhetorik. Das ist der eigentliche Nachrichtenwert dieses Artikels.

Die neue Realität in harten Zahlen

Bevor wir zur Antwort kommen, muss die Bedrohungslage nüchtern und ohne Dramaturgie auf den Tisch. Alle folgenden Zahlen sind durch die Primärquelle anthropic.com/glasswing belegt.

Kennzahl	Wert
Firefox-Exploits in einem Lauf	181
Faktor vs. Vorgänger (2 Exploits)	90x
Bisher unbekannte Zero-Days	14
Glasswing-Partner	~50

Die 181 Firefox-Exploits sind der eigentliche Wendepunkt. In einem einzigen autonomen Lauf fand Claude Mythos 90-mal mehr Schwachstellen als der Vorgänger, darunter 14 bisher unbekannte Zero-Days. Autonome Exploit-Entwicklung von der Vulnerability-Entdeckung bis zum funktionierenden Proof-of-Concept ohne menschliche Nacharbeit. Niveau hochqualifizierter Softwareentwickler bei der Analyse von Angriffspfaden über verteilte Systeme.

Wichtiger als die Zahl ist die Schlussfolgerung: die Annahme, dass ein Angreifer Wochen oder Monate für Reconnaissance, Discovery und Exploit-Entwicklung braucht, stimmt nicht mehr. Laut Gartner-Prognose erreichen vergleichbare Modelle auf Wettbewerber-Seite (OpenAI, Google DeepMind, Meta, chinesische Labs) das Mythos-Fähigkeitsniveau binnen 6 bis 18 Monaten.

Das ökonomische Modell von Security-Pipelines verändert sich strukturell. Was bisher ein signifikanter menschlicher Aufwand war, Schwachstellenforschung, Exploit-Entwicklung, Kettenbildung, wird durch Mythos-Klasse-Modelle parallelisierbar, beschleunigt und kostengünstiger. Die Angreiferseite erhält einen strukturellen Hebel, den Verteidiger mit bisheriger Arbeitsweise zunehmend schwerer kompensieren können.

Was NIS2UmsuCG und das KRITIS-Dachgesetz jetzt konkret verlangen

Die regulatorische Lage in DACH hat sich parallel zur technischen Bedrohungslage verschärft, und zwar so, dass die beiden Seiten sich gegenseitig verstärken.

NIS2UmsuCG ist seit Dezember 2025 in Kraft. Es verlangt von betroffenen Organisationen, und das sind nach der Ausweitung deutlich mehr als unter der alten NIS-Richtlinie, kontinuierliche Schwachstellen-Überwachung, dokumentierte Vulnerability-Prozesse, Nachweise über Angriffserkennung sowie belastbare Meldewege. Die Geschäftsleitung ist für die Umsetzung verantwortlich und kann bei Pflichtverletzungen persönlich haftbar gemacht werden. Die Bußgelder reichen bis 10 Millionen Euro oder 2 Prozent des weltweiten Jahresumsatzes, je nachdem, was höher ist.

Das KRITIS-Dachgesetz wurde am 6. März 2026 vom Bundesrat beschlossen. Es erweitert die Resilienzpflichten physisch und digital zugleich, schreibt alle drei Jahre eine Prüfung vor und verzahnt die Nachweispflicht mit dem NIS2UmsuCG-Prozess. Was in beiden Regelwerken gefordert wird, ist nicht ein Zustand, sondern ein kontinuierlich belegter Prozess mit Evidenz.

Audit-Realität: Ein Prüfer fragt nicht, ob Sie gehärtet haben. Er fragt, welche Härtung zu welchem Stichtag aktiv war, wer sie freigegeben hat, welcher Drift dazwischen aufgetreten ist, und welche Evidenz Sie vorlegen können. Fehlt diese Spur, ist der Befund dokumentiert. Und das Expositionsfenster zwischen Befund und möglicher Ausnutzung wird in der Mythos-Ära kürzer, unabhängig von Prüffristen.

Das bedeutet operativ: ein Excel-Sheet mit Härtungsmaßnahmen, das einmal pro Quartal gepflegt wird, genügt den Nachweisanforderungen in aller Regel nicht. Eine manuelle CIS-Benchmark-Prüfung einmal im Jahr ebenso wenig. Was Prüfer in der Mythos-Ära erwarten, ist eine automatisierte, versionierte, auditierbare Kette von Anforderung bis Zustand.

Warum klassische Härtung nicht mehr ausreicht

Die meisten Enterprise-Plattformen sind gegen eine Welt optimiert, die es nicht mehr gibt. Das Muster ist bekannt: Inventur, Gap-Analyse, Maßnahmenkatalog, Ticket im JIRA, Freigabe-Prozess, Change-Window, Pentest. Zwischen Entdeckung und Behebung vergehen, realistisch, zwischen drei und zehn Wochen. In gut organisierten Organisationen. In schlecht organisierten deutlich mehr.

In der Mythos-Ära trifft dieses Fenster auf eine neue Geschwindigkeits-Klasse auf der Angriffsseite. Das Ergebnis ist nicht, dass Ihre Plattform sofort fällt. Das Ergebnis ist strukturell: Die Wahrscheinlichkeit, dass zum Zeitpunkt einer Lücke noch keine Gegenbewegung aktiv ist, verschiebt sich messbar zu Ihren Ungunsten.

Das Problem ist nicht “Mythos”, es ist der Zyklus

Wenn Ihre Plattform-Härtung nicht als kontinuierlicher, automatisierter, auditierbarer Prozess aufgesetzt ist, ist die Frage nicht mehr, ob Sie eine Lücke haben. Die Frage ist, wie viele Tage zwischen der öffentlichen Verfügbarkeit eines ähnlichen Modells und Ihrem nächsten Change-Window liegen.

Das gilt erst recht für Plattformen mit langen Lifecycle-Abhängigkeiten: JBoss EAP, ältere Linux-LTS-Distributionen, Windows-Server hinter Fachverfahren, IIS für klassische .NET-Stacks, Tomcat, On-Prem- und Cloud-Kubernetes-Cluster. Dort wo “mal eben neu deployen” keine Option ist, zählt nicht Reaktionsfähigkeit. Dort zählt Prävention als Prozess.

Die Operations-Antwort: Plattform-Härtung als kontinuierlicher Prozess

Was NIS2UmsuCG, das KRITIS-Dachgesetz und die Mythos-Ära zusammen verlangen, ist keine neue Software. Es ist eine Umschichtung der Arbeitsweise, weg vom Projekt, hin zum Betrieb. Die Prinzipien sind weder revolutionär noch neu. Sie sind aus anderen Domänen, Infrastructure-as-Code, GitOps, Observability, bekannt. Neu ist, dass sie für Plattform-Sicherheit zur Pflicht werden.

Sieben Kernfähigkeiten, an denen sich das operative Modell messen lassen muss, in zwei klar getrennten Schichten: ein operatives Fundament aus vier Fähigkeiten, auf dem drei weitere aufsetzen.

Das Fundament: vier Fähigkeiten, die den Wirkpfad tragen

Policy, Golden Image, Automatisiertes Deployment, Prüfung. Dieser Fluss ist der eigentliche operative Kern. Ohne ihn passiert nichts, keine Evidenz, keine Auditierbarkeit, kein Enforcement. Nur Dokumente auf Laufwerken.

Sicherheitsstandards, Baselines und Policies. CIS-Benchmarks, NIST, kundenspezifische Vorgaben und lennlay-Standards werden versioniert und standardisiert abgelegt, sodass sie reproduzierbar in Golden Images und Baselines einfließen können. Das ist die Definition dessen, was “sicher” in dieser Umgebung überhaupt heißt.
Golden Images und Plattform-Baselines. Aus der Policy entstehen gehärtete, standardisierte Basisartefakte, nachvollziehbar von “Upstream-Base” bis “Produktions-Image”. Die Policy wird zum Artefakt, das sich bauen, signieren und versionieren lässt.
Automatisierung, Deployment und Plattformintegration. Der Punkt, der in den meisten Debatten fehlt: Wie kommen die Baselines und Images überhaupt auf die Zielplattformen? Über Ansible-Collections, CI/CD-Pipelines, GitOps- oder IaC-nahe Deployments, hinein in Server, VMs, Container und OpenShift/Kubernetes. Ohne diese Schicht bleibt Härtung eine Empfehlung; erst durch Deployment und Integration in die bestehende Toolchain wird sie zum reproduzierbaren Zustand der Plattform.
Compliance-Prüfung und Reporting. Die Kontrolle, dass die Policies auf allen Zielplattformen tatsächlich umgesetzt sind, automatisiert, jede Nacht, nicht quartalsweise. Abweichung erzeugt Ticket und strukturierten Report, nicht Excel-Zeile.

Darüber: drei Fähigkeiten für Management, Prüfer und Betrieb

Wenn das Fundament steht, kommen die Fähigkeiten, die Aufsichtsrat, Auditor und Lifecycle-Planung später einfordern, und die nur dann belastbar sind, wenn die vier unteren Schichten kontinuierlich laufen.

Dokumentation, Nachvollziehbarkeit und Auditierbarkeit. Jede Härtungsaktion, jede Änderung, jede Ausnahme erzeugt einen Audit-Eintrag. Evidenz ist Nebenprodukt, nicht Quartalsend-Übung, und genau das, was NIS2-Prüfer und Interne Revision sehen wollen.
Lifecycle- und Update-Management. Support-Enden, Versionen, Sicherheitsupdates und Migrationen sind Attribute am Asset, nicht im Memo. Wenn das Support-Ende von JBoss EAP 7 näher rückt, steht das Datum im Dashboard, nicht im Kopf des Admins.
Drift-Erkennung und Enforcement. Abweichung vom Soll-Zustand ist kein Nebenbefund, sondern Trigger, je nach Risikoprofil kontrolliert zurückgeführt. Wer driftet, erklärt.

Was sich je Kernfähigkeit konkret ändert

Damit der Titel nicht abstrakt bleibt: der operative Delta zwischen heutigem Betrieb und dem, was die Mythos-Ära verlangt.

Kernfähigkeit	Heute typisch	Ab Mythos erforderlich
Sicherheitsstandards	CIS-Benchmarks als PDF auf SharePoint. Jährliche manuelle Prüfung.	Policies versioniert und standardisiert abgelegt, fließen reproduzierbar in Golden Images ein.
Golden Images	Vendor-Image plus manuelle Härtungs-Checkliste pro Server.	Gebaute, signierte, versionierte Golden Images aus reproduzierbarer Pipeline.
Automatisierung	Einzel-Playbooks, individuelle Skripte, Handarbeit im Change-Fenster.	Ansible-Collections, CI/CD, GitOps, Rollout auf Server, VM, Container, OpenShift als Regelprozess.
Compliance-Prüfung	Quartals-Pentest, externer Report, Excel-Maßnahmenliste.	Nächtliche automatisierte Prüfung, strukturierter Report, Abweichung erzeugt Ticket.
Dokumentation	Audit-Vorbereitung als eigener Kraftakt zwei Wochen vor Prüfung.	Evidenz entsteht im Betrieb. Audit-Report auf Knopfdruck aus Plattform-Daten.
Lifecycle-Management	Support-Ende landet per Memo bei Ops. Update-Planung im Kopf weniger Personen.	EOL-Daten als Asset-Attribut im Dashboard. Update-Pipeline als sichtbarer Prozess.
Drift-Erkennung	Abweichung fällt im nächsten Audit auf, oder gar nicht.	Drift wird erkannt und transparent bewertet. Automatisches Enforcement selektiv und kontrolliert.

Diese sieben Kernfähigkeiten sind das Fundament der Secure Platform Automation Suite (SPAS), mit der wir bei lennlay Plattformen sicher, standardisiert, auditierbar und automatisiert betreibbar machen. SPAS ist kein neues Tool. Es ist die Plattform-Perspektive quer über Security-Scanner, SIEM, Ticket-System und Ihre bestehende Automatisierung, die operative Schicht, die diese Werkzeuge für die Mythos-Ära audit-fähig und dauerhaft wirksam macht.

Warum wir in DACH bei JBoss EAP anfangen

In der Praxis zeigt sich, dass gute Plattform-Härtung nicht als Lauffeuer über alle Systeme gleichzeitig kommt. Sie kommt in Kampagnen, System für System, mit klarem Einstieg dort, wo der Hebel am größten ist. In vielen DACH-Enterprises ist das JBoss EAP.

Warum JBoss zuerst

Konzentration geschäftskritischer Fachverfahren. In Banken, Versicherungen, Industrieunternehmen trägt JBoss EAP oft Kernapplikationen, die nicht kurzfristig migrierbar sind.
Lifecycle-Druck. Red Hat hat feste Support-Enden. Wer in EAP 7 unterwegs ist, weiß, worüber wir sprechen.
Klare Compliance-Landkarte. CIS-Benchmarks und DISA-STIG existieren und sind maschinenlesbar. Automatisierung ist direkt anknüpfbar.
Hoher Sicherheitsbeitrag pro Arbeitsaufwand. Eine EAP-Kampagne saniert oft dreistellig viele Instanzen auf einmal.

Aus der Beratungspraxis ergibt sich ein wiederkehrendes Muster für den Erstschritt: vier Wochen vom Kick-off bis zum ersten Audit-fähigen Report. Woche 1 Scoping und Asset-Inventur. Woche 2 Modul-Anpassung an die Kunden-Realität. Woche 3 Pilot-Rollout auf Staging und ausgewählte Produktion. Woche 4 Regelbetrieb, Drift-Monitoring, erstes Evidenz-Paket.

Was Sie diese Woche tun können, unabhängig von uns

Unabhängig davon, ob Sie mit lennlay zusammenarbeiten, sind drei Schritte in den nächsten zehn Arbeitstagen realistisch und sinnvoll.

Verantwortungs-Landkarte. Wer hat für welche Plattformklasse die operative Verantwortung, wer hält Compliance-Nachweise, wer darf ein Rollout durchführen? Gerade bei Systemen, die über Abteilungsgrenzen wandern, klafft hier oft die größte Lücke. Ohne diese Karte laufen alle weiteren Schritte in Schnittstellen-Konflikte.
Risiko-Priorisierung nach Exposition. Nicht alle Plattformen sind gleich dringlich. Erste Welle: alles, was nach außen spricht, Webserver und Reverse-Proxies an der Perimeter-Grenze, API-Gateways, Ingress-Komponenten. Zweite Welle: interne Fachverfahren mit Internet-Wirkung, oft JBoss EAP, Tomcat, geschäftskritische Middleware. Backoffice kommt später.
Evidenz-Inventur und NIS2-Mapping für die Top-Systeme. Für jede priorisierte Plattform: welcher Standard ist angewandt, wann zuletzt überprüft, wie automatisiert ist die Prüfung, wie schnell liegt ein Audit-Report vor? Das Ergebnis ist selten erfreulich, es ist aber die ehrlichste Ausgangsbasis für Gespräche mit Geschäftsleitung und Audit.

Diese drei Schritte können Sie alleine machen, oder wir begleiten gezielt die Teile, an denen es klemmt. Der Punkt, an dem ein Gespräch sich aufdrängt, ist meist konkret: Plattformen sind inventarisiert, aber nicht gehärtet. CIS-Benchmarks liegen vor, aber niemand weiß, wie man damit Plattformen tatsächlich reproduzierbar härtet. Oder JBoss EAP 7 nähert sich dem Support-Ende und die Migration ist nicht geplant.

Häufige Fragen von Plattform-Verantwortlichen

Betrifft Mythos unsere Plattform überhaupt, wenn wir das Modell gar nicht einsetzen?

Die Frage ist nicht, ob Sie Mythos einsetzen, sondern ob Angreifer oder Researcher ein vergleichbares Modell einsetzen. Mythos ist die öffentlich sichtbare Spitze einer Kategorie. Laut Gartner-Prognose erreichen Wettbewerber-Modelle das Mythos-Fähigkeitsniveau binnen 6 bis 18 Monaten. Die Verteidigungslinie verschiebt sich, unabhängig davon, welches konkrete Modell Sie lizenzieren.

Was fordert NIS2UmsuCG konkret für Plattform-Härtung?

NIS2UmsuCG ist seit Dezember 2025 in Kraft. Organisationen müssen kontinuierliche Schwachstellen-Überwachung, dokumentierte Vulnerability-Prozesse und Nachweise über Angriffserkennung vorhalten. Bei Nichterfüllung drohen Bußgelder bis 10 Millionen Euro oder 2 Prozent des weltweiten Jahresumsatzes. Die Geschäftsleitung kann bei Pflichtverletzungen persönlich haftbar gemacht werden.

Reicht unser bestehendes Schwachstellenmanagement?

Das klassische Quartalsmodell hat ein Zeitfenster von Wochen bis Monaten. Wenn ein autonomes Modell Zero-Days in Stunden findet, entsteht eine strukturelle Lücke. Die Antwort ist nicht “mehr Pentests”, sondern kontinuierliche, automatisierte, audit-fähige Härtung als Prozess.

Warum ausgerechnet JBoss EAP zuerst?

In vielen DACH-Enterprises trägt JBoss EAP geschäftskritische Fachverfahren. Lifecycle-Druck, CIS- und DISA-STIG-Konformität und enge Kopplung an Kernapplikationen machen es zum Einsatzfeld mit dem höchsten Hebel. Weitere Plattform-Module folgen in klarer Roadmap: Linux, Windows, Container, Kubernetes.

Wie sieht ein realistischer Erstschritt aus?

Ein 15- bis 30-minütiger Plattform-Check als Online-Gespräch. Kein Pitch. Wir klären: Welche Plattformen stehen unter Druck, wo liegt der Compliance-Handlungsbedarf, ob und wie SPAS passt. Buchung direkt auf der SPAS-Produktseite. Als Vorbereitung empfiehlt sich der Architektur-Brief, 13 Seiten PDF, ohne Marketing-Sequenz.

Zum SPAS-Überblick: Secure Platform Automation Suite