Krypto-Agilität: Der Weg von der Bedrohung zur Handlungsfähigkeit

Quantencomputer bedrohen die Grundlagen unserer digitalen Sicherheit. Holger von Rhein hat in seinem Beitrag die Hintergründe beleuchtet: Harvest Now, Decrypt Later, Moscas Theorem und die historische Einordnung kryptografisch relevanter Quantencomputer zeichnen ein klares Bild – wir müssen handeln. Dieser Artikel widmet sich dem „Wie“.

Die unbequeme Wahrheit: Kryptografie ist kein „Set and Forget“. Wer Holgers Artikel gelesen hat, kennt die Ausgangslage: Die Frage ist nicht mehr ob, sondern wann ein kryptografisch relevanter Quantencomputer Realität wird. Die NIST hat mit FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) und FIPS 205 (SLH-DSA) bereits 2024 die ersten Post-Quantum-Standards finalisiert. Das BSI positioniert sich klar an der Seite der EU und empfiehlt, die Migration zeitnah einzuleiten. Die Werkzeuge liegen auf dem Tisch.

Und trotzdem wird das Thema in vielen Organisationen nicht mit der gebotenen Dringlichkeit behandelt, ähnlich wie in den frühen Tagen der DSGVO oder aktuell mit der NIS-2-Einführung. Man hat vielleicht davon gehört, aber unterschätzt, wie groß der Berg tatsächlich ist. In der Konsequenz bleibt der erste Schritt aus. Dabei offenbart die Post-Quanten-Herausforderung ein weit tieferliegendes, strukturelles Problem: Die meisten Organisationen wissen schlicht nicht, wo und wie sie Kryptografie einsetzen. Keine Inventare, keine zentrale Governance, keine Agilität. Kryptografie wurde über Jahrzehnte als unsichtbare Selbstverständlichkeit behandelt – eingebettet in Bibliotheken, Protokolle und Appliances, über die niemand eine Gesamtübersicht hat.

Genau hier setzt Krypto-Agilität an. Und nein, das ist kein bloßes Buzzword. Es beschreibt die Fähigkeit einer Organisation, kryptografische Algorithmen, Protokolle und Schlüssel systematisch, zeitnah und möglichst unterbrechungsfrei austauschen zu können – nicht nur einmal, sondern kontinuierlich. Denn selbst Post-Quanten-Algorithmen sind nicht für die Ewigkeit gemacht. Wer heute eine starre PQC-Migration durchführt, ohne dabei Agilität als Designprinzip zu verankern, schafft die nächste Altlast.

Bin ich überhaupt betroffen? Die kurze Antwort: Ja. Wenn eine Organisation digitale Kommunikation betreibt, Daten speichert oder Software entwickelt, nutzt sie Kryptografie. TLS, VPN, PKI, Festplattenverschlüsselung, Signaturverfahren, API-Authentifizierung: All das basiert auf kryptografischen Bausteinen, den sogenannten Primitiven,, die durch Quantencomputer bedroht sind.

Die differenziertere Antwort ergibt sich aus zwei Aspekten – dem Zeitdruck und der Komplexität der eigenen kryptografischen Landschaft. Dabei stehen Organisationen mit langfristig schützenswerten Daten unter dem höchsten Zeitdruck. Moscas Theorem gibt uns die entscheidende Formel an die Hand: Wenn die Summe aus der Geheimhaltungsdauer der Daten und der benötigten Migrationszeit größer ist als die Zeit bis zur Verfügbarkeit eines kryptografisch relevanten Quantencomputers, dann sind die Daten bereits jetzt im Risiko.

Für Organisationen, deren Daten über Jahrzehnte hinweg vertraulich bleiben müssen (etwa in der Verteidigung, der Forschung oder dem Gesundheitswesen), hätte die Migration bereits beginnen müssen. Doch mittlerweile geht die Gleichung für „normale“ Betriebe nicht mehr auf. Schon gesetzliche Aufbewahrungsfristen von zehn Jahren, etwa beim Handels- und Steuerrecht, reichen in Kombination mit realistischen Migrationszeiten aus, um das Zeitfenster von Moscas Theorem zu sprengen. Wenn ein Angreifender heute verschlüsselten Datenverkehr abfängt (Harvest Now, Decrypt Later), ist der Schaden bei der Verfügbarkeit eines kryptografisch relevanten Quantencomputers bereits eingetreten – unabhängig davon, wann das sein wird.

Das betrifft zum Beispiel:

Behörden und Verteidigung: Staatliche Kommunikation, die über Dekaden geheim bleiben muss.
Gesundheitswesen: Patientendaten unterliegen strengstem Schutz – und zwar dauerhaft.
Forschung und geistiges Eigentum: Forschungsergebnisse, deren wirtschaftlicher Wert auf Jahre hinaus kritisch ist.
Finanzsektor: Langfristige Vertragsdaten, Transaktionshistorien, strategische Planungen
Konzerne: Hochkomplexe IT-Landschaften, Patente, Firmengeheimnisse und strategische Planungen

Regulatorische Rahmenwerke verschärfen den Druck zusätzlich. Wer unter NIS-2, den Cyber Resilience Act (CRA), ISO 27001, IT-Grundschutz oder branchenspezifische Regelungen wie DORA oder TISAX fällt, wird sich bald mit der Frage konfrontiert sehen, ob die eigene kryptografische Praxis den Anforderungen noch genügt. Diese Regularien fordern üblicherweise bereits heute explizit den Einsatz „dem Stand der Technik entsprechender“ Kryptografie. Das BSI empfiehlt explizit klassisch eingesetzte Kryptografie für hohe Schutzbedarfe nur bis Ende 2030 und für die restlichen Anwendungen bis Ende 2031. Demnach ist die Definition vom „Stand der Technik“ klar: Die Nutzung von quantensicheren Verfahren.

Organisationen mit komplexen, historisch gewachsenen IT-Landschaften – typischerweise im Mittelstand und in Konzernen – stehen vor einer besonderen Herausforderung: Kryptografie steckt nicht nur in den offensichtlichen Punkten (TLS-Zertifikate, VPN-Gateways), sondern tief in der Lieferkette, in eingebetteten Systemen, in OT-Umgebungen und in selbst entwickelter Software. Die Migrationszeit kann hier besonders groß sein, was das von Mosca beschriebene Zeitfenster weiter verengt.

Selbst wenn ihre Daten keine jahrzehntelange Geheimhaltung erfordern und sie keiner strikten Regulatorik unterliegen: Krypto-Agilität ist eine architektonische Eigenschaft, die sich nicht über Nacht herstellen lässt. Wer heute beginnt, verschafft sich strategischen Spielraum. Wer wartet, wird irgendwann unter Zeitdruck und einem erhöhten Risiko sowie höheren Kosten migrieren müssen.

Der Weg zur Krypto-Agilität

Krypto-Agilität entsteht nicht durch ein einzelnes Projekt, sondern durch einen strategischen Aufbauprozess, der sich in klar abgrenzbare Phasen gliedern lässt. Im Folgenden skizzieren wir unseren erprobten Ansatz, der sich an der Realität mittelständischer und großer Organisationen orientiert.

Phase 1: Standortbestimmung – Wo stehen wir?

Bevor man irgendetwas migriert, muss man verstehen, was es zu migrieren gilt. Und genau hier liegt bei den meisten Organisationen die größte Lücke.

Unser Crypto-Basis-Check ist der erste, entscheidende Schritt. Er umfasst die Sichtung der kryptografischen Landschaft. Das bedeutet eine systematische Erfassung über alle relevanten Domänen hinweg, von der Zusammenarbeit, Vendor- & Supply-Chain-Readiness bis zum internen Wissen. Dabei betrachten wir alle kryptografischen Kategorien:

Operative Kryptografie: PKI-Infrastrukturen, Schlüsselmanagement, Konfigurationen, At-Rest-Verschlüsselung, OT-Umgebungen, …
Software-Kryptografie: Kryptografische Bibliotheken, Abhängigkeiten, hartcodierte Schlüssel oder Algorithmen …
Netzwerk-Kryptografie: Protokolle, Cipher Suites, In-Transit-Verschlüsselung, Firewall- und VPN-Konfigurationen, …
Managed und Hardware-basierte Kryptografie: Verwaltete Schlüssel, HSMs, …

Außerdem gilt klar: Nicht jede Kryptografie ist gleich kritisch. Die zentrale Frage lautet daher:

„Wie lange müssen welche Daten vertraulich, integer oder authentisch bleiben?“

Diese Frage speist direkt in Moscas Theorem ein und liefert die Grundlage für jede sinnvolle Priorisierung. Aus alldem entsteht ein Lagebild, das sich in einem Krypto-Reifegrad-Modell verdichten lässt – von Ad hoc (keine Sichtbarkeit, keine Strategie) bis Optimierend (automatisierte Inventarisierung, abgeschlossener PQC-Rollout für Hochrisikosysteme, kontinuierliche Verbesserung). Dieses Modell dient als KPI-Framework: messbar, nachvollziehbar und steuerungsrelevant. Ein solcher Basis-Check ist – je nach Größe der Organisation – in wenigen Tagen bis zu wenigen Wochen durchführbar und liefert die Entscheidungsgrundlage für alles Weitere.

Phase 2: Inventarisierung und Risikoanalyse – Was haben wir und was davon ist kritisch?

Auf dem Crypto-Basis-Check aufbauend folgt die systematische, unternehmensweite Inventarisierung kryptografischer Assets. Hier gelten einige Grundprinzipien, die wir aus der Praxis ableiten:

Vollständigkeit: Das Inventar wird nie vollständig sein – und das ist in Ordnung. Wer auf Vollständigkeit wartet, wird nie fertig. Wichtiger als Perfektion ist ein belastbarer Prozess, der kontinuierlich verbessert wird. Dennoch muss die Erfassung ambitioniert sein.
Automatisierung: Netzwerk-Scans, TLS-Checks, Dependency-Analysen in CI/CD-Pipelines – vieles lässt sich toolgestützt erfassen. Wo Scanner nicht hinkommen (OT, Legacy, Blackbox-Appliances), braucht es halbautomatisierte oder manuelle Erfassung.
Standardisierung durch CBOM: Die Cryptographic Bill of Materials (CBOM) hat sich als Standardformat für kryptografische Inventare etabliert. Wer sein Inventar heute auf dem CBOM-Standard aufbaut, schafft Anschlussfähigkeit für zukünftige Automatisierung und Tool-Ökosysteme.
Erweiterung des bestehenden Asset-Managements: In vielen Organisationen existieren bereits CMDB- oder Asset-Management-Systeme. Die Frage ist nicht, ob man ein neues System braucht, sondern wie sich das bestehende um kryptografische Attribute erweitern lässt.
Dokumentation: Was nicht erfasst werden kann, muss dokumentiert werden. Wenn ein System sich einer kryptografischen Inventarisierung entzieht – etwa eine proprietäre Appliance ohne Einsicht in die verwendete Kryptografie – ist das kein Grund, es zu ignorieren. Es ist ein Grund, es als Risiko zu behandeln und den Hersteller in die Pflicht zu nehmen.

Auf Grundlage des Inventars erfolgt die Risikoanalyse. Hierbei empfiehlt sich eine Dreistufung:

Kategorie	Beschreibung
Akutes Risiko	bereits heute unsichere Kryptografie (z.B. TLS 1.0, SHA-1, RSA < 2048 Bit)sofortiger Handlungsbedarf, unabhängig von der Quantenbedrohung
Quantum-Risiko	heute noch sichere Kryptografie, in Zukunft durch Quantencomputer knackbarPriorisierung über Moscas Theorem
Kein (akutes) Risiko	kurzlebige Daten mit niedrigem Schutzbedarf und geringer Migrationszeit

Die Ergebnisse lassen sich in einer Risiko-Heatmap verdichten, die sowohl dem operativen Team als auch dem Management als Steuerungsinstrument dient. Assets, die sich der Inventarisierung entzogen haben, sollten mindestens als PQC-Risiko eingestuft werden, denn wo Unklarheit herrscht, muss das Vorsichtsprinzip gelten.

Ein nicht zu unterschätzender Nebeneffekt: Die kryptografische Risikoanalyse fördert häufig akute Schwachstellen zutage, die mit der Quanten-Bedrohung gar nichts zu tun haben. Veraltete Protokolle, abgelaufene Zertifikate, unsichere Konfigurationen – die „Krypto-Hygiene“ ist oft der erste sogenannte No-Regret-Move.

Phase 3: Governance – Richtlinien, Prozesse, Verantwortlichkeiten

Technische Migration ohne organisatorische Verankerung ist Sisyphusarbeit. Deshalb ist die Etablierung einer kryptografischen Governance ein essenzieller Baustein – und einer, der oft unterschätzt wird. Viele Organisationen verfügen über eine Krypto-Richtlinie und seltener über ein Krypto-Konzept. Für die vorhandene Richtlinie gilt allerdings oft, dass sie seit Jahren nicht aktualisiert wurde, ausschließlich auf die ungelesene TR-02102 des BSI für Details verweist und PQC nur indirekt berücksichtigt. Eine zeitgemäße Krypto-Richtlinie muss folgende Aspekte abdecken:

Zuverlässige Verfahren: Klare Vorgaben für zulässige Algorithmen, Schlüssellängen und Protokolle, inklusive einer Positionierung zu PQC und hybriden Verfahren
Regulatorischer Bezug: Ausrichtung an einschlägigen Standards und Vorgaben (BSI TR-02102, NIST SP 800-131A, branchenspezifische Regelwerke)
Reaktionsfähigkeit: Finden von Antworten auf die Fragen: Was passiert, wenn morgen ein Algorithmus gebrochen wird? Wer entscheidet? In welcher Zeit? Über welche Meldewege?

Kryptografie betrifft nicht nur die IT-Abteilung. Einkaufsprozesse müssen kryptografische Anforderungen an Produkte und Dienstleister stellen. Softwareentwicklungsprozesse müssen kryptografische Prüfungen einschließen. Und im Lieferantenmanagement müssen PQC-Roadmaps eingefordert und bewertet werden, denn Ihre Krypto-Agilität ist immer nur so gut wie die Ihrer schwächsten Abhängigkeit. Wenn Ihr VPN-Anbieter, Ihr Cloud-Dienstleister oder Ihr HSM-Hersteller keine PQC-Roadmap hat, wird Ihre eigene Migration an genau dieser Stelle blockiert. Der Dialog mit dritten Parteien muss frühzeitig und strukturiert geführt werden.

Phase 4: Proof of Concept und Pilotprojekte – Kontrolliertes Lernen

Bevor eine unternehmensweite Migration beginnt, braucht es kontrollierte Erfahrungsräume. PoC- und Pilotprojekte sind keine optionale Kür, sondern eine notwendige Risikominderung.

Warum Pilotprojekte unverzichtbar sind:

Wissensaufbau: PQC-Algorithmen verhalten sich anders als ihre klassischen Vorgänger. Signaturgrößen von ML-DSA oder SLH-DSA sind zum Teil erheblich größer als bei RSA oder ECDSA. Schlüsselgrößen bei ML-KEM unterscheiden sich von ECDH. Dieses Wissen muss in der Organisation ankommen. Nicht nur theoretisch, sondern durch praktische Erfahrung.
Interoperabilitätstests: Legacy-Systeme und Middleware kommen mit größeren Schlüsseln und Signaturen nicht immer zurecht. Paketgrößen können MTU-Grenzen überschreiten, Zertifikatsketten können Parser überfordern, Handshakes können Timeouts auslösen. All das will vor dem Produktiv-Rollout entdeckt werden.
Hybride Verfahren validieren: Der empfohlene Migrationspfad führt über hybride Kryptografie – also die Kombination klassischer und PQC-Algorithmen. Damit bleibt die Sicherheit auch dann gewährleistet, wenn sich einer der beiden Algorithmen als schwächer herausstellt als erwartet.

Phase 5: Migration und kontinuierliche Verbesserung

Die eigentliche Migration ist kein Sprint, sondern ein priorisierter, phasenweiser Marathon. Dabei müssen Abhängigkeiten der Assets untereinander, technische Einschränkungen und Work-Arounds sowie Kritikalität berücksichtigt werden. Außerdem können PQC-Algorithmen – je nach Parametersatz – signifikant größere Schlüssel, Signaturen und Ciphertexte erzeugen. Das hat Auswirkungen auf Netzwerkbandbreite, Speicher, CPU-Last und Latenz. Eine vorgelagerte Kapazitätsplanung verhindert böse Überraschungen im Produktivbetrieb.

PQC ist komplex. Entwickelnde und Administrierende müssen verstehen, was sich ändert, warum es sich ändert und wie die neuen Algorithmen korrekt eingesetzt werden. Falsch konfigurierte PQC-Kryptografie ist nicht besser als gar keine. Schulungen sind also zu Beginn von Migrationsbestrebungen besonders sinnvoll.

Nach Abschluss der Migrationsschritte sollte der Krypto-Reifegrad erneut erhoben werden. Das macht Fortschritte sichtbar, identifiziert verbleibende Baustellen und gibt dem Management eine belastbare Grundlage für weitere Investitionsentscheidungen.

Krypto-Reifegrad: Wo stehen Sie?

Um die eigene Position auf dem Weg zur Krypto-Agilität greifbar zu machen, hat sich ein fünfstufiges Reifegradmodell bewährt:

Stufe	Bezeichnung	Charakteristik
1	Ad hoc	Keine Sichtbarkeit über die eigene kryptografische Landschaft. Kryptografie wird reaktiv und ohne zentralen Plan implementiert. Kein Bewusstsein für PQC-Risiken.
2	Sensibilisiert	Wichtige Stakeholder sind informiert. Erste isolierte Assessments finden statt. Pläne werden entwickelt, um Erwartungen und Erkenntnisse mit relevanten Stakeholdern zu teilen.
3	Strukturiert	Unternehmensweite Krypto-Inventare sind erstellt. Risiko-Heatmaps und Strategiedokumente liegen vor. Tools und Ressourcen für die Migration sind identifiziert und zugewiesen.
4	Operativ	Prinzipien der Krypto-Agilität sind in der Architektur verankert. PQC-Piloten laufen. Kryptografische Metriken werden überwacht (z. B. Alerts bei Richtlinienverstößen, Certificate-Lifecycle-Monitoring, Anomalie-Erkennung in hybriden Prozessen).
5	Optimierend	Vollständig automatisierte Inventarisierung und Krypto-Überwachung. PQC-Rollout für Hochrisikosysteme ist abgeschlossen. Prozesse zur kontinuierlichen Verbesserung sind etabliert. Die Organisation kann schnell auf neue Standards oder Bedrohungen reagieren.

Die meisten Organisationen, mit denen wir sprechen, befinden sich derzeit irgendwo zwischen Stufe 1 und 2. Das ist keine Schande – es ist der Normalzustand. Entscheidend ist, dass der Weg nach oben jetzt beginnt.

Der nächste Schritt

Die Post-Quanten-Migration ist aktuell eine der größten Herausforderungen für die IT-Sicherheit. Sie betrifft jede Schicht des Technologie-Stacks, jede Branche und jede Organisationsgröße. Aber sie kann bewältigt werden, wenn man sie strukturiert angeht. Der beste Zeitpunkt, mit Krypto-Agilität zu beginnen, war gestern. Der zweitbeste ist heute.

15. Juni 202615. Juni 2026Schwachstelle

Meta-Fehler bei KI-Support: Angreifer kapern Instagram-Konten über automatisierte Kontowiederherstellung

Mehrere Quellen zeichnen ein konsistentes Bild: Angreifer nutzten Ende Mai und Anfang Juni 2026 eine Schwachstelle in Metas KI-gestütztem Account-Recovery- und Support-System für Instagram aus. Im Zentrum stand das interne bzw. erweiterte Support-Werkzeug „High Touch Support“ (HTS), das laut Meta als AI-assisted account recovery system fungierte. Statt eine klassische Sicherheitslücke in der Instagram-App selbst auszunutzen, zweckentfremdeten die Täter also den automatisierten Account-Wiederherstellungsprozess des KI-Chatbots.

Laut TechCrunch und 404 Media ließen sich die Angriffe offenbar dadurch durchführen, dass Metas AI-Support-Chatbot dazu gebracht wurde, eine neue E-Mail-Adresse zu einem Zielkonto hinzuzufügen beziehungsweise den Reset-Prozess anzustoßen. BleepingComputer berichtet ergänzend, dass HTS dabei unzureichend prüfte, ob die angegebene E-Mail-Adresse tatsächlich mit dem betroffenen Instagram-Konto verknüpft war. Das Problem lag also nicht nur in fehlender Verifikation, sondern in der Automatisierung einer hochsensiblen Entscheidung, die traditionell stärker abgesichert oder menschlich geprüft würde.

Der Vorfall fällt deshalb aus der Reihe, weil er weniger ein klassischer „Exploit“ als ein Beispiel für prozessuale Sicherheitsrisiken durch KI-gestützte Support-Automation ist. Wenn ein KI-System nicht nur informiert, sondern aktiv sicherheitsrelevante Kontofunktionen wie E-Mail-Änderungen oder Passwort-Resets anstoßen kann, wird der Support-Workflow selbst zur Angriffsfläche. Genau darin liegt die eigentliche sicherheitstechnische Relevanz des Falls: Nicht die KI „hackt“ das Konto, sondern sie wird zum fehlbaren Gatekeeper in einem Identity-Recovery-Prozess. Diese letzte Einordnung ist eine Schlussfolgerung aus den berichteten Abläufen. Ein schönes Bespiel für „Excessive Agency“ aus den „OWASP Top 10 LLM“.

Die Auswirkungen waren erheblich. Laut Meta wurden mehr als 20.000 Instagram-Konten kompromittiert; erste Berichte betrafen auch prominente oder begehrte Handles. BleepingComputer beschreibt zudem, dass betroffene Nutzer teils in automatisierten Recovery-Schleifen festhingen, weil auch die Wiedererlangung des Kontos stark auf automatisierte- und KI-gestützte Prozesse setzte. Meta erklärte, das Problem sei inzwischen behoben und betroffene Konten würden abgesichert.

Der Meta/Instagram-Fall ist vor allem deshalb bemerkenswert, weil er zeigt, dass KI-unterstützte Support- und Recovery-Systeme selbst zu einem sicherheitskritischen Vertrauensanker werden können. Für IT- und Security-Teams ist das ein Warnsignal: Sobald automatisierte Assistenten in Identitäts- oder Recovery-Prozesse eingebunden werden, müssen deren Prüfmechanismen genauso streng modelliert, getestet und abgesichert werden wie klassische Authentifizierungs- und Helpdesk-Prozesse.

https://www.bleepingcomputer.com/news/security/meta-ai-support-data-breach-affects-20-000-instagram-accounts/amp

Hackers hijacked Instagram accounts by tricking Meta AI support chatbot into granting access

https://www.404media.co/hackers-are-using-meta-ai-to-hijack-instagram-accounts

15. Juni 202615. Juni 2026KI/ML

Claude Mythos / Project Glasswing: Anthropic erweitert stark eingeschränktes Cyber-Modell auf kritische Infrastrukturen

Anthropic hat Claude Mythos Preview im April 2026 als besonders leistungsfähiges, aber nicht allgemein freigegebenes Modell für cybersicherheitsbezogene Aufgaben vorgestellt. Der Zugang erfolgt über Project Glasswing, ein Programm, in dem ausgewählte Partner das Modell für defensive Sicherheitsarbeit wie Schwachstellenanalyse und Absicherung kritischer Software einsetzen. Anthropic begründet die restriktive Freigabe ausdrücklich mit dem Missbrauchsrisiko solcher Cyber-Fähigkeiten.

Anfang Juni 2026 hat Anthropic Project Glasswing deutlich ausgeweitet: Nach Angaben des Unternehmens erhalten rund 150 weitere Organisationen in mehr als 15 Ländern Zugang, darunter Akteure aus Bereichen wie Energie, Wasser, Gesundheitswesen, Kommunikation und Hardware. Anthropic gibt an, dass jede neue Organisation vor dem Zugang zu Claude Mythos Preview interne Sicherheitsanforderungen erfüllen muss. Worin diese konkret bestehen, legt das Unternehmen jedoch nicht offen.

Für die Einordnung ist vor allem die strategische Bedeutung relevant: Anthropic beschreibt Mythos nicht als gewöhnliches Produkt-Update, sondern als Modellklasse, die die bestehenden Annahmen in der Cybersicherheit verändert. Das Unternehmen betont, dass die eigentliche Herausforderung nicht nur im Auffinden zusätzlicher Schwachstellen liegt, sondern zunehmend auch in deren Verifikation, Offenlegung und Behebung, also in den nachgelagerten Prozessen des Sicherheitsökosystems.

Die bisher kommunizierten Ergebnisse unterstreichen diesen Anspruch: Anthropic berichtet, dass die ersten Project‑Glasswing‑Partner bereits mehr als 10.000 hoch- oder kritisch eingestufte Sicherheitslücken identifiziert hätten. Fachmedien nennen dazu Beispiele einzelner Partner, bei denen die Zahl gefundener Schwachstellen deutlich gestiegen sei; diese Angaben stammen jedoch im Kern aus Unternehmens- und Partnerberichten und sind daher eher als starke Indikation denn als unabhängig auditierte Gesamtbilanz zu lesen.

Der Fall ist damit weniger wegen einer einzelnen CVE relevant als wegen der Governance-Frage, die er aufwirft: Wenn KI-Modelle sicherheitsrelevante Analyse- und Patch-Prozesse spürbar beschleunigen, werden Zugangskontrolle, Schutzmaßnahmen und verantwortliche Bereitstellung selbst zu einem sicherheitspolitischen Thema. Anthropic stellt dabei die kontrollierte Freigabe und den defensiven Einsatzzweck in den Mittelpunkt – das ist die offizielle Begründung. Aus Sicherheitssicht entsteht so aber auch ein abgestuftes Zugangsmodell: Mit dem am 9. Juni 2026 veröffentlichten Claude Fable 5 brachte Anthropic erstmals ein öffentlich verfügbares Modell seiner Mythos-Klasse auf den Markt, dessen Leitplanken Antworten in Hochrisikobereichen wie Cybersicherheit und Biologie blockieren. Konkret werden bei Fable Anfragen zu Cybersicherheit, Biologie und Chemie sowie Distillation automatisch vom schwächeren Claude Opus 4.8 beantwortet. Die ungebremste Variante ist hingegen nicht allgemein zugänglich: Dasselbe Modell ohne diese Beschränkungen ist Claude Mythos 5, das nur einer kleinen Gruppe geprüfter Kunden zur Verfügung steht – im Rahmen von Project Glasswing. Hinzu kommen Preis und Datenauflagen: Fable 5 und Mythos 5 kosten das Doppelte von Claude Opus 4.8. Anthropic koppelte an beide Modelle eine verpflichtende 30-tägige Datenspeicherung, die bestehende Zero-Retention-Vereinbarungen außer Kraft setzt. Damit verschiebt sich „Sicherheit“ tendenziell von einer Grundeigenschaft hin zu einem gestuften Leistungsmerkmal – eine Entwicklung, vor der auch Beobachter warnen: Die Vorgabe könnte einen Branchenpräzedenzfall schaffen, bei dem der Zugang zu Frontier-Modellen an eine als Sicherheitsmaßnahme gerahmte Pflichtspeicherung gekoppelt wird. Ob Anthropics gestaffeltes Modell langfristig der erklärten Mission – dem Nutzen für die Allgemeinheit – dient oder vor allem eine Gatekeeper-Position absichert, wird sich daran messen lassen müssen, wie schnell und breit die Schutzfähigkeiten tatsächlich verfügbar werden.

https://www.anthropic.com/news/expanding-project-glasswing

https://www-cdn.anthropic.com/8b8380204f74670be75e81c820ca8dda846ab289.pdf

https://www.anthropic.com/system-cards

https://coursiv.io/blog/claude-fable-5

https://yellow.com/news/claude-fable-5-free-until-june-22

Here’s how cyber heavyweights in the US and UK are dealing with Claude Mythos

Anthropic debuts preview of powerful new AI model Mythos in new cybersecurity initiative

https://www.cfr.org/articles/six-reasons-claude-mythos-is-an-inflection-point-for-ai-and-global-security

https://www.techradar.com/pro/security/anthropic-to-present-exposed-mythos-flaws-to-global-watchdog-claims-critical-vulnerabilities-found-in-every-major-operating-system-and-web-browser

https://www.tomshardware.com/tech-industry/artificial-intelligence/nsa-using-clause-mythos-for-offensive-cyber-operations-report-claims-says-half-a-dozen-anthropic-engineers-embedded-inside-the-agency

https://www.theneuron.ai/explainer-articles/everything-to-know-about-claude-fable-5-anthropics-new-and-first-public-release-of-its-mythos-model

21. Mai 202629. Mai 2026Kryptographie, Netzwerk, Post-Quanten-Kryptografie, Quantencomputing, Risikomanagement

Die Uhr läuft: Warum die Post-Quanten-Migration jetzt beginnen muss

Be liberal in what you accept – don’t trust anything. Das Thema Vertrauen in Netzwerken hat einen radikalen Wandel vollzogen. Wo es in den Anfangszeiten der modernen IT noch mit einer guten Portion Vertrauensvorschuss voranging, ist heute große Skepsis angebracht. Und mit Quantencomputern steht bereits der nächste Paradigmenwechsel bevor.

Vertrauen im Wandel – eine kurze Geschichte der Netzwerksicherheit

„In general, an implementation should be conservative in its sending behavior, and liberal in its receiving behavior.” Diesen Satz formulierte Jon Postel in den Anfangstagen des Internets. Mit diesem Satz in seinem RFC 760 zum Internet-Protokoll im Jahr 1980 sollte er die Netzwerkentwicklung nachhaltig prägen. Nur ein Jahr später, im RFC 793 zur Spezifikation des TCP, erhob er diesen Gedanken explizit zum Robustheitsprinzip: „Be conservative in what you do, be liberal in what you accept from others.”

Zum damaligen Zeitpunkt galt dies als pragmatische Ingenieursweisheit. Es entsprach dem Geist einer Zeit, in der das Netz eine überschaubare Gemeinschaft von Universitäten und Forschungseinrichtungen verband. Man kannte sich. Man vertraute sich. Und genau dieses Grundvertrauen wurde zum Fundament eines Netzwerks, das nie für das gebaut wurde, was es heute ist: Ein globales Netzwerk, wo die nächste Gefahr fürs eigene Netzwerksegment nur einen Hop entfernt ist.

Als das Internet in den 1990er-Jahren seinen Weg in Unternehmen fand, wurde schnell klar, dass Postels großzügiges Prinzip allein nicht ausreichen würde. Nicht jeder Teilnehmende im Netz hatte gute Absichten. Die Antwort der IT-Sicherheit folgte einer Logik, die so alt ist wie die Zivilisation selbst: Man baute eine Mauer. Das Modell des Perimeterschutzes war geboren – eine klare Grenze zwischen Innen und Außen. Firewalls filterten den Datenverkehr an den Toren. Was innerhalb der Mauern lag, galt als vertrauenswürdig. Postels Prinzip der Großzügigkeit lebte dort weiter – aber nur noch im geschützten Inneren.

Doch Mauern haben ein grundsätzliches Problem: Sie schützen nur, solange niemand sie überwindet. Wer einmal drinnen ist – ob berechtigt oder nicht – genießt volles Vertrauen. Und die Welt jenseits der Mauern wurde größer, feindseliger, unübersichtlicher.

Parallel dazu reiften kryptografische Verfahren heran, die eine fundamental andere Art von Vertrauen ermöglichten: nicht mehr Vertrauen durch Zugehörigkeit zu einem Netzwerk, sondern Vertrauen durch mathematisch überprüfbare Identität. SSL und sein Nachfolger TLS sicherten die Kommunikation zwischen Endpunkten. VPNs schufen verschlüsselte Tunnel zwischen perimetergeschützten Umgebungen über unsicheres Terrain. Public-Key-Infrastrukturen etablierten Vertrauensketten, die an keine physische Netzwerkgrenze gebunden waren. Was als Ergänzung zum Perimeterschutz begann, wurde zunehmend zu einer eigenständigen Sicherheitsschicht – und schließlich zu einer Alternative.

Nach der Jahrtausendwende formulierte John Kindervag bei Forrester Research im Jahr 2010 den konsequenten Schluss aus dieser Entwicklung: Zero Trust. Das Prinzip ist in seiner Radikalität bemerkenswert einfach: Vertraue niemandem. Verifiziere immer alles. Kein Netzwerkstandort, keine IP-Adresse, keine Firewall-Regel gewährt Vertrauen – nur die kryptografisch gesicherte, kontinuierlich überprüfte Identität eines Akteurs und der Kontext seiner Anfrage.

Zero Trust ist damit nicht nur eine technische Architektur. Es ist die konsequente Umkehrung von Postels Erbe. Wo das Robustheitsprinzip noch sagte “Sei großzügig in dem, was du akzeptierst”, antwortet Zero Trust “Akzeptiere nichts, was sich nicht zweifelsfrei ausweisen kann”. Aus implizitem Vertrauen wurde explizite Verifikation. Was einst als Tugend galt – Offenheit, Toleranz gegenüber dem Unbekannten – wurde in einer feindlichen Umgebung zur Schwachstelle.

Die Geschichte der Netzwerksicherheit ist damit auch eine Geschichte darüber, wie sich der Begriff des Vertrauens selbst gewandelt hat: vom sozialen Grundkonsens einer akademischen Gemeinschaft über die territoriale Logik befestigter Grenzen hin zu einem System, in dem Vertrauen nicht vorausgesetzt, sondern in jedem einzelnen Moment mathematisch bewiesen werden muss. Postel entwarf sein Prinzip für eine Welt, in der guter Wille die Regel war. Zero Trust wurde für eine Welt gebaut, in der man sich diesen guten Willen nicht mehr leisten kann.

Die vier Bedrohungsachsen der Kryptografie

Heute ist die Netzwerksicherheit fundamental von der Sicherheit der eingesetzten kryptografischen Verfahren abhängig. Diese Verfahren sehen sich vier zentralen Bedrohungsachsen ausgesetzt:

Kontinuierliche Steigerung der Rechenleistung – was heute als sicher parametrisiert gilt, kann morgen durch brute-force-fähige Hardware fallen.
Protokoll- und Implementierungsfehler – von Heartbleed (CVE-2014-0160) über ROBOT (CVE-2017-17382, CVE-2017-6168) bis hin zu Timing-Seitenkanalangriffen. Die Lücke liegt oft nicht im Algorithmus, sondern im Code.
Mathematische Fortschritte – neue analytische Methoden können die effektive Sicherheit eines Verfahrens über Nacht reduzieren, wie zuletzt die Diskussionen um Angriffe auf gitterbasierte Verfahren zeigten.
Quantencomputer – ein kryptografisch relevanter Quantencomputer (CRQC) würde RSA, ECDSA und Diffie-Hellman mittels Shors Algorithmus in polynomialer Zeit brechen.

Die strategische Antwort auf diese Bedrohungen trägt einen Namen: Kryptoagilität – die architektonische Fähigkeit, kryptografische Verfahren in bestehenden Systemen zügig und ohne disruptive Umbaumaßnahmen austauschen zu können (vgl. Fraunhofer SIT: Kryptoagilität). Kryptoagilität ist keine Option mehr. Sie ist eine Überlebensfähigkeit.

Die Quantenbedrohung: Näher als viele glauben

Lange Zeit galt ein kryptografisch relevanter Quantencomputer (CRQC) als akademische Spekulation. Doch die Faktenlage hat sich verdichtet:

2015 veröffentlichte Prof. Michele Mosca, Mitgründer des Institute for Quantum Computing an der University of Waterloo, eine vielbeachtete Risikoabschätzung: Die Wahrscheinlichkeit, dass die heute eingesetzte Public-Key-Kryptografie durch einen Quantencomputer gebrochen wird, liege bei ca. 14 % bis 2026 und bei 50 % bis 2031 (Mosca 2015, eprint.iacr.org/2015/1075).
2016 rief das NIST den Standardisierungsprozess für Post-Quantum Cryptography (PQC) ins Leben. In der Begründung (NIST IR 8105) hieß es unmissverständlich: Ein CRQC könne innerhalb von ein bis zwei Jahrzehnten zur realen Bedrohung werden.
August 2024 veröffentlichte das NIST die finalen PQC-Standards: FIPS 203 (ML-KEM, basierend auf CRYSTALS-Kyber), FIPS 204 (ML-DSA, basierend auf CRYSTALS-Dilithium) und FIPS 205 (SLH-DSA, basierend auf SPHINCS+). Der Werkzeugkasten für die Post-Quanten-Ära existiert. Die Standards sind da.
2025 und darüber hinaus setzt sich die Standardisierungsdynamik fort: Mit FIPS 206 (FN-DSA, basierend auf FALCON) steht ein weiterer NIST-Standard für digitale Signaturen kurz vor der Veröffentlichung – ein Verfahren, das insbesondere durch kompakte Signaturen bei gleichzeitig moderaten Schlüsselgrößen besticht. Parallel dazu treibt die ISO die Standardisierung zweier Verfahren voran, die bewusst auf konservativere – und damit besser verstandene – mathematische Grundlagen setzen: FrodoKEM, dessen Sicherheit auf dem allgemeinen Learning-with-Errors-Problem (LWE) ohne Gitterstruktur basiert, sowie Classic McEliece, ein codebasiertes Verfahren mit über 40 Jahren kryptoanalytischer Resistenz (vgl. BSI TR-02102-1, Kryptografische Verfahren: Empfehlungen und Schlüssellängen, Version 2026-01, Abschnitte 2.4.1 & 2.4.2). Damit zeichnet sich ein diversifiziertes PQC-Ökosystem ab – eines, das nicht von einer einzelnen mathematischen Annahme abhängt und der Forderung nach Kryptoagilität auch auf Verfahrensebene Rechnung trägt.

Ein bemerkenswertes Detail verdient besondere Aufmerksamkeit: Anders als bei der Kernfusion, die stets „in 50 Jahren“ einsatzbereit sein soll – egal, wann man fragt –, hat sich die Einschätzung der Krypto-Community zum Zeithorizont eines CRQC über das letzte Jahrzehnt nicht nach hinten verschoben. Die Prognosen konvergieren beständig auf den Zeitraum 2030 bis 2035. Das ist keine vage Zukunft. Das ist dieses Jahrzehnt.

Harvest Now, Decrypt Later – die Bedrohung von heute

Die Quantenbedrohung ist keine Zukunftsmusik – sie materialisiert sich bereits. Unter dem Paradigma „Harvest now, decrypt later“ (HNDL) werden heute verschlüsselt übertragene Daten von staatlichen Akteuren und nachrichtendienstlichen Einheiten systematisch abgefangen und gespeichert, um sie zu einem späteren Zeitpunkt mit einem CRQC zu entschlüsseln.

Betroffen sind alle Daten, deren Vertraulichkeit über den Zeitpunkt der Übertragung hinaus Bestand haben muss: Staatsgeheimnisse, medizinische Daten, Geschäftsgeheimnisse, Verhandlungspositionen, Quellenschutz. Wer heute verschlüsselt kommuniziert, aber klassische Verfahren nutzt, gewährt retrospektive Einsicht, sobald ein CRQC verfügbar ist.

Die Bedrohung durch Quantencomputer ist daher nicht erst in zehn Jahren relevant. Sie ist es bereits jetzt.

Moscas Ungleichung: Warum die Schere bereits aufgegangen ist

Die eigentliche Eskalation liegt nicht im Quantencomputer selbst – sie liegt in der Asymmetrie zwischen Angriffs- und Verteidigungstempo.

Filippo Valsorda, einer der profiliertesten Stimmen im Bereich angewandter Kryptografie, hat diese Dynamik in einer vielbeachteten Analyse (words.filippo.io/crqc-timeline) auf den Punkt gebracht: Mit jedem Durchbruch in der Quantenfehlerkorrektur komprimiert sich die prognostizierte Zeitlinie für einen CRQC, während sich gleichzeitig die für eine vollständige kryptografische Migration benötigte Zeit als erschreckend lang erweist.

Das formalisiert Moscas Ungleichung:

x + y < z

x = benötigte Migrationszeit, y = geforderte Schutzfrist der Daten, z = verbleibende Zeit bis zum CRQC

Sobald x + y > z (die Summe aus Migrationszeit und Schutzbedarf die verbleibende Zeit bis zum CRQC übersteigt) ist das Zeitfenster für eine rechtzeitige Absicherung unwiderruflich geschlossen. Jeder Tag ohne begonnene Migration ist ein Tag, an dem die Schere weiter aufgeht. Es gibt keinen Weg, verlorene Zeit zurückzugewinnen.

Die konvergierenden Signale sind eindeutig: Google demonstrierte im Dezember 2024 mit dem Quantenprozessor Willow erstmals eine skalierende Quantenfehlerkorrektur unterhalb der Fehlerschwelle, wie sie seit den 1990er‑Jahren theoretisch vorhergesagt wurde. Die Ergebnisse, veröffentlicht in der wissenschaftlichen Fachzeitschrift Nature, zeigen, dass logische Qubits mit wachsender Größe exponentiell zuverlässiger werden. Ein Durchbruch, der Quantencomputing von einem physikalischen Experiment zu einer ingenieurtechnisch beherrschbaren Technologie und damit das Narrativ „Quantencomputer sind noch Jahrzehnte entfernt“ endgültig obsolet macht.

IBM, Google und Microsoft haben in den Jahren 2024–2025 konsistente Roadmaps veröffentlicht, die jeweils explizit auf fehlerkorrigierte (fault‑tolerante) Quantensysteme abzielen (Roadmap IBM, Roadmap Google, Roadmap Microsoft). Obwohl sie unterschiedliche Hardware‑Ansätze verfolgen, konvergieren ihre Zeitpläne auf die späten 2020er Jahre, mit ersten großskaligen, logisch geschützten Quantensystemen bis zum Ende dieses Jahrzehnts.

Nationale Sicherheitsbehörden gehen heute explizit davon aus, dass staatliche Akteure bereits verschlüsselten Datenverkehr massenhaft erfassen und langfristig speichern, um ihn mit zukünftigen kryptografischen Durchbrüchen – insbesondere durch Quantencomputer – nachträglich zu entschlüsseln. Dieses bereits weiter oben benannte Vorgehen ist als Harvest Now, Decrypt Later (HNDL) bekannt und wird in aktuellen Regierungs‑, Industrie‑ und Aufsichtsberichten als gegenwärtige, operative Realität beschrieben (stateofsurveillance.org, federalreserve.gov).

Damit hat sich die zentrale Frage verschoben: Es geht nicht mehr darum, ob die heutige Public-Key-Kryptografie fällt, sondern ob unsere Infrastrukturen schnell genug umgerüstet sein werden, wenn es so weit ist.

Was jetzt zu tun ist

Das klingt düster, ist aber kein Grund zur Resignation. Es ist ein Grund zum Handeln. Der Werkzeugkasten existiert. Die Standards sind verabschiedet. Die Migrationspfade werden klarer. Was fehlt, ist nicht Technologie. Was fehlt, ist Entschlossenheit und begonnene Arbeit.

Fünf Schritte, die Sie diese Woche anstoßen können:

Kryptografisches Inventar erstellen: Sie können nicht migrieren, was Sie nicht kennen. Erfassen Sie systematisch, wo in Ihrer Infrastruktur welche kryptografischen Verfahren im Einsatz sind – von TLS-Konfigurationen über VPN-Tunnel bis hin zu Signaturverfahren in CI/CD-Pipelines und Firmware-Updates. Das BSI bezeichnet diesen Schritt als unverzichtbare Grundlage jeder Migrationsstrategie.
Daten nach Schutzfrist klassifizieren: Nicht alle Daten sind gleich betroffen. Identifizieren Sie Assets, deren Vertraulichkeit oder Integrität über 2030 hinaus gewährleistet sein muss. Diese Daten stehen unter akuter HNDL-Bedrohung und erfordern priorisierte Migration.
Kryptoagilität architektonisch verankern: Kryptografische Verfahren dürfen nicht hart in Anwendungen und Protokolle eingebrannt sein. Abstraktionsschichten, konfigurierbare Cipher-Suites und modulare Kryptobibliotheken sind die Voraussetzung dafür, dass die PQC-Migration nicht zum Großprojekt mit Zeithorizont 2035 wird.
Hybride Ansätze jetzt evaluieren und pilotieren: Die NIST-Standards (ML-KEM, ML-DSA, SLH-DSA) sind final. Große Anbieter wie Cloudflare, Google und Signal setzen bereits hybride Verfahren (klassisch + PQC) in Produktion ein. Pilotieren Sie hybride TLS-Konfigurationen und Key-Encapsulation in Ihren kritischsten Kommunikationskanälen.
Migration als strategisches Programm aufsetzen – nicht als Technikprojekt: Selbst bei guter Kryptoagilität bleibt die PQC-Migration mehr als ein Algorithmentausch. Sie betrifft Procurement-Anforderungen, Compliance-Nachweise, Partnerkommunikation, Zertifikats-Lifecycles und Legacy-Systeme, die sich nicht per Konfigurationsänderung umstellen lassen. Diese organisatorische Breite erfordert ein Mandat auf Leitungsebene, ein dediziertes Budget und einen realistischen, aber ambitionierten Zeitplan. Kryptoagilität verkürzt die technische Migrationszeit erheblich. Aber nur ein strategisches Programm stellt sicher, dass auch alles drumherum rechtzeitig mitkommt.

Moscas Ungleichung ist keine Abstraktion. Sie ist eine Stoppuhr – und sie läuft. Jeder Tag, an dem Ihre Organisation die Post-Quanten-Migration nicht aktiv vorantreibt, ist ein Tag, an dem sich das Zeitfenster für eine geordnete Transition weiter schließt. Die gute Nachricht: Wer heute beginnt, hat noch die Chance, vor der Kurve zu sein statt hinter ihr. Die Standards stehen. Die Werkzeuge reifen. Die Early Movers haben angefangen.

Die Frage ist nicht mehr, ob Sie migrieren müssen. Die Frage ist, ob Sie es rechtzeitig tun.

Fangen Sie an. Heute.

15. Mai 2026Risikomanagement

Copy Fail, Dirty Frag, Dirty Pipe – Warum SELinux Ihr bester Schutz gegen Local Privilege Escalation ist

Copy Fail, Dirty Frag, Dirty Pipe: Unterschiedliche Exploits mit dem gleichen Ziel: Local Privilege Escalation (LPE). Diese Klasse von Verwundbarkeiten ist häufig anzutreffen. Wenngleich sie nicht so problematisch wie Remote Code Execution (RCE)-Schwachstellen sind, ermöglichen sie Angreifenden durch die Erhöhung der Rechte weitere Möglichkeiten zur Ausbreitung und zur Ausführung von Schadsoftware. Daraus lassen sich nun, je nach Bedarf, unterschiedliche Blickwinkel betrachten. Wir könnten technisch auf die Verwundbarkeiten eingehen und sie beschreiben. Auch spannend ist die Methodik der Sicherheitsforschenden, und ob und wie „künstliche Intelligenz“ dafür eingesetzt wurde. Oder wir könnten Unterschiede zu anderen Schwachstellen dieser Art hervorheben.

Aber in diesem Digest (und in unserer täglichen Arbeit) sind wir pragmatischer und stellen uns die Frage: Wie geht man mit diesen Schwachstellen um? Die Ausnutzung von Schwachstellen ist – außer bei bewusst implementierten Backdoors – auf die Existenz von Defekten angewiesen, sogenannten Bugs. Die Sicherheit eines Systems ist daher darauf angewiesen, dass alle Bestandteile von Hardwarelogik bis Applikation „korrekt“ funktionieren. Eine Möglichkeit, Fehler aufzufangen, ist die Verwendung von Mandatory Access Control (MAC) in Form der SELinux-Erweiterung. Dadurch können Policies festgelegt werden, die den Zugriff auf Dateien und Systemkomponenten festlegen. In dieser Konstellation reicht dann die Korrektheit der eingestellten Policies (und der SELinux-Implementierung), um einen sicheren Betrieb des Systems zu ermöglichen. Ein praktisches Beispiel bietet ein Blick auf Mobil-Betriebssysteme. GrapheneOS hat dazu einige erläuternde Hinweise.

Aus unserer Sicht unterstützen die Lücken unsere in einem vorherigen Digest formulierte Erwartung, dass sich das Security-Modell im Desktop- und Serverbereich sukzessive an das aus dem Mobilbereich anpassen wird. Auch wenn das Thema SELinux eher in den Aufgabenbereich der eingesetzten Distribution fällt, können Sie durch kleine Konfigurationen viel Angriffsoberfläche reduzieren. Sprechen Sie uns gerne an, wenn wir Sie dabei unterstützen können.

https://discuss.grapheneos.org/d/35110-grapheneos-is-protected-against-copy-fail-and-similar-vulnerabilities-by-selinux

https://en.wikipedia.org/wiki/SELinux

https://copy.fail

https://github.com/V4bel/dirtyfrag

https://infosec.exchange/@jrt/116537982697417546

4. Mai 2026Penetrationstest, Red Teaming

Vom Pentester zum Red Teamer: Wie wir neue Mitarbeitende fit machen

Der Schritt vom Pentester zum Red Teamer klingt nach einer logischen Weiterentwicklung. In der Praxis zeigt sich jedoch schnell, dass es kein gradueller Ausbau bestehender Fähigkeiten ist, sondern ein echter Perspektivwechsel. In diesem Artikel beschreiben wir, wie wir neue Mitarbeitende auf genau diesen Wechsel vorbereiten – und was dabei wirklich den Unterschied macht.

Der häufigste Irrtum

Mitarbeitende, die sich für das Red-Teaming-Thema interessieren, kommen häufig aus dem Infrastruktur- oder Active-Directory-Pentesting und gehen davon aus, dass der Schritt hinüber ins Red Teaming ein kleiner sein wird.

In der Praxis zeigt sich jedoch schnell: Red Teaming ist kein erweiterter Penetrationstest, sondern ein anderer Ansatz.

Während klassische Penetrationstests darauf abzielen, möglichst viele Schwachstellen in einem begrenzten Zeitfenster zu identifizieren, geht ein Red-Team-Assessment deutlich weiter. Es kombiniert technische Angriffe, physische Zutrittsversuche und Social Engineering, um die Wirksamkeit technischer, organisatorischer und menschlicher Abwehrmaßnahmen ganzheitlich zu überprüfen.

Im Fokus steht dabei nicht primär das schnelle Finden von Schwachstellen, sondern das möglichst realitätsnahe Emulieren eines Angreifers. Dazu gehört es auch, über längere Zeiträume unentdeckt zu bleiben, um tatsächliche Angriffsverläufe und Reaktionsfähigkeiten unter realen Bedingungen bewerten zu können.

Dieses Ziel erfordert ein anderes Mindset, angepasste Herangehensweisen und die Fähigkeit, das eigene Vorgehen kontinuierlich zu hinterfragen und weiterzuentwickeln.

Erfahrung im Infrastruktur-Penetrationstest ist aus unserer Sicht dabei aber eine sehr gute Basis.

Insbesondere sollten neue Red Teamer gängige Active-Directory-Angriffe sicher beherrschen, typische Fehlkonfigurationen erkennen und ein solides Verständnis für etablierte Tools und Techniken mitbringen. Ohne dieses Fundament wird Red-Teaming schnell zu blindem Tool-Einsatz.

Die entscheidenden Unterschiede: Mindset und OPSEC

Die größten Unterschiede liegt nicht primär in den verwendeten Tools, sondern im Mindset und Herangehensweise.

Ein Red Teamer muss kontinuierlich reflektieren, welche Spuren das eigene Handeln hinterlässt und wie ein Verteidiger darauf reagieren könnte. Jede Aktion sollte bewusst hinterfragt werden, insbesondere im Hinblick auf ihre Sichtbarkeit.

Operational Security (OPSEC) wird damit zu einem zentralen Element. Es geht nicht primär darum, ein Ziel möglichst schnell zu erreichen, sondern ein realistisches Angriffsszenario abzubilden. In der Praxis bedeutet das häufig, bewusst auf den vermeintlich einfacheren oder direkteren Weg zu verzichten und stattdessen einen Ansatz zu wählen, der besser zur angenommenen Angreiferperspektive passt.

Dieses Umdenken erfordert Zeit und entsteht nicht allein durch Theorie oder Zertifizierungen, sondern vor allem durch praktische Erfahrung.

Kontinuierliches Lernen als Grundvoraussetzung

Red Teaming ist ein Bereich mit kurzer Halbwertszeit. Erkennungsmechanismen entwickeln sich stetig weiter und Standard-Tools werden zunehmend zuverlässig erkannt.

Wer sich nicht kontinuierlich weiterbildet, wird zwangsläufig sichtbar.

Deshalb ist aus unserer Sicht die Lernbereitschaft einer der wichtigsten Faktoren. Eigenständiges Einarbeiten in neue Themen, das Verfolgen aktueller Entwicklungen und ein generelles Interesse an der Materie sind entscheidend.

Diese Eigenschaft ist im Red Teaming oft wichtiger als im klassischen Penetrationstest, da sich die Anforderungen deutlich schneller verändern und die Konsequenzen von Erkennung eine andere Tragweite haben. Während in klassischen Penetrationstest auch ältere Tools oder bekannte Techniken häufig weiterhin zuverlässig funktionieren und eine Erkennung für das Ergebnis meist weniger kritisch ist, kann im Red Teaming eine Entdeckung das gesamte Szenario beeinflussen oder vorzeitig beenden.

Sinnvolle Zertifizierungen und Trainings

Zertifizierungen können beim Einstieg helfen, sollten aber nicht als Selbstzweck verstanden werden.

Als besonders praxisnah haben sich die Trainings von ZeroPoint Security erwiesen. Insbesondere der CRTO (Certified Red Team Operator) und CRTL (Certified Red Team Lead) vermitteln ein gutes Grundverständnis für Red-Team-Operationen, Operational Security und strukturierte Vorgehensweisen.

Sie eignen sich daher gut, um ein erstes Gefühl für die Denkweise im Red-Teaming zu entwickeln.

Ergänzend können weitere Trainings sinnvoll sein (beispielweise „wie baue ich eine sichere Red Team Infrastruktur auf“, „wie entwickle ich eigene Malware“ oder Weiterbildungen im Bereich Social Engineering oder physische Pentests), wobei der Fokus weniger auf der Menge an Zertifikaten liegen sollte, sondern auf deren inhaltlichem Mehrwert und darauf abgestimmt sein sollte, welche Skills im Team noch fehlen.

Programmierkenntnisse als Multiplikator

Ein oft unterschätzter Aspekt im Red Teaming ist die Fähigkeit, Code zu verstehen und anzupassen.

Kenntnisse in Programmiersprachen wie C sind besonders hilfreich, um bestehende Tools zu modifizieren und deren Erkennung zu erschweren. Viele Sicherheitslösungen arbeiten unter anderem mit statischen Signaturen, die sich durch kleinere Anpassungen im Code umgehen lassen.

Wer in der Lage ist, Werkzeuge selbst anzupassen oder neue Artefakte zu entwickeln, erweitert seine Möglichkeiten erheblich und reduziert die Abhängigkeit von bekannten Tools.

Dies ist häufig ein entscheidender Unterschied zwischen reinem Tool-Einsatz und einem tieferen technischen Verständnis.

Lernen durch Fehler: Der Moment, der alles verändert

Ein Aspekt, der in der Ausbildung von Red Teamern oft unterschätzt wird, ist der Umgang mit Fehlern.

Früher oder später wird es passieren, dass eine Aktion unmittelbar zur Erkennung führt. Dieser Moment ist unangenehm, aber gleichzeitig äußerst lehrreich.

Er zwingt dazu, das eigene Vorgehen kritisch zu hinterfragen und verändert nachhaltig die eigene Perspektive auf Angriffe und deren mögliche Erkennungsmechanismen.

Statt nur zu überlegen, ob eine Technik funktioniert, rücken andere Fragen in den Vordergrund: Warum wird dieser Befehl ausgeführt? Woran könnte ein Verteidiger diese Aktivität erkennen? Welche Telemetrie entsteht dabei? Wie hoch ist das Risiko und ist es vertretbar?

Genau diese Überlegungen sind zentral für das Red-Teaming. Fehler sind dabei kein Rückschritt, sondern ein notwendiger Teil des Lernprozesses.

Aus unserer Erfahrung sind es häufig genau diese Situationen, in denen sich das notwendige Mindset nachhaltig entwickelt.

Fazit

Der Weg vom Penetrationstest zum Red Teaming ist kein reiner Ausbau bestehender Fähigkeiten, sondern erfordert ein Umdenken.

Eine solide technische Grundlage, insbesondere im Bereich Active Directory, bleibt essenziell. Gleichzeitig gewinnen Themen wie Operational Security, kontinuierliches Lernen und technisches Tiefenverständnis deutlich an Bedeutung.

Zertifizierungen können dabei unterstützen, ersetzen jedoch nicht die praktische Erfahrung und die Bereitschaft, sich stetig weiterzuentwickeln.

Entscheidend ist letztlich die Fähigkeit, das eigene Handeln kritisch zu reflektieren und sich kontinuierlich an veränderte Rahmenbedingungen anzupassen.

9. April 20269. April 2026Schwachstelle

Stryker-Breach: Wenn das eigene MDM zur Waffe wird

Am 11. März 2026 löschte die iranisch-verlinkte Hacktivistengruppe Handala über Microsofts Intune-Wipe-Funktion nahezu 80.000 Geräte des Medizintechnik-Konzerns Stryker. Stryker meldete keine Hinweise auf Ransomware/Malware in der eigenen Umgebung. Der Angriff erfolgte durch den Missbrauch von cloud-basierten Diensten zur Administration der Endgeräte. Für die destruktive Phase war keine zusätzliche Malware auf den Endpoints nötig. Der Angriff missbrauchte legitime Intune‑Wipe‑Funktionen. Der initiale Angriffsweg, mit dem sich die Täter Zugang zur Cloud verschafften (Credential Theft), bleibt jedoch unklar.

Der Fall illustriert ein strukturelles Risiko, das viele Organisationen unterschätzen: Wenn eine einzelne Steuerungsebene Code ausrollen, Konfigurationen ändern oder Geräte auf Unternehmensebene löschen kann, ist sie kein „einfaches Endpoint-Management“ mehr, sondern verhält sich wie kritische Infrastruktur. Ein Angreifender mit Intune-Administrator-Zugang braucht keine Malware – er kann Konfigurationsänderungen verteilen, die VPN oder WLAN lahmlegen, Skripte laufen lassen, die Sicherheitsfunktionen deaktivieren, den Compliance-Status manipulieren – sodass Conditional-Access-Nutzer aussperrt werden – und gleichzeitig Endpoints aus der Ferne löschen, um die Recovery zu verlangsamen.

CISA reagierte am 18. März mit einem Alert und forderte US-Organisationen auf, ihre Intune-Umgebungen gegen ähnliche Angriffe zu härten. Die Kernempfehlungen: Einen Least-Privilege-Ansatz über Intunes RBAC realisieren, bei dem nur die tatsächlich benötigten Berechtigungen vergeben werden. Dazu kommen Multi-Faktor-Authentisierung (MFA) und privilegierte Zugriffshygiene über Conditional Access, Risk Signals und Microsoft Entra ID sowie Multi-Admin-Approval für sensible Aktionen wie Device Wipes, Anwendungsänderungen und RBAC-Modifikationen.

Das reicht allerdings nicht. Diese Empfehlungen härten zwar den administrativen Zugang, adressieren aber nicht die tieferliegende Architektur-Realität: Intune fungiert inzwischen als Teil der Identity Control Plane und muss wie Identity-Infrastruktur geplant, betrieben und überwacht werden. Konkret bedeutet das eine Tier-0-Behandlung: Für administrative Zugänge müssen phishing-resistente MFA-Verfahren wie FIDO2 oder Hardware-Token verbindlich sein; zugleich sollte der Zugriff auf die Intune-Administrationsoberfläche auf gemanagte und konforme Geräte beschränkt werden. Privilegierte Rollen dürfen nicht dauerhaft zugewiesen sein, sondern sollten über Privileged Identity Management (PIM) nur zeitlich begrenzt und nachvollziehbar aktiviert werden. Ebenso wichtig ist ein aktives Monitoring mit Alarmierung auf sicherheitskritische Ereignisse – insbesondere auf Anmeldungen privilegierter Konten sowie auf die Anlage, Änderung oder Rechteausweitung administrativer Identitäten. Schließlich müssen Audit- und Sign-in-Logs über die standardmäßigen Aufbewahrungsfristen hinaus gesichert werden, damit auch verzögert erkannte Kompromittierungen forensisch belastbar rekonstruierbar bleiben.

Das Fazit ist unbequem: Wenn eine Plattform Policies durchsetzen, Zugriff entziehen und den Betrieb auf Unternehmensebene mit Admin-Aktionen stören kann, verdient sie dieselbe architektonische Disziplin wie Identity-Systeme. Der Stryker-Breach ist der Proof of Concept dafür, dass MDM-Plattformen Tier-0-Assets sind – ob Organisationen sie so behandeln oder nicht.

https://www.bleepingcomputer.com/news/security/cisa-warns-businesses-to-secure-microsoft-intune-systems-after-stryker-breach

https://therecord.media/stryker-cyberattack-iran-hackers

Comment
byu/virtualbitz2048 from discussion
incybersecurity

https://petri.com/why-microsoft-intune-belongs-in-the-tier-0-identity-control-plane

25. März 202627. März 2026ISMS

Grundschutz++: Mehr Resilienz in der Informationssicherheit?

Der IT-Grundschutz des Bundesamtes für Sicherheit in der Informationstechnik (BSI) steht vor einer umfassenden Weiterentwicklung. Mit dem Grundschutz++ (GS++) löst das BSI die statische, dokumentenzentrierte Bereitstellung von Sicherheitsanforderungen im IT-Grundschutz-Kompendium ab und etabliert ein maschinenlesbares Regelwerk für die Ära der NIS-2-Richtlinie. Das BSI bildet das Regelwerk dabei in einem maschinenlesbaren digitalen Format (OSCAL/JSON) ab – ein Ansatz, der in der Fachwelt auch als „Compliance as Code“ oder „Rules as Code“ diskutiert wird (im Folgenden wird auf den Begriff „Compliance as Code“ referenziert). Durch die Konsolidierung der bisherigen 111 Bausteine auf 19 Praktiken eröffnet der GS++ das Potenzial, Informationssicherheitsmanagementsysteme (ISMS) von einem relativ statischen Konstrukt hin zu einem schrittweise automatisierbaren und agilen System weiterzuentwickeln. Hierbei strebt das BSI eine Harmonisierung mit der ISO/IEC 27001:2022 an. Parallel dazu werden die methodischen Eckpfeiler der BSI-Standards 200-x systematisch in ein digitales Format überführt.

Dieser Artikel geht auf die beiden folgenden Fragen ein:

Wie kann die mit dem GS++ einhergehende Automatisierung die Resilienz eines ISMS steigern?
Welche Herausforderungen können sich in der Umstellung auf GS++ in der Praxis ergeben?

Der GS++ schafft die strukturellen Voraussetzungen für eine kontinuierlich prüfbare Informationssicherheit und stärkt damit die organisatorische Resilienz. Der Übergang von einer punktuellen Momentaufnahme zur dauerhaften Überwachung des Soll-Ist-Zustands erfordert jedoch eine erhöhte technische Kompetenz aller Beteiligten und eine frühzeitige Investition in OSCAL-fähige Tools.

Vom statischen Katalog zum digitalen Regelwerk¹

Seit Mitte der 1990er Jahre hat sich der IT-Grundschutz des BSI als frei verfügbare Vorgehensweise für die Umsetzung eines ISMS für Behörden, Unternehmen und Organisationen in Deutschland etabliert –unter anderem aufgrund der Verpflichtungen aus dem BSI-Gesetz und dem Umsetzungsplan Bund (UP Bund). Das ISMS definiert dabei den Rahmen für die systematische Steuerung, Überwachung und kontinuierliche Verbesserung der Informationssicherheit, um Geschäftsrisiken zu minimieren und die Resilienz zu stärken. In einer Welt von hochdynamischen Gefährdungsszenarien und agiler Softwareentwicklung stößt das bisherige Kompendium mit 111 Bausteinen und über 6.500 Teilanforderungen jedoch an seine Grenzen. Analysen und Erfahrungen aus der Beraterpraxis belegen, dass die umfangreiche Prosa des IT-Grundschutz-Kompendiums, regelmäßig zu Ungenauigkeiten bei der Maßnahmenumsetzung führt. Komplexe technische Abhängigkeiten in einem Informationsverbund lassen sich manuell kaum noch vollumfänglich und lückenlos pflegen.

Der GS++ löst diese Problematik durch eine Verschlankung oder konkreter ausgedrückt durch eine Konsolidierung auf „atomare“ Anforderungen. Konkret heißt das als Zielbild: Einzeln prüfbare, eindeutig formulierte Sicherheitsanforderungen, die jeweils exakt einen Sachverhalt adressieren, führen zu einem erheblich praktikableren Setup. Die Anzahl der Anforderungen im GS++ reduziert sich auf rund 1000 Anforderungen, was einer quantitativen Straffung des Gesamtkatalogs um ca. 85 % entspricht. Diese Verschlankung ergibt sich aus einem umfangreichen Prozess, der vom BSI angeführt und von der Grundschutz++ Community mit fachlicher Expertise begleitet wird. Anforderungen wurden im Zuge dessen bereinigt, zusammengeführt und auf ihren wesentlichen Regelungsgehalt reduziert. Trotz dieser erheblichen Komplexitätsreduktion sollen keine sicherheitsrelevanten Detailaspekte im GS++ entfallen. Dies wird durch den Wechsel von der dokumentationslastigen und zielobjektorientierten Ausrichtung des IT-Grundschutz zu einer hierarchischen Zielobjekt-Kategorisierung erreicht. Sicherheitsanforderungen werden dabei nicht mehr für jedes einzelne Zielobjekt im Informationsverbund separat modelliert, sondern vererben sich entlang einer definierten Hierarchie von Kategorien auf untergeordnete Objekte – analog zum Vererbungsprinzip beim Schutzbedarf im klassischen IT-Grundschutz (z. B. von der Anwendung über das IT-System bis zur baulichen Infrastruktur). Die bisherigen drei Einstufungen des Schutzbedarfs sind im GS++ nun auf zwei Schutzniveaus (normal-SdT²/erhöht) reduziert.

Metrik	IT-Grundschutz (Edition 2023)	Grundschutz++
Anzahl Anforderungen	6.567 (Teilanforderungen)	985 (atomisierte Anforderungen)
Primäres Format	PDF (Prosa-Text)	OSCAL / JSON (maschinenlesbar)
Strukturierung	111 Bausteine / 10 Schichten	19 Praktiken (Governance, Personal etc.)
Einstufung	3 Schutzbedarfs-Stufen (normal / hoch / sehr hoch)	2 Sicherheitsniveaus (normal-SdT/ erhöht)
Fokus	Zielobjekt-orientiert	Prozess-orientiert
Update-Zyklus	Jährlich / statisch und langwierig	kontinuierlich und agil
Prüfbarkeit	manuell, stichprobenartig	Teil- oder vollautomatisierbare Prüfungen (Zielbild)

Tabelle 1: Struktureller Vergleich IT-Grundschutz 2023 vs. Grundschutz++

Vier wesentliche Neuerungen können im Grundschutz++ im Vergleich zum IT-Grundschutz identifiziert werden:

Governance-Shift – Verantwortlichkeit bei den Risikoeigentümern („risk owners“)
Effizienz durch Konsolidierung – Praktiken statt Bausteine
„Compliance as Code“ – Automatisierung mit OSCAL
Methodische Migration und Überführung

Dieser Artikel fokussiert bewusst auf die Punkte (3) und (4), da sie im Hinblick auf die Umsetzung sowie Migration eines ISMS den operativen Handlungsbedarf für Organisationen definieren. Herausforderungen in der praktischen Umsetzung mittels ISMS-Tools werden thematisiert und Lösungswege aufgezeigt. Die Punkte (1) und (2) betreffen primär strategische und inhaltliche Entscheidungen auf Governance-Ebene und werden mitbetrachtet.

Compliance as Code

Zunächst ist das OSCAL-Format (Open Security Controls Assessment Language) als technologischer Kern des GS++ zu umreißen. OSCAL ist in drei logische Ebenen („layers“) unterteilt:

Anforderungsebene bzw. Controls Layer (Kataloge und Profile)
Implementierungsebene bzw. Implementation Layer (Komponenten-Modelle und System-Sicherheitspläne, sog. System Security Plans, SSP)
Bewertungsebene bzw. Assessment Layer (Prüfpläne und Ergebnisse)

OSCAL strukturiert die Sicherheitsanforderungen in einem maschinenlesbaren Standard und ermöglicht so technische Interoperabilität zwischen ISMS-Tools und Katalogen. „Compliance as Code“ bezeichnet dabei die maschinenlesbare, versionierbare Repräsentation von Sicherheitsanforderungen und deren automatisierte Prüfbarkeit im institutionellen Kontext. CaC ermöglicht dabei das Ziel der Automatisierung, ist allerdings keine Voraussetzung für eine Implementierung oder Migration: So sieht die BSI-Methodik ausdrücklich vor, dass die Standardvorgehensweise auch ohne spezialisierte Werkzeuge durchgeführt werden kann. Perspektivisch empfiehlt das BSI jedoch, ein ISMS mit GS++ durch ein Tool zu betreiben. OSCAL selbst unterstützt die Formate JavaScript Object Notation (JSON), Extensible Markup Language (XML) und YAML (YAML Ain’t Markup Language). Das BSI hat sich beim GS++ für JSON als primäres Datenformat entschieden.

Anforderungen sind durch die drei folgenden Aspekte inhaltlich und technisch gekennzeichnet:

1. Atomisierung und Eindeutigkeit: Jede Anforderung ist atomar aufgebaut und besitzt einen Universally Unique Identifier (UUID), z. B. bf5d3cde-1c6b-4329-9a10-fdbe84279177. Dieser UUID erlaubt konzeptionell eine lückenlose digitale Rückverfolgbarkeit („traceability“). In der Katalog-Datei Grundschutz++-catalog.json ist jede Anforderung zusätzlich mit Metadaten über BSI-spezifische Namensräume („namespaces“) verknüpft. Diese Namespaces sind eine der zentralen Neuerungen des GS++: Sie erlauben eine mehrdimensionale algorithmische Filterung und Zusammenstellung von Anforderungen für spezifische Anwendungszwecke – etwa alle Anforderungen mit einem definierten Umsetzungsaufwand („Effort Level“), für eine bestimmte Zielobjektkategorie (z. B. IT-Systeme) sowie mit einem Modalverb (MUSS, SOLLTE, KANN). Erst diese Systematik ermöglicht die anwendungsspezifische Auswahl und maschinelle Auswertung des Katalogs. Ein fehlerhafter Umgang mit diesen BSI-spezifischen Erweiterungen für Modalverben führt dabei unweigerlich zu inkonsistenten Compliance-Aussagen.

Abbildung 1: Aufbau einer GS++-Anforderung am Beispiel DET.3.1 – Protokollierung sicherheitsrelevanter Ereignisse

2. Parametrisierung: Anforderungen enthalten Platzhalter, wie z. B. {{ retention_period }}. für die Vorhaltungsdauer von Datensätzen Die hinterlegten Parameter erlauben es, das angestrebte Sicherheitsniveau einer Institution präzise im „Profile Model“ zu definieren, ohne den zugrundeliegenden Katalog zu verändern.

3. Kontinuierliche Aktualisierung: Die Anforderungen werden im Rahmen des GS++-Katalog über das GitHub-Repository „Stand-der-Technik-Bibliothek“ des BSI bereitgestellt und fortlaufend aktualisiert. Es kann von ISMS-Tools direkt abgerufen und verarbeitet werden. Technisch ausgedrückt erfolgt die Bereitstellung mithilfe einer Continuous Integration / Continuous Deployment (CI/CD)-Pipeline. Ein wesentlicher Vorteil des GS++ zum IT-Grundschutz liegt dabei nicht nur in der höheren Aktualisierungsfrequenz und der Geschwindigkeit, sondern in der Vollständigkeit: Automatisierte Systeme können alle vorliegenden Dokumente, Einträge und Konfigurationen lückenlos prüfen und kontinuierlich überwachen. Die automatisierte Validierung von Systemzuständen gegen den Anforderungskatalog (gewissermaßen als „Single Source of Truth“) kann die Fehlerquote durch menschliche Fehlinterpretationen reduzieren und erlaubt eine zeitnahe Reaktion auf Sicherheitsvorfälle – im Idealfall nahezu in Echtzeit. Wichtig ist dabei die konzeptionelle Trennung: Die kontinuierliche Aktualisierung des Anforderungskatalogs durch das BSI ist ein separater Prozess von der operativen Überwachung der Anforderungsumsetzung im ISMS des jeweiligen Informationsverbunds – letzterer erfordert eigene Mechanismen auf Systemebene (siehe Abschnitt zur Übersetzung bzw. „transition“).

Die maschinenlesbare OSCAL-Struktur eröffnet zudem Möglichkeiten der Kombination mit sprachverarbeitenden ML- bzw. KI-Modellen: Large Language Models (LLMs) können JSON-Daten maschinell auswerten und ihre Inhalte in natürlicher Sprache aufbereiten – etwa um Konformitätsanalysen von Konfigurationsdateien gegen den Anforderungskatalog darzustellen oder Hinweise zum Kontext eines Zielobjekt in der Umgebung (z. B. ein Switch im Netzwerk) für Verantwortliche zu generieren. Dies setzt jedoch eine sachgerechte Integration in den bestehenden Prüfprozess voraus und ersetzt keine regelbasierte Compliance-Prüfung.

Automatisierung als Treiber für Resilienz

Die beschriebenen Potenziale der Automatisierung der Anforderungsumsetzung wirken sich unmittelbar auf die Resilienz aus. Resilienz im Kontext eines ISMS bezeichnet die Fähigkeit einer Organisation, Sicherheitsvorfälle und regulatorische Veränderungen schnell zu erkennen, darauf zu reagieren und den Normalbetrieb kritischer Prozesse aufrechtzuerhalten. Vier Wirkpfade sind dabei besonders relevant:

Die kontinuierliche, automatisierte Überprüfung von Systemkonfigurationen gegen den Anforderungskatalog verkürzt die Zeit zwischen dem Entstehen einer Abweichung und ihrer Entdeckung erheblich – im klassischen IT-Grundschutz wurde eine solche Lücke oft erst bei einem IT-Grundschutz-Check (GSC) oder Audit aufgedeckt. Die Reduktion dieser Reaktionszeit (Mean Time to Detect, MTTD) ist ein zentraler Faktor für operative Resilienz.
Das automatisierte Versionsmanagement des Katalogs via Git ermöglicht es, dass regulatorische Änderungen am Stand der Technik zeitnah identifiziert und in den jeweiligen Informationsverbund überführt werden können. Dies unterstützt die Anpassungsfähigkeit des ISMS. Gemeint ist die Fähigkeit, das ISMS proaktiv an dynamische Bedrohungslagen anzupassen, anstatt auf festgestellte Gaps im Zuge von GSCs oder auf Findings aus Audits zu reagieren.
Die Automatisierung entlastet die verantwortlichen Sicherheitsteams von Routineaufgaben, wie zum Beispiel der Generierung von Umsetzungsnachweisen, dem Abgleich von Soll- und Ist-Werten und der Dokumentationspflege. Die Automatisierung und KI-gestützte Prüfung erhöht gleichzeitig die Anforderungen an die technische Kompetenz der Beteiligten. Sicherheitsteams, Berater und Auditoren müssen künftig nicht nur Anforderungen kennen und dokumentieren. Sie müssen vielmehr verstehen, wie Konfigurationsdateien, z. B. von Servern, Firewalls und Anwendungen, aufgebaut sind, wie Prüfskripte funktionieren und wie API-Schnittstellen zwischen ISMS-Tools und IT-Systemen belastbar und zuverlässig gestaltet werden. Der GS++ verschiebt den Kompetenzschwerpunkt also von der Beherrschung von rein textlich formulierten Anforderungen hin zur technischen Durchdringung des Informationsverbunds.
Bei einem Audit kann mithilfe der Verknüpfung der Systemkonfigurationen mit den Anforderungen folglich nicht nur das Vorhandensein einer dokumentierten Konfiguration überprüft werden, sondern auch mit geringem Mehraufwand die tatsächliche Umsetzung erfasst werden. Plakativ formuliert erfolgt eine Zertifizierung eines ISMS somit nicht mehr primär auf „Papierebene“ sondern auf Grundlage der tatsächlich umgesetzten und gelebten Informationssicherheit.

Ein praktisches Tool-Beispiel im Zusammenhang mit Audits ist, der von Sicherheitsexperten erstellte „BSI Audit Automator“. Das Tool verarbeitet bestehende Auditdaten, klassifiziert Quelldokumente nach BSI-Kategorien und generiert mehrstufig – hybrid aus KI-gestützter Analyse und deterministischer Berichtszusammenstellung – einen vollständigen BSI-Auditbericht im JSON-Format, einschließlich validierter Findings, Empfehlungen und Compliance-Assessment. Die Verarbeitung basiert auf zwei steuernden Konfigurationsdateien: einer strukturellen Blaupause (master_report_template.json), die definiert, was auditiert wird, und einer operativen Konfiguration (prompt_config.json), die steuert, wie auditiert wird. KI-gestützte Analysen und regelbasierte Auswertungen können sinnvoll kombiniert werden, um Zuverlässigkeit und Prüftiefe gleichzeitig zu gewährleisten.

Methodische Ansätze für eine effiziente Migration

Trotz der vom BSI angekündigten mehrjährigen Übergangsfrist bis zum Jahr 2029, sollten Unternehmen und Behörden möglichst frühzeitig operative Schritte einleiten:

Strukturierte Mapping-Qualitätssicherung: Bestehende Sicherheitskonzepte müssen gegen die 19 neuen Praktiken des GS++ validiert werden. Hierbei ist strikt zwischen direkter Übereinstimmung und indirekt unterstützenden Anforderungen zu unterscheiden, um Deckungslücken präzise zu identifizieren.
Blaupausen als Schablonen: Das Konzept der Blaupausen ist die Weiterentwicklung der IT-Grundschutz-Profile. Es handelt sich um vordefinierte Vorlagen mit einer Auswahl relevanter Zielobjekte, Praktiken und zugehöriger Sicherheitsanforderungen, die Organisationen einen effizienten, risikoorientierten Top-down-Einstieg ermöglichen. Sie dienen also als wiederverwendbare Schablonen für spezifische Branchen, Organisationsstrukturen oder technische Kontexte (z. B. Cloud-Anwendungen). Eine Blaupause fungiert als „Profile Model“ in OSCAL, das Anforderungen aus verschiedenen Katalogen zusammenführt („merging“) und spezifisch auf das jeweilige ISMS ausrichtet und anpasst.
Dach-Dokumente nutzen: Konsolidierte Dach-Dokumente (z. B. die ISMS-Leitlinie, IT-Betriebskonzept etc.) dienen als Ankerpunkte, um die Governance-Anforderungen des GS++ zentral zu erfüllen.

Umsetzung des GS++

Die technische Transformation des Regelwerks stellt insbesondere kleine und mittelständische Unternehmen (KMU) und Behörden mit einem ISMS vor eine signifikante Hürde: Da der Anwenderkatalog primär in maschinenlesbaren Formaten vorliegt, entfällt für ISMS-Tools ohne OSCAL-Unterstützung die Möglichkeit einer automatischen Verarbeitung. Zwar stellt das BSI den Katalog ergänzend auch als filterbare Excel-Datei bereit und betont eine stufenweise Einführung des GS++, die eine manuelle Bearbeitung ohne OSCAL-fähige ISMS-Tools grundsätzlich erlaubt. Für eine vollumfängliche Nutzung der UUID-basierten Verknüpfungen, der Namespace-Filterung und der Vererbungslogiken ist jedoch die Investition in ein OSCAL-fähiges Tool praktisch unumgänglich. Hieraus können sich im GS++ im Vergleich zur Umsetzung des IT-Grundschutz stärkere Abhängigkeiten von den eingesetzten Tools und den Herstellern ergeben. Die hiermit verbundenen Konsequenzen für das Lifecycle-Management (End of Life), Lizenzkosten und der Notwendigkeit kontinuierlicher Update-Zyklen sollten unbedingt berücksichtigt werden.

Außerdem ist im Auswahlprozess des ISMS-Tools sicherzustellen, dass es nicht nur das allgemeine OSCAL-Format unterstützt, sondern auch die BSI-spezifischen Erweiterungen (oscal_satzschablone_schema.json) verlustfrei verarbeiten kann. Es muss in der Lage sein, über Git veröffentlichte Änderungen mit den spezifischen Anpassungen des jeweiligen ISMS zusammenzuführen. Nur durch die Einhaltung dieser Anforderungen bleibt die Interoperabilität zwischen verschiedenen ISMS-Werkzeugen und dem Datenstrom des BSI gewährleistet.

Zusätzlich stellt die eingeschränkte menschliche Lesbarkeit des OSCAL-Formats eine Hürde für agile Eigenentwicklungen dar. Da die tief verschachtelten Strukturen der JSON-Dateien ohne spezialisierte Anzeigeprogramme („reader“, „viewer“) kaum intuitiv erfassbar sind, erfordert jede Automatisierung zunächst eine Transformation in einfacher verarbeitbare Zwischenformate. Dieser zusätzliche Schritt erhöht den Entwicklungsaufwand und verlangsamt iterative Zyklen – auch wenn die Zwischenformate selbst eine bessere Lesbarkeit, geringere Fehleranfälligkeit und verlustfreie Weiterverarbeitung ermöglichen.

Im Folgenden werden drei konkrete Herausforderungen anhand von Beispielen und Lösungen erörtert.

1) Inhaltliche Prüfung:

Herausforderung: Ein Auditor möchte die Erfüllung der Anforderung zur Passwortkomplexität prüfen. Im GS++-Anwenderkatalog findet er lediglich die UUID und einen Platzhalter für einen Parameter. Ohne ein ISMS-Tool, welches die Anforderungen mit der Konfigurationsdatenbank des Informationsverbunds (Configuration Management Database, CMDB) verknüpft, kann der Auditor nicht nachvollziehen, welche spezifische Schutzbedarfskategorie einem System zugewiesen wurde und welcher individuell definierte Parameter-Wert (Soll-Vorgabe) somit für dieses Asset verbindlich ist.
Lösung: Die CMDB dient als Kontextgeber. Das ISMS-Tool muss den im OSCAL-Profil definierten Soll-Wert (z. B. 14 Zeichen Passwortlänge) mit dem Kontext des jeweiligen Zielobjekts aus der CMDB verknüpfen, um festzustellen, auf welche Systeme diese spezifische Anforderung anzuwenden ist.

2) Versionsmanagement:

Herausforderung: Da das BSI den Katalog über ein Repository auf GitHub bereitstellt („Stand-der-Technik-Bibliothek“) und kontinuierlich aktualisiert, können Modifikationen an einzelnen Anforderungen („Controls“) in der komplexen JSON-Datenstruktur manuell kaum identifiziert werden. Die revisionssichere Nachverfolgung von Änderungen am Stand der Technik ist ohne automatisierte Werkzeuge nicht mehr handhabbar. Außerdem droht ohne ein automatisiertes Revisionsmanagement eine vom Unternehmen oder der Behörde unbemerkte Abweichung der internen Dokumentation vom definierten Stand der Technik („Compliance-Drift“).
Lösung: Das verantwortliche Team nutzt eine eigene Kopie des Anwenderkatalogs des BSI als „Fork“ des Git-Repositories. Idealerweise wird dieses in der eigenen Infrastruktur mit einer Registry betrieben, um sicherzustellen, dass schutzbedürftige Konfigurationsdaten nicht auf externen Plattformen verbleiben. Ein automatisierter Diff-Algorithmus vergleicht zyklisch die lokalen UUIDs mit dem Quellstand des BSI. Werden Änderungen detektiert, generiert das System automatisch einen Änderungsbeleg im ISMS-Tool. Dies ermöglicht es den Verantwortlichen, neue Anforderungen methodisch zu bewerten und gezielt zu entscheiden, ob diese in den aktuellen Informationsverbund übernommen oder für den laufenden Audit-Zyklus eingefroren werden.

3) Übersetzung („transition“):

Herausforderung: Methodisch liegt eine Hürde in der Übersetzung („transition“) – die Verbindung zwischen abstrakter Governance und technischer Umsetzung. Die Governance fordert z. B. in der Praktik „Detektion (DET.3.1)“ eine Protokollierung für 30 Tage. Das verantwortliche Team nutzt jedoch automatisierte Skripte, die lediglich 14 Tage vorsehen.
Lösung: Ein Skript prüft täglich die Vorgaben zur Aufbewahrung („retention_policy“) am Server. Das Ergebnis wird per Programmierschnittstelle („application programming interface“, API) an das ISMS-Tool gemeldet. Weicht der Wert vom definierten Parameter ab, wird automatisch ein Ticket im Änderungsmanagement („change management“) ausgelöst und der zuständigen Stelle zur Anpassung zugeführt. Dies überführt die Compliance-Prüfung von einem periodischen in einen kontinuierlichen Prozess. Dieses Vorgehen – das automatisierte Auslesen und strukturelle Auswerten („parsen“) von Konfigurationsdateien, z. B. aus Servern, Firewalls, Verzeichnisdiensten und weiteren Anwendungen, wird im Kontext des GS++ erheblich an Bedeutung gewinnen. Sobald Anforderungen als parametrisierte OSCAL-Objekte vorliegen, lassen sich Soll-Werte direkt gegen maschinenlesbare Konfigurationsartefakte der IT-Infrastruktur abgleichen. Werkzeuge für CaC-Frameworks (z. B. Chef InSpec, Open Policy Agent) sind für genau diesen Zweck konzipiert. Technisch wird dieser Vorgang in der Implementierungsschicht abgebildet.
Kritische Würdigung: Es ist zu beachten, dass Automatisierung keine Allzwecklösung darstellt. Da APIs für verschiedene Serverlandschaften und Anwendungen oft proprietär und nicht durchgängig standardisiert sind, werden wahrscheinlich nicht alle Zielobjekte im Informationsverbund nahtlos an das eingesetzte ISMS-Tool angebunden werden können. Zudem besteht die Gefahr einer „Automatisierungs-Hörigkeit“, bei der sich Verantwortliche zu stark auf digitale Kennzahlen verlassen und nicht-automatisierte Kontrolllücken (z. B. hinsichtlich der physischen Sicherheit oder sozialen Aspekte) übersehen. Die Methodik des GS++ trägt diesem Umstand Rechnung, indem neben technisch-automatisierten Methoden auch Interviews, Dokumentenprüfungen, Beobachtungen und Stichproben als legitime Prüfmethoden im Rahmen eines Auditprogramms vorgesehen sind.

Fazit: Resilienz messbar machen

Zu den beiden eingangs gestellten Fragen lässt sich abschließend Folgendes festhalten: Der GS++ steigert die Resilienz eines ISMS messbar – durch die Reduktion der Erkennungszeit bei Konfigurationsabweichungen, die automatisierte Nachverfolgung von Katalogänderungen via Git sowie die Entlastung von Sicherheitsteams bei der Generierung von Umsetzungsnachweisen. Sobald die im GS++ angelegten Kennzahlen und Metriken vollständig definiert und in ISMS-Tools implementiert sind, sind die Grundlagen geschaffen, Resilienz als strategisches Ziel zu operationalisieren. Das Management erhält datenbasierte Entscheidungsgrundlagen über den tatsächlichen Sicherheitszustand des ISMS und des gesamten Informationsverbunds. Der Prüfprozess wird hierbei umfassender und tiefer, der Anspruch an die fachliche und technische Qualität insgesamt steigt. Konkret verdeutlichen die praktischen Beispiele zur Passwort-Komplexitätsprüfung, zum Versionsmanagement und zur automatisierten Überwachung der Retention Policy, dass der Übergang eine Integration der CMDB, OSCAL-fähige Tools und ausgeprägte technische Kompetenz in allen beteiligten Rollen voraussetzt – wer diese Voraussetzungen nicht erfüllt, läuft Gefahr, die strukturellen Vorteile des GS++ nicht auszuschöpfen.

Die Weiterentwicklung des GS++ gegenüber dem klassischen IT-Grundschutz resultiert aus der konsequenten Anwendung der OSCAL-Schichten-Architektur: Während die Anforderungsschicht („Controls Layer“) die regulatorische Stabilität bietet, erlaubt die Implementierungsschicht („Implementation Layer“) perspektivisch eine hochgradig automatisierte Abbildung der technischen Realität. Die größte Herausforderung ist hierbei nicht der inhaltliche Kern, sondern die Fähigkeit von Unternehmen und Behörden, den Übergang zum „Compliance as Code“-Modell proaktiv durch den Aufbau digitaler Schnittstellen und die Einführung spezialisierter Tools zu gestalten. Dies fördert die Skalierbarkeit der Sicherheitsprozesse und überführt regulatorische Anforderungen von einer weithin statischen Dokumentationspflicht in einen kontinuierlich messbaren Steuerungsprozess.

Referenzen

BSI: Ein Vierteljahrhundert Informationssicherheit: IT-Grundschutz mit Methode, Pressemitteilung, 7. Oktober 2019.
URL: https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2019/25-Jahre-IT-Grundschutz_07102019.html

BSI: IT-Grundschutz-Kompendium, Edition 2023, 1. Februar 2023.
URL: https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/IT-Grundschutz-Kompendium/it-grundschutz-kompendium_node.html

BSI: Übersicht konsolidierte DA im IT-Grundschutz, Stand Kompendium 2023, 27. Juni 2024.
URL: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Drafts/Community_Draft/Uebersicht_DA-IT-Grundschutz_Kompendium_2023.xlsx?__blob=publicationFile&v=3

BSI: Pressemitteilung: BSI veröffentlicht Stand-der-Technik-Bibliothek auf GitHub, 30. September 2025.
URL: https://www.bsi.bund.de/DE/Service-Navi/Presse/Alle-Meldungen-News/Meldungen/Stand-der-Technik-Bibliothek_250930.html

BSI: Stand der Technik
URL: https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Grundschutz-in-der-Informationssicherheit/Stand-der-Technik/stand-der-technik.html

BSI: IT-Grundschutz-Tools
URL: https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/IT-Grundschutz-Kompendium/Alternative-IT-Grundschutztools/IT-Grundschutztools.html

BSI: Stand-der-Technik-Bibliothek (GitHub-Repository), Stand: 16. März 2026.
URL: https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek

BSI: OSCAL-Dokumentation, in: Stand-der-Technik-Bibliothek (GitHub-Repository), Stand: 16. März 2026.
URL: https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/OSCAL.md

BSI: Diskussionspapier zur Modernisierung der Methodik-Grundschutz ++ (Version: 0.9), Stand: 6. Februar 2026.

ISMS-Ratgeber Wiki: Migration von IT-Grundschutz zu Grundschutz++, Stand: 5. Februar 2026.
URL: https://wiki.isms-ratgeber.info/wiki/Grundschutz++Migration

ISMS-Ratgeber Wiki: Grundschutz++ Einführung und Aufbau, Stand: 13. März 2026
URL: https://wiki.isms-ratgeber.info/wiki/Grundschutz++_Einführung_und_Aufbau

Lorenz, Reto; Künkel, Daniel: „Grundschutz++ – Der BSI-Weg zur agilen Sicherheit“, in: IT-SICHERHEIT, 4. August 2025, Ausgabe 3/2025.
URL: https://www.itsicherheit-online.com/security-management/grundschutz-der-bsi-weg-zur-agilen-sicherheit/

Neweling, Benjamin: Deep-Dive ins neue Kompendium (Vortrag), 18. Februar 2026.
URL: https://www.youtube.com/watch?v=bqic_4xUZT0

NIST: OSCAL Layers and Models, 26. Januar 2026.
URL: https://pages.nist.gov/OSCAL/learn/concepts/layer/

Puppe, Christoph: „Experiment: KI entwickelt ISMS-Standard weiter“, in: iX Magazin, 15. September 2025.
URL: https://www.heise.de/hintergrund/Experiment-KI-entwickelt-ISMS-Standard-weiter-10624585.html

Reinhardt, Sebastian; Schiele, Hendrik; Helani, Kinan: „Grundschutz++: Migration und Mapping“, in: <kes> – Zeitschrift für Informationssicherheit, Ausgabe 1/2026, 23. Februar 2026. S. 6-9.
URL: https://www.kes-informationssicherheit.de/print/titelthema-it-grundschutz-2/grundschutz/

Reinhardt, Sebastian: IT-Grundschutz++ – auf dem Weg zum digitalen Regelwerk, in: <kes>, 17. April 2025.
URL: https://www.kes-informationssicherheit.de/print/titelthema-metriken-und-kennzahlen/it-grundschutz-auf-dem-weg-zum-digitalen-regelwerk/

Reinhardt, Sebastian: IT-Grundschutz zu Grundschutz++ (Vortrag), 18. Februar 2026.
URL: https://www.youtube.com/watch?v=I93WCKAu524

Weiß, Jonathan: Blaupausen im Grundschutz++ (Vortrag), 18. Februar 2026.
URL: https://www.youtube.com/watch?v=oq8Zym9cwnY

¹ Hinweis: Die nachfolgenden Ausführungen basieren auf dem aktuellen Entwicklungsstand des BSI-Anwenderkatalogs und dem Diskussionspapier zur Modernisierung der Methodik-Grundschutz++ (Januar 2026).

² SdT: Stand der Technik ist der Entwicklungsstand fortschrittlicher Verfahren, Einrichtungen oder Betriebsweisen, der die praktische Eignung einer Maßnahme zum Schutz von IT-Systemen gegen Beeinträchtigungen der Verfügbarkeit, Integrität, Authentizität und Vertraulichkeit gesichert erscheinen lässt. Der Stand der Technik liegt rechtssystematisch zwischen den allgemein anerkannten Regeln der Technik und dem Stand der Wissenschaft und Forschung. Maßgeblich sind einschlägige Normen und Standards (z. B. ISO-Standards) sowie in der Praxis erprobte Verfahren.

11. März 202611. März 2026Risikomanagement

Vertrauen im digitalen Zeitalter

Oft steht in der IT die Frage im Raum, ob eine bestimmte Anwendung oder Hardware „sicher“ sei. Die kompetente Antwort enthält dabei fast immer das Stichwort „Threat Modelling“ und den Zusatz „es kommt darauf an“. Aber worauf eigentlich genau?

Die kurze Antwort lautet, Sicherheit basiert immer auf Vertrauen. Denn eine noch so gute Anwendung bringt nichts, wenn die Angreifer die darunterliegenden Systeme kompromittiert haben. Insbesondere erfordert dies ein grundlegendes Vertrauen gegenüber den Herstellern und Lieferanten, dass diese nicht selbst die eigentliche Bedrohung darstellen. Seriöse Hersteller heben sich dadurch ab, dass sie klare Sicherheitsgarantien aussprechen. Sie definieren transparent, unter welchen Bedingungen und Annahmen ihre Schutzversprechen gelten. Eine eigene Überprüfung ist bei proprietären Anwendungen meist schwierig. Aber auch die Verfügbarkeit von Quellcode ist noch lange kein Garant für seine Prüfung. Und selbst wenn: Wer garantiert uns am Ende, dass die ausführbare Datei wirklich exakt aus diesem Code kompiliert wurde?

Mit diesem Hintergrund lesen sich die derzeitigen Diskussionen über Altersverifikation im Netz mit einem deutlich differenzierten Blick. Um hochsensible Daten wie den eigenen Personalausweis hochzuladen, muss das Vertrauen in eine Plattform enorm groß sein. Wie das in der Praxis bei LinkedIn abläuft, veranschaulicht der Privacy-Blogger Rogi in seinem Blog: Dahinter steht ein externes Datenverarbeitungsunternehmen mit undurchsichtigen rechtlichen Dokumenten und enormen sensiblen Datenmengen. Besonders die erfasste Verhaltensbiometrie ist dabei ein hochspannendes Thema!

Wie im analogen Leben weist auch hier die altbekannte Weisheit „Vertrauen ist gut, Kontrolle ist besser“ einen schönen Lösungsweg: Trauen Sie sich zu hinterfragen, ob ein Dienst oder eine Webseite wirklich die angefragten Daten benötigt, und zu welchen Zwecken diese Daten möglicherweise sonst noch verwendet werden.

https://thelocalstack.eu/posts/linkedin-identity-verification-privacy

26. Februar 202626. Februar 2026Allgemein, Schwachstelle

OWASP Top 10:2025 – Wenn Framework-Komplexität zum Geschäftsrisiko wird

Die OWASP Top 10 sind eine regelmäßig veröffentlichte Rangliste der zehn kritischsten Sicherheitsrisiken für Webanwendungen. Sie dienen als eine Art „Übersichtskarte“ für typische Schwachstellen wie Einschleusen von Code, Probleme bei der Zugriffskontrolle (Broken Access Control) oder fehlerhafte Sicherheitskonfigurationen. Erstellt und gepflegt wird die Liste vom gemeinnützigen Open Web Application Security Project (OWASP). Selbstverständlich bleibt die Entwicklung bei der Top 10 der Webschwachstellen nicht stehen. Aus diesem Grund wird im Abstand von etwa drei bis vier Jahren eine neue Version der Liste veröffentlicht. Die Version von 2021 wurde entsprechend im November vergangenen Jahres durch die OWASP Top 10:2025 ersetzt.

Dabei markiert die Veröffentlichung der OWASP Top 10:2025 einen Wendepunkt in der Applikationssicherheit.
Während die Version 2021 den Grundstein für ein modernes Risikoverständnis gelegt hat, reflektiert das Update 2025 eine Realität, in der Webanwendungen kaum noch „from scratch“ entwickelt werden.

Moderne Webanwendungen werden heute hochgradig modular aus mächtigen Frameworks und einer Vielzahl an Drittanbieter-Bibliotheken zusammengebaut. Diese Bausteine bringen wiederum ihre eigenen, unüberschaubaren Abhängigkeitsketten mit sich.

Damit verschiebt sich das Risiko und es geht nicht mehr nur um den Code, den die Entwickler selbst schreiben, sondern um die Integrität und Sicherheit des gesamten Ökosystems, auf dem die Webanwendung fußt.

Die wesentlichen Verschiebungen

Der Vergleich zwischen 2021 und 2025 zeigt, dass Angriffsvektoren, die nur eine bestimmte Schwachstellenklassifikation repräsentieren, in systemische Kategorien überführt wurden.

Für IT-Verantwortliche und Sicherheitsverantwortliche ist das wichtige Signal: Sicherheit lässt sich nicht mehr über eine einfache Checkliste von Schwachstellen-Typen verwalten.

1. Die Einordnung von SSRF in die Zugriffskontrolle (A01)

Ein markantes Detail ist der Wegfall von Server-Side Request Forgery (SSRF), zu Deutsch “server-seitige Anfragenfälschung”, als eigenständige Top-10 Kategorie. Das bedeutet keine Entwarnung für dieses Risiko. Vielmehr folgt das OWASP der Erkenntnis, dass SSRF im Kern ein strukturelles Problem der Broken Access Controls ist.

Eine Herausforderung dabei ist, dass automatisierte Scanner zwar teilweise technisch in der Lage sind, die Endpunkte zu ermitteln, aber die zugrundeliegende Geschäftslogik und den Kontext nicht verstehen können. Die Scanner Software allein kann deshalb gar nicht umfassend bewerten, ob ein für SSRF anfälliger Endpunkt missbraucht werden kann, um interne Systemressourcen, Metadaten oder sensible Informationen zu exfiltrieren. Hierfür bedarf es der Zusammenarbeit von Mensch und Maschine und einer kontextsensitiven Einschätzung eines Security Auditors oder Pentesters.

2. Vertrauen ALS GEWAGTE Strategie – Software Supply Chain (A03)

Neu priorisiert wurde die Integrität von Code und Software Dritter. Angesichts der Tatsache, dass moderne Webanwendungen zu einem Großteil aus fremdem Code bestehen, ist die Software Supply Chain eine kritische Sollbruchstelle geworden. Angreifende zielen heute immer öfter darauf ab, die Zulieferer- und Build-Pipeline anzugreifen, anstatt sich in die Komplexität der Custom Features einer Webanwendung einzuarbeiten.

Die Nutzung von Frameworks und Bibliotheken vereinfacht im Alltag die Entwicklung von Webanwendungen und klingt nach einer massiven Zeitersparnis, jedoch verstecken sich Schwachstellen oft tiefer in der Integration dieser Frameworks und Bibliotheken.

3. Resilienz unter Last – Mishandling of Exceptional Conditions (A10)

Neu in der Liste ist das „Mishandling of Exceptional Conditions (A10)“. Hier geht es um die Stabilität des Systemsselbst. Wie verhält sich die Webanwendung bei Fehlern zur Laufzeit oder unter extremen Bedingungen?
Ein System, das im Fehlerfall „offen“ bleibt (Fail-Open), stellt ein massives Sicherheitsrisiko dar, das oft erst durch gezielte Stress-Simulationen oder einem kontextsensitiven manuellen Pentest sichtbar wird.

Fazit: Sicherheit als begleitender Qualitätsprozess im gesamten Software Development Life Cycle (SDLC)

Die OWASP Top 10:2025 zeigt deutlich, wie wichtig es wird, eine kontextsensitive Bewertung durch Experten vornehmen zu lassen. So lässt sich sicherstellen, dass die komplexen Webanwendungen in der Praxis standhalten und Angriffsversuche applikationsseitig ordentlich vereitelt werden. Im Idealfall versteht auch die Sicherheit bei modernen Webanwendungen im Jahr 2026 als Prozess, der den gesamten Software Development Life Cycle begleitet.