Was man nicht sieht, kann man nicht sichern: Die grundlegende Argumentation für kryptografische Ermittlung

Jede Organisation, die RSA- , ECC-, TLS- oder AES-basierte Verschlüsselung einsetzt, verfügt über kryptografische Ressourcen. Die meisten Organisationen haben jedoch keine Kenntnis darüber, was diese Ressourcen umfassen. Dies ist keine Kritik, sondern eine strukturelle Realität. Kryptografie war nie für die Verwaltung wie Server oder Anwendungen konzipiert. Sie besitzt keine IP-Adresse. Sie löst keine Warnung aus, wenn sie das Ende ihrer Nutzungsdauer erreicht. Sie läuft unbemerkt im Hintergrund nahezu jedes Systems, bis ein Fehler auftritt, eine Aufsichtsbehörde Dokumente anfordert, die nicht vorgelegt werden können, oder ein Bedrohungsmodell, das man zunächst als theoretisch abgetan hat, so real wird, dass jemand mit entsprechenden Ressourcen Maßnahmen ergreift. Die kryptografische Ermittlung ist ein mehrstufiger Prozess, der alle Algorithmen, Schlüssel, Zertifikate, Protokolle und Bibliotheken in der gesamten Umgebung findet und erfasst. Artikel 9.2 des DORA-Gesetzes und Anforderung 12.3.3 des PCI DSS-Standards machen dies seit Anfang 2025 zur rechtlichen Verpflichtung. Die im August 2024 finalisierten NIST FIPS 203, 204 und 205 machen sie zur technischen Voraussetzung für die Migration zu PQC (Python Qualifications Collection). Empfohlene Vorgehensweise: Beginnen Sie jetzt mit der kryptografischen Ermittlung, denn jede Compliance-Anforderung und jede Migrationsinitiative hängt davon ab. Was Sie mit den gefundenen Daten tun können, erfahren Sie unter „ Warum Ihr kryptografisches Inventar Ihr Hauptschlüssel ist“ und „Warum ein CBOM heute wichtiger denn je ist“.

Kurzantwort: Was ist kryptografische Ermittlung und warum ist sie obligatorisch?

Die kryptografische Ermittlung ist der Prozess der Identifizierung sämtlicher Algorithmen, Schlüssel, Zertifikate, Protokolle und kryptografischer Bibliotheken in der IT-Umgebung einer Organisation. Dies geschieht mithilfe von fünf sich ergänzenden Ermittlungsebenen: passive Netzwerkverkehrsanalyse, statische Codeanalyse, Konfigurations- und Zertifikatsprüfung, Laufzeit- und Binäranalyse sowie manuelle Untersuchung. Sie ist heute obligatorisch, da DORA-Artikel 9.2 und PCI-DSS-Anforderung 12.3.3 ab Januar bzw. März 2025 dokumentierte kryptografische Inventare als verbindliche Verpflichtungen vorschreiben. Zudem lässt sich die PQC-Migration gemäß NIST FIPS 203, 204 und 205 ohne ein solches Basisinventar weder planen noch abgrenzen.

Das wahre Ausmaß des Problems

Wenn Organisationen zum ersten Mal ein kryptografisches Inventar erstellen , sind sie durchweg überrascht von dem, was sie finden – nicht weil die Ergebnisse unerwartet sind, sondern weil es so viele sind und nur so wenige in einem bestehenden Aufzeichnungssystem erfasst wurden.

Laut BIS-Papier Nr. 158 bestehen 70 bis 90 Prozent der Unternehmenssoftware aus Komponenten von Drittanbietern. Jede dieser Komponenten beinhaltet kryptografische Entscheidungen, die das einsetzende Unternehmen nie direkt getroffen hat: Bibliotheksversionen, die an veraltete Abhängigkeiten gebunden sind, Standard-Verschlüsselungssuiten, die zum Zeitpunkt der Bibliothekserstellung festgelegt wurden, und Algorithmen, die in den Code eines Produkts integriert sind, dessen Hersteller nie kryptografische Informationen offengelegt hat.

Das Applied Quantum PQC Migration Framework schätzt, dass eine einzelne Mobile-Banking-Anwendung über 320 kryptografische Funktionsaufrufe enthält. Im gesamten Unternehmensnetzwerk beläuft sich die Gesamtzahl der kryptografischen Assets, Algorithmen, Schlüssel, Zertifikate, Protokolle und Bibliotheksimplementierungen auf Hunderttausende. Die meisten Organisationen haben nur einen Bruchteil davon formal dokumentiert.

Die Diskrepanz zwischen dem, was Unternehmen über ihren kryptografischen Bestand wissen, und dem, was tatsächlich im Produktivbetrieb läuft, ist keine geringfügige Bestandsabweichung. Sie ist die Ursache für jede Compliance-Lücke, jede Verzögerung bei der Behebung von Mängeln und jedes Migrationsprojekt, das doppelt so lange dauert wie geplant.

Die bereits aktiven Compliance-Verpflichtungen

Für Organisationen, die DORA , PCI DSS 4.0 oder NIS2 unterliegen , ist ein kryptografisches Inventar keine bloße Empfehlung, sondern eine geltende, rechtsverbindliche Verpflichtung.

Artikel 9.2 des DORA verpflichtet Finanzinstitute zur Führung eines aktuellen Verzeichnisses aller Informationsbestände, einschließlich kryptografischer Bestände, für alle IKT-Systeme, die kritische oder wichtige Funktionen unterstützen. Artikel 7.4 des DORA schreibt zudem vor, dass dieses Verzeichnis alle digitalen Zertifikate und die Geräte, auf denen sie gespeichert sind, umfassen muss. Beide Bestimmungen sind seit dem 17. Januar 2025 in Kraft.

Die PCI-DSS-Anforderung 12.3.3 verlangt ein dokumentiertes und fortlaufend aktualisiertes Verzeichnis aller verwendeten kryptografischen Verschlüsselungssammlungen und -protokolle mit einer geschäftlichen Begründung für jeden Eintrag, einer aktiven Überwachung der Funktionsfähigkeit und einer dokumentierten Reaktionsstrategie für alle identifizierten kryptografischen Schwachstellen. Diese Anforderung ist seit dem 31. März 2025 verbindlich.

Beides sind keine zukünftigen Fristen, sondern bereits heute geltende Verpflichtungen. Eine Organisation, die die erforderlichen Unterlagen im Rahmen einer aufsichtsrechtlichen Prüfung nicht vorlegen kann, weist keine Lücke in ihrem Fahrplan auf, sondern eine Lücke in einer seit Anfang 2025 geltenden, durchsetzbaren Anforderung. Der Business Case für den Aufbau eines kryptografischen Inventars erfordert keine umfassende Bedrohungsanalyse. Die Einhaltung der Vorschriften allein ist seit Januar 2025 mehr als ausreichend.

PQC-Standards und warum die Entdeckung an erster Stelle stehen muss

Das NIST finalisierte FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) und FIPS 205 (SLH-DSA) im August 2024. NIST IR 8547, veröffentlicht im November 2024, stuft RSA-2048 und ECC P-256 bis 2030 als veraltet und bis 2035 als vollständig unzulässig ein. NSA CNSA 2.0 setzt verbindliche Fristen für nationale Sicherheitssysteme ab Januar 2027. Diese Fristen erfordern dringenden Handlungsbedarf. Doch die Kenntnis der zu migrierenden Algorithmen ist nur die halbe Miete. Die andere Hälfte besteht darin, zu wissen, welche Systeme RSA, ECDH, ECDSA und Diffie-Hellman verwenden, in welchem ​​Kontext und mit welchen Hardware- und Softwareabhängigkeiten. Ohne ein grundlegendes kryptografisches Inventar ist die Migrationsplanung reine Spekulation, und Migrationsprojekte dauern regelmäßig doppelt so lange wie geplant. Die Migration von SHA-1 zu SHA-256 war auf fünf Jahre geschätzt; sie dauerte über zehn Jahre. Der postquantenmechanische Übergang ist in jeder Dimension größer.

Warum Ihre aktuellen Werkzeuge strukturelle Schwächen aufweisen

Beim Erstellen eines kryptografischen Inventars greift man instinktiv auf vorhandene Tools zurück: Schwachstellenscanner ausführen, Zertifikatsverwaltungssystem exportieren, CMDB abfragen. Jedes dieser Tools erfasst zwar nützliche Informationen, weist aber strukturelle Einschränkungen auf, die sich durch keine Konfiguration beheben lassen.

Zertifikatsverwaltungsplattformen verwalten die von Ihnen bei ihnen registrierten Zertifikate. Sie verfügen über keinen Mechanismus zur Erkennung von Zertifikaten, die außerhalb Ihres verwalteten Workflows bereitgestellt wurden, wie beispielsweise das Zertifikat, das ein Entwickler direkt bei einer öffentlichen Zertifizierungsstelle angefordert hat, das von einer Cloud-Plattform automatisch generiert wurde oder das noch in einer Staging-Umgebung aktiv ist, die nie außer Betrieb genommen wurde.

Schwachstellenscanner geben Auskunft darüber, was erreichbar ist und welche Dienste laufen. Sie zeigen jedoch nicht an, welche Verschlüsselungssammlungen aktiv für den Ost-West-Verkehr zwischen Ihren Anwendungsebenen ausgehandelt werden – also für die internen Dienstverbindungen, die am Netzwerkrand unsichtbar sind und fast nie denselben TLS-Richtlinien wie eingehender externer Datenverkehr unterliegen.

CMDBs erfassen offiziell bereitgestellte Infrastruktur. Sie erfassen jedoch nicht Cloud-Ressourcen, die außerhalb von Standard-Workflows eingesetzt werden, OT-Geräte, die vom Facility Management unabhängig bereitgestellt wurden, Systeme von übernommenen Unternehmen, die in den Betrieb integriert, aber nie in das Anlagenregister aufgenommen wurden, und alle Systeme, deren Eigentümer das Unternehmen verlassen hat, ohne dies zu dokumentieren.

Dies sind keine Werkzeugfehler, sondern konstruktionsbedingte Einschränkungen. Jedes Werkzeug wurde für einen bestimmten Zweck entwickelt, und dieser Zweck war nicht die kryptografische Ermittlung . Um die Lücken zu schließen, muss die Ermittlung als mehrschichtiger Prozess betrachtet werden, nicht als einmaliger Scan, der dann nicht weiter verfolgt wird.

Die fünf Entdeckungsebenen und was jede einzelne offenbart

Ein vollständiges kryptografisches Inventar erfordert fünf unterschiedliche Erkennungsebenen. Diese sind weder austauschbar noch redundant. Jede Ebene deckt auf, was die anderen strukturell nicht verbergen können.

Schichtmethode	Was es auf einzigartige Weise findet
Analyse des passiven Netzwerkverkehrs	Protokollverhandlung in Echtzeit im Produktivbetrieb: Was wird tatsächlich verwendet, nicht nur, was konfiguriert ist?
Statische Code-Analyse	Fest codierte Schlüssel, veraltete Bibliotheksimporte und in der Anwendungslogik festgelegte Algorithmen.
Konfiguration und Zertifikatsprüfung	Richtlinien für Verschlüsselungssuiten auf verwalteter Infrastruktur; Schattenzertifikate über CT-Protokolle
Laufzeit- und Binäranalyse	Kryptografische Sicherheitslage von Geräteherstellern, OT-Systemen und Firmware, die Sie nicht direkt lesen können
Manuelle Untersuchung	Kundenspezifische Protokolle, proprietäre Verfahren, undokumentierte Integrationen und organisatorischer Kontext

Schicht 1: Analyse des passiven Netzwerkverkehrs

Die passive Netzwerkanalyse ist die einzige Methode, die aufdeckt, welche kryptografischen Protokolle tatsächlich im Produktivbetrieb ausgehandelt werden – und nicht nur die, die laut Konfigurationen ausgehandelt werden sollten. Diese Unterscheidung ist wichtiger, als die meisten Teams annehmen.

Ein Server, der für TLS 1.3 konfiguriert ist , kann unter Umständen weiterhin TLS 1.1 mit älteren Endpunkten aushandeln, die keine höhere Kompatibilität bieten. Ein Load Balancer, der moderne Verschlüsselungssuiten am Netzwerkrand erzwingt, hat keine Kontrolle über die Backend-Verbindungen zwischen Anwendungsservern und Datenbanken, die die ursprünglich für die Anwendung vorgesehene Verschlüsselung verwenden. Die passive Analyse, die an Netzwerk-Taps oder SPAN-Ports an wichtigen Aggregationspunkten eingesetzt wird, erfasst Live-TLS-Handshake-Metadaten dieser Verbindungen, ohne den Datenverkehr zu entschlüsseln oder Produktionssysteme zu belasten.

Das von Jaime Gómez García auf der PKI Consortium PQC Conference 2025 vorgestellte kryptografische Inventarisierungsprogramm von Santander erreichte Transparenz über 9,000 Apache-Instanzen weltweit mithilfe angepasster bestehender Tools anstelle eigens entwickelter Discovery-Plattformen. Auf Layer 1 treten regelmäßig die operativ bedeutendsten Überraschungen auf.

Ebene 2: Statische Codeanalyse

Die statische Analyse durchsucht Quellcode-Repositories nach kryptografischen Elementen, die direkt in die Anwendungslogik eingebettet sind: fest codierte Schlüsselwerte, veraltete Bibliotheksimporte und explizite Schlüssellängenparameter bei der Schlüsselerzeugung. Diese kryptografischen Einstellungen sind auf Codeebene festgelegt und können nur durch eine vollständige Neuinstallation geändert werden.

Ein Aufruf von `hashlib.sha1()` in einer Produktionsanwendung ist nicht nur eine Warnung vor einem veralteten Algorithmus. Er erfordert eine Behebung des Problems, die eine Codeänderung, einen Build-Zyklus, einen Testzyklus und eine Bereitstellung notwendig macht. In einer unternehmensweiten Codebasis mit Hunderttausenden von Aufrufen kryptografischer Funktionen wird auf Layer 2 das wahre Ausmaß des Migrationsaufwands auf Anwendungsebene erstmals sichtbar.

Schicht 3: Konfiguration und Zertifikatsprüfung

Diese Ebene umfasst die auf Load Balancern, Firewalls und VPN-Konzentratoren konfigurierten Cipher-Suite-Richtlinien sowie den Zertifikatsbestand in Ihrer PKI- Umgebung und Cloud-Infrastruktur.

Die Protokolle für Zertifikatstransparenz (CT-Protokolle) sind die am häufigsten unterschätzte Datenquelle in dieser Ebene. Jede öffentlich vertrauenswürdige Zertifizierungsstelle (CA) ist verpflichtet, jedes von ihr ausgestellte Zertifikat in den CT-Protokollen zu erfassen , die öffentlich abfragbar sind. Eine CT-Protokollabfrage für Ihre Domains liefert alle jemals für diese ausgestellten Zertifikate, einschließlich derer, die nie in Ihrem Zertifikatsverwaltungssystem registriert wurden. Diese sogenannten Schattenzertifikate unterliegen den regulatorischen Bestimmungen, unabhängig davon, ob sie in Ihrem verwalteten Zertifikatsbestand aufgeführt sind.

Schicht 4: Laufzeit- und Binäranalyse

Bei Geräten von Drittanbietern, eingebetteter Firmware und OT-Systemen, für die kein Quellcode verfügbar ist, ist die Laufzeit- und Binäranalyse die einzig praktikable Methode zur Beurteilung des tatsächlichen kryptografischen Status. Dies gilt für Geldautomaten und POS-Terminals, Netzwerkgeräte, industrielle Steuerungssysteme und alle Geräte, deren kryptografische Implementierung in Firmware enthalten ist, die Ihr Unternehmen nicht selbst entwickelt hat und die es nicht direkt überprüfen kann.

NIST CSWP 39 dokumentiert, dass der durchschnittliche Aktualisierungszyklus von OT-Systemen 20 Jahre beträgt. In der Praxis bedeutet dies, dass veraltete kryptografische Algorithmen ein Jahrzehnt oder länger in Betriebstechnologieumgebungen verbleiben können, ohne dass ein Aktualisierungsmechanismus existiert und kein Governance-Prozess sie jemals berührt hat.

Ebene 5: Manuelle Untersuchung

Die Überprüfung von Architekturdokumentationen, die Prüfung von HSM- und KMS -Audit-Logs, die Analyse von Sicherheitsdokumentationen der Hersteller sowie strukturierte Interviews mit Plattform- und Systemverantwortlichen vervollständigen das Gesamtbild. Manuelle Untersuchungen decken kundenspezifische Protokolle, proprietäre Verschlüsselungsverfahren und undokumentierte Integrationen auf, die jeder automatisierten Ebene entgehen, und liefern den organisatorischen Kontext, der aus rein technischen Erkenntnissen verwertbare Handlungsempfehlungen macht.

Jede Ebene findet, was die anderen nicht finden. Wer eine Ebene überspringt, übernimmt dauerhaft deren blinde Flecken.

Welche Erkenntnisse müssen ans Licht kommen: Einschränkungen bei Algorithmen und Interoperabilität

Ein kryptografisches Erkennungsprogramm, das sich auf die Identifizierung vorhandener Algorithmen beschränkt, ist für die PQC-Migrationsplanung nicht ausreichend. Die Erkennung muss auch die Hardware- und Softwarebeschränkungen aufzeigen, die bestimmen, wie schnell jedes System migriert werden kann:

• Lücken in der HSM-Firmware-Unterstützung: Viele nach FIPS 140-3 validierte HSMs unterstützen ML-KEM oder ML-DSA noch nicht. Discovery muss für jedes kryptografische Asset, das ein HSM verwendet, das HSM-Modell und die Firmware-Version erfassen und die Roadmap des Herstellers für die Unterstützung von PQC-Algorithmen sowie den Zeitplan für die erneute Validierung nach FIPS 140-3 dokumentieren.
• TLS-Bibliotheksversionen: TLS 1.3-Implementierungen müssen aktualisiert oder gepatcht werden, um PQC-Schlüsselaustauschgruppen zu unterstützen. Die Erkennung muss die TLS-Bibliotheksversionen aller Endpunkte und Dienste erfassen und diejenigen kennzeichnen, die PQC ohne Bibliotheksaktualisierung nicht unterstützen.
• Fest codierte Algorithmusoptionen: Die Erkennung auf Ebene 2 deckt Algorithmen auf, die im Anwendungscode fest integriert sind. Diese lassen sich nicht durch Konfiguration ändern; sie erfordern Codeänderungen, Build-Zyklen und Deployments. Die Erkennung muss diese Algorithmen als solche kennzeichnen, die einen anderen Lösungsweg als Konfigurationsänderungen erfordern.
• Abhängigkeiten von Gegenparteien: Systeme, die die Interoperabilität mit noch nicht migrierten Gegenparteien aufrechterhalten müssen, benötigen während der Übergangsphase einen Hybridmodus. Im Rahmen der Analyse müssen die Abhängigkeiten von den Gegenparteien identifiziert werden, die den Migrationszeitplan einschränken.
• HNDL-Exposition: Die Erkennung muss die Algorithmennutzung der Lebensdauer der Datenvertraulichkeit zuordnen, damit Systeme, die Daten mit langfristigen Vertraulichkeitsanforderungen übertragen, die mit quantenanfälligen Algorithmen verschlüsselt sind, frühzeitig für eine Migration gekennzeichnet werden können.

Checkliste zur Implementierung der kryptografischen Erkennung

• Setzen Sie passive Netzwerksensoren an wichtigen Aggregationspunkten ein, um Live-TLS-Handshake-Metadaten aus dem Produktionsdatenverkehr zu erfassen.
• Führen Sie eine statische Codeanalyse in allen Quellcode-Repositories des Unternehmens durch und scannen Sie die Abhängigkeitsstrukturen von Drittanbietern.
• Führen Sie Abfragen der Certificate Transparency-Protokolle für alle Ihre Domains durch, um Schattenzertifikate aufzudecken, die sich nicht in Ihrem verwalteten Bestand befinden.
• Scannen Sie die Konfigurationen der Verschlüsselungssuiten auf allen Load Balancern, Firewalls und VPN-Konzentratoren.
• Führen Sie eine Laufzeit- oder Binäranalyse aller herstellerspezifischen Geräte, OT-Systeme und Firmware im Geltungsbereich durch.
• Führen Sie strukturierte Interviews mit Plattform- und Systeminhabern durch, um kundenspezifische Protokolle und undokumentierte Integrationen aufzudecken.
• Erfassen Sie HSM-Modell und Firmware-Version für alle Assets, die ein HSM verwenden; dokumentieren Sie die Roadmap für den PQC-Support des Anbieters.
• Erfassen Sie die TLS-Bibliotheksversionen aller Endpunkte und Dienste; kennzeichnen Sie diejenigen, die für den PQC-Schlüsselaustausch aktualisiert werden müssen.
• Verwendung eines Mapping-Algorithmus zur Bestimmung der Datenvertraulichkeitsdauer, um HNDL-exponierte Systeme für eine prioritäre Migration zu identifizieren.
• Weisen Sie jedem entdeckten Asset die Verantwortung zu; leiten Sie die Behebung an das zuständige Team weiter.
• Kennzeichnen Sie jedes gefundene Asset gemäß DORA Artikel 9, PCI DSS 12.3.3, CNSA 2.0 und NIST IR 8547, sofern zutreffend.
• Integrieren Sie die Erkennungstools in die DevSecOps-Pipeline, sodass neue Bereitstellungen das Inventar aktualisieren, bevor sie in die Produktion gelangen.
• Führen Sie eine kontinuierliche Überwachung des Zertifikatstransparenzprotokolls ein, um neu ausgestellte oder ablaufende Zertifikate zu identifizieren.

Wie Verschlüsselungsberatung Ihnen beim Aufbau Ihres kryptografischen Inventars helfen kann

Das Verständnis des Discovery-Problems ist der erste Schritt. Die richtige Plattform für dessen Umsetzung zu haben, ist der zweite, und genau hier kommt CBOM Secure ins Spiel.

CBOM Secure ist die ACDI-Plattform (Automated Cryptography Discovery and Inventory) von Encryption Consulting. Sie wurde speziell entwickelt, um alle fünf Erkennungsebenen als eine einzige integrierte Funktion auszuführen. Passive Netzwerksensoren erfassen die Protokollverhandlungen im Produktivverkehr in Echtzeit. Die statische Analyse ist direkt in Versionskontrollsysteme integriert, um sowohl den Quellcode als auch Abhängigkeiten von Drittanbietern zu scannen. Die Zertifikatsaufzählung erfolgt kontinuierlich anhand von CT-Protokollen und Zertifikatsverwaltungssystemen. Cloud-API-Abfragen decken die Konfigurationen für ruhende Verschlüsselung und Schlüsselverwaltung in verbundenen Cloud-Konten ab. Manuelle Untersuchungsworkflows fließen direkt in das CBOM ein, sodass keine außerhalb der automatisierten Tools entdeckten Informationen unentdeckt bleiben.

Jeder CBOM-Eintrag wird automatisch mit Informationen zum Status der Quanten-Schwachstellen, zur Eigentümerzuordnung und zu regulatorischen Compliance-Lücken gemäß DORA, PCI DSS 4.0 und NIS2 angereichert, sodass Ihr Team immer mit einem priorisierten, kontextbezogenen Bild des Systems arbeitet und nicht mit einer Sammlung unstrukturierter Ergebnisse.

CBOM Secure erstellt nicht einfach eine Liste von Ergebnissen und überlässt es Ihrem Team, die entsprechenden Maßnahmen zu ergreifen. Es bietet ein kontrolliertes, kontinuierlich gepflegtes System, das Erkenntnisse in konkrete Maßnahmen umsetzt – vom ersten Scan bis hin zu jeder nachfolgenden Änderung in Ihrer Umgebung.

Wo soll man anfangen

Der vollständige Umfang eines kryptografischen Inventars kann überwältigend wirken. Man muss sich nicht alles auf einmal vornehmen.

• Beginnen Sie mit den Ebenen 1 und 3: Ihre Load Balancer, VPN-Konzentratoren und Reverse-Proxys sind bereits in Ihrer CMDB erfasst, haben identifizierbare Verantwortliche und ihre kryptografischen Konfigurationen lassen sich mit den in den meisten Unternehmen bereits vorhandenen Tools ermitteln. Für Abfragen der Certificate Transparency-Protokolle ist keine zusätzliche Infrastruktur erforderlich.
• Bauen Sie den Lagerbestand schrittweise auf, nicht auf einmal: Das Applied Quantum PQC Migration Framework empfiehlt, zunächst eine umfassende Abdeckung der Layer 1 und Layer 2 zu erreichen. Je nach Größe des Systems kann dies Wochen bis Monate dauern. Beginnen Sie die Risikobewertung dieser Einträge umgehend, anstatt auf ein vollständiges Inventar zu warten, bevor Sie mit der Behebung beginnen. Sie können die Korrekturen für die bereits bekannten Probleme schrittweise durchführen und gleichzeitig die Transparenz der übrigen Bereiche weiter ausbauen.
• Binden Sie jetzt Ihre strategischen Lieferanten ein: Falls eine vom Hersteller gelieferte Komponente in Ihrer Umgebung von einer kryptografischen Bibliothek oder einem HSM abhängt, deren Upgrade-Pfad nach der Quantenablösung noch nicht kommuniziert wurde, muss dieses Gespräch umgehend beginnen. Die Zeitpläne der Hersteller liegen vollständig außerhalb Ihrer Kontrolle. Sie können lediglich den Zeitpunkt des Gesprächsbeginns beeinflussen.

Fazit

Das Problem der kryptografischen Erkennung ist keine zukünftige Herausforderung, sondern eine akute. Die meisten Unternehmen arbeiten mit erheblichen Diskrepanzen zwischen dem, was sie über ihren kryptografischen Bestand wissen, und dem, was tatsächlich im Produktivbetrieb eingesetzt wird. Diese Diskrepanzen sind nicht zu unterschätzen. Sie sind der Grund dafür, dass Migrationsprojekte ins Stocken geraten, Compliance-Audits unerwartete Ergebnisse zutage fördern und die Zeitpläne für die Behebung von Mängeln die ursprünglichen Schätzungen deutlich überschreiten.

Die Migration von SHA-1 zu SHA-256 war auf fünf Jahre geschätzt. Tatsächlich dauerte sie über zehn Jahre. Der Übergang zur Post-Quanten-Kryptographie ist in jeder Hinsicht komplexer, und die Compliance-Vorgaben gemäß DORA und PCI DSS 4.0 gelten bereits. Jeder Monat ohne ein vollständiges und kontrolliertes Inventar birgt ein zusätzliches Risiko. Zu wissen, was vorhanden ist, ist nicht das Ziel, sondern der Startpunkt. Doch alle weiteren Initiativen – Compliance, Migration und Governance – müssen diesen Punkt zuerst erreichen. Was Sie mit den gewonnenen Erkenntnissen anfangen können, erfahren Sie in „ Warum Ihr kryptografisches Inventar Ihr Schlüssel zum Erfolg ist“ und „Warum ein CBOM heute wichtiger denn je ist“ . Informationen zur Planung der PQC-Migration finden Sie in „ Das Quantenzeitalter erschließen: Wichtige Schritte für die Post-Quanten-Kryptographie-Bereitschaft“.

Im zweiten Teil dieser Reihe geht es darum, was mit den gefundenen Daten zu tun ist: wie eine kryptografische Stückliste Discovery-Daten in ein geregeltes Aufzeichnungssystem umwandelt und wie man sie nutzen kann, um Compliance-Nachweise zu erstellen, Risiken zu priorisieren und die Migration zu PQC zu planen.

Häufig gestellte Fragen

Was ist kryptografische Ermittlung und warum unterscheidet sie sich von einem Zertifikatsinventar?

Die kryptografische Ermittlung ist ein mehrstufiger Prozess zur Identifizierung aller Algorithmen, Schlüssel, Zertifikate, Protokolle und kryptografischen Bibliotheken, die in der IT-Umgebung eines Unternehmens verwendet werden. Sie unterscheidet sich von einem Zertifikatsinventar, da Zertifikatsverwaltungsplattformen nur die bei ihnen registrierten Zertifikate verwalten. Schattenzertifikate, Verschlüsselungssuiten für den Ost-West-Datenverkehr, fest codierte Schlüssel im Quellcode sowie kryptografische Einstellungen in Geräte- und OT-Systemen von Drittanbietern werden nicht berücksichtigt.

Welche Compliance-Anforderungen machen die kryptografische Ermittlung heute zwingend erforderlich?

Artikel 9.2 des DORA (Department of Credit Reporting Act) verpflichtet Finanzinstitute seit dem 17. Januar 2025 zur Führung eines dokumentierten kryptografischen Anlagenregisters. Anforderung 12.3.3 des PCI DSS (Payment Card Industry Data Security Standard) verlangt seit dem 31. März 2025 die fortlaufende Aktualisierung des Inventars der verwendeten Verschlüsselungssuiten. Beide Anforderungen sind aktiv durchsetzbar. Organisationen, die die erforderlichen Dokumente im Rahmen einer Aufsichtsprüfung nicht vorlegen können, erfüllen eine seit Anfang 2025 geltende, durchsetzbare Anforderung nicht.

Was sind die fünf kryptographischen Erkennungsebenen und was findet jede einzelne davon auf einzigartige Weise?

Schicht 1 (passive Netzwerkanalyse) deckt auf, welche Protokolle im Produktionsdatenverkehr tatsächlich ausgehandelt werden. Schicht 2 (statische Codeanalyse) findet fest codierte Schlüssel und veraltete Bibliotheksimporte in der Anwendungslogik. Schicht 3 (Konfigurations- und Zertifikatsprüfung) untersucht Cipher-Suite-Richtlinien und Schattenzertifikate mithilfe von CT-Logs. Schicht 4 (Laufzeit- und Binäranalyse) ist die einzige praktikable Methode für Geräte von Herstellern und OT-Systeme ohne Zugriff auf den Quellcode. Schicht 5 (manuelle Untersuchung) deckt benutzerdefinierte Protokolle und undokumentierte Integrationen auf, die von automatisierten Schichten übersehen werden.

Warum weisen bestehende Tools wie Schwachstellenscanner und CMDBs strukturelle blinde Flecken auf?

Zertifikatsverwaltungsplattformen verwalten ausschließlich registrierte Zertifikate. Schwachstellenscanner melden erreichbare Dienste, jedoch keine Verschlüsselungssuiten für den Ost-West-Datenverkehr. CMDBs erfassen offiziell bereitgestellte Infrastruktur, übersehen aber Cloud-Ressourcen, die außerhalb von Standard-Workflows eingesetzt werden, OT-Geräte aus dem Facility Management sowie Systeme aus Akquisitionen, die nie in das Anlagenregister integriert wurden. Dies sind konstruktionsbedingte Einschränkungen, keine Werkzeugfehler; jedes Werkzeug wurde für einen anderen Zweck als die kryptografische Erkennung entwickelt.

Wie unterstützt die kryptografische Ermittlung die PQC-Migration gemäß NIST FIPS 203, 204 und 205?

Die kryptografische Analyse liefert die notwendige Grundlage für die Planung und Festlegung des Umfangs der PQC-Migration. Das NIST finalisierte FIPS 203, 204 und 205 im August 2024. Die Auswahl der zu migrierenden Algorithmen ist nur die halbe Miete. Die andere Hälfte besteht darin, zu wissen, welche Systeme RSA, ECDH, ECDSA und Diffie-Hellman verwenden, in welchem ​​Kontext und mit welchen Hardware- und Softwareabhängigkeiten, die den Migrationszeitplan einschränken. Die Analyse identifiziert Lücken in der HSM-Firmware-Unterstützung, Einschränkungen der TLS-Bibliotheksversion, fest codierte Algorithmen, die Codeänderungen erfordern, und HNDL-exponierte Systeme, die frühzeitig migriert werden müssen.