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

Jede Organisation, die läuft RSAECC-, TLS- oder AES-basierte Verschlüsselungsmethoden verfügen über einen kryptografischen Bestand. Die meisten Organisationen haben keine Ahnung, was dieser umfasst.

Das ist keine Kritik, sondern eine strukturelle Realität. Cryptography Es war nie für die Verwaltung wie Server oder Anwendungen konzipiert. Es besitzt keine IP-Adresse. Es löst keine Warnung aus, wenn es das Ende seiner Nutzungsdauer erreicht. Es läuft unbemerkt im Hintergrund fast jedes Systems, das Sie betreiben – bis etwas ausfällt, bis eine Aufsichtsbehörde Dokumente anfordert, die Sie nicht vorlegen können, oder bis ein Bedrohungsmodell, das Sie als theoretisch abgetan haben, so real wird, dass jemand mit den entsprechenden Ressourcen zum Handeln gezwungen ist.

Das Ergebnis ist vorhersehbar. Organisationen häufen über Jahre hinweg kryptografische Schulden an, ohne deren volles Ausmaß zu erkennen. SHA-1 bleibt in Systemen bestehen, die jahrelang unberührt geblieben sind. Triple-DES Es läuft immer noch auf Zahlungsterminals, die in einer anderen Ära konfiguriert wurden. Fest codierte Schlüssel befinden sich in Repositories, die Entwickler längst nicht mehr nutzen. Zertifikate laufen auf einer Infrastruktur, die offiziell niemandem gehört. Und irgendwo in Ihrer Cloud-Umgebung läuft ein Microservice mit Standardverschlüsselungseinstellungen, die nie bewusst festgelegt wurden.

Dies ist das Problem der kryptografischen Erkennung, und es liegt jeder anderen kryptografischen Initiative zugrunde, die Ihr Unternehmen durchführen muss. Compliance-Bereitschaft, Migration nach der Quantenmigration, Zertifikatslebenszyklusverwaltungund wichtige Governance-Aspekte: All diese Aspekte erfordern, dass man weiß, was man hat, bevor sinnvolle Arbeit beginnen kann.

Das wahre Ausmaß des Problems 

Wenn Organisationen zum ersten Mal versuchen kryptografisches InventarSie sind immer wieder überrascht von dem, was sie finden, nicht weil die Ergebnisse unerwartet sind, sondern weil es so viele davon gibt 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 birgt kryptografische Entscheidungen, die das einsetzende Unternehmen nie direkt getroffen hat: Bibliotheksversionen, die an veraltete Abhängigkeiten gebunden sind, Chiffresuite Standardeinstellungen, die zum Zeitpunkt der Erstellung der Bibliothek festgelegt wurden, algorithmische Entscheidungen, die in den Code integriert sind, der in einem Produkt ausgeliefert wird, dessen Anbieter niemals eine kryptografische Offenlegung veröffentlicht hat.

Die angewandte Quanten PQC-Migration Das Framework schätzt, dass eine einzelne Mobile-Banking-Anwendung über 320 kryptografische Funktionsaufrufe enthält. Unternehmensweit 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. 

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 Sie die Zertifikate, die Sie bei ihnen registriert haben. Sie verfügen über keinen Mechanismus zur Erkennung von Zertifikaten, die außerhalb Ihres verwalteten Workflows bereitgestellt wurden, beispielsweise das Zertifikat, das ein Entwickler direkt von einer öffentlichen Zertifizierungsstelle angefordert hat, das von einer Cloud-Plattform automatisch generiert wurde oder das noch in einer Staging-Umgebung ausgeführt wird, die nie außer Betrieb genommen wurde. 

Sicherheitslücken-Scanner Sie berichten darüber, was erreichbar ist und welche Dienste laufen. Sie geben jedoch nicht preis, 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 wird offiziell bereitgestellte Infrastruktur. Nicht berücksichtigt werden 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 Anlagenverzeichnis aufgenommen wurden, und alle Systeme, deren Eigentümer das Unternehmen verlassen hat, ohne dies zu dokumentieren.

Dies sind keine Werkzeugfehler, sondern Konstruktionsmängel. Jedes Werkzeug wurde für einen bestimmten Zweck entwickelt, und dieser Zweck war nicht kryptographische EntdeckungUm die Lücken zu schließen, muss die Datenanalyse als mehrschichtige Disziplin betrachtet werden, nicht als ein einzelner Scan, den man einmal durchführt und dann hinter sich lässt.

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 & 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 die Unterstützung konfiguriert ist TLS 1.3 Möglicherweise wird weiterhin TLS 1.1 mit älteren Endpunkten ausgehandelt, die keine höhere Sicherheit 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, wie z. B. fest codierte Schlüsselwerte, veraltete Bibliotheksimporte und explizite Schlüssellängenparameter bei Schlüsselerzeugungsaufrufen. 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 Ihres Netzwerks. PKI Umgebung und Cloud-Infrastruktur.

Certificate Transparency (CT)-Logs sind die am häufigsten unterschätzte Datenquelle in dieser Ebene. Jedes öffentlich vertrauenswürdige Zertifikat. Zertifizierungsstelle (CA) ist verpflichtet, jeden Bescheinigung Es werden Zertifikate in CT-Logs gespeichert, die öffentlich abfragbar sind. Eine CT-Log-Abfrage für Ihre Domains liefert alle jemals für diese ausgestellten Zertifikate, einschließlich derer, die nie in Ihrem Zertifikatsverwaltungssystem registriert wurden. Dies sind Ihre Schattenzertifikate, die unabhängig davon, ob sie in Ihrem verwalteten Bestand erscheinen, regulatorisch relevant 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 Dokumente belegen, 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

Überprüfung der Architekturdokumentation HSM und KMS Die Prüfung von Audit-Logs, die Analyse der Sicherheitsdokumentation von Anbietern und 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 Informationen generiert.

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

Die Compliance-Verpflichtungen sind bereits aktiv 

Für Organisationen, die folgenden Bestimmungen unterliegen DORA, PCI DSS 4.0 oder NIS2Ein kryptografisches Inventar ist keine bloße Empfehlung für bewährte Verfahren. Es handelt sich um eine geltende, durchsetzbare rechtliche Verpflichtung. 

DORA Artikel 9.2 Verlangt von Finanzinstituten, ein aktuelles Verzeichnis aller Informationsbestände, einschließlich kryptografischer Bestände, für alle IKT-Systeme zu führen, die kritische oder wichtige Funktionen unterstützen. DORA Artikel 7.4 Ferner ist vorgeschrieben, dass dieses Register alle digitalen Zertifikate und die Geräte, auf denen sie gespeichert sind, enthalten muss. Beide Bestimmungen sind seit [Datum einfügen] in Kraft. 17. Januar 2025.

PCI DSS-Anforderung 12.3.3 Erfordert ein dokumentiertes und fortlaufend aktualisiertes Verzeichnis aller verwendeten kryptografischen Verschlüsselungssuiten 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 [Datum einfügen] durchsetzbar. 31. März 2025.

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 im Fahrplan auf, sondern eine Lücke in einer rechtsverbindlichen Anforderung, die seit Anfang des Jahres in Kraft ist.

Die wirtschaftliche Begründung für den Aufbau eines kryptografischen Inventars erfordert weder eine Quantenbedrohungsanalyse noch ein formelles Mandat für eine Post-Quanten-Migration. Die Compliance-Anforderungen allein sind seit Januar 2025 mehr als ausreichend.

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 Die ACDI-Plattform (Automated Cryptography Discovery and Inventory) von Encryption Consulting 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-Logs 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 dynamische CBOM (Cryptography Observation Model) ein und stellen so sicher, dass keine außerhalb der automatisierten Tools entdeckten Informationen unentdeckt bleiben.

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

CBOM Secure erstellt keine Liste von Ergebnissen und überlässt es Ihrem Team, die entsprechenden Maßnahmen festzulegen. Stattdessen bietet es 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 Eigentümer und ihre kryptografischen Konfigurationen lassen sich mit Tools ermitteln, die die meisten Unternehmen bereits besitzen.
• 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 mit der Behebung zu warten, bis ein vollständiges Inventar vorliegt. Sie können die Korrekturen für die bereits bekannten Probleme schrittweise durchführen und gleichzeitig die Transparenz der übrigen Einträge 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 kryptographische Entdeckung Das Problem 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 sollte ursprünglich fünf Jahre dauern. Tatsächlich dauerte sie über zehn Jahre. Der Übergang nach der Quantenintegration ist in jeder Hinsicht umfangreicher, und die Compliance-Vorgaben gemäß DORA und PCI DSS 4.0 gelten bereits. Jeder Monat ohne vollständiges und ordnungsgemäß geführtes Inventar birgt ein zusätzliches Risiko.

Zu wissen, was man hat, ist nicht das Ziel, sondern der Startpunkt. Doch jede weitere Initiative, jede Compliance-Maßnahme, jede Migration und jede Governance-Maßnahme muss diesen ersten Schritt bestehen. Die Organisationen, die sich diese Transparenz jetzt schaffen, sind bereit, wenn es darauf ankommt.

Teil 2 Diese Reihe behandelt die Frage, was mit den gefundenen Daten zu tun ist: wie eine kryptografische Stückliste Discovery-Daten in ein geregeltes Aufzeichnungssystem umwandelt und wie man sie nutzt, um Compliance-Nachweise zu generieren, Risiken zu priorisieren und die Migration zu PQC zu planen.