Das CTO-Büro der Microsoft Security Division hat in dieser Woche ein Framework für Cryptographic Posture Management veröffentlicht. Es strukturiert PQC-Arbeit in vier Domänen (Code, Netzwerk, Laufzeit, Speicher), einen sechsstufigen Lebenszyklus (Discover, Normalize, Assess, Prioritize, Remediate, Monitor) und eine Tabelle, die Microsoft-eigene Werkzeuge sowie namentlich genannte Partnerprodukte den Domänen zuordnet.
Für eine CISO-Ebene, die ein PQC-Programm über ein großes Estate hinweg sequenziert, ist das Framework eine nützliche gemeinsame Struktur. Die Aufteilung in Domänen verhindert, dass Code-Inventar, Netzwerk-Posture, Laufzeittelemetrie und Speicher-at-rest-Aspekte zu einer einzigen Frage „sind wir PQC-bereit“ verwischen. Die Lebenszyklusstufen geben Programm-Managern etwas, gegen das sie prüfen können. Dass Microsoft das aus dem Security-Division-Büro veröffentlicht, signalisiert zudem, dass Beschaffungsgespräche zum Thema PQC jetzt auf ein benanntes Framework verweisen können, statt aus ersten Prinzipien zu improvisieren.
Dieser Beitrag liest das Framework so, wie ein Netzwerk-Team es liest, und schlägt vor, wo eine begleitende Messebene daneben passt.
Die Netzwerkspalte und was sie abdeckt
Microsofts Tabelle weist der Netzwerkdomäne zwei Werkzeuge zu. Defender for Endpoint ist das primäre. Die Zelle lautet:
Identifies encrypted traffic sessions (TLS, SSH) via network detection and response.
Daneben steht Azure Network Watcher, der auf Flow-Ebene anzeigt, dass Verkehr verschlüsselt ist und zu welcher Protokollklasse er gehört. Die Lebenszyklus-Anweisungen wiederholen die Form: Die Startschritte der Netzwerkdomäne sind, MDE zur Erkennung verschlüsselter Sessions zu aktivieren und Network Watcher zur Erfassung von Verkehrsmetadaten zu konfigurieren.
Das ist eine nützliche Information. Ein Inventar der Session-Präsenz sagt einem Programm-Team, wo verschlüsselter Verkehr überhaupt existiert, und dort beginnt jeder PQC-Migrationsplan. Ohne dieses Inventar kann ein Team Endpunkte komplett übersehen.
Ein Netzwerk-Team möchte typischerweise zusätzlich wissen, was diese Sessions aushandeln: welche Algorithmen der Client angeboten hat, welchen der Server ausgewählt hat, ob der Schlüsselaustausch klassisch, hybrid oder rein Post-Quanten ist und ob die Zertifikatskette mit RSA, ECDSA oder ML-DSA signiert ist. Das sind andere Fragen als „ist eine Session verschlüsselt“, und sie kommen aus der Analyse von Handshake-Inhalten, nicht aus Flow-Metadaten.
Wie die genannten Partner die Abdeckung erweitern
Vier Partner erscheinen im Framework. Keyfactor und Entrust arbeiten in PKI und Zertifikatslebenszyklus-Management, was zählt, weil Zertifikatsauthentifizierung eine der beiden Stellen ist, an der PQC landet (die andere ist der Schlüsselaustausch). Isara fokussiert Discovery, Inventarisierung und Remediation-Workflow über ein großes Estate. Forescout bringt Netzwerk-Posture ein, in der PQC-Klassifizierung eine Dimension unter vielen in einer Risikomatrix für IT, IoT und OT ist.
Jeder dieser Partner passt gut zu der Ebene, die er besetzt. Ein Handshake-Inhaltsparser daneben, der liest, was auf der Leitung tatsächlich ausgehandelt wird an den Endpunkten, die MDE als verschlüsselt markiert hat, rundet das Bild ab. pqprobe ist eine Möglichkeit für diese Rolle; ein in-House-Werkzeug auf Basis von Zeek oder tshark ist eine andere. Die Kategorie zählt mehr als das konkrete Produkt.
Wo Trajektorie in den Lebenszyklus passt
Die sechs Lebenszyklusstufen erzeugen jeweils Zustand zu einem Zeitpunkt. Monitor verfolgt Inventaränderungen über Snapshots hinweg, was die Frage „was hatten wir damals gegenüber jetzt“ beantwortet. Eine ergänzende Sicht ist, ob ein bestimmter Endpunkt sich über aufeinanderfolgende Scans in Richtung PQC verbessert, stabil bleibt, oszilliert oder zurückfällt. Trajektorie als messbare Größe passt natürlich in die Monitor-Stufe und gibt Programm-Teams ein frühes Signal, wenn ein Deployment regressiert, anstatt auf den nächsten vollen Bewertungszyklus zu warten.
Das ist keine Kritik am Framework. Es ist die Art Messung, die sich darauf setzen lässt.
Was pqprobe beiträgt, innerhalb und außerhalb des Microsoft-Estates
pqprobe analysiert TLS-Handshakes über dreizehn Protokolle im passiven Modus. Jeder Scan erfasst angebotene und ausgewählte Cipher Suites, Schlüsselaustauschgruppen einschließlich hybrider Konstruktionen wie X25519MLKEM768, Signaturalgorithmen der Zertifikate über die gesamte Kette und die Konformität mit hybrider PQC nach BSI TR-02102. Wiederholte Scans erzeugen eine Trajektorienklassifikation (IMPROVING, DEGRADING, STABLE, OSCILLATING) gegen eine Baseline.
Für Teams, die bereits MDE betreiben, liest pqprobe Advanced-Hunting-Exporte direkt ein. Ein einzelnes pqprobe import mde konsumiert die Tabellen DeviceTvmSoftwareInventory und DeviceFileCertificateInfo aus einem MDE-CSV- oder -JSON-Export, bildet jeden Software-Eintrag gegen einen PQC-Fähigkeitskatalog ab, der fünfzehn Krypto-Bibliotheken abdeckt (OpenSSL, BoringSSL, rustls, Bouncy Castle, Go crypto, Windows SymCrypt und weitere) und mit Versionsbereich-Matching arbeitet, und erzeugt PQC-Bewertungen pro Gerät zusammen mit Befunden zum Zertifikatszustand. Die Ergebnisse fließen in dasselbe Dashboard und dieselbe Bewertung wie Handshake-Scans, sodass Inventar-Baseline und On-Wire-Messung nebeneinander in einer Ansicht leben. Das deckt die Stufen Discover und Assess des CPM-Lebenszyklus ab, ohne dass etwas auf Endpunkten ausgerollt werden muss.
Der zweite Teil zählt für die meisten Organisationen mehr. Das CPM-Framework ist um Microsoft-Werkzeuge herum organisiert, was für den Microsoft-gemanagten Teil eines Estates der richtige Umfang ist. Der Rest des Estates reicht normalerweise darüber hinaus: Linux-Server außerhalb der Defender-Abdeckung, Netzwerk-Appliances und Load Balancer, SaaS-Endpunkte, die die Organisation nutzt aber nicht selbst betreibt, Anbieter-APIs, externe Zahlungsdienstleister, IoT- und OT-Systeme, Legacy-Infrastruktur aus Übernahmen. Diese Endpunkte tragen TLS-Handshakes, und Harvest-now-decrypt-later gilt für sie genauso wie für Windows-Workloads. Eine CISO-Ebene, die ein PQC-Programm plant, braucht einen Blick auf diese Oberfläche und nicht nur auf den Teil, den Microsoft ohnehin sieht.
pqprobe scannt jeden erreichbaren Endpunkt per Hostname oder IP, sodass die MDE-Baseline und die externen Handshake-Daten in demselben Dashboard landen. Selbstgehostete Deployments halten alle Scan-Daten innerhalb der Infrastruktur des Kunden.
Das Framework gut nutzen
Das CPM-Framework gibt einem PQC-Programm echte Struktur für den Microsoft-gemanagten Teil eines Estates. MDE und Network Watcher decken Session-Inventar innerhalb dieses Estates ab. Die Partnerliste füllt PKI, Remediation-Workflow und generalistische Posture. Handshake-Inhaltsmessung an den Endpunkten, die MDE identifiziert hat, Scans der nicht-Microsoft-Oberfläche, die das Framework nicht abdeckt, und Trajektorien-Tracking über das Ganze geben einem Netzwerk-Team das Gesamtbild, das es für die Sequenzierung einer Migration und deren Verifikation braucht.
Das Mitnehmen für Teams, die den Microsoft-Beitrag diese Woche lesen: Das Framework ist ein solides Planungswerkzeug für den Teil des Estates, den Microsoft sehen kann, und die meisten Organisationen brauchen eine ergänzende Ebene für alles Weitere. Die interne Sicht mit externer Handshake-Messung zu paaren, ist das, was einer CISO-Ebene ein Bedrohungsmodell liefert, das zur tatsächlichen Angriffsoberfläche passt.