Migration zu Post-Quanten-Kryptografie mit ISO 27001

Das Summen des Projektors ist das einzige Geräusch im Sitzungsraum. Sarah, die CISO, hat gerade ihr vierteljährliches Risiko-Update abgeschlossen, als der CEO den Ausdruck eines Finanznachrichtenartikels hochhält. Die Überschrift ist unmissverständlich: „Der Quanten-Countdown: Sind Ihre Daten bereits veraltet?“
„Sarah“, sagt er, weniger vorwurfsvoll als ehrlich besorgt, „wir haben Millionen in Verschlüsselung investiert. Wir erfüllen die Anforderungen. Wir sind sicher. Dieser Artikel sagt, dass ein ausreichend leistungsfähiger Quantencomputer all das brechen könnte. Sind wir exponiert? Was ist mit den Daten, die wir gerade jetzt verschlüsseln und speichern? Ist das eine tickende Zeitbombe?“
Diese Diskussion verlagert sich derzeit aus Sicherheitskonferenzen in die Leitungsgremien. Es geht nicht mehr darum, ob Quantencomputing für Forschende interessant ist. Es geht darum, ob heutige kryptografische Entscheidungen die geschäftlichen Verpflichtungen von morgen schützen können.
Für viele Organisationen ist die ehrliche Antwort unbequem. Verschlüsselung ist überall: TLS-Gateways, VPNs, Kundenportale, Identitätstoken, Datenbank-Backups, mobile Anwendungen, Zahlungsplattformen, S/MIME, SSH, API-Integrationen, SaaS-Dienste, Hardware-Sicherheitsmodule, Cloud-Schlüsselmanagementdienste, Firmware-Signierung, Code Signing und digitale Verträge.
Genau darin liegt das Problem. Kryptografie ist überall, aber die Zuständigkeit ist häufig nirgends eindeutig verankert.
Die Migration zu Post-Quanten-Kryptografie betrifft nicht nur einen zukünftigen kryptografisch relevanten Quantencomputer. Sie betrifft auch das heutige „Harvest now, decrypt later“-Risiko: Angreifer erfassen heute verschlüsselte Daten und warten, bis künftige Fähigkeiten eine Entschlüsselung praktikabel machen. Wenn Ihre Organisation personenbezogene Daten, Gesundheitsakten, regulierte Finanzdaten, Geschäftsgeheimnisse, rechtliche Kommunikation, Daten nationaler Infrastrukturen, Produkt-Firmware oder langlebiges geistiges Eigentum speichert, ist das Risiko bereits heute ein Lebenszyklusrisiko.
Ein quantensicherer Migrationsplan für Kryptografie ist kein Panikprojekt. Er ist ein strukturiertes Programm aus Governance, Inventarisierung, Lieferantensteuerung, Architektur, Tests und Audit. Die praktische Frage für CISOs ist einfach:
Wie erstellen wir einen Post-Quanten-Migrationsplan, der für Führungskräfte glaubwürdig, für Engineering-Teams nutzbar und gegenüber Auditoren belastbar ist?
Die Antwort lautet: Die Arbeiten werden in ISO/IEC 27001:2022 verankert, Kontrollen werden über ISO/IEC 27002:2022 interpretiert, NIST-Standards zu Post-Quanten-Kryptografie dienen als technischer Kompass, und es wird ein einheitliches Nachweismodell geschaffen, das Verpflichtungen aus ISO 27001, NIST, COBIT 2019, GDPR, DORA und NIS2 unterstützt.
Warum Post-Quanten-Kryptografie in das ISMS gehört
Ein häufiger Fehler besteht darin, die Post-Quanten-Migration ausschließlich kryptografischen Ingenieurinnen und Ingenieuren zuzuweisen. Sie sind unverzichtbar, können das Governance-Problem aber nicht allein lösen.
Die Post-Quanten-Migration berührt Asset-Management, Datenklassifizierung, Lieferantenmanagement, sichere Architektur, Schlüsselmanagement, Anwendungsentwicklung, Cloud-Sicherheit, Incident Response, Aufrechterhaltung des Geschäftsbetriebs, Rechtsrisiken, regulatorische Rechenschaftspflicht und Auditnachweise. Das sind ISMS-Themen.
ISO/IEC 27001:2022 stellt den Governance-Rahmen bereit. Die Norm verlangt, dass die Organisation ihren Kontext, interessierte Parteien, Risiken, Ziele, Verantwortlichkeiten, Kompetenzen, dokumentierte Informationen, operative Planung, Leistungsbewertung, interne Audits, Managementbewertung und kontinuierliche Verbesserung steuert. ISO/IEC 27002:2022 liefert anschließend die Auslegung der Kontrollen, insbesondere rund um 8.24 Use of cryptography, 5.9 Inventory of information and other associated assets, 5.12 Classification of information, 5.21 Managing information security in the ICT supply chain, 5.23 Information security for use of cloud services, 8.25 Secure development life cycle, 8.8 Management of technical vulnerabilities, 8.16 Monitoring activities und 5.30 ICT readiness for business continuity.
Deshalb wird Post-Quanten-Vorbereitung bei Clarysec als ISMS-gesteuerte Transformation behandelt, nicht als isolierter Austausch von Algorithmen.
Wie in Clarysecs Zenith Blueprint: 30-Schritte-Roadmap für Auditoren, Phase 2, Schritt 8, „Abgrenzung von Assets, Abhängigkeiten und Nachweisen“, beschrieben:
„Einer Kontrolle kann erst dann vertraut werden, wenn die Organisation nachweisen kann, wo sie gilt, wer sie verantwortet, welche Nachweise sie stützen und welches Risiko sie reduziert.“
Dieser Satz ist für Post-Quanten-Kryptografie besonders wichtig. Bevor Algorithmen ersetzt werden, muss bekannt sein, wo Algorithmen eingesetzt werden.
Clarysecs Zenith Controls: Der Cross-Compliance-Leitfaden stellt Kryptografie als zusammenhängende Nachweiskette dar, nicht als einzelne technische Einstellung:
„Kryptografische Sicherheit wird über den Lebenszyklus von Informationen auditiert: Identifizierung, Klassifizierung, genehmigte Nutzung, Schlüsselschutz, operative Überwachung, Lieferantenabhängigkeit, Ausnahmebehandlung und Nachweisaufbewahrung.“
Diese Lebenszyklussicht verhindert den häufigsten Fehler: nur zu fragen: „Verwenden wir quantensichere Algorithmen?“ Die besseren Fragen lauten:
- Welche Systeme benötigen zuerst eine Post-Quanten-Migration?
- Welche Daten haben eine Vertraulichkeitsdauer, die länger ist als der Quantenrisikohorizont?
- Welche Anbieter kontrollieren unsere Verschlüsselung, Signaturen, Zertifikate oder unser Schlüsselmanagement?
- Welche Anwendungen sind kryptoagil und welche sind hartcodiert?
- Welche kompensierenden Kontrollen bestehen, solange die Migration unvollständig ist?
- Welche Nachweise belegen, dass Entscheidungen risikobasiert getroffen und überprüft wurden?
Von der Quantenbedrohung zum auditierbaren Geschäftsrisiko
Ein wirksamer Post-Quanten-Plan beginnt mit Risikoszenarien. Vermeiden Sie vage Aussagen wie „Quantencomputing könnte Verschlüsselung brechen“. Erstellen Sie stattdessen auditierbare Risikodatensätze, die geschäftliche Auswirkungen, Bedrohung, Schwachstelle, betroffene Assets, bestehende Kontrollen, Restrisiko und Risikobehandlungsmaßnahmen miteinander verbinden.
Beispiel:
„Verschlüsselte Identitätsdokumente von Kunden, die sieben Jahre aufbewahrt werden, können künftig für Entschlüsselung anfällig sein, wenn Backups heute exfiltriert werden und heutige Public-Key-Kryptografie in Zukunft brechbar wird.“
Dieses Szenario verweist auf Datenaufbewahrung, Backup-Verschlüsselung, Schlüsselmanagement, Zugriffskontrolle, Hosting durch Lieferanten, Überwachung und Migrationspriorität.
Ein weiteres Beispiel:
„Die Firmware-Signierung für vernetzte Geräte stützt sich auf Signaturverfahren, die über den erwarteten Gerätelebenszyklus möglicherweise nicht vertrauenswürdig bleiben.“
Das verweist auf Produktsicherheit, sichere Aktualisierungsmechanismen, HSM-Fähigkeiten, Kundensicherheit, Design Assurance durch Lieferanten und langfristige operative Resilienz.
Ein drittes Beispiel:
„Heute verschlüsselte archivierte Rechtskommunikation kann eine Vertraulichkeit von mehr als fünfzehn Jahren erfordern und damit eine ‚Harvest now, decrypt later‘-Exponierung erzeugen.“
Das verweist auf Klassifizierung, Aufbewahrung, kryptografischen Schutz, Legal Hold, sichere Kommunikation und Risikoakzeptanz durch die Geschäftsleitung.
Das Risiko ist nicht nur ein zukünftiger „Q-Day“. Es umfasst drei zusammenhängende Aspekte:
- Harvest now, decrypt later: Angreifer sammeln heute verschlüsselte Daten zur künftigen Entschlüsselung.
- Kompromittierung digitaler Signaturen: Künftige Angriffe untergraben das Vertrauen in Software-Updates, Identitätstoken, Rechtsdokumente, Firmware und Finanztransaktionen.
- Kryptografisches Konzentrationsversagen: Eine breite Klasse von Produkten, Protokollen, Bibliotheken oder Lieferanten wird gleichzeitig obsolet.
Clarysecs Enterprise Policy, Richtlinie zu Kryptografie und Schlüsselmanagement, Klausel 5.1, formuliert die Governance-Anforderung wie folgt:
„Kryptografische Kontrollen müssen auf Grundlage der Klassifizierung von Informationen, der erforderlichen Schutzdauer, genehmigter kryptografischer Standards, der Verantwortung für Schlüssel und dokumentierter Entscheidungen zur Risikobehandlung ausgewählt, umgesetzt, überprüft und außer Betrieb genommen werden.“
Diese Klausel ist entscheidend, weil die Schutzdauer zu einem Priorisierungsfaktor wird. Kurzlebige Sitzungsdaten und langfristig aufzubewahrende medizinische Unterlagen tragen nicht dasselbe Quantenrisiko. Ein Code-Signing-Schlüssel, auf dem das Gerätevertrauen für fünfzehn Jahre beruht, hat ein anderes Risikoprofil als ein kurzlebiges internes Testzertifikat.
Dieselbe Richtlinienfamilie, in Clarysec-Materialien als Richtlinie zu kryptografischen Kontrollen bezeichnet, kann die Erwartungen an Überprüfungen außerdem mit Formulierungen wie der folgenden formalisieren:
Klausel 5.4: Standards für Algorithmen und Schlüssellängen
„Alle in der Organisation verwendeten kryptografischen Algorithmen und Schlüssellängen müssen aus einer genehmigten Liste ausgewählt werden, die vom Informationssicherheitsteam gepflegt wird. Diese Liste ist jährlich anhand von Best Practices der Branche und Vorgaben nationaler Cybersicherheitsbehörden (z. B. NIST, ENISA) zu überprüfen; dabei ist der Entwicklung von Post-Quanten-Standards für Kryptografie besondere Aufmerksamkeit zu widmen. Als Bestandteil des kryptografischen Asset-Inventars muss eine Roadmap für die Migration von Systemen weg von Algorithmen geführt werden, die gegenüber quantenbasierten Angriffen verwundbar sind.“
Dies verlangt keine unsichere Früheinführung. Es verlangt Sensibilisierung, Planung, Überprüfung und Nachweise.
NIST PQC-Standards als technischer Kompass
Die Arbeiten von NIST zu Post-Quanten-Kryptografie geben Organisationen eine belastbare technische Richtung. NIST hat ML-KEM für die Schlüsseletablierung, ML-DSA für digitale Signaturen und SLH-DSA für zustandslose hashbasierte Signaturen standardisiert. Diese Standards geben Anbietern und Architekten eine Grundlage für Roadmaps und Pilotdesigns.
Für CISOs geht es nicht darum, Algorithmendetails auswendig zu lernen. Es geht darum, einen Migrationspfad zu schaffen, der genehmigte kryptografische Verfahren aufnehmen kann, ohne Geschäftsdienste, Compliance-Verpflichtungen oder Audit-Nachvollziehbarkeit zu gefährden.
Ein an NIST ausgerichteter Migrationsplan sollte vier Arbeitsstränge umfassen:
- Ermittlung: feststellen, wo verwundbare Public-Key-Kryptografie vorhanden ist.
- Priorisierung: Systeme nach Datensensitivität, Schutzdauer, Exponierung, Integritätsauswirkung und Geschäftskritikalität einstufen.
- Übergangsarchitektur: festlegen, wo hybride, kryptoagile oder Post-Quanten-Mechanismen getestet und eingeführt werden.
- Sicherstellung: Nachweise erzeugen, dass Entscheidungen, Ausnahmen, Lieferantenabhängigkeiten, Tests und Restrisiken kontrolliert werden.
Kryptoagilität verdient besondere Aufmerksamkeit. Ein kryptoagiles System kann Algorithmen, Schlüssellängen, Bibliotheken, Zertifikate und Protokolle ohne wesentliche Neugestaltung ändern. In der Post-Quanten-Ära ist Kryptoagilität kein Luxus. Sie ist eine Resilienzanforderung.
Wenn eine Zahlungs-API hartcodierte kryptografische Bibliotheken und keinen dokumentierten Verantwortlichen hat, ist sie nicht kryptoagil. Wenn eine mobile Anwendung Zertifikate pinnt, ohne einen gesteuerten Aktualisierungspfad zu haben, kann die Migration teuer werden. Wenn ein IoT-Gerät eine fünfzehnjährige Einsatzdauer im Feld hat und keine größeren Signaturen oder sicheren Firmware-Updates unterstützen kann, ist das Risiko strategisch.
Das kryptografische Inventar aufbauen, bevor der Migrationspfad gewählt wird
Die meisten Organisationen verfügen nicht über ein vollständiges kryptografisches Inventar. Sie haben möglicherweise ein Zertifikatsinventar, eine Tabelle zum Schlüsselmanagement, HSM-Aufzeichnungen, eine Cloud-KMS-Liste oder CMDB-Einträge. Selten gibt es eine einheitliche Sicht auf kryptografische Abhängigkeiten.
Ein Migrationsplan für Post-Quanten-Kryptografie benötigt eine Cryptographic Bill of Materials, kurz CBOM. Sie muss am ersten Tag nicht perfekt sein. Sie muss jedoch strukturiert, einem Verantwortlichen zugeordnet und kontinuierlich verbessert werden.
Mindestens die folgenden Felder sollten erfasst werden:
| Inventarfeld | Warum es für die Post-Quanten-Migration relevant ist |
|---|---|
| Geschäftsservice | Priorisiert die Migration nach geschäftlicher Auswirkung |
| Asset-Verantwortlicher | Weist Rechenschaftspflicht und Entscheidungsbefugnis zu |
| Datenklassifizierung | Identifiziert Anforderungen an Vertraulichkeit und Integrität |
| Schutzdauer | Hebt „Harvest now, decrypt later“-Exponierung hervor |
| Kryptografische Funktion | Trennt Verschlüsselung, Schlüsselaustausch, Signaturen, Hashing und Zertifikate |
| Algorithmus und Protokoll | Identifiziert, wo verwundbare Public-Key-Mechanismen verwendet werden |
| Bibliothek oder Implementierung | Zeigt Softwareabhängigkeiten und Einschränkungen bei Aktualisierungen |
| Speicherort des Schlüssels | Zeigt, ob Schlüssel in HSM, Cloud KMS, Software, Endpoints oder Lieferantenplattformen liegen |
| Lieferantenabhängigkeit | Macht sichtbar, wo Migration von Drittparteien abhängt |
| Migrationskomplexität | Unterstützt Sequenzierung, Tests und Budgetplanung |
| Nachweisquelle | Macht das Inventar auditfähig |
Ein initiales Inventar könnte wie folgt aussehen:
| Asset-Kennung | Asset-Name | Verantwortlicher | Geschäftskritikalität | Kryptografische Nutzung | Standort | PQC-Verwundbarkeit | Migrationspriorität |
|---|---|---|---|---|---|---|---|
| APP-042 | Kundenabrechnungs-API | Finanztechnologie | Hoch | RSA-2048-Signaturen, TLS, AES-256-Verschlüsselung | AWS eu-west-1 | Hoch für RSA-abhängiges Vertrauen | 1 |
| NET-007 | Fernzugriffs-VPN | IT-Infrastruktur | Hoch | ECDSA-Authentifizierung, IKEv2 | On-Premises und Cloud Edge | Hoch für ECC-abhängige Authentifizierung | 1 |
| DB-011 | Archivierte Patientenakten | Compliance | Hoch bei 30-jähriger Aufbewahrung | AES-256-Datenbankverschlüsselung | On-Premises-Datenbank | Niedriger für symmetrische Verschlüsselung, hoch, wenn Schlüssel mit verwundbaren Public-Key-Verfahren ausgetauscht oder verpackt werden | 2 |
| CODE-001 | CI/CD Code Signing | DevOps | Hohe Integritätsauswirkung | RSA-4096 Code Signing | HSM und Build-Pipeline | Hoch für langfristiges Signaturvertrauen | 1 |
Diese Tabelle zeigt unmittelbar, warum Inventarisierung wichtig ist. AES-256 hat nicht dieselbe Art von Quantenrisiko wie RSA oder ECC, aber archivierte Patientenakten können weiterhin von verwundbarem Key Wrapping, Zertifikaten, Identitätssystemen oder Backup-Übertragungskanälen abhängen. Code Signing schützt möglicherweise nicht die Vertraulichkeit, aber es schützt Softwareintegrität und Vertrauen.
In Zenith Controls wird Kryptografie mit unterstützenden Standards querverknüpft, die zusätzliche Tiefe schaffen. ISO/IEC 27005 unterstützt Informationssicherheitsrisikomanagement und hilft, Quantenunsicherheit in strukturierte Risikoszenarien zu übersetzen. ISO/IEC 27017 unterstützt cloud-spezifische Sicherheitskontrollen, was entscheidend ist, wenn kryptografische Dienste über Cloud KMS, verwaltetes TLS, SaaS-Verschlüsselung oder Plattformzertifikate bereitgestellt werden. ISO/IEC 27018 ist relevant, wenn personenbezogene Daten in öffentlichen Cloud-Services verarbeitet werden. ISO 22301 ist relevant, wenn kryptografisches Versagen die Kontinuität kritischer Services beeinträchtigen könnte. ISO/IEC 27036 unterstützt die Sicherheit von Lieferantenbeziehungen, was entscheidend ist, wenn Anbieter Verschlüsselung, Signaturen, Zertifikate oder sichere Kommunikation in Ihrem Auftrag verwalten.
Die Lehre ist einfach: Sie können nicht migrieren, was Sie nicht finden.
Nach Sensitivität, Schutzdauer, Exponierung und Migrationsaufwand priorisieren
Sobald die CBOM vorliegt, wird Priorisierung nachweisbasiert. Der beste Einstieg ist eine kleine Anzahl kritischer Systeme, nicht der Versuch unternehmensweiter Perfektion.
Stellen Sie sich ein Finanzdienstleistungsunternehmen mit drei hochwertigen Systemen vor:
- ein Kundendokumenten-Tresor, der Identitätsnachweise zehn Jahre lang speichert
- ein B2B-API-Gateway für Partnertransaktionen
- eine Code-Signing-Plattform für Desktop-Software-Updates
Mithilfe von Zenith Blueprint, Phase 2, Schritt 8, extrahiert das Team Assets aus der CMDB, Zertifikate aus der Zertifikatsmanagement-Plattform, Schlüssel aus HSM und Cloud KMS, Datenklassen aus dem Datenschutzregister und Lieferantenabhängigkeiten aus Beschaffungsunterlagen.
Anschließend bewertet das Team die Systeme:
| System | Datensensitivität | Schutzdauer | Externe Exponierung | Lieferantenabhängigkeit | Migrationspriorität |
|---|---|---|---|---|---|
| Kundendokumenten-Tresor | Sehr hoch | Lang | Mittel | Cloud KMS und Speicheranbieter | Kritisch |
| B2B-API-Gateway | Hoch | Kurz bis mittel | Sehr hoch | Anbieter für API-Management | Hoch |
| Code-Signing-Plattform | Sehr hohe Integritätsauswirkung | Langfristiges Gerätevertrauen | Mittel | HSM- und Build-Pipeline-Werkzeuge | Kritisch |
Der Kundendokumenten-Tresor wird wegen der Vertraulichkeitsdauer priorisiert. Die Code-Signing-Plattform wird priorisiert, weil Signaturvertrauen Softwareintegrität und Kundensicherheit beeinflusst. Das API-Gateway hat aufgrund der externen Exponierung eine hohe Priorität, aber die aufbewahrten Daten können eine kürzere Vertraulichkeitsdauer haben.
Das Risikoregister sollte anschließend jedes Szenario mit Risikobehandlung und Nachweisen verknüpfen:
| Risikoszenario | Aktuelle Kontrolle | Risikobehandlungsentscheidung | Erforderliche Nachweise |
|---|---|---|---|
| Langlebige Kundendatensätze können künftiger Entschlüsselung ausgesetzt sein | Verschlüsselung ruhender Daten, Zugriffskontrolle, Cloud KMS | Roadmap für Speicherverschlüsselung bewerten, Schlüsseltrennung stärken, Kryptografie für Backup-Übertragungen überprüfen | CBOM, Lieferanten-Roadmap, Architekturentscheidung, Risikobehandlungsdatensatz |
| Vertrauen in Software-Updates kann durch künftige Signaturkompromittierung geschwächt werden | Code-Signing-HSM, Release-Freigabe | Bereitschaft für Post-Quanten-Signaturen, Zeitstempelstrategie und Signaturlebenszyklus bewerten | Signaturinventar, HSM-Fähigkeitsbericht, Verfahren für sichere Entwicklung |
| Kryptografie der Partner-API kann schwer kurzfristig zu ändern sein | TLS-Zertifikate, API-Gateway-Konfiguration | Tests zur Kryptoagilität und Überprüfung der Anbieter-Roadmap umsetzen | TLS-Scan, Baseline-Konfiguration, Anbieterbescheinigung |
Clarysecs Enterprise Policy, Richtlinie für sichere Softwareentwicklung, Klausel 6.4, liefert die Perspektive der Softwarebereitstellung:
„Prüfungen des Sicherheitsdesigns müssen kryptografische Abhängigkeiten, Bibliothekslebenszyklen, Algorithmusagilität, Umgang mit Geheimnissen, Aktualisierungsmechanismen und lieferantengesteuerte Komponenten vor der Produktivfreigabe bewerten.“
Diese Klausel macht Post-Quanten-Vorbereitung zu einer Engineering-Anforderung. Sie verhindert, dass Teams neue Systeme bereitstellen, die später nicht migriert werden können.
Einer 12-Monats-Roadmap folgen, die Auditoren verstehen
Die Post-Quanten-Migration wird für viele Organisationen Jahre dauern. Im ersten Jahr sollte die Organisation von Unsicherheit zu gesteuerter Migration gelangen.
| Monat | Arbeitsstrang | Ergebnis | Nachweise |
|---|---|---|---|
| 1 | Mandat der Geschäftsleitung | Geltungsbereich auf Ebene des Leitungsorgans, Risikobereitschaft und Finanzierungspfad | Protokolle des Lenkungsgremiums, genehmigte Charta |
| 1 bis 2 | Kryptografische Ermittlung | Initiale CBOM für kritische Services | Inventarexport, CMDB-Verknüpfungen, Bescheinigungen der Systemverantwortlichen |
| 2 bis 3 | Überprüfung von Daten und Schutzdauer | Priorisierte Liste langlebiger sensitiver Daten und Assets mit hoher Integritätsrelevanz | Klassifizierungsregister, Aufbewahrungsplan, Risikodatensätze |
| 3 bis 4 | Überprüfung von Lieferantenabhängigkeiten | Anbieter-Roadmaps und Analyse vertraglicher Lücken | Lieferantenfragebögen, Vertragsklauseln, Risikoausnahmen |
| 4 bis 6 | Architektur- und Kryptoagilitätsbewertung | Zielarchitekturmuster und Migrationsbeschränkungen | Aufzeichnungen zur Architekturprüfung, Designentscheidungen |
| 6 bis 8 | Pilotumsetzung | Hybrid- oder Post-Quanten-Test in einer ausgewählten risikoarmen Umgebung | Testergebnisse, Rollback-Plan, Feststellungen zur Leistung |
| 8 bis 10 | Aktualisierung von Richtlinien und Verfahren | Aktualisierte Regeln für Kryptografie, Schlüsselmanagement, Lieferanten, sichere Entwicklung und Assets | Genehmigte Richtlinien, Schulungsaufzeichnungen |
| 10 bis 12 | Auditbereitschaft | Internes Audit, Managementbewertung und Aktualisierung des Risikobehandlungsplans | Auditbericht, Korrekturmaßnahmen, aktualisierter Risikobehandlungsplan |
In Zenith Blueprint, Phase 3, Schritt 14, „Gestaltung und Verantwortlichkeit der Risikobehandlung“, warnt die Roadmap vor nicht finanzierten Sicherheitsabsichten:
„Ein Behandlungsplan ohne Verantwortlichen, Nachweiserwartung, Finanzierungspfad und Überprüfungsdatum ist kein Plan. Er ist ein ungelöstes Risiko mit besserer Formatierung.“
Genau so scheitern Post-Quanten-Programme. Sie erzeugen Sensibilisierungsfolien, aber keinen verantworteten Maßnahmenbestand. Sie diskutieren Algorithmen, aktualisieren aber keine Lieferantenverträge. Sie dokumentieren Risiken, testen aber keine Migrationsmuster.
Eine belastbare Roadmap schafft Entscheidungsaufzeichnungen, Verantwortliche, Abhängigkeiten, Nachweiserwartungen, Budgets und Überprüfungsdaten.
Lieferanten frühzeitig in das Programm einbinden
Viele kryptografische Abhängigkeiten sind ausgelagert. Cloud-Anbieter terminieren TLS. SaaS-Plattformen verschlüsseln Datensätze. Identitätsanbieter signieren Token. Zahlungsdienstleister verwalten Zertifikate. Hardwareanbieter kontrollieren Firmware-Signierung. Managed Service Provider betreiben VPNs und Sicherheitsgateways.
Selbst wenn Ihr internes Team bereit ist, kann Ihre Migration durch fehlende Lieferantenfähigkeit blockiert werden.
Clarysecs Enterprise Policy, Richtlinie zur Lieferanten- und Drittparteiensicherheit, Klausel 5.6, legt fest:
„Lieferanten, die sicherheitsrelevante Services bereitstellen, müssen wesentliche Abhängigkeiten, kryptografische Verantwortlichkeiten, Sicherstellungsnachweise, Prozesse zur Behandlung von Schwachstellen und Roadmap-Änderungen offenlegen, die das Risikoprofil der Organisation beeinflussen können.“
Für die Post-Quanten-Vorbereitung sollten Sie kritische Lieferanten fragen:
- Welche Algorithmen, Protokolle, Zertifikate und Schlüsselmanagementdienste schützen unsere Daten oder Transaktionen?
- Führen Sie ein kryptografisches Inventar oder eine CBOM?
- Wie sieht Ihre NIST-Post-Quanten-Roadmap aus?
- Werden Sie hybriden Schlüsselaustausch, Post-Quanten-Signaturen oder quantenresistente Schlüsseletablierung unterstützen?
- Wie werden Änderungen an Zertifikaten, Token, Signierung und Verschlüsselung kommuniziert?
- Welche Maßnahmen werden von Kunden erforderlich sein?
- Welche Testumgebungen werden verfügbar sein?
- Wie werden Leistung, Interoperabilität und Rollback behandelt?
- Sind kryptografische Verantwortlichkeiten im Vertrag oder im Modell der gemeinsamen Verantwortung definiert?
- Welche Exit- oder Portabilitätsoptionen bestehen, wenn Ihre Roadmap unsere Risikoanforderungen nicht erfüllt?
Antworten von Lieferanten sollten in das Risikoregister einfließen. Schwache Antworten bedeuten nicht immer eine sofortige Ablösung, erfordern aber eine Risikobehandlung. Möglicherweise benötigen Sie kompensierende Kontrollen, Vertragsänderungen, Benachrichtigungsklauseln, Exit-Planung, verstärkte Überwachung oder eine angepasste Sourcing-Strategie.
Dies ist besonders wichtig im Kontext von DORA und NIS2-orientierten Erwartungen an operative Resilienz. DORA legt den Schwerpunkt auf IKT-Risikomanagement und das Management von IKT-Drittparteirisiken, einschließlich der Aufsicht über kritische Abhängigkeiten. NIS2 Article 21 verlangt geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen zum Management von Sicherheitsrisiken, einschließlich Sicherheit der Lieferkette, Umgang mit Informationssicherheitsvorfällen, Aufrechterhaltung des Geschäftsbetriebs und, soweit angemessen, Kryptografie. GDPR Article 32 verlangt eine dem Risiko angemessene Sicherheit, einschließlich Vertraulichkeit, Integrität, Verfügbarkeit, Resilienz und der Fähigkeit, den fortlaufenden Schutz personenbezogener Daten sicherzustellen.
Die regulatorische Sprache unterscheidet sich, aber die Kontrolllogik ist konsistent: Abhängigkeiten kennen, Risiko steuern, Nachweise aufbewahren und handeln, bevor Resilienz beeinträchtigt wird.
Cross-Compliance-Mapping: ein Migrationsplan, viele Verpflichtungen
Ein starker Migrationsplan für Post-Quanten-Kryptografie sollte vermeiden, für jedes Rahmenwerk separate Nachweispakete zu erzeugen. Dieselben Kernnachweise können mehrere Verpflichtungen unterstützen, wenn sie richtig strukturiert sind.
Zenith Controls ordnet das Kryptografiethema ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIST, COBIT 2019, GDPR, DORA und NIS2 zu, indem der Kontrollzweck in den Mittelpunkt gestellt wird und nicht die Bezeichnung, die das jeweilige Rahmenwerk verwendet.
| Rahmenwerk | Wie der Post-Quanten-Plan die Einhaltung unterstützt |
|---|---|
| ISO/IEC 27001:2022 | Zeigt risikobasierte Kontrollauswahl, dokumentierte Informationen, interne Audits, Managementbewertung und kontinuierliche Verbesserung |
| ISO/IEC 27002:2022 | Unterstützt die Kontrollauslegung für 8.24 Use of cryptography, Asset-Inventar, Klassifizierung, Lieferantensicherheit, Cloud-Services, sichere Entwicklung, Überwachung und Kontinuität |
| NIST PQC-Standards | Bietet technische Richtung für den genehmigten Übergang zu Post-Quanten-Algorithmen und kryptografische Planung |
| NIST Cybersecurity Framework 2.0 | Verknüpft Migrationsaktivitäten mit Ergebnissen in Govern, Identify, Protect, Detect, Respond und Recover |
| COBIT 2019 | Richtet kryptografische Risiken an Governance- und Managementzielen wie APO12 Managed Risk, APO13 Managed Security, APO10 Managed Vendors, DSS05 Managed Security Services und MEA03 Managed Compliance aus |
| GDPR | Unterstützt Erwartungen nach Article 32 an angemessene Sicherheit, Vertraulichkeit, Integrität, Resilienz und Rechenschaftspflicht bei der Verarbeitung personenbezogener Daten |
| DORA | Unterstützt IKT-Risikomanagement, Management von IKT-Drittparteirisiken, Resilienztests, Vorfallsbereitschaft und Aufsicht durch das Leitungsorgan |
| NIS2 | Unterstützt Sicherheitsrisikomanagementmaßnahmen nach Article 21, Sicherheit der Lieferkette, Umgang mit Informationssicherheitsvorfällen, Aufrechterhaltung des Geschäftsbetriebs und Governance-Rechenschaftspflicht |
Die Wiederverwendung von Nachweisen ist der Schlüssel. Ein kryptografisches Inventar unterstützt ISO Asset-Management, NIST Identify-Ergebnisse, DORA-Sichtbarkeit von IKT-Assets, NIS2-Risikomanagement und GDPR-Rechenschaftspflicht. Lieferantenfragebögen unterstützen ISO-Lieferantenkontrollen, DORA-IKT-Drittparteirisiken, NIS2-Sicherheit der Lieferkette und COBIT-Lieferanten-Governance. Ergebnisse von Migrationstests unterstützen sichere Änderungen, Resilienztests, Auditbereitschaft und Managementbewertung.
Was Auditoren fragen werden
Post-Quanten-Kryptografie ist noch ein aufkommendes Auditthema, aber Auditoren haben bereits ausreichend Kontrollerwartungen, um anspruchsvolle Fragen zu stellen.
Ein Auditor nach ISO/IEC 27001:2022 wird in der Regel mit dem Risiko beginnen. Er wird fragen, ob quantenbezogene kryptografische Risiken im ISMS identifiziert, beurteilt, behandelt, überwacht und überprüft werden. Erwartet werden Nachweise, dass kryptografische Kontrollen auf Grundlage geschäftlicher Risiken ausgewählt werden und Verantwortlichkeiten definiert sind.
Ein an NIST orientierter Assessor kann den Fokus auf Asset-Sichtbarkeit, Schutzmechanismen, Lieferkettenrisiken, Schwachstellenmanagement und Governance-Ergebnisse legen. Er kann fragen, ob die Organisation Systeme identifiziert hat, die verwundbare Public-Key-Kryptografie verwenden, und ob die Migrationsplanung an der NIST-Richtung ausgerichtet ist.
Ein COBIT- oder ISACA-Auditor wird häufig nach Governance fragen. Wer ist rechenschaftspflichtig? Wie erhält das Leitungsorgan Berichte? Werden Investitionen priorisiert? Werden Lieferantenabhängigkeiten gesteuert? Sind Nutzen, Risiken und Ressourcen ausbalanciert?
Ein Datenschutzauditor kann sich darauf konzentrieren, ob Verschlüsselung und Schlüsselmanagement weiterhin der Sensitivität und Aufbewahrungsdauer personenbezogener Daten angemessen sind.
Ein auf DORA oder NIS2 fokussierter Prüfer wird Resilienz, IKT-Konzentration bei Drittparteien, operative Kontinuität und Vorfallsbereitschaft betrachten.
| Auditperspektive | Wahrscheinliche Fragen | Vorzubereitende Nachweise |
|---|---|---|
| ISO/IEC 27001:2022 | Ist das Post-Quanten-Risiko im ISMS-Risikoprozess enthalten? Werden kryptografische Kontrollen ausgewählt und überprüft? | Risikoregister, Behandlungsplan, Erklärung zur Anwendbarkeit, Richtlinienfreigaben, Ergebnisse interner Audits |
| NIST | Hat die Organisation den kryptografischen Einsatz inventarisiert und die Migration zu genehmigten Ansätzen geplant? | CBOM, Architekturentscheidungen, Pilotergebnisse, Migrations-Backlog |
| COBIT 2019 | Wird der kryptografische Übergang gesteuert, finanziert und überwacht? | Berichte an das Leitungsorgan, Governance-Protokolle, KPIs, Dashboards zu Lieferantenrisiken |
| GDPR | Bleibt der kryptografische Schutz für Sensitivität und Aufbewahrung personenbezogener Daten angemessen? | Datenklassifizierung, Verweise auf DPIAs, Aufbewahrungsplan, Verschlüsselungsdesign |
| DORA | Sind IKT- und Lieferantenabhängigkeiten verstanden und resilient? | IKT-Asset-Register, Lieferantenbescheinigungen, Testnachweise, Exit-Pläne |
| NIS2 | Sind Maßnahmen zum Management von Lieferketten- und Sicherheitsrisiken wirksam? | Lieferantenüberprüfungen, Verfahren zum Umgang mit Informationssicherheitsvorfällen, Kontinuitätspläne, Risikobehandlungsdatensätze |
Zenith Controls empfiehlt, Auditvorbereitung als Nachweispfad zu behandeln. Warten Sie nicht darauf, dass Auditoren Screenshots und Tabellen anfordern. Bauen Sie einen GRC-Arbeitsbereich auf, der jedes kryptografische Risiko mit seinem Verantwortlichen, betroffenen Assets, Lieferanten, Entscheidungen, Tests, Ausnahmen und Überprüfungsdaten verbindet.
Richtlinien aktualisieren, damit das Programm operativ wirksam wird
Die meisten Kryptografierichtlinien wurden für klassische Anforderungen an Vertraulichkeit und Integrität geschrieben. Die Post-Quanten-Migration erfordert gezielte Ergänzungen.
Ihre Richtlinie zu Kryptografie und Schlüsselmanagement sollte genehmigte Standards, Überprüfungsfrequenz, Datenklassifizierung, Schutzdauer, Algorithmusagilität, Schlüsselerzeugung, Schlüsselspeicherung, Rotation, Vernichtung, Verantwortlichkeit, Zertifikatslebenszyklus, HSM-Verantwortung, Cloud-KMS-Verantwortung, Ausnahmegenehmigung, lieferantengesteuerte Kryptografie und Überwachung des Post-Quanten-Übergangs abdecken.
Ihre Richtlinie für sichere Softwareentwicklung sollte Genehmigung kryptografischer Bibliotheken, das Verbot hartcodierter Algorithmen ohne Prüfung, Nachverfolgung von Abhängigkeiten, sichere Aktualisierungsmechanismen, Leistungstests für größere Schlüssel oder Signaturen, Abwärtskompatibilität, Rollback und Bedrohungsmodellierung für langlebige Produkte abdecken.
Ihre Richtlinie zur Lieferantensicherheit sollte kryptografische Transparenz, Anfragen zu Post-Quanten-Roadmaps, vertragliche Benachrichtigungspflichten, gemeinsame Verantwortung für Verschlüsselung und Schlüsselmanagement, Exit-Planung und Portabilität abdecken.
Ihr Verfahren zum Asset-Management sollte Felder des kryptografischen Inventars, Verantwortlichkeiten, Nachweisquellen, Überprüfungsfrequenz und Integration mit CMDB, Cloud-Inventar, Zertifikatsmanagement, HSM-Aufzeichnungen und Code-Repositories abdecken.
Hier hilft Clarysecs Richtlinienbibliothek Organisationen, schneller voranzukommen. Statt bei einer leeren Seite zu beginnen, können Teams Richtlinienklauseln in Verfahren, Register, Fragebögen und Auditnachweise überführen.
Die häufigsten Fehler bei der Post-Quanten-Migration vermeiden
Die gefährlichsten Fehler sind in der Regel Governance-Fehler, keine technischen Fehler.
Mit Algorithmen statt mit Assets beginnen. Wenn Sie nicht wissen, wo Kryptografie eingesetzt wird, hilft die Auswahl von Algorithmen nicht.
Die Lebensdauer von Daten ignorieren. Kurzlebige Transaktionsdaten und langlebige sensitive Archive tragen nicht dasselbe Risiko.
Lieferanten als spätere Phase behandeln. Viele kryptografische Kontrollen werden von Lieferanten verwaltet. Wenn Lieferanten nicht frühzeitig einbezogen werden, kann Ihr Plan unrealistisch sein.
Signaturen vergessen. Post-Quanten-Planung betrifft nicht nur Verschlüsselung. Digitale Signaturen, Code Signing, Zertifikate, Identitätstoken, Firmware-Updates und Dokumentsignaturen erfordern Aufmerksamkeit.
Annehmen, dass Cloud-Anbieter alles lösen. Cloud-Plattformen werden eine wichtige Rolle spielen, aber die Verantwortung bleibt geteilt. Sie müssen weiterhin wissen, welche Services, Konfigurationen, Schlüssel, Regionen und Integrationen betroffen sind.
Keine Auditnachweise erzeugen. Ein Migrationsplan, der nicht nachweisbar ist, wird Management, Aufsichtsbehörden, Kunden oder Auditoren nicht überzeugen.
Leistungs- und Interoperabilitätstests überspringen. Post-Quanten-Algorithmen können Payload-Größe, Handshake-Verhalten, Latenz, Speicherbedarf, Einschränkungen eingebetteter Systeme und Kompatibilität beeinflussen.
Kennzahlen, die der CISO an das Leitungsorgan berichten sollte
Berichte an das Leitungsorgan sollten einfach genug sein, um verstanden zu werden, und spezifisch genug, um Maßnahmen auszulösen. Vermeiden Sie tiefgehende Algorithmendebatten. Konzentrieren Sie sich auf Exponierung, Fortschritt, Entscheidungen und Restrisiko.
| Kennzahl | Bedeutung für das Leitungsorgan |
|---|---|
| Anteil kritischer Services mit abgeschlossenem kryptografischem Inventar | Zeigt Sichtbarkeit |
| Anteil langlebiger sensitiver Daten, die kryptografischen Kontrollen zugeordnet sind | Zeigt Vorbereitung auf „Harvest now, decrypt later“ |
| Anzahl kritischer Lieferanten, von denen eine Post-Quanten-Roadmap eingegangen ist | Zeigt Bereitschaft Dritter |
| Anzahl kryptografischer Ausnahmen mit hohem Risiko | Zeigt ungesteuerte Exponierung |
| Anteil kritischer Anwendungen, die auf Kryptoagilität bewertet wurden | Zeigt Machbarkeit der Migration |
| Abschlussstatus des Piloten | Zeigt praktischen Fortschritt |
| Überfällige offene Risikobehandlungsmaßnahmen | Zeigt Umsetzungsrisiko |
| Trend des Restrisikos | Zeigt, ob das Programm die Exponierung reduziert |
Eine geeignete Botschaft an das Leitungsorgan könnte so lauten:
„Wir haben die kryptografische Ermittlung für 72 Prozent der kritischen Services abgeschlossen. Zwei Systeme weisen eine kritische langlebige Vertraulichkeitsexponierung auf, und drei Lieferanten haben noch keine Post-Quanten-Roadmaps vorgelegt. Wir haben ein Projekt zur Vorbereitung des Code Signings und eine Überprüfung der Cloud-KMS-Abhängigkeiten gestartet. Ein Notfallaustausch wird derzeit nicht empfohlen, aber die Lieferantenunsicherheit bleibt das größte Restrisiko.“
Das ist die Sprache gesteuerter Cyberrisiken.
Eine praktische Checkliste für den Start in dieser Woche
Sie müssen nicht auf vollständige Gewissheit warten. Beginnen Sie mit Schritten, die Sichtbarkeit und Governance unmittelbar verbessern.
- Benennen Sie einen Verantwortlichen für Post-Quanten-Kryptografie.
- Nehmen Sie quantenbezogene kryptografische Risiken in das ISMS-Risikoregister auf.
- Identifizieren Sie die zehn wichtigsten Services mit langlebigen sensitiven Daten oder hohen Integritätsauswirkungen.
- Erstellen Sie für diese Services eine minimal tragfähige CBOM.
- Fragen Sie kritische Lieferanten nach ihrer Post-Quanten-Roadmap.
- Überprüfen Sie Richtlinien zu Kryptografie, sicherer Entwicklung, Lieferanten und Assets.
- Identifizieren Sie Systeme mit hartcodierten Algorithmen, veralteten Bibliotheken, manueller Zertifikatsrotation oder unklarer Verantwortlichkeit.
- Wählen Sie einen risikoarmen Piloten für Kryptoagilitätstests aus.
- Definieren Sie Kennzahlen für das Leitungsorgan und die Berichtsfrequenz.
- Planen Sie ein internes Audit mit Schwerpunkt auf kryptografischer Governance und Nachweisen.
Der wichtigste Schritt besteht darin, Unsicherheit in gesteuerte Arbeit zu überführen. Quantenrisiken mögen zukunftsgerichtet sein, aber kryptografische Altlasten bestehen bereits heute.
Nächste Schritte mit Clarysec
Die Post-Quanten-Migration wird einer der komplexesten Sicherheitsübergänge des nächsten Jahrzehnts sein, weil sie Identität, Verschlüsselung, Signaturen, Lieferanten, Cloud, Software, Geräte, Archive und Auditnachweise berührt. Organisationen, die mit Governance und Inventarisierung beginnen, werden schneller vorankommen als diejenigen, die auf einen kurzfristigen Austauschzyklus warten.
Clarysec kann Sie beim Aufbau eines quantensicheren Migrationsplans für Kryptografie unterstützen mit:
- Zenith Blueprint: 30-Schritte-Roadmap für Auditoren für phasenweise Umsetzung und Auditbereitschaft
- Zenith Controls: Der Cross-Compliance-Leitfaden für die Zuordnung zu ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIST, COBIT 2019, GDPR, DORA und NIS2
- Richtlinie zu Kryptografie und Schlüsselmanagement für governancefähige kryptografische Regeln
- Richtlinie zur Lieferanten- und Drittparteiensicherheit für Anforderungen an Lieferanten-Roadmaps und Sicherstellungsnachweise
- Richtlinie für sichere Softwareentwicklung für kryptoagile Engineering-Praktiken
Der beste Zeitpunkt, mit der Post-Quanten-Planung zu beginnen, ist, bevor eine Aufsichtsbehörde, ein Auditor, ein Kunde oder ein Mitglied des Leitungsorgans nach Nachweisen fragt. Beginnen Sie mit dem Inventar, verknüpfen Sie es mit Risiken und bauen Sie den Migrationspfad Entscheidung für Entscheidung kontrolliert auf.
Frequently Asked Questions
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council


