Non scelga un algoritmo post-quantum finché non sa dove si trova la crittografia a chiave pubblica nel Suo patrimonio IT. A agosto 2024 il NIST ha pubblicato FIPS 203, 204 e 205 e raccomanda alle organizzazioni di iniziare subito la migrazione. Gli standard indicano verso cosa migrare. Non dicono nulla su ciò che state eseguendo oggi, e scoprirlo è la parte più lenta.
Cosa chiedono le scadenze
La pagina del progetto NIST afferma che, secondo il calendario di transizione di NIST IR 8547, gli algoritmi vulnerabili ai computer quantistici saranno deprecati e infine rimossi dai suoi standard entro il 2035, mentre i sistemi ad alto rischio dovranno muoversi molto prima. La pagina della bozza di IR 8547 riporta che la versione definitiva l'ha sostituita il 27 ottobre 2026. Le nostre fonti non elencano gli standard vulnerabili né le date anticipate per i sistemi ad alto rischio: li legga direttamente nel testo del NIST.
L'NCSC britannico traduce il calendario in tappe su cui un team IT può costruire un budget, nella sua guida sulle tempistiche di migrazione alla PQC:
| Entro | Cosa si aspetta l'NCSC |
|---|---|
| 2028 | Definire gli obiettivi di migrazione, completare un'attività di discovery completa, preparare un piano iniziale |
| 2031 | Eseguire la migrazione iniziale, quella a priorità più alta, e trasformare il piano in una roadmap completa |
| 2035 | Completare la migrazione di tutti i sistemi, servizi e prodotti |
L'inventario alimenta tutte e tre le attività del 2028. Se è scarno, le altre due si riducono a congetture.
Cosa inserire nell'elenco
L'obiettivo è tutto ciò che si basa sulla crittografia asimmetrica a chiave pubblica, che secondo l'NCSC i computer quantistici saranno in grado di violare. La sezione dell'NCSC dedicata alla discovery copre queste aree:
- sistemi e servizi che gestite, per gli utenti interni e per soggetti esterni;
- prodotti che realizzate o utilizzate e che svolgono una funzione di crittografia, sicurezza, comunicazione o elaborazione dati;
- applicazioni software e apparati di rete come router, switch, gateway, VPN e stazioni radio base;
- dispositivi mobili, server e workstation;
- dispositivi IoT e ICS con funzione di comunicazione, token rilasciati agli utenti, dispositivi e sensori installati sul campo;
- i dati che detenete, la loro durata prevista e il loro valore per un avversario, e il modo in cui sono protetti in transito e a riposo.
I certificati non sono citati in questo elenco, anche se l'NCSC dedica una sezione separata alla PKI aziendale. Aggiunga come righe a sé i certificati web pubblici, le CA interne, i certificati client e le chiavi di firma del codice: è una nostra valutazione, non dell'NCSC. Aggiunga anche i fornitori di servizi gestiti.
Non si tratta di un registro formale degli asset. Per ogni sistema annoti natura, dimensioni, versione, livello di patch e dipendenze; basta una riga per sistema.
Dove gli inventari falliscono
Tre punti richiedono un'attenzione deliberata, perché nessuno emerge da un export dei certificati o da un elenco di pacchetti: le chiavi scritte direttamente nel codice applicativo o nella configurazione, le chiavi di firma custodite in un HSM e il firmware dei dispositivi embedded e sul campo, che non si aggiorna come un server. L'NCSC segnala come vincolo l'hardware a lunga vita e i cicli di sostituzione poco frequenti, ed è proprio su questi dispositivi che il vincolo pesa di più.
Censire tutto in una settimana
Parta dall'alto, dai servizi principali e dalle loro interdipendenze, poi scenda dal basso dove quella vista si esaurisce. Una suddivisione praticabile per un team ridotto:
- Primo giorno. Elenchi i servizi chiave e i dati che ciascuno tratta, e contrassegni i dati che devono restare segreti per anni. Invii lo stesso giorno l'email ai fornitori riportata più sotto, perché sono le risposte che richiedono più tempo.
- Secondo e terzo giorno. Esporti gli elenchi dei certificati da ogni CA che gestite e chieda i propri a ciascun team che acquista certificati. Aggiunga le configurazioni di VPN e accesso remoto. Raccolga SBOM, lockfile o elenchi di pacchetti del software che sviluppate e eseguite, e vi cerchi le librerie crittografiche e le relative versioni. Cerchi nei repository e nelle directory di configurazione chiavi private e certificati sottoposti a commit; ogni riscontro è una riga, e una chiave privata in un repository va comunque corretta.
- Quarto giorno. Esegua uno scanner TLS sugli endpoint esterni e interni, e verifichi le chiavi host SSH e le proposte VPN o IPsec offerte dai Suoi gateway. Confronti i risultati con le righe già compilate: l'output della scansione è un controllo incrociato, non un sostituto.
- Quinto giorno. Unisca i dati, segnali le lacune e scriva "sconosciuto" dove non è stato possibile confermare.
Le domande ai fornitori che stanno in una sola email:
- Quali dei vostri prodotti o servizi che utilizziamo si basano sulla crittografia a chiave pubblica, e quali librerie e versioni contengono?
- Qual è il vostro piano di migrazione alla PQC, con le date?
L'NCSC indica di assicurarsi che i fornitori di servizi gestiti svolgano queste valutazioni per i servizi che erogano a Lei. Chiedere per iscritto è la nostra raccomandazione per farlo.
Dall'elenco al piano
Per ogni riga scelga una delle strategie dell'NCSC: migrazione in loco, re-platform, dismissione del servizio, utilizzo fino a fine vita o accettazione del rischio. I sistemi privi di crittografia a chiave pubblica non richiedono interventi.
Ordini le righe in base alla durata e al valore dei dati che proteggono, poi in base alla dipendenza da hardware a lunga vita.
Si aspetti che vecchio e nuovo convivano per un certo periodo. Preferisca prodotti con crypto agility, cioè che supportano facilmente suite di algoritmi alternative, e decida in anticipo quando terminerà il supporto tradizionale.
Solo a quel punto scelga gli algoritmi. Il NIST prevede che ML-KEM (FIPS 203) per lo stabilimento delle chiavi, e ML-DSA (FIPS 204) e SLH-DSA (FIPS 205) per le firme, siano il fondamento della maggior parte delle implementazioni. FIPS 203 contiene una nota di pianificazione su un problema che sarà corretto in una revisione futura, quindi controlli l'errata prima di implementare partendo da esso. Il NIST sta ancora standardizzando Falcon e HQC; la sua pagina del progetto PQC è il posto in cui seguire le novità.
Per un supporto nella discovery, il nostro team di consulenza svolge assessment dedicati.
Da dove iniziare
- Nomini un responsabile, riservi una settimana e invii l'email ai fornitori il primo giorno.
- Crei una riga per sistema: responsabile, scopo, dove si usa la crittografia a chiave pubblica, versioni, dipendenze, durata dei dati, fornitore, strategia scelta, data obiettivo.
- Raccolga certificati, configurazioni VPN e SBOM, poi esegua le ricerche TLS, SSH e nei repository.
- Verifichi a mano chiavi scritte nel codice, firme basate su HSM e firmware embedded, e contrassegni come "sconosciuto" tutto ciò che non è confermato.
- Ordini le righe per durata dei dati e dipendenza dall'hardware, e assegni a ciascuna una strategia NCSC e una data obiettivo, così che il foglio diventi il Suo piano per il 2028.
- Legga la versione definitiva di IR 8547 per le date di deprecazione dei sistemi ad alto rischio e fissi date interne anteriori al 2035 dove richiesto.
