Eccezioni crittografiche ISO 27001: guida alle evidenze e alle CER

La conversazione di audit che David temeva di più arrivò con tre settimane di anticipo. InnovatePay aveva appena acquisito una società più piccola, QuickAcquire. L’operazione era un successo strategico, ma nello stack tecnologico era nascosto un modulo legacy di trasferimento dati basato su una libreria crittografica non conforme agli standard approvati da InnovatePay. Sostituirlo avrebbe richiesto un progetto di sei mesi. L’auditor esterno sarebbe arrivato la settimana successiva.

Nella mente di David, la scena era dolorosamente chiara. L’auditor, calmo e metodico, avrebbe individuato la deviazione e posto l’unica domanda capace di trasformare sappiamo che è rischioso in una non conformità: mostratemi le evidenze dell’eccezione crittografica e il criterio con cui avete stabilito che fosse accettabile.

In quel momento non conta l’intenzione; conta il controllo. Senza un processo di gestione delle eccezioni documentato, accettazione del rischio da parte dell’alta direzione, controlli compensativi, log di gestione delle chiavi e un piano di rimedio limitato nel tempo, un auditor tenderà a qualificare la questione come fallimento del controllo o come debolezza della governance del SGSI. Questa guida di riferimento mostra come trasformare quel momento in una dimostrazione di maturità, utilizzando toolkit e politiche Clarysec, il controllo ISO/IEC 27001:2022 A.8.24 Uso della crittografia e una prospettiva di conformità trasversale che copre NIS2, DORA, GDPR, NIST e COBIT 2019.

Perché le eccezioni crittografiche sono inevitabili e come le valutano gli auditor

Le eccezioni crittografiche nascono da cause prevedibili. Negli incarichi Clarysec osserviamo schemi ricorrenti:

• Vincoli tecnologici legacy, ad esempio algoritmi, suite crittografiche o lunghezze di chiave non supportati.
• Lock-in del fornitore e ritardi di certificazione che impediscono aggiornamenti tempestivi alla crittografia approvata.
• Esigenze operative nella risposta agli incidenti o nell’analisi forense, che richiedono deviazioni temporanee per raccogliere evidenze o mantenere la continuità del servizio.
• Periodi di migrazione, nei quali l’interoperabilità transitoria impone impostazioni più deboli per un periodo limitato.
• Vincoli di partner o clienti che impediscono l’applicazione della baseline preferita.

Gli auditor ISO/IEC 27001:2022 non pretendono la perfezione: pretendono il controllo. Valutano se la cifratura è appropriata e coerente, se la gestione delle chiavi è governata e registrata nei log e se l’organizzazione identifica e gestisce attivamente gli algoritmi obsoleti nel proprio ambiente. Il primo passo consiste nell’allineare la gestione delle eccezioni a ciò che gli auditor si aspettano di vedere.

Ancorare l’eccezione alla politica e alla governance del rischio

Un SGSI maturo tratta le eccezioni come decisioni di trattamento del rischio, non come debito tecnico. Il meccanismo formale è la richiesta di eccezione crittografica (CER), e la clausola di policy che la impone è il punto di passaggio tra un’eccezione gestita e una risultanza di audit.

La Politica sui controlli crittografici enterprise di Clarysec richiede: l’uso di algoritmi crittografici non standard o la deviazione temporanea dalle pratiche approvate per il ciclo di vita richiede una richiesta di eccezione crittografica (CER) documentata. La famiglia di politiche si collega direttamente al trattamento del rischio. La Politica di gestione del rischio complementare supporta la valutazione dei rischi relativi ai controlli crittografici e documenta la strategia di trattamento del rischio per eccezioni, obsolescenza degli algoritmi o scenari di compromissione delle chiavi.

Una volta definito il requisito nella politica, ogni eccezione deve essere riconducibile a una CER con accettazione del rischio da parte dell’alta direzione, voce collegata nel registro dei rischi, controlli compensativi e piano di uscita. Presenta questi artefatti prima che vengano richiesti, accompagnando l’auditor dalla governance allo stato tecnico, con l’approccio di intervista e campionamento previsto nello Zenith Blueprint.

Costruire la CER come registrazione del controllo pronta per l’audit

I commenti nei ticket non sono registrazioni di eccezione. Una CER deve essere strutturata, soggetta a controllo delle versioni e campionabile come qualsiasi altra registrazione di controllo. Che sia gestita in uno strumento GRC o in un modello controllato, una CER solida include:

• Sintesi dell’eccezione, che cosa non è conforme e dove.
• Ambito di applicazione, tipologie di dati e indicazione se l’eccezione interessa dati a riposo, dati in transito o entrambi.
• Giustificazione aziendale, il motivo collegato a vincoli di servizio o di business.
• Valutazione dell’impatto sulla sicurezza, con scenari di minaccia realistici quali rischio di downgrade, MITM, hashing debole, compromissione delle chiavi.
• Controlli compensativi, ad esempio segmentazione, certificati client, durata ridotta delle sessioni, regole WAF, autenticazione aggiuntiva, monitoraggio rafforzato.
• Punteggio di rischio prima e dopo i controlli compensativi, allineato alla matrice del rischio.
• Responsabile, un responsabile del rischio sul lato business.
• Approvazioni, sicurezza, responsabile del sistema e accettazione del rischio da parte dell’alta direzione.
• Data di scadenza e frequenza di riesame, senza durata indeterminata.
• Piano di uscita, tabella di marcia, dipendenze, milestone e date di scadenza.
• Riferimenti alle evidenze, link a configurazioni, log, risultati dei test, dichiarazioni dei fornitori e approvazioni delle modifiche.

Nel caso di David, l’eccezione QuickAcquire passò da passività nascosta a decisione verificabile in audit quando la presentò in apertura, rese disponibile il pacchetto di evidenze e invitò l’auditor a effettuare il campionamento.

Il pacchetto minimo di evidenze per un’eccezione crittografica

Gli auditor si aspettano qualcosa di più di una fotografia tecnica. Per le eccezioni vogliono evidenze di governance ed evidenze operative. Un pacchetto di evidenze pratico include:

1. La CER completata, con approvazioni e scadenza.
2. La valutazione del rischio collegata e la decisione di trattamento.
3. Le procedure di gestione delle chiavi per il sistema interessato, con log di generazione, distribuzione, rotazione, accesso e distruzione delle chiavi.
4. Le registrazioni delle modifiche alle impostazioni crittografiche e le evidenze dei test che dimostrano la convalida delle modifiche o la verifica dei vincoli.
5. Le evidenze di monitoraggio e rilevamento relative ai controlli compensativi, incluse regole SIEM e test degli alert.
6. Le registrazioni delle comunicazioni che dimostrano che il personale interessato è stato informato e formato sulla deviazione e sulle aspettative di monitoraggio.
7. Un piano di uscita limitato nel tempo con milestone, date, budget ove applicabile e responsabili.
8. La cronologia dei riesami della politica, che dimostra il mantenimento della baseline crittografica e la gestione del ciclo di vita degli algoritmi.

Queste tipologie di evidenza sono allineate alle indicazioni ISO/IEC 27002:2022 su crittografia e controllo delle modifiche.

Utilizzare lo Zenith Blueprint per raccogliere e presentare le evidenze

Il metodo di gestione delle evidenze nello Zenith Blueprint è semplice e adatto all’audit: intervistare, riesaminare, osservare e campionare. Applicalo alle eccezioni:

• Intervistare il responsabile del sistema e il responsabile della sicurezza delle informazioni. Perché l’eccezione è necessaria, che cosa è cambiato dall’ultimo riesame e qual è il passo successivo nel piano di uscita.
• Riesaminare la CER, la registrazione del rischio, la clausola di policy e i vincoli del fornitore o del partner. Confermare scadenza e date di riesame.
• Osservare lo stato tecnico, ossia la configurazione esatta e il punto in cui l’eccezione è applicata, e verificare dove sono attivi i controlli compensativi.
• Campionare più eccezioni, di norma da tre a cinque, per dimostrare coerenza di struttura, approvazioni, riesami, registrazione nei log e gestione delle scadenze.

Esempio operativo: rendere verificabile in audit un’eccezione TLS legacy

Scenario: un’integrazione B2B critica per i ricavi richiede una suite crittografica TLS obsoleta perché l’endpoint del partner non può negoziare le impostazioni approvate. Interrompere la connessione non è praticabile.

Rendila verificabile in audit con quattro interventi:

1. Creare la CER e collegarla al rischio. Imposta una scadenza a 90 giorni con riesami ogni 30 giorni, allega la corrispondenza con il partner e collega la CER a una voce del registro dei rischi con responsabilità assegnata al business.
2. Scegliere controlli compensativi che producano evidenze. Limita gli IP sorgente agli intervalli del partner tramite registrazioni delle modifiche al firewall. Applica mutual TLS se possibile e conserva le registrazioni di emissione dei certificati. Rafforza il monitoraggio delle anomalie di handshake e conserva le definizioni delle regole SIEM e i test degli alert.
3. Dimostrare disciplina nella gestione delle chiavi. Mostra i log di accesso KMS, le assegnazioni RBAC, le registrazioni break glass e i verbali dei riesami periodici degli accessi. Per i programmi più piccoli, il requisito di baseline è esplicito nella Politica sui controlli crittografici per PMI: tutti gli accessi alle chiavi crittografiche devono essere registrati nei log e conservati per il riesame in sede di audit, con riesami periodici degli accessi.
4. Predisporre il pacchetto dell’eccezione. Prepara una singola cartella di evidenze o un PDF che includa CER, registrazione del rischio, snapshot della configurazione del gateway, ticket di modifica del firewall, log KMS, regola SIEM e campioni di eventi, registrazioni dei test e comunicazioni alle operations.

Agilità crittografica: dimostrare che le eccezioni sono temporanee per progettazione

ISO/IEC 27002:2022 promuove l’agilità crittografica, ossia la capacità di aggiornare algoritmi e suite senza ricostruire interi sistemi. Gli auditor cercano evidenze di agilità, non promesse:

• Cadenza di riesame della politica che aggiorna algoritmi e pratiche accettabili con registri delle modifiche versionati.
• Registrazioni dei test sugli aggiornamenti crittografici che dimostrano percorsi di rollout sicuri.
• Comunicazioni al personale sulle modifiche crittografiche e sui relativi impatti operativi.
• Elementi di backlog con avanzamento della delivery collegato alle date di scadenza delle eccezioni.

La governance delle eccezioni incontra l’analisi forense

Le eccezioni possono complicare le indagini, soprattutto quando la cifratura o dispositivi non supportati bloccano la raccolta delle evidenze. La Politica per la raccolta delle evidenze e l’analisi forense di Clarysec affronta il tema con indicazioni esplicite per le evidenze richieste da dispositivi non supportati o cifrati. La versione per PMI, la Politica per la raccolta delle evidenze e l’analisi forense per PMI, anticipa modalità pratiche di fallimento, ad esempio quando le evidenze non possono essere raccolte secondo la politica a causa di un arresto anomalo del sistema o di supporti danneggiati.

Prevedi questo aspetto nelle CER. Includi il potenziale impatto sull’analisi forense, custodisci in escrow le chiavi necessarie e definisci i requisiti di accesso di emergenza e di registrazione nei log.

Mappatura di conformità trasversale: una sola eccezione, molte prospettive

Negli ambienti regolamentati o multi-framework, la stessa eccezione viene esaminata da prospettive diverse. Utilizza la guida Zenith Controls per mantenere coerente il pacchetto di evidenze.

Come indagheranno auditor diversi e come rispondere

Anche in un singolo audit gli stili variano. Preparati a ciascun approccio e guida la narrazione:

• L’auditor ISO/IEC 27001:2022 chiederà dove si trova la politica sulla crittografia, dove è definito il processo di gestione delle eccezioni, con quale frequenza le eccezioni sono riesaminate e vorrà effettuare un campionamento. Parti dalle CER e da un registro controllato.
• L’auditor orientato a NIST cercherà baseline delle suite crittografiche, protezioni contro il downgrade, procedure di generazione e distruzione delle chiavi e log con alerting. Porta log KMS, regole SIEM e test di convalida.
• L’auditor COBIT o ISACA si concentrerà su chi è responsabile del rischio, chi lo ha accettato, qual è la cadenza dei riesami e quali metriche mostrano la riduzione progressiva delle eccezioni. Porta verbali del comitato direttivo e report di aging delle eccezioni.
• Il revisore orientato alla regolamentazione chiederà in che modo l’eccezione incida sulla disponibilità e sull’integrità dei servizi critici e se il rischio di esposizione dei dati personali sia aumentato. Presenta artefatti di pianificazione della resilienza e una tempistica di rimedio vincolante.

Errori comuni che generano non conformità

• Eccezioni senza data di scadenza, interpretate come rischio non gestito.
• Assenza di accettazione del rischio da parte dell’alta direzione, ad esempio quando un ingegnere approva in un ticket senza responsabilità formalmente assegnata.
• Controlli compensativi descritti ma non supportati da evidenze, ad esempio dichiarazioni di monitoraggio senza regole SIEM.
• Log di gestione delle chiavi mancanti o non accessibili.
• La politica dice una cosa e la prassi un’altra, ad esempio le CER sono obbligatorie ma non vengono utilizzate.

Checklist del giorno di audit per le eccezioni crittografiche

• Un registro aggiornato elenca tutte le eccezioni crittografiche con ID CER, responsabili, approvazioni, date di riesame e scadenze.
• Ogni eccezione è collegata a una registrazione del rischio e a una decisione di trattamento documentata.
• Per ogni eccezione esistono almeno due controlli compensativi, supportati da evidenze solide.
• L’accesso alle chiavi è registrato nei log, i log sono conservati e vengono eseguiti riesami degli accessi.
• È disponibile la cronologia dei riesami della politica crittografica, con modifiche versionate.
• È possibile campionare tre o più eccezioni e presentare una narrazione coerente.
• Una tabella di marcia mostra la riduzione delle eccezioni nel tempo.

Vincoli di fornitori e partner

Molte eccezioni nascono fuori dal controllo diretto dell’organizzazione. I partner impongono suite crittografiche, i fornitori ritardano sulle roadmap oppure i sistemi acquisiti portano con sé debito tecnico. Tratta i vincoli esterni come parte della governance, non come scuse. Richiedi dichiarazioni dei fornitori sulle roadmap crittografiche, includi clausole contrattuali che definiscano le baseline crittografiche e registra le dipendenze esterne nel registro dei rischi.

Prossimi passi: costruire il programma di eccezioni in uno sprint

1. Inventariare tutte le eccezioni crittografiche, incluse quelle nascoste nei servizi edge.
2. Creare o aggiornare retroattivamente le CER per ciascuna eccezione con approvazioni, scadenza e piani di uscita.
3. Collegare ogni CER a una voce del registro dei rischi con un responsabile assegnato.
4. Predisporre un modello standard di pacchetto di evidenze per le eccezioni e provare il campionamento in audit.
5. Convalidare la capacità di dimostrare la conformità trasversale con la guida Zenith Controls.

Trasforma l’ansia per le eccezioni crittografiche in fiducia in sede di audit. Prenota una sessione operativa con Clarysec. In un unico incarico, implementiamo un workflow CER, un registro delle eccezioni e una struttura del pacchetto di evidenze pronta per l’auditor. Il risultato: audit più rapidi, meno risultanze ricorrenti ed eccezioni crittografiche che dimostrano governance invece di improvvisazione.