Sieben systematische Lücken der ISO/IEC 27002:2022

Methodik der Lückenanalyse

Die Lückenanalyse erfolgt dreistufig. Erstens werden alle Anforderungen der fünf primären Vergleichsframeworks – C5:2026, NIST, DORA, CRA und NIS2 mit Durchführungsverordnung – gegen den ISO-27002:2022-Katalog abgeglichen. Zweitens werden jene Anforderungen extrahiert, die ISO 27002 nicht oder nur sehr abstrakt kennt. Drittens wird für jede extrahierte Anforderung geprüft, ob sie unter Mythos-Bedingungen eine harte Schutzwirkung entfaltet – also eines der Kriterien aus Kapitel 3.2 erfüllt: kryptografische Unmöglichkeit, strukturelle Reduktion des Blast Radius, Aggregationsresistenz oder harte Zeitbarriere.

Anforderungen, die lediglich eine andere Formulierung für bereits in ISO 27002 vorhandene Controls sind, werden nicht als Lücke gezählt. Anforderungen, die zwar in einem anderen Framework detaillierter, aber unter Mythos-Bedingungen selbst degradiert sind, ebenfalls nicht. Die folgende Analyse beschränkt sich auf substantielle Differenzen zum ISO-Text bei gleichzeitiger Mythos-Standfestigkeit.

Die Lücken gruppieren sich zu sieben thematischen Clustern, geordnet nach operativer Nähe zur Mythos-Kernbedrohung.

Cluster 1: Post-Quantum-Strategie und Crypto-Agility

ISO-27002-Bezug: A.8.24 (Verwendung von Kryptographie) fordert einen dokumentierten, risikobasierten Umgang mit kryptografischen Mechanismen, bleibt aber auf abstrakter Ebene. Keine explizite Anforderung an Post-Quantum-Vorbereitung, kryptografisches Inventar oder Crypto-Agility.

Forderung in anderen Frameworks: C5:2026 CRY-01.01AC fordert verbindlich eine dokumentierte Post-Quantum-Strategie mit vier Elementen: einem kryptografischen Inventar mit Prioritätsstufen, laufender Beobachtung des Stands der Technik, Einsatz von Hybrid-Cryptography-Modellen und definierten Triggern, Ressourcen, Transitionsplänen und Erfolgskriterien für die PQC-Umstellung. CRY-01.03AC fordert mindestens jährliche Überprüfung. CRY-02 (Cryptographic Change Management) verankert Crypto-Agility operativ.

Mythos-Standfestigkeit: Die Lücke ist mythos-standfest aus zwei Gründen. Erstens: Das Bedrohungsmodell Store-now-decrypt-later ist konkret und heute wirksam. Exfiltrierte Daten können Jahre gelagert werden, bis Quantum-Computing operationalisiert ist. Zweitens: Crypto-Agility ist eine strukturelle Voraussetzung, um auf plötzlich entwertete Algorithmen reagieren zu können, ohne in wochenlange Reengineering-Zyklen zu geraten. Einschränkend gilt: Der Kern dieser Lücke – die Quantenbedrohung – resultiert nicht aus Mythos, sondern besteht unabhängig davon; die ISO fordert über die Risikobetrachtung implizit bereits angemessene Verfahren. Mythos-spezifisch ist ein dritter Aspekt: PQC-Verfahren sind vergleichsweise neu und weniger erprobt als RSA oder ECDH, sodass AI-gestützte Kryptoanalyse unreife Schemata schneller schwächen könnte. Das erhöht die Anforderung an Krypto-Agilität zusätzlich – etwa mehrere Trust-Anchor mit unterschiedlichen Algorithmen und die Möglichkeit, einzelne kurzfristig zu deaktivieren.

Schlüsselmanagement-Facetten. Eine Analyse der Cloud Security Alliance zum PQC-Schlüsselmanagement (Cloud Key Management Working Group, Entwurf, August 2026) konkretisiert vier Aspekte, die eine reine Algorithmus-Umstellung übersieht. Erstens die Trust-Now-Forge-Later-Variante des Ernte-Angriffs: Nicht nur verschlüsselte Daten, auch heute gültige Signaturen – Zertifikate, Code-Signaturen, langlebige signierte Dokumente – können geerntet und später mit einem kryptografisch relevanten Quantencomputer rückwirkend gefälscht oder abgestritten werden; langlebige Signaturen gehören daher in Inventar und Migrationsscope. Zweitens das Downgrade-Risiko hybrider Protokolle: Ein Angreifer kann eine hybride Aushandlung (etwa Hybrid-TLS) auf den klassischen Anteil zurückzwingen; erforderlich sind erzwungene quantensichere Aushandlung, Ablehnung rein klassischer Sitzungen und protokollierte Downgrade-Erkennung. Drittens die Migrationsreihenfolge in der Schlüsselhierarchie: Zuerst muss die Wurzel (Master- bzw. Key-Encryption-Key, Stamm-CA) auf PQC umgestellt werden, dann die abgeleiteten Schlüssel – PQC nur auf unteren Ebenen bei klassischer Wurzel lässt den Trust-Anchor verwundbar, besonders bei Archivdaten mit langem Schutzbedarf. Viertens quantensichere Zeitstempel: Ein klassischer Zeitstempeldienst (TSA) schwächt die Non-Repudiation-Kette unabhängig vom Signaturalgorithmus; Signatur- und TSA-Zertifikate sind auf PQC zu migrieren, für Langzeitarchive mit periodischer Zeitstempel-Erneuerung.

Cluster 2: Supply-Chain-Transparenz und SBOM-Pflicht

ISO-27002-Bezug: A.5.19 bis A.5.23 adressieren die Lieferkette auf Policy- und Vertragsebene. Keine Anforderung an technische Transparenz über eingesetzte Softwarekomponenten, keine SBOM-Pflicht und keine verbindliche Build-Provenance-Anforderung.

Forderung in anderen Frameworks: C5:2026 DEV-13 (Transparency about Software Components). Die Erstellung einer SBOM gehört nach EU CRA Annex I Teil II zu den grundlegenden Anforderungen an das Schwachstellenmanagement; die Erfüllung der anwendbaren Anforderungen ist ihrerseits Voraussetzung der Konformität, auf deren Basis die CE-Kennzeichnung erfolgt. Verbindlich ist dies nur für Hersteller von Produkten mit digitalen Elementen, die in der EU in Verkehr gebracht werden; für andere Organisationen bleibt die SBOM eine risikobasierte Entscheidung. DORA Art. 28 fordert für ICT-Drittdienstleister detaillierte Transparenz. NIS2-DVO Nr. 5 (Sicherheit der Lieferkette) verpflichtet zu dokumentierten Abhängigkeiten. SLSA-Framework definiert Build-Provenance-Levels.

Mythos-Standfestigkeit: SBOM ermöglicht strukturelle Detektion, die nicht auf Angreiferreibung beruht. Der Angriff wird erkennbar, sobald die kompromittierte Komponente in EUVD, CVE oder OSV publiziert wird. Die Reduktion der Detektionslatenz ist strukturell, nicht zeitlich.

Cluster 3: Container, Confidential Computing und Multi-Tenancy

C5:2026 hat mit der Revision von März 2026 drei strukturell neue Kontrolldomänen eingeführt, die ISO 27002 nicht kennt und die explizit auf moderne Cloud-Workload-Architekturen zugeschnitten sind.

Container-Sicherheit

ISO-27002-Bezug: Keine container-spezifischen Controls. Allgemeine Umgebungs- und Konfigurations-Controls (A.8.9, A.8.19, A.8.31) sind anwendbar, adressieren aber nicht die spezifischen Container-Angriffsflächen.

Forderung: C5:2026 OPS-34 (Container Management – Policies and Procedures) und OPS-35 (Implementation) sowie PSS-11 (Images for Virtual Machines and Containers) fordern dokumentierte Image-Quellen, signierte Images, Runtime-Protection und Netzwerk-Segmentierung auf Container-Ebene. NIST SP 800-190 als Referenz.

Mythos-Standfestigkeit: Container-Signatur schafft eine kryptografisch-strukturelle Barriere gegen kompromittierte Basis-Images aus Public Registries.

Confidential Computing

ISO-27002-Bezug: Keine Anforderungen an Trusted Execution Environments oder Remote Attestation.

Forderung: C5:2026 OPS-32 (Confidential Computing – Policies and Procedures) und OPS-33 (Remote Attestation). NIST-Konzepte zu Trusted Computing als Referenz.

Mythos-Standfestigkeit: Confidential Computing ist die derzeit härteste Barriere gegen Angreifer mit Infrastruktur-Zugriff, weil sie die Vertraulichkeit von Daten in der Verarbeitung schützt – nicht nur in Transit und at Rest.

Multi-Tenancy-Isolation

ISO-27002-Bezug: Keine spezifischen Multi-Tenancy-Controls. Generische Trennungs-Controls (A.8.22, A.8.31) reichen nicht aus.

Forderung: C5:2026 OPS-30 (Separation of Datasets – Policies and Procedures) und OPS-31 (Implementation) fordern explizit die Trennung von Kundendaten in Multi-Tenant-Umgebungen mit nachweisbarer Implementierung. PSS-10 (Software Defined Networking) ergänzt die Netzwerkseite.

Mythos-Standfestigkeit: Strukturelle Begrenzung des Blast Radius: Ein Angreifer, der in einem Tenant Fuß fasst, wird nachweislich daran gehindert, auf andere Tenants zuzugreifen.

Cluster 4: Verbindliche Meldefristen und Root-Cause-Analyse

ISO-27002-Bezug: A.5.5 (Kontakt mit Behörden) und A.5.25 (Beurteilung von Ereignissen) adressieren Meldewege ohne konkrete Fristen. A.5.27 (Lernen aus Vorfällen) fordert keine Root-Cause-Analysis-Pflicht.

Forderung in anderen Frameworks: NIS2-Richtlinie Art. 23 Abs. 4 fordert binnen 24 Stunden eine Frühwarnung, binnen 72 Stunden eine Vollbenachrichtigung bei erheblichen Sicherheitsvorfällen sowie einen Abschlussbericht nach einem Monat. DORA Art. 19 fordert Major-Incident-Reports an Aufsichtsbehörden mit detaillierten Inhaltsanforderungen. DORA Art. 17 macht Root-Cause-Analyse zur verpflichtenden Phase im Incident-Management-Lifecycle. Der Cyber Resilience Act (CRA) verpflichtet Inverkehrsbringer von Produkten mit digitalen Elementen zusätzlich zu Meldepflichten bei aktiv ausgenutzten Schwachstellen (u. a. 24-Stunden-Frühwarnung an ENISA bzw. das zuständige CSIRT). NIS2-DVO Nr. 3.6 verpflichtet zu nachträglichen Überprüfungen einschließlich Ursachenermittlung.

Mythos-Standfestigkeit: Zeitbasierte Meldefristen sind mythos-standfest, weil sie die Zeitkompression, die Mythos-Angreifern zugutekommt, auf der regulatorischen Seite spiegeln: Wer in 24 Stunden melden muss, braucht detection- und triage-seitig entsprechende Automatisierung. Root-Cause-Analyse schafft die empirische Grundlage für Detection-Verbesserung. Die Fristen gelten allerdings nicht für jede Organisation gleichermaßen – maßgeblich sind die Rolle (etwa Inverkehrsbringer nach CRA) und die Einstufung unter NIS2; für nicht erfasste Organisationen fällt die Lücke entsprechend kleiner aus. Über die Compliance-Pflichten eines ISMS (Betrachtung der Erwartungen interessierter Parteien, einschließlich rechtlicher Vorgaben) fließen die jeweils anwendbaren Fristen ohnehin in die Sicherheitsziele ein.

Cluster 5: Kontinuierliche Prüfung zusätzlich zu periodischen Audits

ISO-27002-Bezug: A.5.35 (Unabhängige Überprüfung) beschreibt periodische Audits. A.5.36 (Einhaltung von Richtlinien) und A.8.8 (Vulnerability Management) sind in Kapitel 6 als reine Reibung eingestuft.

Forderung in anderen Frameworks: C5:2026 OPS-25.01AS fordert als Sharpening tägliche Vulnerability-Scans. COM-03 und COM-04 fordern kontinuierliche ISMS-Wirksamkeitsprüfung. NIS2-DVO Nr. 2.2 (Überwachung der Einhaltung) verlangt ein wirksames System der Berichterstattung. DORA Art. 24–26 fordert ein Digital Operational Resilience Testing Programme; Art. 26–27 das Threat-Led Penetration Testing (TLPT) für kritische Funktionen.

Mythos-Standfestigkeit: Kontinuierliche Prüfung gleicht die Zeitkompression auf Verteidigungsseite aus. Die Detektionslatenz wird von Monaten und Quartalen auf Stunden und Tage reduziert. TLPT mit Mythos-spezifischen Szenarien ist das bekannteste regulatorische Regime, das die Empirie-Ebene explizit adressiert: Es prüft, ob die Controls wirken, nicht ob sie dokumentiert sind.

Cluster 6: Phishing-resistente Identität und Zero-Trust-Architektur

ISO-27002-Bezug: A.5.17 und A.8.5 fordern dem Schutzbedarf angemessene Authentisierung, ohne konkrete Verfahren oder Assurance-Levels zu nennen. A.5.16 fordert Identitätsmanagement ohne explizite Workload-Identity-Anforderung.

Forderung in anderen Frameworks: NIST SP 800-63B definiert drei Authentication Assurance Levels; für Mythos-Umgebungen sind AAL2 und AAL3 relevant. FIDO-Alliance-Standards (WebAuthn, Passkeys). NIST SP 800-207 Zero Trust Architecture definiert Workload-Identity als strukturelles Prinzip. NIST NCCoE-Arbeiten zu Agent Identity. SPIFFE/SPIRE als De-facto-Standard.

Mythos-Standfestigkeit: Phishing-resistente MFA ist die direkte Antwort auf AI-qualitatives Phishing: Selbst wenn ein Nutzer auf einer perfekt gestalteten Phishing-Seite landet, kann der Angreifer keinen verwertbaren Authentisierungsnachweis erlangen, weil FIDO2 eine Origin-Bindung vornimmt. Workload-Identity ist strukturell: Sie ersetzt Shared Secrets durch hardware-verankerte, kurzlebige Identitäten.

Cluster 7: Automatisierungspflicht und Resilienz-Testing

ISO-27002-Bezug: Keine ausdrückliche Automatisierungspflicht. A.5.30 (ICT-BCM) und A.8.16 (Monitoring) erwähnen keine konkreten Testszenarien für parallele Incidents.

Forderung in anderen Frameworks: NIS2-DVO Nr. 3.2.2 verpflichtet zu automatisierter Überwachung, soweit durchführbar. NIS2-DVO Nr. 3.5.5 fordert die Testung der Reaktionsverfahren. DORA Art. 24–26 fordert ein umfassendes Digital Operational Resilience Testing Programme. DORA Art. 26–27 fordert TLPT mit Szenarien, die reale Bedrohungen abbilden. Anthropic empfiehlt im Glasswing-Defensivpost explizit Tabletop-Übungen für drei bis fünf parallele Incidents.

Hinweis zur Schärfe der NIS2-DVO-Formulierung: Die DVO formuliert die Automatisierungspflicht als Soll-Vorschrift („soweit durchführbar", „vorbehaltlich der betrieblichen Kapazitäten") und nicht als absolute Pflicht. Für Mythos-exponierte Organisationen sollte die Durchführbarkeit restriktiv ausgelegt werden, da manuelle Reaktionszeiten gegenüber agentischen Angreifern strukturell versagen.

Mythos-Standfestigkeit: Die Automatisierungspflicht ist die einzig realistische Antwort auf die Asymmetrie zwischen agentischem Angreifer und menschlicher Verteidigungskette. Parallel-Incident-Testing adressiert direkt die Fragmentierungs-Strategie.

Zusammenfassung: Das Lücken-Delta der ISO 27002

Die sieben Cluster beschreiben gemeinsam das systematische Delta zwischen ISO/IEC 27002:2022 und den regulatorischen Anforderungen der letzten drei Jahre. Dieses Delta wurde in der Konzeption der ISO 27002 nicht als Mangel angelegt – es reflektiert die Framework-weise Spezialisierung der Normenlandschaft.

Unter Mythos-Bedingungen wird dieses Delta zum operativ relevanten Problem. Eine Organisation, die sich auf die reine ISO-27002-Basis stützt, verfügt nicht über die konkreten Anforderungen, die C5:2026, NIST, DORA, CRA und NIS2 mit Durchführungsverordnung an die aktuelle Bedrohungslage stellen. Das Delta zu schließen ist keine Compliance-Übung, sondern die Kernaufgabe der operativen Mythos-Härtung.

Die sieben Cluster lassen sich zu zwei Bewegungen verdichten: einer strukturellen Modernisierung der Sicherheitsarchitektur (Cluster 1 Kryptografie, 3 Cloud-Infrastruktur, 6 Identität) und einer zeitlichen Verkürzung der Verteidigungsschleifen (Cluster 2 Lieferkette, 4 Meldepflichten, 5 kontinuierliche Prüfung, 7 Automatisierung). Kapitel 9 führt diese Bewegungen zum priorisierten Katalog von Mythos-Härtungs-Controls zusammen.

Ableitung aus den Lückenclustern

Zwölf der dreizehn MHC lassen sich primär auf die sieben Lückencluster aus Kapitel 8 zurückführen; MHC-08 entsteht primär aus der Control-Degradation-Analyse und wird durch externe Framework-Anforderungen zusätzlich gestützt:

• Cluster 1 (Kryptografie und Post-Quantum): MHC-01.
• Cluster 2 (Supply-Chain-Transparenz): MHC-02; MHC-13 ergänzt um agentische Supply-Chain-Komponenten (MCP-Server, IDE-Extensions, Agentic Skills).
• Cluster 3 (Container, Confidential Computing, Multi-Tenancy): MHC-06 und MHC-07.
• Cluster 4 (Meldepflichten und Root-Cause): MHC-11 (Reaktionsseite); die Meldefrist-Compliance wird nicht als eigenes MHC gelistet, weil sie als direkte Rechtspflicht aus NIS2 und DORA ohnehin umzusetzen ist.
• Cluster 5 (Kontinuierliche Prüfung): MHC-10 und MHC-12.
• Cluster 6 (Phishing-resistente Identität und Zero Trust): MHC-03, MHC-04 und MHC-13 (Identitäts-Lifecycle der AI-Agenten).
• Cluster 7 (Automatisierung und Resilienz-Testing): MHC-05, MHC-09 und MHC-11.

MHC-08 (unveränderliche Backups) resultiert nicht primär aus der externen Framework-Lückenanalyse, sondern aus der vertieften Bewertung von A.8.13, A.5.29, A.5.30 und der angrenzenden Resilienz-Controls in den Kapiteln 4 und 5: Die ISO fordert Sicherung und Wiederherstellbarkeit, aber keine Unveränderlichkeit und keine getrennten Zugriffspfade für die Backup-Infrastruktur – genau diese beiden Eigenschaften entscheiden unter Mythos-Bedingungen über die Wirksamkeit. MHC-05 ist die operative Grundlage der Automatisierungspflicht (Cluster 7) und zugleich Antwort auf die Aggregationsblindheit klassischer Detection.