Registro dei rischi, il documento più pericoloso se finisce nelle mani sbagliate

Un’organizzazione che conduce un’analisi dei rischi comprensiva delle misure in essere ed eventualmente di quelle pianificate — sulla sicurezza delle informazioni, sulla protezione dei dati personali, o su entrambe o più in generale una analisi del rischio sul criterio X — produce inevitabilmente un documento molto sensibile. Infatti, non descrive solo le minacce astratte, ma fotografa cosa è protetto, come, cosa, quando e come verrà protetto in futuro con le relative priorità e soprattutto cosa non lo è ancora.

È proprio qui che nasce il problema che moltissime organizzazioni sottovalutano. Un registro dei rischi che elenca le misure di trattamento applicate rivela, per differenza, anche quelle non applicate. E le misure non applicate sono, per definizione, vulnerabilità residue.

In altri termini, se un malintenzionato (interno o esterno) riesce a leggere quel documento, non ha bisogno di “scoprire” le debolezze del sistema con tecniche di attacco — gliele state consegnando già mappate, classificate per gravità e persino prioritizzate.

Perché l’analisi dei rischi è un documento riservato

Un’analisi dei rischi ben fatta (che segua ad esempio ISO/IEC 27001, la metodologia NIST SP 800-30, o i criteri richiesti dal GDPR per il trattamento dei dati personali) tipicamente contiene:

• l’inventario degli asset critici (sistemi, banche dati, processi, sedi fisiche);
• le minacce e vulnerabilità identificate per ciascun asset;
• la valutazione di probabilità e impatto, spesso con punteggi numerici che indicano dove il rischio è più alto;
• i modelli più sofisticati indicano anche, sempre associandoli a dei punteggi, il grado di rilevabilità della minaccia;
• le misure di trattamento effettivamente implementate (controlli tecnici, organizzativi, fisici, sulle persone);
• il rischio residuo accettato — cioè, esplicitamente, ciò che l’organizzazione ha scelto di non coprire o di coprire solo parzialmente o che non ha ancora le risorse disponibili per coprire in modo adeguato e le priorità di intervento;
• talvolta anche tempistiche di remediation e responsabili, che indicano per quanto tempo una debolezza resterà ad un livello non accettabile.

Ognuno di questi elementi, preso singolarmente, sembra “solo documentazione interna”. Ma nell’insieme costituiscono una mappa operativa dell’esposizione dell’organizzazione — esattamente il tipo di informazione che un malintenzionato cercherebbe di ricostruire con settimane di ricognizione, tramite tecniche specifiche (es. OSINT, scansioni, ingegneria sociale). Un documento a cui ha possibilità di accesso gli risparmia tutto questo lavoro.

Analisi dei rischi: dalle misure alle vulnerabilità residue

Il punto centrale, alla base del tema in oggetto, merita di essere esplicitato bene.

Se un rischio X è trattato con le misure A, B e C, ed esiste un elenco standard di misure possibili per quel tipo di rischio (A, B, C, D, E), chiunque acceda al documento può dedurre facilmente per differenza che D ed E non sono state implementate.

Questo vale sia per la sicurezza delle informazioni (dove esistono cataloghi di controlli molto noti, come l’Allegato A della ISO/IEC 27001, i CIS Controls – Center for Internet Security Critical Security Controls – o il catalogo NIST) sia per la protezione dei dati personali (dove il GDPR stesso, all’art. 32, elenca categorie di misure tecniche e organizzative attese es. pseudonimizzazione, cifratura, resilienza, procedure di test, ecc.).

I cataloghi di controllo come checklist inversa

Il NIST (National Institute of Standards and Technology) mette a disposizione due riferimenti particolarmente rilevanti in questo contesto:

• il NIST Cybersecurity Framework (CSF 2.0), che organizza le attività di sicurezza in sei funzioni (Governare, Identificare, Proteggere, Rilevare, Rispondere, Ripristinare) e permette di rappresentare in modo sintetico — ma comunque leggibile da chiunque conosca il framework — a che livello di maturità si trova un’organizzazione per ciascuna area;
• il catalogo NIST SP 800-53, estremamente dettagliato (centinaia di controlli specifici, suddivisi in famiglie come controllo degli accessi, gestione degli incidenti, protezione dei sistemi e delle comunicazioni), spesso usato, vista la sua valenza, come riferimento anche al di fuori del contesto per cui era stato originariamente concepito.

Analisi dei rischi: documenti sensibili e scenari di esposizione

Chi conosce questi cataloghi — e un attaccante mediamente competente li conosce — usa il documento come una checklist inversa ovvero non “cosa devo verificare”, ma “cosa so già che manca”.

Dal registro IT ai report VAPT

Registro dei rischi IT con misure di mitigazione elencate – Il documento riporta: “Rischio: accesso non autorizzato ai server di produzione. Misure applicate: autenticazione a fattore singolo, segmentazione di rete parziale, logging centralizzato.” → Chi legge capisce immediatamente che manca l’autenticazione a più fattori (MFA) e che la segmentazione è incompleta; si tratta di due indicazioni dirette su dove concentrare un tentativo di intrusione.

Valutazione d’impatto sulla protezione dei dati (DPIA) – Una DPIA per un’applicazione che tratta dati sanitari indica: “Cifratura dei dati in transito: sì. Cifratura dei dati a riposo: prevista ma non ancora implementata (pianificata per Q3).” → Un attaccante che ottenga accesso al database sa già, prima ancora di guardarlo, che troverà dati in chiaro, e sa anche entro quale finestra temporale agire prima che la misura venga completata.

Piano di continuità operativa (BCP/DR) – Il documento descrive: “Sistema di fatturazione: nessun sito di disaster recovery secondario. Single point of failure identificato e accettato come rischio residuo per limiti di budget.” → Questo indica esattamente quale sistema colpire con un attacco ransomware o un sabotaggio per massimizzare il danno, dato che non esiste un piano B.

Report di sicurezza fisica – “Sala server: accesso controllato da badge; copertura videosorveglianza assente su tutto il perimetro dell’edificio per vincoli imposti dalle belle arti.” → Un’informazione di questo tipo, se diffusa, indica letteralmente il punto cieco fisico da cui tentare un accesso non autorizzato.

Analisi dei rischi fornitori (vendor risk assessment) – “Fornitore cloud X: certificazione ISO/IEC 27001 verificata. Fornitore cloud Y (backup secondario): introdotto da poche settimane e nessuna verifica formale dei controlli di sicurezza effettuata.” → Rivela quale terza parte rappresenta l’anello più debole della catena di fornitura, orientando un attacco supply-chain verso il bersaglio meno protetto.

Piano di gestione degli incidenti – “Soglie di allerta per traffico anomalo non ancora calibrate; il SOC opera solo in orario lavorativo (8-18, giorni feriali).” → Indica non solo una lacuna tecnica ma anche una finestra temporale di minor sorveglianza in cui un’azione malevola avrebbe maggiori probabilità di passare inosservata.

Report di audit di sicurezza e risultati di VAPT (Vulnerability Assessment & Penetration Test) – Questo è probabilmente il caso più critico in assoluto, perché questi documenti non descrivono rischi teorici ma vulnerabilità tecniche concrete, verificate e spesso già sfruttabili, con tanto di indicazioni su come sono state individuate.

Un report VAPT tipico contiene elementi come:

• l’elenco degli asset testati (IP, applicazioni, sottoreti) e, per differenza, quelli esclusi dal perimetro del test — che restano quindi non verificati;
• le vulnerabilità rilevate, spesso con CVE specifici, versione del software vulnerabile e relativo severity score (CVSS);
• la prova di sfruttabilità (proof of concept), che in molti casi documenta passo-passo come la vulnerabilità è stata sfruttata durante il test;
• lo stato di remediation e nello specifico (quali vulnerabilità sono state corrette, quali sono “pianificate” e quali sono state “accettate come rischio residuo” – cioè lasciate intenzionalmente aperte, magari per motivi di budget o compatibilità);
• le credenziali o configurazioni deboli individuate (es. password di default non cambiate, servizi esposti senza autenticazione, permessi eccessivi).

In tutti questi casi il rischio non deriva da un errore nell’analisi o nei piani di remediation che devono tenere conto di più vincoli — anzi, sono analisi corrette e ben fatte — ma dalla loro circolazione incontrollata.

Analisi dei rischi e obblighi di riservatezza

La riservatezza di questi documenti è quindi un requisito implicito degli stessi framework che ne impongono la produzione.

• GDPR, art. 5(1)(f) e art. 32 – il principio di integrità e riservatezza si applica (indirettamente) anche alla documentazione che descrive le misure di sicurezza adottate per il trattamento dei dati, non solo ai dati stessi. Una fuga di questa documentazione può essere considerata essa stessa un evento che aumenta il rischio per gli interessati, e va valutata nell’ambito della responsabilizzazione del titolare (art. 5(2)).
• ISO/IEC 27001 – richiede la classificazione delle informazioni (controllo A.5.12 nella revisione 2022) e l’analisi dei rischi stessa, insieme allo Statement of Applicability, è dovrebbe esssere classificata come “riservata” o “strettamente riservata” proprio per questa ragione.
• NIS2 (per i soggetti essenziali e importanti) – impone la gestione del rischio in modo documentato, ma la direttiva presuppone che tale documentazione sia trattata con misure di sicurezza commisurate alla sua criticità — un’autoreferenzialità che spesso viene trascurata.
• Perizie e audit di terze parti – report di penetration test, vulnerability assessment e audit di sicurezza sono, per la stessa logica, tra i documenti più sensibili che un’azienda possiede, e vanno trattati con controlli di accesso equivalenti (o superiori) a quelli riservati ai dati che proteggono.

Riservatezza dell’analisi dei rischi: le buone pratiche

• Classificazione esplicita – etichettare l’analisi dei rischi, i relativi piani di trattamento i risultati dei VAPT e degli audit come “riservato” o “strettamente riservato”, con un registro di chi vi ha accesso.
• Principio del need-to-know – solo chi ha effettiva responsabilità sulla gestione del rischio (CISO, DPO, Risk Owner, vertice aziendale) dovrebbe avere accesso al documento completo.
• Versioni disaggregate e/o parziale mascheramento delle informazioni per audience diverse – per il management si può condividere una sintesi con livelli di rischio aggregati (es. “rischio alto/medio/basso”), senza il dettaglio delle singole vulnerabilità tecniche non trattate.
• Separazione tra registro dei rischi e piano di remediation dettagliato – il “cosa manca ancora” e le tempistiche di chiusura sono spesso l’informazione più pericolosa; può avere un accesso ancora più ristretto rispetto al registro generale.
• NDA e accordi di riservatezza specifici – per auditor, consulenti esterni e fornitori che devono visionare l’analisi, solo laddove si rilevasse strettamente necessario.
• Conservazione sicura – cifratura a riposo, accesso tracciato (log), divieto di copie non controllate su email o cloud personali.
• Redazione (redaction) per condivisioni parziali – quando il documento va condiviso per finalità di certificazione o compliance con enti terzi, valutare se mascherare i dettagli tecnici delle misure non ancora implementate, lasciando visibile solo lo stato di rischio complessivo.
• Audit sugli accessi al documento stesso – conoscere chi ha letto l’analisi dei rischi e quando è, essa stessa, una misura di sicurezza.

Analisi dei rischi: la riservatezza come condizione di sicurezza

L’analisi dei rischi e il relativo piano di trattamento sono strumenti indispensabili di governance della sicurezza — ma sono anche, paradossalmente, una delle informazioni più pericolose che un’organizzazione possa produrre se finiscono nelle mani sbagliate. Il motivo non sta in un difetto del processo, ma nella sua stessa efficacia. Un’analisi ben fatta descrive con precisione cosa è protetto e cosa no. Trattare questi documenti con lo stesso rigore riservato ai sistemi che descrivono non è un eccesso di cautela, ma una condizione necessaria perché l’analisi dei rischi raggiunga il suo scopo, invece di diventare essa stessa un vettore di rischio.