Un attacco riuscito significa che la sicurezza ha fallito?
Un attacco informatico riesce a superare le difese di un’organizzazione. Dati personali vengono sottratti, divulgati o resi accessibili a soggetti non autorizzati.
La conclusione potrebbe apparire immediata: se l’attacco è riuscito, le misure di sicurezza erano inadeguate. Ma è davvero così?
La Corte di giustizia dell’Unione europea, con la sentenza del 14 dicembre 2023 nella causa C-340/21, VB contro Natsionalna agentsia za prihodite, ha fornito una risposta molto più articolata.
La controversia trae origine da un attacco informatico ai sistemi dell’amministrazione fiscale bulgara che aveva determinato la divulgazione su Internet di dati personali relativi a milioni di soggetti.
Un’interessata aveva quindi chiesto il risarcimento del danno immateriale derivante dal timore che i propri dati potessero essere utilizzati abusivamente.
Il rinvio pregiudiziale ha consentito alla Corte di affrontare questioni centrali per la cybersecurity governance: adeguatezza delle misure tecniche e organizzative, onere della prova, intervento illecito di terzi e responsabilità del titolare, nonché risarcibilità del danno immateriale.
Se l’attacco riuscito non dimostra automaticamente l’inadeguatezza delle misure di sicurezza, che cosa dovrebbe essere in grado di dimostrare l’organizzazione il giorno dopo?
L’attacco riuscito non equivale automaticamente a sicurezza inadeguata
Uno dei principi più significativi affermati dalla Corte è che una divulgazione non autorizzata di dati personali o un accesso non autorizzato da parte di terzi non consentono, per il solo fatto di essersi verificati, di concludere che le misure tecniche e organizzative adottate dal titolare non fossero adeguate.
L’art. 32 GDPR non impone un risultato di invulnerabilità assoluta.
La sicurezza è costruita secondo un approccio basato sul rischio.
Stato dell’arte, costi di attuazione, natura, oggetto, contesto e finalità del trattamento devono essere considerati insieme alla probabilità e alla gravità dei rischi per i diritti e le libertà delle persone fisiche.
L’adeguatezza delle misure deve pertanto essere valutata in concreto.
Ne deriva che due affermazioni apparentemente opposte risultano entrambe insufficienti: «L’attacco è riuscito, quindi la sicurezza era inadeguata» e «È stato un hacker, quindi l’organizzazione non è responsabile».
La condotta criminale del terzo non risolve da sola il problema della responsabilità.
Occorre verificare il comportamento del titolare e l’adeguatezza delle misure adottate.
La sicurezza non viene giudicata esclusivamente dal risultato dell’attacco, ma dal modo in cui il rischio è stato governato.
Accountability: la domanda diventa «puoi dimostrarlo?»
La pronuncia assume particolare importanza quando affronta l’onere della prova.
La Corte collega il principio di responsabilizzazione previsto dall’art. 5, par. 2, GDPR agli obblighi posti dagli artt. 24 e 32.
Non è quindi sufficiente sostenere che l’organizzazione disponesse di policy, procedure e controlli.
Occorre poter ricostruire quali rischi erano stati individuati; quali misure erano state adottate; perché erano state considerate adeguate; se erano effettivamente implementate e operative.
L’accountability assume così anche una dimensione probatoria.
Ed è proprio l’incidente cyber a sottoporre questo sistema alla prova dei fatti.
Che cosa avevamo previsto? Che cosa è realmente accaduto? Come abbiamo reagito?
Con quali evidenze possiamo dimostrarlo?
Dal principio giuridico al protocollo operativo
La C-340/21 può essere utilizzata come punto di partenza per costruire una risposta all’incidente orientata all’accountability dimostrabile.
Il primo obiettivo è naturalmente contenere l’attacco. Ma contenere non dovrebbe significare distruggere indiscriminatamente ciò che servirà successivamente a comprenderlo.
Isolamento dei sistemi, revoca delle credenziali, chiusura delle sessioni, reinstallazione delle macchine e ripristino dei backup possono essere indispensabili per limitare gli effetti dell’incidente.
Queste operazioni devono però essere coordinate, quando le circostanze lo richiedono, con la necessità di preservare gli elementi utili alla ricostruzione.
Log, alert, configurazioni, autenticazioni, comunicazioni, artefatti digitali e registrazioni delle attività compiute dagli operatori possono assumere un’importanza determinante.
«Abbiamo risolto il problema?» deve affiancarsi a:
«Siamo ancora in grado di dimostrare che cosa è successo?».
Prima ricostruire, poi concludere
Le prime ore successive alla scoperta di un incidente sono caratterizzate da un problema strutturale: si deve decidere rapidamente disponendo di informazioni incomplete.
Diventa pertanto fondamentale distinguere almeno quattro categorie: fatti accertati – evidenze disponibili – ipotesi investigative – informazioni ancora da verificare.
Affermare che «non vi è stata esfiltrazione di dati» è molto diverso dall’affermare che «allo stato delle evidenze disponibili non sono stati individuati indicatori di esfiltrazione».
La seconda formulazione rappresenta correttamente il livello di conoscenza raggiunto in quel determinato momento.
Anche la dimensione temporale assume particolare importanza.
Il momento dell’attacco, quello della registrazione dell’evento da parte di un sistema, quello della rilevazione da parte degli strumenti di sicurezza, quello dell’escalation interna e quello in cui l’organizzazione dispone di elementi sufficienti per qualificare l’incidente possono essere differenti.
Una timeline multi-fonte dell’incidente, con normalizzazione delle timezone e indicazione della provenienza di ciascun evento, può quindi diventare contemporaneamente strumento investigativo, di governance e di accountability.
Quando l’incidente cyber diventa personal data breach
Non ogni incidente informatico costituisce automaticamente una violazione di dati personali.
Il GDPR definisce il personal data breach come una violazione di sicurezza che comporta accidentalmente o illecitamente distruzione, perdita, modifica, divulgazione non autorizzata o accesso ai dati personali.
La violazione può pertanto compromettere riservatezza, integrità o disponibilità dei dati.
Quando l’incidente coinvolge dati personali, alla risposta tecnica deve affiancarsi un Data Breach Assessment.
Occorre valutare natura e portata della violazione, categorie e volume dei dati, interessati coinvolti, possibili conseguenze e misure adottate per ridurne l’impatto.
Il titolare deve notificare la violazione all’autorità di controllo senza ingiustificato ritardo e, ove possibile, entro 72 ore dalla conoscenza, salvo che sia improbabile che la violazione comporti un rischio per i diritti e le libertà delle persone fisiche.
In presenza di rischio elevato può inoltre sorgere l’obbligo di comunicazione agli interessati.
Un elemento merita particolare attenzione: la documentazione della violazione prescinde dalla decisione di notificare.
Documentare non soltanto l’incidente, ma le decisioni
La documentazione dovrebbe riguardare non soltanto gli eventi tecnici. Dovrebbe consentire di ricostruire anche il processo decisionale.
Perché un determinato sistema è stato isolato? Perché è stato autorizzato il ripristino?
Su quali elementi si è ritenuto che fossero coinvolti dati personali? Come è stato valutato il rischio per gli interessati?
Perché si è deciso di notificare oppure di non notificare l’Autorità?
Ogni decisione significativa dovrebbe poter essere collegata alle informazioni disponibili in quel momento, alle evidenze considerate, ai soggetti coinvolti nella valutazione e alla motivazione adottata.
L’Incident Response genera così una seconda categoria di evidenze: non soltanto evidence of incident, ma anche evidence of decision.
Il ripristino non chiude l’incidente
Il ritorno alla normale operatività non dovrebbe coincidere automaticamente con la chiusura dell’incidente.
Dopo il recovery occorre individuare, per quanto possibile, la root cause, verificare l’efficacia delle azioni correttive, individuare eventuali debolezze tecniche e organizzative e aggiornare il risk assessment.
L’incidente dovrebbe quindi alimentare un ciclo di miglioramento: Contain → Preserve → Reconstruct → Assess → Decide → Recover → Learn. Una funzione attraversa tutte le fasi: DOCUMENT.
La gestione dell’incidente diventa così parte di un processo più ampio di Incident Readiness: preparare l’organizzazione non soltanto a reagire tecnicamente, ma a prendere decisioni tempestive e verificabili in condizioni di incertezza.
Verso una cybersecurity accountability operativa
La C-340/21 non afferma che un’organizzazione vittima di un cyberattacco sia automaticamente esente da responsabilità. Il verificarsi dell’attacco non dimostra, da solo, l’inadeguatezza delle misure di sicurezza.
Queste devono essere valutate concretamente alla luce del rischio e il titolare deve essere in grado di sostenere probatoriamente l’adeguatezza delle proprie scelte.
La pronuncia permette quindi di formulare un concetto operativo di cybersecurity accountability: non dimostrare che l’incidente fosse impossibile, ma poter dimostrare che il rischio era stato adeguatamente governato prima dell’attacco e che, una volta verificatosi l’incidente, la risposta è stata tempestiva, proporzionata, documentata e verificabile.
La sicurezza assoluta non esiste.
La capacità di spiegare – e soprattutto di provare – come il rischio sia stato governato può invece essere costruita.
