Von der Entdeckung zur Anwendung: Wie eine kryptografische Stückliste Inventar in Erkenntnisse verwandelt

Dies ist Teil 2 einer zweiteiligen Serie. Teil 1 behandelt das kryptografische Ermittlungsproblem und das Fünf-Schichten-Framework zum Aufbau eines vollständigen Inventars.

In Teil 1 haben wir dargelegt, warum die kryptografische Erkennung fünf verschiedene Ebenen erfordert, warum bestehende Tools strukturelle Schwachstellen aufweisen und warum die Fristen für die Einhaltung der Vorschriften gemäß DORA und PCI DSS 4.0 nicht erst näher rücken, sondern bereits abgelaufen sind. Doch die Erkennung allein genügt nicht.

Die Ergebnisse einer kryptografischen Bestandsaufnahme sind nur so nützlich wie deren Auswertung. Die meisten Teams, die diesen Punkt erreichen, tappen in eine von zwei Fallen: Entweder behandeln sie die Ergebnisse als eine Liste, die in einer Tabelle priorisiert wird, oder sie warten mit jeglichen Maßnahmen, bis die Bestandsaufnahme vollständig ist. Beide Ansätze führen zum gleichen Problem: Sie verzögern den Zeitpunkt, an dem die Erkenntnisse tatsächlich zu einer Risikominderung führen.

Dieser Blog behandelt die zweite Hälfte der Herausforderung: Was eine kryptografische Stückliste (CBOM) ist, warum sie sich grundlegend von einer Ergebnisliste unterscheidet und wie man sie nutzen kann, um die Generierung von Compliance-Nachweisen, die Risikopriorisierung und die Planung der Post-Quanten-Migration voranzutreiben.

Was ein CBOM ist und was er nicht ist

Das Ergebnis der kryptografischen Analyse ist keine Liste von Problemen, die in einer Tabellenkalkulation verwaltet werden müssen. Es handelt sich um ein CBOM ( Cryptographic Asset Management), einen dynamischen, kontinuierlich aktualisierten und abfragefähigen Datensatz, der als zentrale Datenquelle für alle kryptografischen Assets in Ihrem gesamten Portfolio dient.

Der Unterschied zwischen einem CBOM und einer Mängelliste ist nicht rein semantischer Natur. Eine Mängelliste beschreibt, was nicht stimmt. Ein CBOM hingegen zeigt Ihnen, was existiert , wem es gehört, welches Risiko damit verbunden ist, welche Daten es schützt und was damit geschehen muss. Und all das liefert es kontinuierlich, nicht als Momentaufnahme, die bereits mit ihrer Erstellung veraltet ist.

CycloneDX ECMA-424 ist das etablierte Standardformat für CBOMs. Es wurde von OWASP übernommen, in den Post-Quanten-Migrationsrichtlinien des NIST NCCoE referenziert und als Grundlage für das Open-Source-CBOM-Datenmodell von Santander verwendet. Jeder Eintrag in einem korrekt strukturierten CBOM erfasst:

• Algorithmenkennung und OID
• Schlüsselgröße
• Protokollkontext
• Bibliotheksname und Version
• Zertifikatsreferenz
• Datensensitivitätsklassifizierung
• Quantenverwundbarkeitsstatus
• Migrationsstatus
• Benannter Eigentümer
• Herstellerabhängigkeitsflag

Diese letzte Gruppe von Feldern – Datensensibilitätsklassifizierung, Status der Quantensicherheitslücke, benannter Eigentümer und Herstellerabhängigkeit – macht einen CBOM-Eintrag erst relevant und nicht nur informativ. Beachten Sie den Unterschied:

Die Feststellung, dass RSA-2048 in einem TLS- Kontext verwendet wird, ist eine Beobachtung.

Ein Befund, der besagt, dass RSA-2048 in einem TLS-Kontext auf einer Zahlungsverarbeitungs- API , die PAN-Daten mit langer Aufbewahrungsdauer verarbeitet, dem Team für Zahlungsinfrastruktur untersteht und die eine HSM- Abhängigkeit eines Anbieters aufweist, dessen FIPS 203- Roadmap für das dritte Quartal 2026 vorgesehen ist, ein Arbeitselement mit einem bekannten Verantwortlichen, einem definierten Risikokontext und einer konkreten Einschränkung ist, wann die Behebung realistischerweise beginnen kann.

Ein Eintrag befindet sich im Rückstand. Der andere treibt einen Plan voran.

Die vier Risikodimensionen, die die Priorisierung bestimmen

Nicht alle kryptografischen Schwachstellen haben die gleiche Dringlichkeit, und ein CBOM, das den Risikokontext nicht berücksichtigt, erzeugt eine undifferenzierte Liste von Befunden, die die Behebungsteams überfordert und dazu führt, dass die falschen Punkte zuerst priorisiert werden.

Eine effektive Risikobewertung im Rahmen Ihres CBOM sollte vier verschiedene Dimensionen berücksichtigen:

1. HNDL-Enthüllung (Harvest Now, Decrypt Later): Angreifer sammeln heute aktiv verschlüsselten Datenverkehr, um ihn nach der Einführung leistungsfähiger Quantencomputer zu entschlüsseln – eine dokumentierte Strategie, kein theoretisches Risiko. Besonders gefährdete Daten bleiben auch nach der Einführung dieser Hardware sensibel: Finanzdaten mit langer Aufbewahrungsfrist, geschützte Gesundheitsinformationen, Regierungskommunikation und Geschäftsgeheimnisse. Systeme, die diese Daten schützen, haben ein deutlich kürzeres Zeitfenster für Gegenmaßnahmen als Systeme, die flüchtige Sitzungsdaten verarbeiten.
2. Zeit, bis es nicht mehr machbar ist (TNFL): Wie lange dauert es, bis ein Schutzsystem für ein Asset praktisch angreifbar wird? RSA-2048 schätzt, dass diese Zeitspanne bei optimistischen Zeithorizonten 10–15 Jahre beträgt und sich mit fortschreitender Hardwareentwicklung verkürzt. Unternehmensmigrationen dauern in der Regel drei bis fünf Jahre für jedes komplexe Programm. Die Lücke zwischen TNFL Die Migrationszeit ist Ihr eigentliches Risikofenster, und dieses schrumpft.
3. Regulatorisches Engagement: DORA, PCI DSS 4.0 und NIS2 jeweils festgelegte Fristen für die Einhaltung der Vorschriften unabhängig von der Quantenzeitleiste; ein veraltetes Chiffresuite Die Nutzung einer Zahlungsabwicklungs-API birgt bereits heute regulatorische Risiken, unabhängig davon, wann Quanten-Sicherheit eine praktische Bedrohung darstellt. Kennzeichnen Sie CBOM-Einträge anhand spezifischer regulatorischer Anforderungen, damit Compliance-Lücken als eigenständige Dimension neben der zugrunde liegenden technischen Schwachstelle sichtbar bleiben.
4. Machbarkeit der Sanierung: Eine Schwachstelle in einem System, das von einem HSM eines Herstellers abhängig ist, der die FIPS-Standards 203, 204 oder 205 nicht unterstützt, kann erst behoben werden, wenn der Hersteller das entsprechende HSM bereitstellt. Diese Einschränkung gehört zusammen mit dem entsprechenden Befund in den CBOM-Eintrag, da sie den frühestmöglichen Beginn der Behebung festlegt und direkt in die Migrationsplanung einfließen muss.

Eine Risikobewertung, die alle vier Dimensionen berücksichtigt, erzeugt eine priorisierte, sequenzielle Abfolge von Sanierungsmaßnahmen, nicht nur eine Bestandsaufnahme von allem, was letztendlich geändert werden muss, sondern einen Plan, der widerspiegelt, was jetzt tatsächlich getan werden kann, was durch externe Abhängigkeiten blockiert ist und was das dringendste HNDL- oder regulatorische Risiko birgt.

Wie ein CBOM die Erstellung von Compliance-Nachweisen unterstützt

Sowohl Artikel 7.4 des DORA als auch Anforderung 12.3.3 des PCI DSS schreiben die Dokumentation und kontinuierliche Pflege kryptografischer Inventare vor. Entscheidend ist, dass die Nachweispflicht für die Einhaltung der Vorschriften nicht einmalig im Rahmen eines Audits erbracht werden muss, sondern eine fortlaufende Anforderung darstellt, die den aktuellen Zustand der IT-Systeme jederzeit widerspiegeln muss.

Eine Organisation, die Compliance-Nachweise vor jedem Auditzyklus manuell zusammenstellt, birgt zwei strukturelle Risiken. Erstens beansprucht die manuelle Zusammenstellung Zeit, die den meisten Sicherheitsteams fehlt. Zweitens spiegelt die resultierende Dokumentation einen Stichtag wider, der zum Zeitpunkt der Prüfung durch den Prüfer bereits veraltet sein kann.

Ein nach dem CycloneDX ECMA-424-Schema strukturiertes CBOM beseitigt beide Probleme, indem es die bedarfsgerechte Generierung von konformitätsfähigen Ausgaben ermöglicht:

• DORA-Artikel 7.4-Zertifikatsregister: Jeder Zertifikatseintrag im CBOM, einschließlich Eigentümer, Ausstellungsdatum, Ablaufdatum, ausstellender Zertifizierungsstelle und zugehörigem ICT-Asset, wird kontinuierlich aktualisiert, sobald neue Zertifikate durch CT-Protokollüberwachung und Zertifikatsscanning entdeckt werden.
• Inventar der PCI DSS 12.3.3 Verschlüsselungssuiten: Jeder Algorithmus- und Protokolleintrag im CBOM, mit geschäftlicher Begründung pro Eintrag, Datum der letzten Überprüfung und dokumentiertem Reaktionsstatus für alle markierten Schwachstellen, bereit zur Überprüfung durch den Prüfer ohne manuelle Vorzusammenstellung.

Die praktischen Auswirkungen auf die Auditvorbereitung sind erheblich: Anstatt vor jedem Prüfzyklus wochenlang Nachweise zu sammeln, wird der Nachweis der Konformität durch eine Abfrage des aktuellen, kontinuierlich gepflegten CBOM-Status erbracht. Der operative Aufwand verlagert sich von der Erstellung zur Wartung, und bei korrekter Durchführung ist die laufende Wartung deutlich geringer.

Nutzung des CBOM zur Steuerung der PQC-Migrationsplanung

Die Migration nach der Quantenmigration ist kein einzelnes Projekt mit einem festgelegten Start- und Enddatum. Sie ist vielmehr ein Portfolio voneinander abhängiger Sanierungsmaßnahmen, die jeweils durch unterschiedliche Faktoren eingeschränkt werden: Liefertermine der Anbieter, Abhängigkeitsketten von Anwendungen, HSM-Upgrade-Zyklen, regulatorische Fristen und das HNDL-Exponierungszeitraum der zu schützenden Daten.

Ohne ein CBOM (Community-Based Outsourcing Model) beruht die PQC-Migrationsplanung größtenteils auf fundierten Schätzungen hinsichtlich Umfang, Zeitplan und Abhängigkeitsketten. Mit einem solchen Model kann der Migrationsplan auf tatsächlichen Systemzuständen basieren, anstatt auf Annahmen, die aus unvollständigen Anlagendatensätzen abgeleitet werden.

Drei Planungsparameter, die sich direkt aus CBOM-Daten ergeben, verdienen besondere Erwähnung:

• Lieferantenabhängigkeitsabbildung: Das Applied Quantum PQC Migration Framework identifiziert die Abhängigkeit von Anbietern als das längste Segment auf dem kritischen Pfad für die meisten Unternehmen. PQC-Migration Programme. Liegt der GA-Termin eines Anbieters gemäß FIPS 203, 204 oder 205 noch 18 Monate in der Zukunft, können abhängige Systeme erst nach der Auslieferung durch den Anbieter migriert werden, unabhängig vom Umfang der internen Vorarbeiten. Jeder Monat Verzögerung bei der Kontaktaufnahme verschiebt den Zeitplan um einen Monat. CBOM-Einträge mit Anbieterabhängigkeit liefern Ihnen die genaue Liste der Anbieter, die Sie vor Beginn der formalen Planung kontaktieren sollten.
• Quantifizierung des Anwendungsbereichs: Die Ergebnisse der statischen Layer-2-Analyse, aggregiert über das gesamte CBOM, liefern Ihnen die vollständige Anzahl veralteter kryptografischer Aufrufe in Ihrer Codebasis: Aufrufe von hashlib.sha1(), RSA-Schlüsselgenerierung mit zu kleinen Parametern und fest codierte Schlüssel in der Anwendungslogik. Jeder dieser Aufrufe erfordert eine Codeänderung, einen Build, einen Test und eine Bereitstellung. Die Kenntnis dieser Anzahl vor der Festlegung eines Zeitplans ist entscheidend für einen realistischen Plan und für einen, der ständig überarbeitet werden muss, sobald der Umfang klarer wird.
• HNDL-Triage: Nicht alle Arbeitsabläufe sind gleich dringlich, und eine vollständige Migration ist selten realisierbar. CBOM-Einträge mit Kennzeichnung der Datensensibilität und des Status der Quantensicherheitslücke ermöglichen eine Priorisierung, die Systeme zum Schutz sensibler Langzeitdaten, Systeme mit aktiver Gefährdung durch HNDL (High-Nuclear Data Licensing) und solche, die hauptsächlich durch regulatorische Fristen gesteuert werden, voneinander trennt. Diese Unterscheidung ist entscheidend für die Reihenfolge der Arbeitsabläufe, wenn Kapazitäten und Zeitpläne der Anbieter die parallele Ausführung einschränken.

Das CBOM ist kein Lieferergebnis, sondern eine Fähigkeit.

Einer der folgenreichsten Fehler bei Programmen zur kryptografischen Inventarisierung ist die Behandlung des CBOM als Projektergebnis: etwas, das erstellt, abgenommen und übergeben wird. Das ist es nicht. Wie das Applied Quantum PQC Migration Framework ausdrücklich feststellt, ist die kontinuierliche Erkennung eine Voraussetzung für Krypto-Agilität.

Eine Organisation, die keinen aktuellen Überblick über ihre kryptografische Infrastruktur hat, kann nicht überprüfen, ob Algorithmusänderungen korrekt angewendet wurden. Sie kann nicht erkennen, wenn Systeme von den vorgesehenen Richtlinien abweichen. Sie kann auf eine neu entdeckte kryptografische Schwachstelle nicht mit der nötigen Sicherheit hinsichtlich des Ausmaßes der Gefährdung reagieren. Und sie kann die von DORA und PCI DSS explizit geforderte, fortlaufend aktualisierte Compliance-Dokumentation nicht erstellen.

Das CBOM ist keine einmalige Entwicklung, die man archiviert. Es handelt sich um eine fortlaufende operative Fähigkeit, ein kontinuierlich gepflegtes Datenerfassungssystem, das die persistente Datenermittlung in eine dauerhafte Steuerung umwandelt. Der anfängliche Entwicklungsaufwand ist beträchtlich. Die laufende Wartung hingegen, bei korrekter Strukturierung und mit den richtigen Werkzeugen, ist es nicht.

Wie Verschlüsselungsberatung Ihnen bei der optimalen Nutzung Ihres CBOM helfen kann

Der Aufbau eines CBOM und dessen Aufrechterhaltung als lebendige, operative Fähigkeit erfordert die richtige Plattform: CBOM Secure.

CBOM Secure wurde von Grund auf nach dem Prinzip entwickelt, dass Erkennung und Governance kontinuierlich und nicht periodisch erfolgen müssen. Die Plattform integriert alle fünf Erkennungsebenen – passive Netzwerkanalyse, statische Code-Scans, Zertifikatsaufzählung, Laufzeit- und Binäranalyse sowie manuelle Untersuchungs-Workflows – in einen einzigen, einheitlichen CBOM-Datenspeicher. Jeder Eintrag wird automatisch mit einer Risikobewertung in den vier in diesem Beitrag behandelten Dimensionen angereichert: HNDL-Exponierung, TNFL, Kennzeichnung regulatorischer Lücken gemäß DORA, PCI DSS 4.0 und NIS2 sowie Machbarkeit von Abhilfemaßnahmen basierend auf dem Status der Anbieterabhängigkeit.

Die Nachweise zur Einhaltung der Vorschriften, das Zertifikatsregister gemäß DORA Artikel 7.4 und das Inventar der PCI-DSS-12.3.3-Verschlüsselungssuiten mit der jeweiligen geschäftlichen Begründung werden bedarfsgesteuert direkt aus dem aktuellen CBOM-Status generiert. Eine manuelle Vorbereitung vor den Auditzyklen entfällt. Die Dokumentation spiegelt den Ist-Zustand wider, nicht den Zustand zum letzten Erfassungszeitpunkt.

CBOM Secure gewährleistet zudem die Betriebskontinuität, die die meisten Inventarisierungsprogramme nicht gewährleisten können. Bei der Bereitstellung neuer Systeme, der Implementierung von Code und Änderungen von Lieferantenabhängigkeiten aktualisiert die Plattform kontinuierlich das CBOM. So bleibt Ihr Überblick über die Systemlandschaft stets aktuell und Ihre Compliance-Anforderungen werden zwischen den Prüfungen stets erfüllt.

Was macht man als nächstes

Wenn Sie mit einem minimalen kryptografischen Inventar beginnen, sieht die praktische Abfolge folgendermaßen aus:

1. Führe eine CT-Protokollabfrage aus Prüfen Sie für Ihre primären Domains, ob die Ergebnisse mit Ihrem Zertifikatsverwaltungssystem übereinstimmen. Jedes Zertifikat, das in den CT-Protokollen erscheint, aber in Ihrem verwalteten Bestand fehlt, ist ein Schattenzertifikat – aktiv, unterliegt regulatorischen Bestimmungen und ist nicht dokumentiert. Diese Lücke ist Ihr unmittelbarster und greifbarster Verstoß gegen Artikel 7.4 des DORA-Gesetzes.
2. Beginn der Entdeckung von Ebene 1 und Ebene 3 Ihre gesamte verwaltete Infrastruktur umfasst Load Balancer, VPN-Konzentratoren und Reverse-Proxys. Diese Ressourcen haben bekannte Verantwortliche, sind mit den Tools erreichbar, die Sie wahrscheinlich bereits besitzen, und liefern schnell wertvolle Erkenntnisse.
3. Beginnen Sie vom ersten Tag an mit dem Erstellen von CBOM-Einträgen. Anstatt auf eine umfassende Datenabdeckung zu warten, bevor Sie mit den Daten arbeiten, sollten Sie die vorhandenen Daten sofort nach Erhalt einer Risikobewertung unterziehen. Beginnen Sie die Behebung der Probleme mit der höchsten Priorität. Erweitern Sie parallel dazu die Datenerfassung.
4. Identifizieren Sie Ihre strategischen Lieferantenabhängigkeiten.Alle vom Hersteller gelieferten Komponenten Ihrer kryptografischen Infrastruktur, deren Upgrade-Pfad nach der Quantenabstinenz unbekannt ist oder deren Roadmap gemäß FIPS 203/204/205 noch nicht offiziell kommuniziert wurde, sollten umgehend kontaktiert werden. Die Zeitpläne der Hersteller liegen außerhalb Ihrer Kontrolle; Sie können lediglich den Zeitpunkt des Gesprächsbeginns bestimmen.
5. Behandeln Sie das CBOM als ein lebendes System, nicht als einen Projektmeilenstein. Weisen Sie die Verantwortlichkeiten zu. Etablieren Sie einen kontinuierlichen Ermittlungszyklus. Binden Sie die Ermittlungsergebnisse direkt in den CBOM-Datenspeicher ein, damit neue Erkenntnisse stets im Kontext sichtbar sind und sich nicht in unzusammenhängenden Tabellen ansammeln, für deren Abgleich niemand verantwortlich ist.

Fazit

Ein kryptografisches Inventar ohne Governance-Struktur ist lediglich eine Momentaufnahme, die schnell veraltet. Ein CBOM ohne kontinuierliche Überprüfung ist ein Dokument, keine Fähigkeit. Organisationen, die ihre kryptografische Infrastruktur als ein lebendiges, verwaltetes System und nicht als ein abzuschließendes und abzulegendes Projekt behandeln, werden ihre Compliance-Verpflichtungen erfüllen, ihre Post-Quanten-Migration in einem realistischen Zeitrahmen durchführen und auf neue Schwachstellen souverän statt unsicher reagieren können.

Die Migration von SHA-1 zu SHA-256 war auf fünf Jahre geschätzt. Tatsächlich dauerte sie über zehn Jahre. Der Übergang nach der Quantenverschlüsselung ist in jeder Hinsicht umfangreicher, und die Compliance-Vorgaben gelten bereits. Das Zeitfenster für den Aufbau dieser Kapazitäten, bevor sie dringlich werden, schließt sich. Organisationen, die jetzt mit einem verwalteten und kontinuierlich gewarteten CBOM (Community-Based Outsourcing Management) als zentralem Bestandteil ihres kryptografischen Programms beginnen, werden bereit sein, wenn es darauf ankommt.