Migrering til postkvantekryptografi med ISO 27001

Projektorens summen er den eneste lyd i bestyrelseslokalet. Sarah, CISO’en, har netop afsluttet sin kvartalsvise risikoopdatering, da den administrerende direktør løfter en udskrift af en artikel fra finanspressen. Overskriften er kontant: “The Quantum Countdown: Is Your Data Already Obsolete?”
“Sarah,” siger han, mindre anklagende end oprigtigt bekymret, “vi har brugt millioner på kryptering. Vi overholder kravene. Vi er sikre. Artiklen siger, at en tilstrækkeligt kraftig kvantecomputer kan bryde det hele. Er vi eksponeret? Hvad med de data, vi krypterer og lagrer lige nu? Er det en tikkende bombe?”
Det er den samtale, der nu bevæger sig fra sikkerhedskonferencer ind i direktioner og bestyrelsesudvalg. Spørgsmålet er ikke længere, om kvantecomputing er interessant for forskere. Spørgsmålet er, om nutidens kryptografiske valg kan beskytte morgendagens forretningsmæssige forpligtelser.
For mange organisationer er det ærlige svar ubehageligt. Kryptering findes overalt: TLS-gateways, VPN’er, kundeportaler, identitetstokens, databasesikkerhedskopier, mobilapplikationer, betalingsplatforme, S/MIME, SSH, API-integrationer, SaaS-tjenester, Hardware Security Modules (HSM’er), cloudbaserede nøglestyringstjenester, firmwaresignering, kodesignering og digitale kontrakter.
Det er problemet. Kryptografi findes overalt, men ejerskabet findes ofte ingen steder.
Migrering til postkvantekryptografi handler ikke kun om en fremtidig kryptografisk relevant kvantecomputer. Det handler også om nutidens “harvest now, decrypt later”-risiko, hvor modstandere indsamler krypterede data i dag og venter, indtil fremtidige kapabiliteter gør dekryptering praktisk mulig. Hvis din organisation opbevarer personoplysninger, helbredsoplysninger, regulerede finansielle data, forretningshemmeligheder, juridisk kommunikation, data om national infrastruktur, produktfirmware eller langtidsholdbar intellektuel ejendom, er risikoen allerede en livscyklusrisiko.
En kvanteklar migreringsplan for kryptografi er ikke et panikprojekt. Det er et struktureret program for governance, aktivfortegnelse, leverandører, arkitektur, test og revision. Det praktiske spørgsmål for CISO’er er enkelt:
Hvordan opbygger vi en postkvantemigreringsplan, der er troværdig over for ledelsen, anvendelig for ingeniører og forsvarlig over for revisorer?
Svaret er at forankre arbejdet i ISO/IEC 27001:2022, fortolke kontroller gennem ISO/IEC 27002:2022, bruge NIST’s standarder for postkvantekryptografi som teknisk kompas og etablere én evidensmodel, der understøtter forpligtelser efter ISO 27001, NIST, COBIT 2019, GDPR, DORA og NIS2.
Hvorfor postkvantekryptografi hører hjemme i ISMS
En almindelig fejl er udelukkende at placere postkvantemigrering hos kryptografiingeniører. Ingeniører er afgørende, men de kan ikke løse styringsproblemet alene.
Postkvantemigrering berører aktivforvaltning, dataklassificering, leverandørstyring, sikker arkitektur, nøglestyring, applikationsudvikling, cloud-sikkerhed, hændelseshåndtering, forretningskontinuitet, juridisk risiko, regulatorisk ansvarlighed og revisionsbevis. Det er ISMS-emner.
ISO/IEC 27001:2022 giver governance-rammen. Den kræver, at organisationen forstår kontekst, interessenter, risiko, mål, ansvar, kompetencer, dokumenteret information, operationel planlægning, performanceevaluering, intern revision, ledelsens gennemgang og løbende forbedring. ISO/IEC 27002:2022 giver derefter kontrolfortolkningen, især vedrørende 8.24 Use of cryptography, 5.9 Inventory of information and other associated assets, 5.12 Classification of information, 5.21 Managing information security in the ICT supply chain, 5.23 Information security for use of cloud services, 8.25 Secure development life cycle, 8.8 Management of technical vulnerabilities, 8.16 Monitoring activities og 5.30 ICT readiness for business continuity.
Hos Clarysec er det derfor, postkvanteberedskab behandles som en ISMS-drevet transformation, ikke som en isoleret udskiftning af algoritmer.
Som anført i Clarysecs Zenith Blueprint: En auditors 30-trins køreplan, fase 2, trin 8, “Afgrænsning af aktiver, afhængigheder og bevismateriale”:
“En kontrol kan ikke anses for pålidelig, før organisationen kan dokumentere, hvor den gælder, hvem der ejer den, hvilket bevismateriale der understøtter den, og hvilken risiko den reducerer.”
Den sætning er særligt vigtig for postkvantekryptografi. Før du udskifter algoritmer, skal du vide, hvor algoritmerne anvendes.
Clarysecs Zenith Controls: Vejledningen til tværgående compliance beskriver kryptografi som en sammenhængende evidenskæde frem for en enkelt teknisk indstilling:
“Kryptografisk sikkerhed revideres gennem informationens livscyklus: identifikation, klassificering, godkendt brug, beskyttelse af nøgler, driftsmæssig overvågning, leverandørafhængighed, undtagelseshåndtering og opbevaring af bevismateriale.”
Dette livscyklusperspektiv forhindrer den mest almindelige fejl: kun at spørge, “Bruger vi kvantesikre algoritmer?” De bedre spørgsmål er:
- Hvilke systemer skal postkvantemigreres først?
- Hvilke data har en fortrolighedslevetid, der er længere end kvanterisikohorisonten?
- Hvilke leverandører kontrollerer vores kryptering, signaturer, certifikater eller nøglestyring?
- Hvilke applikationer er kryptoagile, og hvilke er hardkodede?
- Hvilke kompenserende kontroller findes, mens migreringen ikke er fuldført?
- Hvilket bevismateriale vil dokumentere, at beslutningerne var risikobaserede og gennemgået?
Fra kvantetrussel til revisionsbar forretningsrisiko
En brugbar postkvanteplan begynder med risikoscenarier. Undgå uklare udsagn som “kvantecomputing kan bryde kryptering.” Opret i stedet revisionsbare risikoregistreringer, der kobler forretningspåvirkning, trussel, sårbarhed, berørte aktiver, eksisterende kontroller, restrisiko og behandlingsaktiviteter sammen.
For eksempel:
“Krypterede kundeidentitetsdokumenter, der opbevares i syv år, kan være sårbare over for fremtidig dekryptering, hvis sikkerhedskopier eksfiltreres i dag, og den nuværende asymmetriske kryptografi bliver brydbar i fremtiden.”
Det scenarie peger på dataopbevaring, backupkryptering, nøglestyring, adgangsstyring, leverandørhosting, overvågning og migreringsprioritet.
Et andet eksempel:
“Firmwaresignering til forbundne enheder bygger på signaturskemaer, som muligvis ikke forbliver tillidsværdige gennem den forventede enhedslivscyklus.”
Det peger på produktsikkerhed, sikre opdateringsmekanismer, HSM-kapabilitet, kundesikkerhed, leverandørens designsikkerhed og langsigtet operationel robusthed.
Et tredje eksempel:
“Arkiveret juridisk kommunikation, der krypteres i dag, kan kræve fortrolighed i mere end femten år og dermed skabe eksponering for harvest now, decrypt later.”
Det peger på klassificering, opbevaring, kryptografisk beskyttelse, legal hold, sikker kommunikation og ledelsens risikoaccept.
Risikoen er ikke kun en fremtidig “Q-Day.” Den omfatter tre relaterede forhold:
- Harvest now, decrypt later, hvor modstandere indsamler krypterede data i dag til fremtidig dekryptering.
- Kompromittering af digitale signaturer, hvor fremtidige angreb underminerer tilliden til softwareopdateringer, identitetstokens, juridiske dokumenter, firmware og finansielle transaktioner.
- Kryptografisk koncentrationssvigt, hvor en bred klasse af produkter, protokoller, biblioteker eller leverandører bliver forældet på samme tid.
Clarysecs Enterprise Policy, Politik for kryptografi og nøglestyring, clause 5.1, indfanger governance-kravet sådan:
“Kryptografiske kontroller skal vælges, implementeres, gennemgås og udfases på grundlag af informationsklassificering, den krævede beskyttelseslevetid, godkendte kryptografiske standarder, nøgleejerskab og dokumenterede risikobehandlingsbeslutninger.”
Denne bestemmelse er kritisk, fordi beskyttelseslevetid bliver en prioriteringsfaktor. Kortlivede sessionsdata og langsigtede medicinske registre har ikke samme kvanterisiko. En kodesigneringsnøgle, der understøtter enhedstillid i femten år, har en anden risikoprofil end et kortlivet internt testcertifikat.
Den samme politikfamilie, som i Clarysec-materialer omtales som Politik for kryptografiske kontroller, kan også formalisere krav til gennemgang med formuleringer som:
Clause 5.4: Standarder for algoritmer og nøglelængder
“Alle kryptografiske algoritmer og nøglelængder, der anvendes i organisationen, skal vælges fra en godkendt liste, som vedligeholdes af informationssikkerhedsteamet. Listen skal gennemgås årligt op mod branchens bedste praksis og vejledning fra nationale cybersikkerhedsmyndigheder (f.eks. NIST, ENISA), med særlig opmærksomhed på udviklingen af postkvantekryptografiske standarder. En køreplan for migrering af systemer væk fra algoritmer, der er sårbare over for kvantebaserede angreb, skal vedligeholdes som en del af den kryptografiske aktivfortegnelse.”
Dette kræver ikke usikker tidlig ibrugtagning. Det kræver bevidsthed, planlægning, gennemgang og bevismateriale.
Brug NIST PQC-standarder som teknisk kompas
NIST’s arbejde med postkvantekryptografi giver organisationer en troværdig teknisk retning. NIST har standardiseret ML-KEM til nøgleetablering, ML-DSA til digitale signaturer og SLH-DSA til tilstandsløse hash-baserede signaturer. Disse standarder giver leverandører og arkitekter et grundlag for køreplaner og pilotdesign.
For CISO’er er pointen ikke at memorere algoritmedetaljer. Pointen er at etablere en migreringsvej, der kan optage godkendte kryptografiske valg uden at bryde forretningstjenester, compliance-forpligtelser eller revisionssporbarhed.
En NIST-tilpasset migreringsplan bør omfatte fire spor:
- Kortlægning, identificér hvor sårbar asymmetrisk kryptografi findes.
- Prioritering, rangordn systemer efter datafølsomhed, beskyttelseslevetid, eksponering, integritetspåvirkning og forretningskritikalitet.
- Overgangsarkitektur, definér hvor hybride, kryptoagile eller postkvantemekanismer skal testes og indføres.
- Assurance, producér bevismateriale for, at beslutninger, undtagelser, leverandørafhængigheder, tests og restrisici er under kontrol.
Kryptoagilitet fortjener særlig opmærksomhed. Et kryptoagilt system kan ændre algoritmer, nøglestørrelser, biblioteker, certifikater og protokoller uden større redesign. I postkvanteæraen er kryptoagilitet ikke en luksus. Det er et krav til robusthed.
Hvis en betalings-API har hardkodede kryptografiske biblioteker og ingen dokumenteret ejer, er den ikke kryptoagil. Hvis en mobilapplikation pin’er certifikater uden en styret opdateringsvej, kan migrering blive dyr. Hvis en IoT-enhed har en feltlevetid på femten år og ikke kan understøtte større signaturer eller sikre firmwareopdateringer, er risikoen strategisk.
Opbyg den kryptografiske fortegnelse, før migreringsvejen vælges
De fleste organisationer har ikke en fuldstændig kryptografisk fortegnelse. De kan have en certifikatfortegnelse, et regneark til nøglestyring, HSM-optegnelser, en cloud KMS-liste eller CMDB-poster. Sjældent har de et samlet overblik over kryptografiske afhængigheder.
En migreringsplan for postkvantekryptografi kræver en kryptografisk materialefortegnelse, eller CBOM. Den behøver ikke være perfekt på dag ét. Den skal være struktureret, have en ejer og forbedres løbende.
Som minimum bør følgende felter registreres:
| Felt i fortegnelsen | Hvorfor det har betydning for postkvantemigrering |
|---|---|
| Forretningstjeneste | Prioriterer migrering efter forretningspåvirkning |
| Aktivejer | Tildeler ansvarlighed og beslutningskompetence |
| Dataklassificering | Identificerer krav til fortrolighed og integritet |
| Beskyttelseslevetid | Synliggør eksponering for harvest now, decrypt later |
| Kryptografisk funktion | Adskiller kryptering, nøgleudveksling, signaturer, hashing og certifikater |
| Algoritme og protokol | Identificerer hvor sårbare asymmetriske mekanismer anvendes |
| Bibliotek eller implementering | Viser softwareafhængigheder og opdateringsbegrænsninger |
| Nøgleplacering | Viser om nøgler ligger i HSM, cloud KMS, software, endpoint eller leverandørplatform |
| Leverandørafhængighed | Viser hvor migrering afhænger af tredjeparter |
| Migreringskompleksitet | Understøtter rækkefølge, test og budgetplanlægning |
| Kilde til bevismateriale | Gør fortegnelsen revisionsklar |
En indledende fortegnelse kan se sådan ud:
| Aktiv-id | Aktivnavn | Ejer | Forretningskritikalitet | Kryptografisk anvendelse | Placering | PQC-sårbarhed | Migreringsprioritet |
|---|---|---|---|---|---|---|---|
| APP-042 | API til kundefakturering | Finans-teknologi | Høj | RSA-2048-signaturer, TLS, AES-256-kryptering | AWS eu-west-1 | Høj for RSA-afhængig tillid | 1 |
| NET-007 | VPN til fjernadgang | IT-infrastruktur | Høj | ECDSA-autentifikation, IKEv2 | On-premise og cloud edge | Høj for ECC-afhængig autentifikation | 1 |
| DB-011 | Arkiverede patientjournaler | Compliance | Høj med 30 års opbevaring | AES-256-databasekryptering | On-premise-database | Lavere for symmetrisk kryptering, høj hvis nøgler udveksles eller wrappes med sårbare asymmetriske metoder | 2 |
| CODE-001 | CI/CD-kodesignering | DevOps | Høj integritetspåvirkning | RSA-4096-kodesignering | HSM og build-pipeline | Høj for langsigtet signaturtillid | 1 |
Denne tabel viser straks, hvorfor fortegnelsen er vigtig. AES-256 er ikke samme type kvanterisiko som RSA eller ECC, men arkiverede patientjournaler kan stadig afhænge af sårbar key wrapping, certifikater, identitetssystemer eller kanaler til overførsel af sikkerhedskopier. Kodesignering beskytter måske ikke fortrolighed, men den beskytter softwareintegritet og tillid.
I Zenith Controls krydshenvises kryptografi til understøttende standarder, der giver dybde. ISO/IEC 27005 understøtter informationssikkerhedsrisikostyring og hjælper med at omsætte kvanteusikkerhed til strukturerede risikoscenarier. ISO/IEC 27017 understøtter cloudspecifikke sikkerhedskontroller, hvilket er afgørende, når kryptografiske tjenester leveres gennem cloud KMS, administreret TLS, SaaS-kryptering eller platformscertifikater. ISO/IEC 27018 er relevant, når personoplysninger behandles i offentlige cloudtjenester. ISO 22301 er relevant, hvor kryptografisk svigt kan påvirke kontinuiteten i kritiske tjenester. ISO/IEC 27036 understøtter sikkerhed i leverandørrelationer, hvilket er afgørende, når leverandører administrerer kryptering, signaturer, certifikater eller sikker kommunikation på dine vegne.
Læren er enkel: du kan ikke migrere det, du ikke kan finde.
Prioritér efter følsomhed, levetid, eksponering og migreringssværhedsgrad
Når CBOM findes, bliver prioritering evidensbaseret. Det bedste udgangspunkt er et lille antal kritiske systemer, ikke en øvelse i perfektion på tværs af hele organisationen.
Forestil dig en finansiel virksomhed med tre værdifulde systemer:
- En kundedokumentboks, der opbevarer identitetsbeviser i ti år
- En B2B API-gateway, der understøtter partnertransaktioner
- En kodesigneringsplatform til desktopsoftwareopdateringer
Ved brug af Zenith Blueprint, fase 2, trin 8, udtrækker teamet aktiver fra CMDB’en, certifikater fra certifikatstyringsplatformen, nøgler fra HSM og cloud KMS, dataklasser fra privatlivsregisteret og leverandørafhængigheder fra indkøbsregistreringer.
Derefter scorer de systemerne:
| System | Datafølsomhed | Beskyttelseslevetid | Ekstern eksponering | Leverandørafhængighed | Migreringsprioritet |
|---|---|---|---|---|---|
| Kundedokumentboks | Meget høj | Lang | Mellem | Cloud KMS og lagerudbyder | Kritisk |
| B2B API-gateway | Høj | Kort til mellem | Meget høj | API-styringsleverandør | Høj |
| Kodesigneringsplatform | Meget høj integritetspåvirkning | Lang enhedstillid | Mellem | HSM og build-pipeline-værktøjer | Kritisk |
Kundedokumentboksen bliver en prioritet på grund af fortrolighedslevetiden. Kodesigneringsplatformen bliver en prioritet, fordi signaturtillid påvirker softwareintegritet og kundesikkerhed. API-gatewayen har høj prioritet på grund af ekstern eksponering, men dens opbevarede data kan have en kortere fortrolighedslevetid.
Risikoregisteret bør derefter knytte hvert scenarie til behandling og bevismateriale:
| Risikoscenarie | Nuværende kontrol | Behandlingsbeslutning | Krævet bevismateriale |
|---|---|---|---|
| Langtidsholdbare kunderegistre kan blive eksponeret for fremtidig dekryptering | Kryptering af data i hvile, adgangsstyring, cloud KMS | Vurder køreplan for lagerkryptering, styrk nøglesegregering, gennemgå kryptografi til overførsel af sikkerhedskopier | CBOM, leverandørkøreplan, arkitekturbeslutning, risikobehandlingsregistrering |
| Tilliden til softwareopdateringer kan svækkes af fremtidig kompromittering af signaturer | HSM til kodesignering, release-godkendelse | Vurder parathed til postkvantesignaturer, tidsstemplingsstrategi og signeringslivscyklus | Signeringsfortegnelse, HSM-kapabilitetsrapport, procedure for sikker udvikling |
| Partner-API-kryptografi kan være vanskelig at ændre hurtigt | TLS-certifikater, API-gatewaykonfiguration | Implementér test af kryptoagilitet og gennemgang af leverandørens køreplan | TLS-scanning, konfigurationsbaseline, leverandørattestation |
Clarysecs Enterprise Policy, Politik for sikker udvikling, clause 6.4, giver softwareleveringsperspektivet:
“Gennemgange af sikkerhedsdesign skal evaluere kryptografiske afhængigheder, bibliotekers livscyklus, algoritmeagilitet, håndtering af hemmeligheder, opdateringsmekanismer og leverandørkontrollerede komponenter før godkendelse til produktionsmiljøet.”
Denne bestemmelse gør postkvanteberedskab til et ingeniørkrav. Den forhindrer teams i at implementere nye systemer, der ikke kan migreres senere.
Følg en 12-måneders køreplan, som revisorer kan forstå
Postkvantemigrering vil for mange organisationer tage år. Det første år bør flytte organisationen fra usikkerhed til styret migrering.
| Måned | Arbejdsspor | Resultat | Bevismateriale |
|---|---|---|---|
| 1 | Ledelsesmandat | Omfang på bestyrelsesniveau, risikovillighed og finansieringsvej | Referater fra styregruppe, godkendt kommissorium |
| 1 til 2 | Kryptografisk kortlægning | Indledende CBOM, der dækker kritiske tjenester | Eksport af fortegnelse, CMDB-links, attestationer fra systemejere |
| 2 til 3 | Gennemgang af data og beskyttelseslevetid | Prioriteret liste over langtidsholdbare følsomme data og aktiver med høj integritet | Klassificeringsregister, opbevaringsplan, risikoregistreringer |
| 3 til 4 | Gennemgang af leverandørafhængigheder | Leverandørkøreplan og analyse af kontraktmæssige huller | Leverandørspørgeskemaer, kontraktklausuler, risikoundtagelser |
| 4 til 6 | Vurdering af arkitektur og kryptoagilitet | Målarkitekturmønstre og migreringsbegrænsninger | Registreringer fra arkitekturgennemgang, designbeslutninger |
| 6 til 8 | Pilotimplementering | Hybrid eller postkvantetest i et udvalgt lavrisikomiljø | Testresultater, tilbagerulningsplan, performancekonstateringer |
| 8 til 10 | Opdatering af politikker og procedurer | Opdaterede regler for kryptografi, nøglestyring, leverandører, sikker udvikling og aktiver | Godkendte politikker, træningsregistreringer |
| 10 til 12 | Revisionsberedskab | Intern revision, ledelsens gennemgang og opdatering af behandlingsplan | Revisionsrapport, korrigerende handlinger, opdateret risikobehandlingsplan |
I Zenith Blueprint, fase 3, trin 14, “Design og ejerskab af risikobehandling,” advarer køreplanen mod ufinansierede sikkerhedsintentioner:
“En behandlingsplan uden ejer, forventning til bevismateriale, finansieringsvej og gennemgangsdato er ikke en plan. Det er en uafklaret risiko med bedre formatering.”
Det er præcis sådan postkvanteprogrammer fejler. De producerer awareness-slides, men ingen ejet afhjælpningsbacklog. De diskuterer algoritmer, men opdaterer ikke leverandørkontrakter. De dokumenterer risiko, men tester ikke migreringsmønstre.
En troværdig køreplan skaber beslutningsregistreringer, ejere, afhængigheder, forventninger til bevismateriale, budgetter og gennemgangsdatoer.
Inddrag leverandører tidligt i programmet
Mange kryptografiske afhængigheder er outsourcet. Cloududbydere terminerer TLS. SaaS-platforme krypterer registreringer. Identitetsudbydere signerer tokens. Betalingsbehandlere administrerer certifikater. Hardwareleverandører kontrollerer firmwaresignering. Managed service providers (MSP’er) driver VPN’er og sikkerhedsgateways.
Selv hvis dit interne team er klar, kan din migrering blive blokeret af leverandørens kapacitet.
Clarysecs Enterprise Policy, Politik for tredjeparts- og leverandørsikkerhed, clause 5.6, fastslår:
“Leverandører, der leverer sikkerhedsrelevante tjenester, skal oplyse væsentlige afhængigheder, kryptografiske ansvarsområder, sikkerhedsbevismateriale, processer for sårbarhedshåndtering og køreplansændringer, der kan påvirke organisationens risikobillede.”
For postkvanteberedskab bør kritiske leverandører spørges:
- Hvilke algoritmer, protokoller, certifikater og nøglestyringstjenester beskytter vores data eller transaktioner?
- Vedligeholder I en kryptografisk fortegnelse eller CBOM?
- Hvad er jeres NIST-postkvantekøreplan?
- Vil I understøtte hybrid nøgleudveksling, postkvantesignaturer eller kvanteresistent nøgleetablering?
- Hvordan vil ændringer af certifikater, tokens, signering og kryptering blive kommunikeret?
- Hvilke kundetiltag vil være nødvendige?
- Hvilke testmiljøer vil være tilgængelige?
- Hvordan vil performance, interoperabilitet og tilbagerulning blive håndteret?
- Er kryptografiske ansvarsområder defineret i kontrakten eller modellen for delt ansvar?
- Hvilke exit- eller portabilitetsmuligheder findes, hvis jeres køreplan ikke opfylder vores risikokrav?
Leverandørsvar bør indgå i risikoregisteret. Svage svar betyder ikke altid øjeblikkelig udskiftning, men de kræver behandling. Der kan være behov for kompenserende kontroller, kontraktændringer, underretningsklausuler, exitplanlægning, styrket overvågning eller en revideret sourcingstrategi.
Dette er særligt vigtigt i lyset af forventningerne til operationel robusthed efter DORA- og NIS2-modellerne. DORA lægger vægt på styring af IKT-risiko og IKT-tredjepartsrisikostyring, herunder tilsyn med kritiske afhængigheder. NIS2 Article 21 kræver passende og forholdsmæssige tekniske, operationelle og organisatoriske sikkerhedsrisikostyringsforanstaltninger, herunder sikkerhed i forsyningskæden, håndtering af hændelser, forretningskontinuitet og kryptografi, hvor det er relevant. GDPR Article 32 kræver sikkerhed, der står mål med risikoen, herunder fortrolighed, integritet, tilgængelighed, robusthed og evnen til at sikre løbende beskyttelse af personoplysninger.
Det regulatoriske sprog er forskelligt, men kontrollogikken er den samme: kend dine afhængigheder, styr risikoen, bevar bevismateriale, og handl før robustheden kompromitteres.
Kortlægning på tværs af compliance: én migreringsplan, mange forpligtelser
En stærk migreringsplan for postkvantekryptografi bør undgå at oprette separate evidenspakker for hvert framework. Det samme kernebevismateriale kan understøtte flere forpligtelser, hvis det struktureres korrekt.
Zenith Controls kortlægger kryptografiemnet på tværs af ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIST, COBIT 2019, GDPR, DORA og NIS2 ved at fokusere på kontrollens formål frem for den label, hvert framework bruger.
| Framework | Hvordan postkvanteplanen understøtter compliance |
|---|---|
| ISO/IEC 27001:2022 | Dokumenterer risikobaseret kontroludvælgelse, dokumenteret information, intern revision, ledelsens gennemgang og løbende forbedring |
| ISO/IEC 27002:2022 | Understøtter kontrolfortolkning for 8.24 Use of cryptography, aktivfortegnelse, klassificering, leverandørsikkerhed, cloudtjenester, sikker udvikling, overvågning og kontinuitet |
| NIST PQC-standarder | Giver teknisk retning for overgang til godkendte postkvantealgoritmer og kryptografisk planlægning |
| NIST Cybersecurity Framework 2.0 | Knytter migreringsaktiviteter til resultater inden for Govern, Identify, Protect, Detect, Respond og Recover |
| COBIT 2019 | Afstemmer kryptografisk risiko med governance- og ledelsesmål såsom APO12 Managed Risk, APO13 Managed Security, APO10 Managed Vendors, DSS05 Managed Security Services og MEA03 Managed Compliance |
| GDPR | Understøtter forventningerne i Article 32 til passende sikkerhed, fortrolighed, integritet, robusthed og ansvarlighed ved behandling af personoplysninger |
| DORA | Understøtter styring af IKT-risiko, IKT-tredjepartsrisikostyring, robusthedstest, hændelsesberedskab og ledelsesorganets tilsyn |
| NIS2 | Understøtter Article 21-sikkerhedsrisikostyringsforanstaltninger, sikkerhed i forsyningskæden, håndtering af hændelser, forretningskontinuitet og governance-ansvarlighed |
Genbrug af bevismateriale er nøglen. En kryptografisk fortegnelse understøtter ISO-aktivstyring, NIST Identify-resultater, DORA-synlighed over IKT-aktiver, NIS2-risikostyring og GDPR-ansvarlighed. Leverandørspørgeskemaer understøtter ISO-leverandørkontroller, DORA IKT-tredjepartsrisiko, NIS2-sikkerhed i forsyningskæden og COBIT-leverandørstyring. Migreringstestresultater understøtter sikker ændring, robusthedstest, revisionsberedskab og ledelsens gennemgang.
Hvad revisorer vil spørge om
Postkvantekryptografi er stadig et fremspirende revisionsemne, men revisorer har allerede tilstrækkelige kontrolforventninger til at stille vanskelige spørgsmål.
En ISO/IEC 27001:2022-revisor vil normalt starte med risiko. Vedkommende vil spørge, om kvanterelateret kryptografisk risiko er identificeret, vurderet, behandlet, overvåget og gennemgået i ISMS. Revisoren vil forvente bevismateriale for, at kryptografiske kontroller er valgt ud fra forretningsrisiko, og at ansvarsområder er defineret.
En NIST-orienteret assessor kan fokusere på synlighed over aktiver, beskyttelsesmekanismer, forsyningskæderisiko, sårbarhedsstyring og governance-resultater. Vedkommende kan spørge, om organisationen har identificeret systemer, der anvender sårbar asymmetrisk kryptografi, og om migreringsplanlægningen er afstemt med NIST’s retning.
En COBIT- eller ISACA-revisor vil ofte spørge til governance. Hvem er ansvarlig? Hvordan modtager bestyrelsen rapportering? Prioriteres investeringer? Styres leverandørafhængigheder? Er gevinster, risici og ressourcer balanceret?
En privatlivsrevisor kan fokusere på, om kryptering og nøglestyring fortsat er passende i forhold til personoplysningers følsomhed og opbevaringsperiode.
En DORA- eller NIS2-fokuseret reviewer vil se på robusthed, tredjeparts IKT-koncentration, driftskontinuitet og hændelsesberedskab.
| Revisionsperspektiv | Sandsynlige spørgsmål | Bevismateriale, der skal forberedes |
|---|---|---|
| ISO/IEC 27001:2022 | Er postkvanterisiko inkluderet i ISMS-risikoprocessen? Er kryptografiske kontroller valgt og gennemgået? | Risikoregister, behandlingsplan, anvendelighedserklæring (SoA), politikgodkendelser, interne revisionsresultater |
| NIST | Har organisationen kortlagt kryptografisk anvendelse og planlagt migrering mod godkendte tilgange? | CBOM, arkitekturbeslutninger, pilotresultater, migreringsbacklog |
| COBIT 2019 | Er kryptografisk overgang styret, finansieret og overvåget? | Bestyrelsesrapporter, governance-referater, KPI’er, dashboards for leverandørrisiko |
| GDPR | Er kryptografisk beskyttelse fortsat passende i forhold til personoplysningers følsomhed og opbevaring? | Dataklassificering, DPIA-henvisninger, opbevaringsplan, krypteringsdesign |
| DORA | Er IKT- og leverandørafhængigheder forstået og robuste? | IKT-aktivregister, leverandørattestationer, testbevismateriale, exitplaner |
| NIS2 | Er foranstaltninger til forsyningskæde- og sikkerhedsrisikostyring effektive? | Leverandørgennemgange, hændelsesprocedurer, kontinuitetsplaner, risikobehandlingsregistreringer |
Zenith Controls anbefaler at behandle revisionsforberedelse som en evidensvej. Vent ikke på, at revisorer beder om screenshots og regneark. Opbyg et GRC-arbejdsområde, der forbinder hver kryptografisk risiko med dens ejer, berørte aktiver, leverandører, beslutninger, tests, undtagelser og gennemgangsdatoer.
Opdater politikker, så programmet bliver operationelt
De fleste kryptografipolitikker blev skrevet til traditionelle krav om fortrolighed og integritet. Postkvantemigrering kræver målrettede tilføjelser.
Jeres politik for kryptografi og nøglestyring bør omfatte godkendte standarder, gennemgangsfrekvens, dataklassificering, beskyttelseslevetid, algoritmeagilitet, generering af nøgler, nøgleopbevaring, rotation, destruktion, ejerskab, certifikatlivscyklus, HSM-ansvar, cloud KMS-ansvar, godkendelse af undtagelser, leverandørkontrolleret kryptografi og overvågning af postkvanteovergangen.
Jeres politik for sikker udvikling bør omfatte godkendelse af kryptografiske biblioteker, forbud mod hardkodede algoritmer uden gennemgang, afhængighedssporing, sikre opdateringsmekanismer, performancetest for større nøgler eller signaturer, bagudkompatibilitet, tilbagerulning og trusselsmodellering for produkter med lang levetid.
Jeres leverandørsikkerhedspolitik bør omfatte kryptografisk transparens, anmodninger om postkvantekøreplaner, kontraktlige underretningspligter, delt ansvar for kryptering og nøglestyring, exitplanlægning og portabilitet.
Jeres procedure for aktivforvaltning bør omfatte kryptografiske fortegnelsesfelter, ejerskab, kilder til bevismateriale, gennemgangsfrekvens og integration med CMDB, cloudfortegnelse, certifikatstyring, HSM-optegnelser og koderepositorier.
Det er her, Clarysecs politikbibliotek hjælper organisationer med at bevæge sig hurtigere. I stedet for at skrive fra bunden kan teams tilpasse politikklausuler til procedurer, registre, spørgeskemaer og revisionsbevis.
Undgå de mest almindelige fejl ved postkvantemigrering
De farligste fejl er normalt governance-svigt, ikke tekniske svigt.
At starte med algoritmer i stedet for aktiver. Hvis du ikke ved, hvor kryptografi anvendes, hjælper algoritmevalg ikke.
At ignorere dataenes levetid. Kortlivede transaktionsdata og langtidsholdbare følsomme arkiver har ikke samme risiko.
At behandle leverandører som en senere fase. Mange kryptografiske kontroller administreres af leverandører. Hvis leverandører ikke inddrages tidligt, kan planen være urealistisk.
At glemme signaturer. Postkvanteplanlægning handler ikke kun om kryptering. Digitale signaturer, kodesignering, certifikater, identitetstokens, firmwareopdateringer og dokumentsignering kræver opmærksomhed.
At antage, at cloududbydere løser alt. Cloudplatforme vil spille en stor rolle, men ansvaret forbliver delt. Du skal stadig vide, hvilke tjenester, konfigurationer, nøgler, regioner og integrationer der er berørt.
Ikke at skabe revisionsbevis. En migreringsplan, der ikke kan dokumenteres, vil ikke tilfredsstille ledelse, tilsynsmyndigheder, kunder eller revisorer.
At springe performance- og interoperabilitetstest over. Postkvantealgoritmer kan påvirke payload-størrelse, handshake-adfærd, latenstid, lagring, indlejrede begrænsninger og kompatibilitet.
Metrikker, som CISO’en bør rapportere til bestyrelsen
Bestyrelsesrapportering bør være enkel nok til at forstå og specifik nok til at drive handling. Undgå dybe algoritmediskussioner. Fokuser på eksponering, fremdrift, beslutninger og restrisiko.
| Metrik | Betydning på bestyrelsesniveau |
|---|---|
| Andel af kritiske tjenester med fuldført kryptografisk fortegnelse | Viser synlighed |
| Andel af langtidsholdbare følsomme data kortlagt til kryptografiske kontroller | Viser beredskab over for harvest now, decrypt later |
| Antal kritiske leverandører, hvor postkvantekøreplan er modtaget | Viser tredjepartsberedskab |
| Antal højrisiko-kryptografiske undtagelser | Viser ustyret eksponering |
| Andel af kritiske applikationer vurderet for kryptoagilitet | Viser migreringens gennemførlighed |
| Status for pilotgennemførelse | Viser praktisk fremdrift |
| Åbne behandlingshandlinger efter frist | Viser eksekveringsrisiko |
| Trend for restrisiko | Viser om programmet reducerer eksponering |
Et nyttigt budskab til bestyrelsen kan lyde sådan:
“Vi har gennemført kryptografisk kortlægning for 72 procent af de kritiske tjenester. To systemer har kritisk langtidseksponering for fortrolighed, og tre leverandører har endnu ikke leveret postkvantekøreplaner. Vi har igangsat et projekt for kodesigneringsberedskab og en gennemgang af cloud KMS-afhængigheder. Der anbefales ingen nødudskiftning i dag, men leverandørusikkerhed er fortsat den største restrisiko.”
Det er sproget for styret cyberrisiko.
En praktisk tjekliste til at starte i denne uge
Du behøver ikke vente på fuld sikkerhed. Start med trin, der straks forbedrer synlighed og styring.
- Udpeg en ansvarlig for postkvantekryptografi.
- Tilføj kvanterelateret kryptografisk risiko til ISMS-risikoregisteret.
- Identificér de ti vigtigste tjenester med langtidsholdbare følsomme data eller høj integritetspåvirkning.
- Opbyg en minimumslevedygtig CBOM for disse tjenester.
- Bed kritiske leverandører om deres postkvantekøreplan.
- Gennemgå politikker for kryptografi, sikker udvikling, leverandører og aktiver.
- Identificér systemer med hardkodede algoritmer, forældede biblioteker, manuel certifikatrotation eller uklart ejerskab.
- Vælg én lavrisikopilot til test af kryptoagilitet.
- Definér bestyrelsesmetrikker og rapporteringsfrekvens.
- Planlæg en intern revision med fokus på kryptografisk styring og bevismateriale.
Det vigtigste skridt er at omsætte usikkerhed til styret arbejde. Kvanterisiko kan være fremadrettet, men kryptografisk gæld findes allerede i dag.
Næste skridt med Clarysec
Postkvantemigrering bliver en af det næste årtis mest komplekse sikkerhedsovergange, fordi den berører identitet, kryptering, signaturer, leverandører, cloud, software, enheder, arkiver og revisionsbevis. Organisationer, der starter med styring og fortegnelser, vil bevæge sig hurtigere end dem, der venter på en udskiftningscyklus i sidste øjeblik.
Clarysec kan hjælpe jer med at opbygge en kvanteklar migreringsplan for kryptografi med:
- Zenith Blueprint: En auditors 30-trins køreplan til faseopdelt implementering og revisionsberedskab
- Zenith Controls: Vejledningen til tværgående compliance til kortlægning af ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIST, COBIT 2019, GDPR, DORA og NIS2
- Politik for kryptografi og nøglestyring til governance-klare kryptografiske regler
- Politik for tredjeparts- og leverandørsikkerhed til leverandørkøreplaner og dokumentationskrav
- Politik for sikker udvikling til kryptoagile ingeniørpraksisser
Det bedste tidspunkt at begynde postkvanteplanlægning på er, før en tilsynsmyndighed, revisor, kunde eller et bestyrelsesmedlem beder om bevismateriale. Start med fortegnelsen, forbind den med risiko, og opbyg migreringsvejen én kontrolleret beslutning ad gangen.
Frequently Asked Questions
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council


