Migrazione alla crittografia post-quantistica secondo ISO 27001

Il ronzio del proiettore è l’unico suono nella sala del consiglio. Sarah, CISO, ha appena concluso l’aggiornamento trimestrale sui rischi quando l’amministratore delegato solleva la stampa di un articolo di una testata finanziaria. Il titolo è diretto: “Il conto alla rovescia quantistico: i tuoi dati sono già obsoleti?”

“Sarah,” dice, più preoccupato che accusatorio, “abbiamo speso milioni in cifratura. Siamo conformi. Siamo sicuri. Questo articolo sostiene che un computer quantistico sufficientemente potente potrebbe violare tutto. Siamo esposti? E i dati che stiamo cifrando e archiviando oggi? Sono una bomba a orologeria?”

Questa conversazione sta passando dalle conferenze di sicurezza ai comitati esecutivi. Il punto non è più se il calcolo quantistico sia interessante per i ricercatori. Il punto è se le scelte crittografiche di oggi siano in grado di proteggere gli obblighi aziendali di domani.

Per molte organizzazioni, la risposta onesta è scomoda. La cifratura è ovunque: gateway TLS, VPN, portali clienti, token di identità, backup dei database, applicazioni mobili, piattaforme di pagamento, S/MIME, SSH, integrazioni API, servizi SaaS, moduli hardware di sicurezza (HSM), servizi cloud di gestione delle chiavi, firma del firmware, firma del codice e contratti digitali.

Il problema è questo: la crittografia è ovunque, ma spesso non ha una responsabilità chiaramente assegnata.

La migrazione alla crittografia post-quantistica non riguarda solo un futuro computer quantistico crittograficamente rilevante. Riguarda anche il rischio attuale di “harvest now, decrypt later”, in cui gli avversari acquisiscono oggi dati cifrati e attendono che capacità future rendano praticabile la decifratura. Se l’organizzazione conserva dati personali, cartelle cliniche, dati finanziari regolamentati, segreti commerciali, comunicazioni legali, dati di infrastrutture nazionali, firmware di prodotto o proprietà intellettuale a lunga durata, il rischio è già un rischio di ciclo di vita.

Un piano di migrazione crittografica pronto per l’era quantistica non è un progetto dettato dal panico. È un programma strutturato di governance, inventario, gestione dei fornitori, architettura, test e audit. La domanda pratica per i CISO è semplice:

Come costruire un piano di migrazione post-quantistica credibile per la direzione, utilizzabile dagli ingegneri e difendibile davanti agli auditor?

La risposta è ancorare il lavoro a ISO/IEC 27001:2022, interpretare i controlli attraverso ISO/IEC 27002:2022, usare gli standard NIST sulla crittografia post-quantistica come bussola tecnica e creare un unico modello di evidenze a supporto degli obblighi ISO 27001, NIST, COBIT 2019, GDPR, DORA e NIS2.

Perché la crittografia post-quantistica deve rientrare nel SGSI

Un errore comune è assegnare la migrazione post-quantistica solo agli ingegneri crittografici. Gli ingegneri sono essenziali, ma da soli non possono risolvere il problema di governance.

La migrazione post-quantistica impatta la gestione degli asset, la classificazione dei dati, la gestione dei fornitori, l’architettura sicura, la gestione delle chiavi, lo sviluppo applicativo, la sicurezza del cloud, la risposta agli incidenti, la continuità operativa, il rischio legale, la responsabilità regolatoria e le evidenze di audit. Sono tutti ambiti propri del SGSI.

ISO/IEC 27001:2022 fornisce il contenitore di governance. Richiede all’organizzazione di comprendere contesto, parti interessate, rischio, obiettivi, responsabilità, competenze, informazioni documentate, pianificazione operativa, valutazione delle prestazioni, audit interno, riesame della direzione e miglioramento continuo. ISO/IEC 27002:2022 fornisce poi l’interpretazione dei controlli, in particolare in relazione a 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 e 5.30 ICT readiness for business continuity.

In Clarysec, per questo motivo la preparazione post-quantistica viene trattata come una trasformazione guidata dal SGSI, non come una sostituzione isolata di algoritmi.

Come indicato in Zenith Blueprint: An Auditor’s 30-Step Roadmap di Clarysec, fase 2, passaggio 8, “Definizione dell’ambito di asset, dipendenze ed evidenze”:

“Un controllo non può essere considerato affidabile finché l’organizzazione non è in grado di dimostrare dove si applica, chi ne è responsabile, quali evidenze lo supportano e quale rischio riduce.”

Questa frase è particolarmente importante per la crittografia post-quantistica. Prima di sostituire gli algoritmi, occorre sapere dove vengono utilizzati.

Zenith Controls: The Cross-Compliance Guide di Clarysec inquadra la crittografia come una catena di evidenze collegate, non come una singola impostazione tecnica:

“L’assurance crittografica viene sottoposta ad audit lungo il ciclo di vita delle informazioni: identificazione, classificazione, uso approvato, protezione delle chiavi, monitoraggio operativo, dipendenza dai fornitori, gestione delle eccezioni e conservazione delle evidenze.”

Questa visione di ciclo di vita evita l’errore più comune: chiedersi solo “Stiamo usando algoritmi quantum-safe?”. Le domande migliori sono:

• Quali sistemi devono essere migrati per primi alla crittografia post-quantistica?
• Quali dati hanno una durata di riservatezza superiore all’orizzonte di rischio quantistico?
• Quali fornitori controllano la nostra cifratura, le firme, i certificati o la gestione delle chiavi?
• Quali applicazioni sono crittograficamente agili e quali hanno elementi hardcoded?
• Quali controlli compensativi esistono mentre la migrazione è incompleta?
• Quali evidenze dimostreranno che le decisioni sono state basate sul rischio e riesaminate?

Dalla minaccia quantistica al rischio aziendale verificabile in audit

Un piano post-quantistico efficace parte da scenari di rischio. Occorre evitare affermazioni generiche come “il calcolo quantistico potrebbe violare la cifratura”. È preferibile creare registrazioni di rischio verificabili in audit, che colleghino impatto aziendale, minaccia, vulnerabilità, asset interessati, controlli esistenti, rischio residuo e azioni di trattamento.

Ad esempio:

“I documenti cifrati di identità dei clienti conservati per sette anni possono essere vulnerabili a una futura decifratura se i backup vengono esfiltrati oggi e l’attuale crittografia a chiave pubblica diventa violabile in futuro.”

Questo scenario rimanda a conservazione dei dati, cifratura dei backup, gestione delle chiavi, controllo degli accessi, hosting presso fornitori, monitoraggio e priorità di migrazione.

Un altro esempio:

“La firma del firmware per dispositivi connessi si basa su schemi di firma che potrebbero non rimanere affidabili per l’intero ciclo di vita previsto del dispositivo.”

Questo rimanda a sicurezza del prodotto, meccanismi di aggiornamento sicuri, capacità degli HSM, sicurezza dei clienti, assurance della progettazione dei fornitori e resilienza operativa a lungo termine.

Un terzo esempio:

“Le comunicazioni legali archiviate e cifrate oggi potrebbero richiedere riservatezza per oltre quindici anni, creando un’esposizione harvest now, decrypt later.”

Questo rimanda a classificazione, conservazione, protezione crittografica, conservazione a fini legali, comunicazioni sicure e accettazione del rischio da parte della direzione.

Il rischio non è solo un futuro “Q-Day”. Comprende tre aspetti correlati:

1. Harvest now, decrypt later, in cui gli avversari raccolgono oggi dati cifrati per decifrarli in futuro.
2. Compromissione delle firme digitali, in cui attacchi futuri indeboliscono la fiducia in aggiornamenti software, token di identità, documenti legali, firmware e transazioni finanziarie.
3. Fallimento per concentrazione crittografica, in cui un’ampia classe di prodotti, protocolli, librerie o fornitori diventa obsoleta nello stesso momento.

La politica aziendale di Clarysec Politica di crittografia e gestione delle chiavi, clausola 5.1, esprime così il requisito di governance:

“I controlli crittografici devono essere selezionati, attuati, riesaminati e dismessi in base alla classificazione delle informazioni, alla durata di protezione richiesta, agli standard crittografici approvati, alla titolarità delle chiavi e alle decisioni documentate di trattamento del rischio.”

Questa clausola è essenziale perché la durata di protezione diventa un fattore di prioritizzazione. I dati di sessione di breve durata e le cartelle cliniche a lungo termine non presentano lo stesso rischio quantistico. Una chiave di firma del codice che sostiene la fiducia nei dispositivi per quindici anni ha un profilo di rischio diverso rispetto a un certificato interno di test di breve durata.

La stessa famiglia di politiche, indicata nei materiali Clarysec come Politica sui controlli crittografici, può inoltre formalizzare le aspettative di riesame con formulazioni come:

Clausola 5.4: standard sugli algoritmi e sulle lunghezze delle chiavi
“Tutti gli algoritmi crittografici e le lunghezze delle chiavi utilizzati all’interno dell’organizzazione devono essere selezionati da un elenco approvato mantenuto dalla funzione Sicurezza delle informazioni. Tale elenco deve essere riesaminato annualmente rispetto alle buone pratiche di settore e alle indicazioni degli organismi nazionali di cibersicurezza (ad es. NIST, ENISA), con specifica attenzione all’evoluzione degli standard crittografici post-quantistici. Deve essere mantenuta, come parte dell’inventario degli asset crittografici, una roadmap per la migrazione dei sistemi da algoritmi vulnerabili ad attacchi basati sul calcolo quantistico.”

Questo non richiede un’adozione precoce e non sicura. Richiede consapevolezza, pianificazione, riesame ed evidenze.

Usare gli standard NIST PQC come bussola tecnica

Il lavoro di NIST sulla crittografia post-quantistica fornisce alle organizzazioni una direzione tecnica credibile. NIST ha standardizzato ML-KEM per l’instaurazione delle chiavi, ML-DSA per le firme digitali e SLH-DSA per le firme stateless basate su hash. Questi standard offrono a fornitori e architetti una base per roadmap e progetti pilota.

Per i CISO, il punto non è memorizzare i dettagli degli algoritmi. Il punto è creare un percorso di migrazione capace di recepire scelte crittografiche approvate senza interrompere servizi aziendali, impegni di conformità o tracciabilità in audit.

Un piano di migrazione allineato a NIST dovrebbe includere quattro filoni:

1. Discovery, identificare dove è presente crittografia a chiave pubblica vulnerabile.
2. Prioritizzazione, ordinare i sistemi per sensibilità dei dati, durata di protezione, esposizione, impatto sull’integrità e criticità aziendale.
3. Architettura di transizione, definire dove saranno testati e adottati meccanismi ibridi, ad agilità crittografica o post-quantistici.
4. Assurance, produrre evidenze che dimostrino il controllo di decisioni, eccezioni, dipendenze dai fornitori, test e rischi residui.

L’agilità crittografica merita particolare attenzione. Un sistema crittograficamente agile può modificare algoritmi, dimensioni delle chiavi, librerie, certificati e protocolli senza una riprogettazione rilevante. Nell’era post-quantistica, l’agilità crittografica non è un lusso. È un requisito di resilienza.

Se un’API di pagamento ha librerie crittografiche hardcoded e nessun proprietario documentato, non è crittograficamente agile. Se un’applicazione mobile effettua certificate pinning senza un percorso di aggiornamento gestito, la migrazione può diventare costosa. Se un dispositivo IoT ha una vita operativa sul campo di quindici anni e non può supportare firme più grandi o aggiornamenti firmware sicuri, il rischio è strategico.

Costruire l’inventario crittografico prima di scegliere il percorso di migrazione

La maggior parte delle organizzazioni non dispone di un inventario crittografico completo. Può avere un inventario dei certificati, un foglio di calcolo per la gestione delle chiavi, registrazioni HSM, un elenco di cloud KMS o voci CMDB. Raramente dispone di una vista unica delle dipendenze crittografiche.

Un piano di migrazione alla crittografia post-quantistica richiede una Cryptographic Bill of Materials, o CBOM. Non deve essere perfetta dal primo giorno. Deve però essere strutturata, avere proprietari assegnati ed essere migliorata in modo continuo.

Come minimo, occorre rilevare i seguenti campi:

Un inventario iniziale potrebbe presentarsi così:

Questa tabella mostra immediatamente perché l’inventario è importante. AES-256 non presenta lo stesso tipo di rischio quantistico di RSA o ECC, ma le cartelle cliniche archiviate possono comunque dipendere da key wrapping vulnerabile, certificati, sistemi di identità o canali di trasferimento dei backup. La firma del codice può non proteggere la riservatezza, ma protegge integrità e fiducia del software.

In Zenith Controls, la crittografia è collegata a standard di supporto che aggiungono profondità. ISO/IEC 27005 supporta la gestione dei rischi per la sicurezza delle informazioni e aiuta a tradurre l’incertezza quantistica in scenari di rischio strutturati. ISO/IEC 27017 supporta controlli di sicurezza specifici per il cloud, essenziali quando i servizi crittografici sono erogati tramite cloud KMS, TLS gestito, cifratura SaaS o certificati di piattaforma. ISO/IEC 27018 è rilevante quando dati personali sono trattati in servizi cloud pubblici. ISO 22301 è rilevante quando un fallimento crittografico potrebbe incidere sulla continuità di servizi critici. ISO/IEC 27036 supporta la sicurezza delle relazioni con i fornitori, cruciale quando i fornitori gestiscono cifratura, firme, certificati o comunicazioni sicure per conto dell’organizzazione.

La lezione è semplice: non è possibile migrare ciò che non si riesce a trovare.

Dare priorità per sensibilità, durata, esposizione e difficoltà di migrazione

Una volta disponibile la CBOM, la prioritizzazione diventa basata su evidenze. Il punto di partenza migliore è un numero limitato di sistemi critici, non un esercizio di perfezione su scala aziendale.

Immaginiamo una società di servizi finanziari con tre sistemi ad alto valore:

• Un vault documentale clienti che conserva evidenze di identità per dieci anni
• Un gateway API B2B a supporto delle transazioni con i partner
• Una piattaforma di firma del codice per aggiornamenti software desktop

Utilizzando Zenith Blueprint, fase 2, passaggio 8, il team estrae gli asset dalla CMDB, i certificati dalla piattaforma di gestione dei certificati, le chiavi dagli HSM e dal cloud KMS, le classi di dati dal registro privacy e le dipendenze dai fornitori dalle registrazioni di procurement.

Poi attribuisce un punteggio ai sistemi:

Il vault documentale clienti diventa prioritario per la durata della riservatezza. La piattaforma di firma del codice diventa prioritaria perché la fiducia nelle firme incide sull’integrità del software e sulla sicurezza dei clienti. Il gateway API è ad alta priorità per l’esposizione esterna, ma i dati conservati possono avere una durata di riservatezza più breve.

Il Registro dei rischi dovrebbe quindi collegare ogni scenario a trattamento ed evidenze:

La politica aziendale di Clarysec Politica di sviluppo sicuro, clausola 6.4, fornisce la prospettiva della distribuzione software:

“I riesami della progettazione di sicurezza devono valutare dipendenze crittografiche, ciclo di vita delle librerie, agilità degli algoritmi, gestione dei segreti, meccanismi di aggiornamento e componenti controllati dai fornitori prima dell’approvazione per la produzione.”

Questa clausola trasforma la preparazione post-quantistica in un requisito ingegneristico. Impedisce ai team di rilasciare nuovi sistemi che non possano essere migrati in seguito.

Seguire una roadmap di 12 mesi comprensibile agli auditor

Per molte organizzazioni la migrazione post-quantistica richiederà anni. Il primo anno dovrebbe portare l’organizzazione dall’incertezza a una migrazione governata.

In Zenith Blueprint, fase 3, passaggio 14, “Progettazione del trattamento del rischio e assegnazione delle responsabilità”, la roadmap mette in guardia dalle intenzioni di sicurezza non finanziate:

“Un piano di trattamento senza un proprietario, un’aspettativa sulle evidenze, un percorso di budget e una data di riesame non è un piano. È un rischio irrisolto con una formattazione migliore.”

È esattamente così che falliscono i programmi post-quantistici. Producono slide di sensibilizzazione, ma nessun backlog di remediation con proprietari. Discutono di algoritmi, ma non aggiornano i contratti con i fornitori. Documentano il rischio, ma non testano i pattern di migrazione.

Una roadmap credibile crea registrazioni delle decisioni, proprietari, dipendenze, aspettative sulle evidenze, budget e date di riesame.

Coinvolgere tempestivamente i fornitori nel programma

Molte dipendenze crittografiche sono esternalizzate. I cloud provider terminano TLS. Le piattaforme SaaS cifrano le registrazioni. I provider di identità firmano i token. I processori di pagamento gestiscono i certificati. I fornitori hardware controllano la firma del firmware. I fornitori di servizi gestiti gestiscono VPN e gateway di sicurezza.

Anche se il team interno è pronto, la migrazione può essere bloccata dalle capacità dei fornitori.

La politica aziendale di Clarysec Politica di sicurezza delle terze parti e dei fornitori, clausola 5.6, stabilisce:

“I fornitori che erogano servizi rilevanti per la sicurezza devono comunicare dipendenze significative, responsabilità crittografiche, evidenze di assurance, processi di trattamento delle vulnerabilità e modifiche alla roadmap che possano incidere sulla postura di rischio dell’organizzazione.”

Per la preparazione post-quantistica, chiedere ai fornitori critici:

• Quali algoritmi, protocolli, certificati e servizi di gestione delle chiavi proteggono i nostri dati o le nostre transazioni?
• Mantenete un inventario crittografico o una CBOM?
• Qual è la vostra roadmap post-quantistica NIST?
• Supporterete scambio di chiavi ibrido, firme post-quantistiche o instaurazione delle chiavi resistente agli attacchi quantistici?
• Come saranno comunicate le modifiche a certificati, token, firme e cifratura?
• Quali azioni saranno richieste ai clienti?
• Quali ambienti di test saranno disponibili?
• Come saranno gestiti prestazioni, interoperabilità e rollback?
• Le responsabilità crittografiche sono definite nel contratto o nel modello di responsabilità condivisa?
• Quali opzioni di uscita o portabilità esistono se la vostra roadmap non soddisfa i nostri requisiti di rischio?

Le risposte dei fornitori devono alimentare il Registro dei rischi. Risposte deboli non comportano sempre una sostituzione immediata, ma richiedono trattamento. Possono essere necessari controlli compensativi, modifiche contrattuali, clausole di notifica, pianificazione dell’uscita, monitoraggio rafforzato o una strategia di sourcing rivista.

Questo è particolarmente importante nel contesto delle aspettative di resilienza operativa proprie di DORA e NIS2. DORA pone l’accento sulla gestione del rischio ICT e sulla gestione del rischio ICT di terze parti, inclusa la supervisione delle dipendenze critiche. NIS2 Article 21 richiede misure tecniche, operative e organizzative di gestione dei rischi di sicurezza adeguate e proporzionate, incluse sicurezza della catena di fornitura, gestione degli incidenti, continuità operativa e crittografia ove appropriato. GDPR Article 32 richiede una sicurezza adeguata al rischio, incluse riservatezza, integrità, disponibilità, resilienza e capacità di garantire la protezione continua dei dati personali.

Il linguaggio regolatorio cambia, ma la logica di controllo è coerente: conoscere le dipendenze, gestire il rischio, conservare le evidenze e agire prima che la resilienza sia compromessa.

Mappatura cross-compliance: un piano di migrazione, molti obblighi

Un piano solido di migrazione alla crittografia post-quantistica dovrebbe evitare la creazione di pacchetti di evidenze separati per ogni framework. Le stesse evidenze principali possono supportare più obblighi se sono strutturate correttamente.

Zenith Controls mappa il tema della crittografia su ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIST, COBIT 2019, GDPR, DORA e NIS2 concentrandosi sulla finalità del controllo, non sull’etichetta usata da ciascun framework.

Il riuso delle evidenze è fondamentale. Un inventario crittografico supporta la gestione degli asset ISO, gli esiti Identify di NIST, la visibilità degli asset ICT prevista da DORA, la gestione del rischio NIS2 e l’accountability GDPR. I questionari ai fornitori supportano i controlli sui fornitori ISO, il rischio ICT di terze parti DORA, la sicurezza della catena di fornitura NIS2 e la governance dei fornitori COBIT. I risultati dei test di migrazione supportano cambiamenti sicuri, test di resilienza, preparazione agli audit e riesame della direzione.

Che cosa chiederanno gli auditor

La crittografia post-quantistica è ancora un tema di audit emergente, ma gli auditor dispongono già di aspettative di controllo sufficienti per porre domande difficili.

Un auditor ISO/IEC 27001:2022 partirà normalmente dal rischio. Chiederà se il rischio crittografico connesso al calcolo quantistico è identificato, valutato, trattato, monitorato e riesaminato all’interno del SGSI. Si aspetterà evidenze del fatto che i controlli crittografici siano selezionati in base al rischio aziendale e che le responsabilità siano definite.

Un valutatore orientato a NIST può concentrarsi su visibilità degli asset, meccanismi di protezione, rischio della catena di fornitura, gestione delle vulnerabilità ed esiti di governance. Può chiedere se l’organizzazione ha identificato i sistemi che usano crittografia a chiave pubblica vulnerabile e se la pianificazione della migrazione è allineata alla direzione NIST.

Un auditor COBIT o ISACA chiederà spesso informazioni sulla governance. Chi è accountable? Come riceve il consiglio di amministrazione la reportistica? Gli investimenti sono prioritizzati? Le dipendenze dai fornitori sono gestite? Benefici, rischi e risorse sono bilanciati?

Un auditor privacy può concentrarsi sul fatto che cifratura e gestione delle chiavi rimangano adeguate alla sensibilità e al periodo di conservazione dei dati personali.

Un revisore focalizzato su DORA o NIS2 valuterà resilienza, concentrazione ICT presso terze parti, continuità operativa e preparazione agli incidenti.

Zenith Controls raccomanda di trattare la preparazione agli audit come un percorso di evidenze. Non attendere che gli auditor chiedano screenshot e fogli di calcolo. Costruisci uno spazio di lavoro GRC che colleghi ogni rischio crittografico al relativo proprietario, agli asset interessati, ai fornitori, alle decisioni, ai test, alle eccezioni e alle date di riesame.

Aggiornare le politiche per rendere operativo il programma

La maggior parte delle politiche crittografiche è stata scritta per requisiti tradizionali di riservatezza e integrità. La migrazione post-quantistica richiede integrazioni mirate.

La politica di crittografia e gestione delle chiavi dovrebbe trattare standard approvati, frequenza di riesame, classificazione dei dati, durata di protezione, agilità degli algoritmi, generazione delle chiavi, archiviazione delle chiavi, rotazione, distruzione, titolarità, ciclo di vita dei certificati, responsabilità HSM, responsabilità del cloud KMS, approvazione delle eccezioni, crittografia controllata dai fornitori e monitoraggio della transizione post-quantistica.

La politica di sviluppo sicuro dovrebbe trattare approvazione delle librerie crittografiche, divieto di algoritmi hardcoded senza riesame, tracciamento delle dipendenze, meccanismi di aggiornamento sicuri, test di prestazione per chiavi o firme più grandi, compatibilità retroattiva, rollback e modellazione delle minacce per prodotti a lunga durata.

La politica di sicurezza dei fornitori dovrebbe trattare trasparenza crittografica, richieste di roadmap post-quantistica, obblighi contrattuali di notifica, responsabilità condivisa per cifratura e gestione delle chiavi, pianificazione dell’uscita e portabilità.

La procedura di gestione degli asset dovrebbe trattare campi dell’inventario crittografico, titolarità, fonti delle evidenze, frequenza di riesame e integrazione con CMDB, inventario cloud, gestione dei certificati, registrazioni HSM e repository del codice.

È qui che la libreria di politiche Clarysec aiuta le organizzazioni ad accelerare. Invece di partire da una pagina vuota, i team possono adattare clausole di policy in procedure, registri, questionari ed evidenze di audit.

Evitare gli errori più comuni nella migrazione post-quantistica

Gli errori più pericolosi sono di solito fallimenti di governance, non fallimenti tecnici.

Iniziare dagli algoritmi invece che dagli asset. Se non sai dove viene usata la crittografia, la selezione degli algoritmi non aiuterà.

Ignorare la durata dei dati. I dati transazionali di breve durata e gli archivi sensibili a lunga durata non presentano lo stesso rischio.

Considerare i fornitori come una fase successiva. Molti controlli crittografici sono gestiti dai fornitori. Se i fornitori non vengono coinvolti presto, il piano può essere irrealistico.

Dimenticare le firme. La pianificazione post-quantistica non riguarda solo la cifratura. Firme digitali, firma del codice, certificati, token di identità, aggiornamenti firmware e firma dei documenti richiedono attenzione.

Presumere che i cloud provider risolvano tutto. Le piattaforme cloud avranno un ruolo rilevante, ma la responsabilità resta condivisa. Occorre comunque sapere quali servizi, configurazioni, chiavi, regioni e integrazioni sono interessati.

Non creare evidenze di audit. Un piano di migrazione che non può essere dimostrato con evidenze non soddisferà direzione, autorità di regolamentazione, clienti o auditor.

Saltare i test di prestazioni e interoperabilità. Gli algoritmi post-quantistici possono incidere su dimensione dei payload, comportamento degli handshake, latenza, storage, vincoli embedded e compatibilità.

Metriche che il CISO dovrebbe riportare al consiglio

La reportistica al consiglio deve essere abbastanza semplice da comprendere e sufficientemente specifica da guidare l’azione. Evitare discussioni approfondite sugli algoritmi. Concentrarsi su esposizione, avanzamento, decisioni e rischio residuo.

Un messaggio utile per il consiglio potrebbe suonare così:

“Abbiamo completato la discovery crittografica per il 72 percento dei servizi critici. Due sistemi presentano un’esposizione critica di riservatezza a lunga durata e tre fornitori non hanno ancora fornito roadmap post-quantistiche. Abbiamo avviato un progetto di preparazione alla firma del codice e un riesame delle dipendenze dal cloud KMS. Oggi non si raccomanda alcuna sostituzione d’emergenza, ma l’incertezza sui fornitori resta il principale rischio residuo.”

Questo è il linguaggio del rischio cyber governato.

Una checklist pratica per iniziare questa settimana

Non è necessario attendere una certezza perfetta. Inizia con attività che migliorano subito visibilità e governance.

1. Nominare un proprietario della crittografia post-quantistica.
2. Aggiungere il rischio crittografico connesso al calcolo quantistico al Registro dei rischi del SGSI.
3. Identificare i primi dieci servizi con dati sensibili a lunga durata o impatto elevato sull’integrità.
4. Costruire una CBOM minima utilizzabile per tali servizi.
5. Richiedere ai fornitori critici la loro roadmap post-quantistica.
6. Riesaminare le politiche su crittografia, sviluppo sicuro, fornitori e asset.
7. Identificare i sistemi con algoritmi hardcoded, librerie obsolete, rotazione manuale dei certificati o titolarità debole.
8. Selezionare un pilota a basso rischio per testare l’agilità crittografica.
9. Definire le metriche per il consiglio e la frequenza di reportistica.
10. Pianificare un audit interno focalizzato su governance crittografica ed evidenze.

La mossa più importante è convertire l’incertezza in lavoro gestito. Il rischio quantistico guarda al futuro, ma il debito crittografico esiste già oggi.

Prossimi passi con Clarysec

La migrazione post-quantistica sarà una delle transizioni di sicurezza più complesse del prossimo decennio perché tocca identità, cifratura, firme, fornitori, cloud, software, dispositivi, archivi ed evidenze di audit. Le organizzazioni che partono da governance e inventario si muoveranno più rapidamente di quelle che attendono un ciclo di sostituzione dell’ultimo minuto.

Clarysec può aiutarti a costruire un piano di migrazione crittografica pronto per l’era quantistica utilizzando:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap per attuazione per fasi e preparazione agli audit
• Zenith Controls: The Cross-Compliance Guide per la mappatura ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIST, COBIT 2019, GDPR, DORA e NIS2
• Politica di crittografia e gestione delle chiavi per regole crittografiche pronte per la governance
• Politica di sicurezza delle terze parti e dei fornitori per requisiti di roadmap e assurance dei fornitori
• Politica di sviluppo sicuro per pratiche ingegneristiche ad agilità crittografica

Il momento migliore per iniziare la pianificazione post-quantistica è prima che un’autorità di regolamentazione, un auditor, un cliente o un membro del consiglio chieda evidenze. Parti dall’inventario, collegalo al rischio e costruisci il percorso di migrazione una decisione controllata alla volta.