Beoordeling van de gereedheid na de kwantumcrash: 75 vragen voor PKI- en beveiligingsteams

Kort antwoord: Een grondige beoordeling van de gereedheid na kwantumcomputing omvat acht categorieën: cryptografische inventaris, PKI- en certificaatinfrastructuur, HSM en sleutelbeheer, TLS en netwerkprotocollen, codeondertekening en softwareleveringsketen, applicatie- en endpointafhankelijkheden, gereedheid van leveranciers en derden, en governance, testen, budget en tijdlijn. Deze checklist bevat 75 vragen verdeeld over die acht categorieën, ontworpen om de specifieke lacunes aan het licht te brengen die generieke zelfbeoordelingen als "bent u klaar voor PQC?" over het hoofd zien.

De meeste zelfevaluaties van de PQC-gereedheid blijven zo algemeen dat bijna elke organisatie "enigszins gereed" kan antwoorden zonder dat de oefening een specifiek tekort aan het licht brengt. Deze checklist is juist andersom opgebouwd: specifiek genoeg dat een "nee" of "weet niet zeker" antwoord direct wijst op een concrete volgende actie, in plaats van een vaag aandachtspunt.

Key Takeaways

• 75 specifieke vragen, verdeeld over acht categorieën, leggen concrete lacunes bloot in plaats van een vage, onmeetbare score voor paraatheid te produceren.
• De categorieën inventaris, PKI en HSM roepen de meeste vragen op, wat aangeeft in hoeverre het risico in de beginfase van een daadwerkelijk PQC-programma zich in deze drie gebieden concentreert.
• Vragen over governance, testen, budget en tijdlijn zijn bewust opgenomen, omdat technische paraatheid zonder programmadiscipline zelden standhoudt bij een daadwerkelijke migratie die meerdere jaren duurt.
• Gebruik dit als een werkdocument dat elk kwartaal wordt herzien, en niet als een eenmalige scorekaart, aangezien de gereedheid en validatiestatus van leveranciers gedurende een migratieprogramma kunnen veranderen.

Cryptografische inventaris (12 vragen)

1. Beschikt u over een gedocumenteerde, actuele cryptografische inventaris met daarin algoritmen, sleutels en certificaten?
2. Wordt er bij die inventarisatie gebruikgemaakt van een gestandaardiseerd, machinaal leesbaar formaat (CycloneDX CBOM of een equivalent daarvan)?
3. Heeft elke inventarispost een benoemde eigenaar, en niet alleen een technische bevinding?
4. Heeft u de vertrouwelijkheidsduur van de gegevens die door elk cryptografisch element worden beschermd, berekend?
5. Heeft u de externe blootstelling voor elke bevinding geclassificeerd?
6. Omvat uw detectie ook netwerkverkeer, en niet alleen statische configuratie?
7. Omvat uw onderzoek de broncode en vastgelegde algoritme-aanroepen?
8. Omvat uw onderzoek ook gecompileerde binaire bestanden en software van derden waarvan u geen toegang hebt tot de broncode?
9. Omvat uw ontdekking ook in de cloud beheerde sleutels en certificaten via API's van providers?
10. Omvat uw onderzoek cryptografie op eindpuntniveau (schijfversleuteling, stuurprogramma's, Secure Boot)?
11. Heeft u een gedocumenteerd plan voor systemen die niet via een fysiek netwerk bereikbaar zijn en voor verouderde systemen die door geen enkel geautomatiseerd hulpmiddel kunnen worden bereikt?
12. Wordt uw voorraad volgens een vast, terugkerend schema bijgewerkt, in plaats van een eenmalige momentopname?

PKI en certificaatinfrastructuur (11 vragen)

1. Weet u of uw CA-platform ML-DSA ondersteunt, en zo ja, vanaf welke versie en update?
2. Weet u of uw CA-platform een ​​parallelle hiërarchie vereist in plaats van een in-place upgrade?
3. Heeft u de doelparametersets voor ML-DSA geselecteerd op basis van de CA-laag (root, intermediate, leaf)?
4. Heeft u al beoordeeld welke partijen een ML-DSA- of hybride certificaat momenteel kunnen valideren?
5. Heeft u een distributieplan voor een vertrouwensanker voor een nieuwe root-CA?
6. Heeft u al een keuze gemaakt tussen een puur PQC-certificaat en een samengesteld/hybride certificaatformaat op basis van het gebruiksscenario?
7. Heeft u uw OCSP- en CRL-infrastructuur getest met PQC-ondertekende antwoorden?
8. Heeft u de uitgifte van kortstondige certificaten al overwogen als alternatief voor het opschalen van de intrekkingsinfrastructuur?
9. Heeft u een vastgesteld pensioenplan en een datum voor de pensionering van uw bestaande CA-hiërarchie?
10. Heeft u een inventarisatie gemaakt van certificaatsjablonen die nog steeds gebruikmaken van verouderde cryptografische providers?
11. Houdt u bij welke certificaten buiten uw centrale PKI-proces zijn uitgegeven (via monitoring van het Certificate Transparency-logboek)?

HSM en sleutelbeheer (10 vragen)

1. Weet u of uw huidige HSM-firmware het PQC-algoritme ondersteunt?
2. Weet u wat de actuele FIPS 140-3/CMVP-validatiestatus van uw HSM-leverancier is voor de PQC-algoritmen, inclusief certificaatnummers?
3. Heeft u de doorvoer van PQC-ondertekening getest onder uw werkelijke productievolume?
4. Heeft u de PQC-sleutelback-up en -herstelfunctie getest op uw specifieke HSM-platform?
5. Heb je bevestigd dat de HA- en clusteringfuncties werken met PQC-sleuteltypen op je firmware?
6. Weet u welke van uw compliance-vereisten het bewaren van hardwarematige sleutels voor PQC-sleutels verplichten?
7. Als u overweegt van HSM-leverancier te veranderen, heeft u dan een plan opgesteld rondom sleutelheruitgifte in plaats van sleuteloverdraagbaarheid?
8. Heeft u belangrijke ceremonies gepland voor een nieuwe PQC-basis of -hiërarchie, onder dezelfde discipline van dubbele controle als uw bestaande ceremonies?
9. Heeft u een gedocumenteerd budget voor de vernieuwing van het HSM-systeem, gekoppeld aan uw PQC-tijdlijn?
10. Wordt uw overgang van FIPS 140-2 naar 140-3 als een aparte deadline bijgehouden, los van uw PQC-migratie?

TLS en netwerkprotocollen (9 vragen)

1. Heeft u hybride ML-KEM-sleuteluitwisseling (X25519MLKEM768) ingeschakeld op TLS-eindpunten die met internet verbonden zijn?
2. Heeft u hybride TLS getest met uw specifieke middlebox en TLS-inspectieapparaten?
3. Beschikt u over telemetrie op basis van onderhandelingsalgoritmen om stille klassieke terugval in productie te detecteren?
4. Heeft u de gereedheid voor de post-quantumperiode van uw VPN- en IPsec-infrastructuur specifiek beoordeeld?
5. Heeft u RFC 8784-vooraf gedeelde sleutels al overwogen als een eenvoudige, tijdelijke VPN-beveiliging?
6. Heb je gecontroleerd of je SSH-omgeving een recente OpenSSH-versie gebruikt met hybride sleuteluitwisseling als standaardinstelling?
7. Heeft u een inventarisatie gemaakt van jump hosts en automatiseringspipelines die afhankelijk zijn van SSH-hostsleutels?
8. Heeft u de gereedheid voor S/MIME-certificering beoordeeld, inclusief de vereiste voor een dubbel certificaat (ML-KEM plus ML-DSA)?
9. Heeft u de daadwerkelijke handshake-prestaties getest onder uw werkelijke gelijktijdigheid, en niet alleen de gepubliceerde benchmarks van de leverancier?

Codeondertekening en de softwareleveringsketen (9 vragen)

1. Heeft u de PQC-gereedheid van uw tijdstempelautoriteit bevestigd, los van uw codeondertekeningsalgoritme?
2. Heeft u firmware-artefacten die na implementatie niet opnieuw kunnen worden ondertekend, als een aparte risicocategorie beoordeeld?
3. Heeft u in kaart gebracht welke verificatiesystemen die uw ondertekende artefacten gebruiken, ML-DSA momenteel kunnen valideren?
4. Heeft u een parallelle pilot uitgevoerd met zowel klassieke als PQC-ondertekening op productie-artefacten?
5. Heeft u het PQC-migratiepad van uw Sigstore, SLSA of attestatietools beoordeeld?
6. Heeft u een CBOM die losstaat van uw bestaande SBOM en die de cryptografie omvat die uw build-artefacten beschermt?
7. Heeft u gecontroleerd of de HSM-integratie van uw CI/CD-ondertekeningspipeline de ML-DSA-sleutelopslagprovider ondersteunt?
8. Heeft u FN-DSA geëvalueerd voor scenario's met beperkte ondertekeningsmogelijkheden en de status van de conceptstandaardisatie ervan bijgehouden?
9. Heeft u langetermijnvalidatie (tijdstempels plus bewijs van intrekking) geconfigureerd voor uw ondertekeningsproces?

Applicatie- en eindpuntafhankelijkheden (8 vragen)

1. Heeft u een inventarisatie gemaakt van applicaties die hun eigen TLS-stack bundelen, onafhankelijk van het besturingssysteem?
2. Heeft u de toepassingen die gebruikmaken van de oudere CryptoAPI-providers vergeleken met de CNG-providers?
3. Heeft u schijfversleuteling en driverondertekening als een aparte eindpuntcategorie beoordeeld?
4. Heeft u de patchniveaus van de besturingssystemen van uw endpoints vergeleken met de specifieke uitroldata van de PQC-functionaliteit?
5. Heeft u apparaten met beperkingen (IoT, embedded systemen, OT) afzonderlijk beoordeeld van de algemene endpointinfrastructuur?
6. Heeft u een gateway-terminatiestrategie voor apparaten die PQC niet native kunnen uitvoeren?
7. Heeft u de PKI-beslissingen in de productiefase beoordeeld voor apparaten die nog in actieve productie zijn?
8. Heeft u de blockchain- of digitale activa-bewaarinfrastructuur, indien van toepassing, binnen uw organisatie beoordeeld?

Gereedheid van leveranciers en derden (8 vragen)

1. Heeft u een gestructureerde PQC-gereedheidsvragenlijst naar uw belangrijkste leveranciers gestuurd, waarin u om bewijsmateriaal vraagt ​​in plaats van algemene beweringen te accepteren?
2. Heeft u de PQC-gereedheid van uw specifieke cloudprovider voor elke dienst bevestigd, en niet een bewering die voor het hele bedrijf geldt?
3. Heeft u bevestigd aan welke kant van de verantwoordelijkheidslijn elke cloud PQC-functionaliteit zich daadwerkelijk bevindt?
4. Heeft u de PQC-gereedheid van de betalingsverwerker en de financiële tegenpartij beoordeeld, indien van toepassing?
5. Heeft u de gereedheid van correspondentbanken of interbancaire API-partners beoordeeld, indien van toepassing?
6. Heeft u met elke belangrijke leverancier bevestigd dat er een terugdraaiplan bestaat voor het geval er na de implementatie een compatibiliteitsprobleem optreedt?
7. Heeft u het uitfaseringbeleid en de planning voor elke leverancier met betrekking tot klassieke algoritmen gedocumenteerd?
8. Heeft u al overwogen of een hardwarevernieuwing in het kader van PQC ook een geschikt moment is om de leverancierskeuze te heroverwegen?

Bestuur, testen, budget en tijdlijn (8 vragen)

1. Is er een aangewezen, verantwoordelijke leidinggevende voor uw PQC-programma?
2. Heeft u een gedocumenteerde RACI-matrix voor de volgende rollen: crypto, PKI, applicaties, infrastructuur, inkoop, juridische zaken, risicobeheer en audit?
3. Heeft u uw programma afgestemd op de toepasselijke wettelijke deadlines (CNSA 2.0, federale PQC-mandaten, DORA, eIDAS of andere)?
4. Hanteert u een risicogebaseerd scoringsmodel voor de volgorde van migraties, in plaats van een vaste prioriteitenlijst?
5. Heeft u een gedocumenteerd budget voor detectietools, HSM-vernieuwing, PKI-infrastructuur en adviesondersteuning?
6. Heeft u een meerjarenplanning opgesteld met duidelijk gedefinieerde fasegrenzen, in plaats van één enkele streefdatum voor de voltooiing?
7. Heeft u gedocumenteerd bewijsmateriaal en een rapportagecyclus voor naleving en belanghebbenden op directieniveau?
8. Herziet u deze beoordeling met een vaste frequentie naarmate de gereedheid van de leverancier en de normen zich ontwikkelen?

Wat we daadwerkelijk zouden aanbevelen

Beoordeel elke categorie eerlijk in plaats van optimistisch; een "nee" of "weet niet" antwoord is waardevoller voor een programma dan een ambitieus "ja", omdat het direct wijst op een concrete volgende actie. Geef prioriteit aan de categorieën inventaris, PKI en HSM als uw organisatie zich nog in de beginfase van het programma bevindt, aangezien hiaten op deze gebieden de voortgang in alle andere categorieën kunnen belemmeren. Bekijk deze checklist elk kwartaal opnieuw in plaats van deze als een eenmalige scorekaart te beschouwen, aangezien de status van leveranciersvalidatie en de volwassenheid van de standaarden beide voortdurend veranderen tot en met 2026 en verder.

Hoe encryptieconsultancy kan helpen

Onze PQC Advisory Services voeren deze beoordeling uit als een gestructureerde workshop in uw daadwerkelijke omgeving, waarbij elk "nee"-antwoord wordt omgezet in een afgebakend, stapsgewijs werkitem in plaats van een open vraag te blijven. CBOM Secure beantwoordt de vragen over de inventariscategorieën direct met behulp van echte ontdekkingsgegevens in plaats van een zelfgerapporteerde schatting.

Een checklist die expres ongemakkelijk is gemaakt.

Een goede gereedheidsbeoordeling moet een aantal ongemakkelijke "nee"-antwoorden opleveren; dat is precies de bedoeling. 75 specifieke vragen over inventaris, PKI, HSM, TLS, codeondertekening, applicaties, leveranciers en governance leggen de werkelijke lacunes bloot die een organisatie met een algemene zelfbeoordeling niet kan negeren. Door eerlijk elke categorie te doorlopen en de resultaten elk kwartaal in plaats van eenmalig te evalueren, wordt een checklist daadwerkelijk omgezet in programma-vooruitgang.

Veelgestelde Vragen / FAQ

Hoe kan een organisatie een checklist met 75 vragen gebruiken zonder overweldigd te raken?

Werk de categorieën één voor één af in plaats van alles tegelijk, en beschouw elke "nee" als een taak die je moet inplannen in plaats van een score waar je je slecht over voelt. Door eerst de categorieën inventaris, PKI en HSM te prioriteren, komen de belangrijkste knelpunten meestal aan het licht.

Hoe vaak moet deze beoordeling worden herhaald?

Een driemaandelijkse evaluatie is voor de meeste organisaties een redelijke frequentie tijdens een actief migratieprogramma, aangezien de validatiestatus van leveranciers, de afronding van standaarden en de platformmogelijkheden in die periode aanzienlijk veranderen.

Welke categorie brengt doorgaans de meeste tekortkomingen aan het licht bij organisaties in de beginfase van hun PQC-programma?

Cryptografische inventarisatie, consistent. De meeste organisaties die een PQC-programma starten, ontdekken dat hun bestaande inventarisatie, indien aanwezig, niet de ontdekkingslagen, eigendomsgegevens of blootstellingsclassificatie omvat die deze checklist vereist.

Is deze checklist relevant voor organisaties buiten gereguleerde sectoren?

Ja. Hoewel sommige vragen verwijzen naar specifieke regelgeving, zijn de onderliggende categorieën – inventaris, PKI, HSM, TLS, codeondertekening, applicaties, leveranciers en governance – van toepassing op elke organisatie met een degelijke cryptografische infrastructuur, ongeacht wettelijke verplichtingen.

Moet elke vraag evenveel gewicht in de schaal leggen bij het beoordelen van de paraatheid?

Nee. Weeg de vragen op basis van hun relevantie voor uw specifieke omgeving en wettelijke verplichtingen; een vraag over de gereedheid van een betalingsinfrastructuur weegt bijvoorbeeld niet mee voor een organisatie zonder betalingsinfrastructuur en moet eerder worden beoordeeld dan gescoord.