Key4biz

Modelli organizzativi per la gestione dei rischi informatici. Il caso Rousseau

La conformità del trattamento dei dati personali alla disciplina del regolamento 2016/679 (e ad altre disposizioni del diritto europeo o nazionale) riposa sull’adozione di un modello organizzativo in cui, seguendo il noto princìpio della divisione del lavoro di Adam Smith, il titolare e il responsabile del trattamento definiscono compiti e funzioni connessi al trattamento per il cui svolgimento vengono opportunamente designate figure interne ed esterne all’organizzazione (responsabili del trattamento, amministratori di sistema, persone autorizzate al trattamento). La designazione – peraltro richiesta dal nuovo d.lgs. 196/2003 all’art. 2-quaterdecies nel caso in cui i citati titolari e responsabili prevedano un’organizzazione delle attività di trattamento[1] – appare opportuna sotto il profilo dell’accountability, rappresentando la testimonianza di uno sforzo organizzativo compiuto per conseguire i predetti obiettivi di compliance. Il d.lgs. 231/2001, con la previsione dell’organismo di vigilanza per l’attuazione, da parte dell’ente, del Modello di Organizzazione, Gestione e Controllo (art. 6, c.1, lett. b) ), ci offre un ulteriore spunto circa l’opportunità di costituire una struttura di controllo del funzionamento del modello organizzativo per la protezione dei dati, e dunque dello stato di adeguamento alla normativa. In questa prospettiva, si delineano ipotesi di costituzione di “gruppi di lavoro privacy” indipendenti (con componenti esterni all’organizzazione del trattamento) o di organi di staff collocati in posizioni di terzietà, in cui cioè non vengono determinate le finalità e i mezzi del trattamento; strutture che peraltro sono chiamate a supportare la funzione del data protection officer nei casi in cui una tale figura sia stata designata dal titolare o dal responsabile del trattamento[2]. Il modello organizzativo privacy (insieme alla struttura di controllo) descrive pertanto un assetto aziendale preordinato allo svolgimento della propria attività in chiave data protection, rappresentando in tale prospettiva un’evoluzione culturale dell’organizzazione con effetti favorevoli sul piano dell’immagine e dei requisiti di affidabilità attesi o richiesti dall’esterno, ad esempio, nei rapporti con le associazioni dei consumatori, nelle attività di public affairs, nelle procedure di gara.

Profili di sicurezza del modello organizzativo data protection

Con riguardo al profilo della sicurezza dei trattamenti, il modello dovrebbe integrare processi, routine organizzative e regolamenti interni a supporto della gestione dei rischi, connotandosi pertanto anche come governance del rischio; sotto questo aspetto, le attività operative principali indicate dalla prassi e dalla letteratura tecnica comprendono (i) l’individuazione degli asset informatici che intervengono nelle attività di trattamento e la valutazione delle loro vulnerabilità, (ii) l’individuazione delle minacce incombenti sui sistemi di Ict (con cui i dati sono trattati), (iii) la valutazione del rischio (nelle sue componenti di probabilità e gravità delle conseguenze) alla luce delle misure di sicurezza esistenti, per poi (iv) determinare gli eventuali interventi (misure) di variazione che, in linea con le previsioni dell’articolo 32 del regolamento, possano garantire un livello di sicurezza adeguato al rischio[3]. Il (sintetico) processo operativo appena tratteggiato lascia intuire il suo carattere dinamico in ragione del fatto che il “rischio residuo”, ossia il rischio a cui sono esposti i dati con l’applicazione delle ultime misure di sicurezza, va necessariamente rivalutato in relazione a possibili modifiche del quadro di riferimento (cambiamenti organizzativi, evoluzione tecnologica, nuove modalità di trattamento, passaggio da dati comuni a dati particolari)[4].

I processi e le procedure che caratterizzano il modello organizzativo per gli aspetti di sicurezza vanno, altresì, integrati in relazione alla gestione dei casi di violazione che possono riguardare i dati personali, in ragione del fatto che anche l’adozione di misure di sicurezza efficaci non esclude che la minaccia possa verificarsi producendo un impatto; l’intervento ex post, dunque, va sempre pianificato in considerazione di un rischio che non è completamente e permanentemente eliminabile. La gestione delle violazioni (in cui la minaccia si è verificata, ma va accertato se e in che misura questa ha interessato dati personali) si caratterizza pertanto come capacità di reazione dell’organizzazione, implicando la costituzione di una data breach unit per il coordinamento di un complesso di attività volte a rilevare gli eventi e i comportamenti (alert, tracciamento degli accessi)e valutarne le caratteristiche (apertura di una scheda descrittiva) per decidere in merito alla loro registrazione[5], all’attivazione di protocolli di risposta e alle comunicazioni all’autorità di controllo e agli interessati. Una tale gestione è tanto più complessa in relazione all’esternalizzazione del trattamento in cui gli accordi di appalto e subappalto di operazioni sui dati personali coinvolgono più responsabili esterni del trattamento. Simili situazioni richiedono l’integrazione nel modello organizzativo di attività di gestione e coordinamento dei casi di violazione della sicurezza esterni al titolare – che avvengono, cioè, presso i responsabili o sub-responsabili del trattamento – affinché lo stesso possa venirne a conoscenza nei tempi più brevi, per poi valutare come procedere nel quadro delle previsioni degli articoli 33 e 34 del regolamento[6]. Con riguardo alla valutazione del rischio post-violazione che, nell’ambito di tale quadro, il titolare è tenuto a svolgere, merita osservare come la disponibilità di una preventiva analisi del rischio – ad esempio, quella che ricorre nella valutazione di impatto del trattamento sulla protezione dei dati – possa rappresentare una fonte utile da cui derivare il rischio che consegue a una violazione dei dati personali; ben inteso la necessità di effettuare una valutazione aggiuntiva in relazione alle specifiche circostanze della violazione[7].

Il caso della piattaforma Rousseau

Il caso Rousseau – la piattaforma tecnologica del Movimento 5 Stelle utilizzata, tra l’altro, per svolgere operazioni di votazione – mostra come una gestione ‘occasionale’ dei processi sottostanti la valutazione dei rischi, priva di un modello organizzativo di riferimento, possa essere all’origine delle vulnerabilità dei sistemi di Ict del Movimento 5 Stelle che, con ogni probabilità, sono state sfruttate per compiere l’intrusione informatica e determinare la violazione dell’agosto del 2017[8].

Sotto questo profilo, l’attività ispettiva del Garante ha fatto emergere un quadro della sicurezza dei siti web gestiti dal Movimento caratterizzato da misure tecniche obsolescenti e da misure organizzative che non garantivano un apprezzabile livello di riservatezza agli iscritti alla piattaforma di e-voting. Le policies adottate ammettevano l’uso di chiavi di identificazione di lunghezza inferiore a otto caratteri che, in tal modo, risultavano facilmente esposte ad azioni di tipo brute force[9]; le stesse politiche sono apparse limitate con riguardo all’auditing informatico in ragione del mancato tracciamento degli accessi effettuati dagli amministratori di sistema e la mancata configurazione di profili di autorizzazione differenziati e limitati ai soli trattamenti e dati necessari in relazione agli specifici ambiti di operatività.

Conclusioni

La vicenda appena tratteggiata, come altre (si pensi ai casi Ashley Madison del 2015, Heartbleed del 2014, Target del 2013), lasciano intuire come l’assenza di una governance del rischio ovvero l’adozione di soluzioni destrutturate e approssimate siano l’immagine di una vulnerabilità di tipo organizzativo prima ancora che tecnico-strumentale; e come tale condizione possa generare impatti sulla sfera giuridica delle persone (diritti e libertà) o su taluni loro aspetti e interessi comunque significativi (economico-finanziario, fisico, psicologico) che possono anche determinare azioni legali da parte degli interessati. Sotto altro profilo – se pure non rilevante ai fini del regolamento – non vanno sottaciute le conseguenze sulle stesse aziende (e pubbliche amministrazioni) derivanti dalla mancanza di modelli organizzativi privacy. A tal riguardo, il caso Yahoo! – la data breach più importante della storia (oltre un miliardo di account violati) – é emblematico; gli attaccanti avrebbero sottratto nomi, indirizzi e-mail, numeri di telefono, date di nascita, password criptate e in qualche caso anche domande di sicurezza cifrate o in chiaro, con le relative risposte; tali dati sarebbero stati messi in vendita nel dark web, per circa 300.000 dollari. Anche a causa di questa violazione (e di altre precedenti, non comunicate tempestivamente dall’azienda), secondo alcuni analisti finanziari la quotazione di Yahoo!, nell’ambito dell’acquisizione da parte di Verizon, avrebbe subìto un ribasso di circa 350 milioni di dollari[10].

La governance del rischio descrive un aspetto centrale del modello organizzativo per la protezione dei dati personali delineato dal regolamento; da essa promanano le decisioni sul trattamento (tecnologie utilizzate, valutazione di impatto) ovvero, nel caso di una violazione dei dati, sulla notifica al Garante e la comunicazione agli interessati, nonché sugli accordi con gli operatori esterni che dovrebbero trattare dati per conto del titolare. Nella prospettiva del regolamento, un tale modello è destinato a diventare il driver di una cultura organizzativa della data protection che, dal vertice alle unità operative, pone al centro il rischio per i diritti e le libertà degli interessati attuando processi strutturati e mezzi del trattamento che incorporano nativamente misure di anonimizzazione o pseudonimizzazione o, ancora, di minimizzazione dei dati.


[1] Sul punto, il primo comma dell’art. 2-quaterdecies stabilisce che “Il titolare o il responsabile del trattamento possono prevedere, sotto la propria responsabilità e nell’ambito del proprio assetto organizzativo, che specifici compiti e funzioni connessi al trattamento di dati personali siano attribuiti a persone fisiche, espressamente designate, che operano sotto la loro autorità.”.

[2] Merita al riguardo osservare come la letteratura abbia accostato la funzione del data protection officer a quella dell’organismo di vigilanza ex d.lgs. 231, in ragione dei compiti di sorveglianza che gli sono stati attribuiti dal regolamento, ponendo tra l’altro il quesito circa una possibile sovrapposizione dei ruoli in quelle realtà in cui è stato costituito un Odv. Sul punto si veda, tra gli altri P. Ghini, Data protection officer: ODV per la privacy?, 3 settembre 2015, https://www.tavoli231.it/single-post/2015/09/03/Data-protection-officer-ODV-per-la-privacy A. Sannoner, Il rapporto tra Organismo di Vigilanza e il nuovo GDPR, 14 settembre 2018, https://www.portale231.com/il-rapporto-tra-organismo-di-vigilanza-e-il-nuovo-gdpr/

[3] Sappiamo, al riguardo, che l’art. 32 non prescrive “misure minime” ma elenca alcune misure attuative, segnatamente (i) la pseudonimizzazione e la cifratura dei dati personali, (ii) la capacità di assicurare su base permanente la riservatezza, l’integrità, la disponibilità e la resilienza dei sistemi e dei servizi di trattamento, (iii) la capacità di ripristinare tempestivamente la disponibilità e l’accesso dei dati personali in caso di incidente fisico o tecnico, (iv) una procedura per testare, verificare e valutare regolarmente l’efficacia delle misure tecniche e organizzative al fine di garantire la sicurezza del trattamento.

[4] Si pensi, ad esempio al disegno di legge appena approvato in via definitiva recante “Interventi per la concretezza delle azioni delle pubbliche amministrazioni e la prevenzione dell’assenteismo” in virtù del quale, ai fini della verifica dell’osservanza dell’orario di lavoro, le amministrazioni pubbliche (di cui all’articolo 1, comma 2, del decreto legislativo n. 165/2001) dovranno introdurre sistemi di identificazione biometrica e di videosorveglianza in sostituzione dei diversi sistemi di rilevazione automatica, attualmente in uso. Una tale modifica del trattamento di dati personali implica una rivalutazione del rischio residuo alla luce dell’introduzione di dati biometrici precedentemente non raccolti.

[5] È il caso previsto dall’art. 33, par. 5 del regolamento che, in altre parole, stabilisce l’obbligo per i titolari del trattamento di costituire un registro delle violazioni dei dati personali, indipendentemente dalla necessità di comunicazione all’autorità di controllo e agli interessati.

[6] A tal riguardo, va ricordato che, nel caso di violazione di dati personali, il responsabile del trattamento è tenuto a informare il titolare dopo essere venuto a conoscenza della violazione stessa (art. 33, par. 2); il che lascia ragionevolmente intendere che sia il responsabile del trattamento ad attuare le misure tecniche e organizzative per la rilevazione delle violazioni della sicurezza e le loro eventuali implicazioni sui dati personali.

[7] Al riguardo, si veda Gruppo di lavoro articolo 29 per la protezione dei dati, Linee-guida sulla notifica delle violazioni dei dati personali ai sensi del regolamento (UE) 2016/679, p. 12.

[8] Cfr. Garante per la protezione dei dati personali, Provvedimento su data breach – 21 dicembre 2017, Provvedimento n. 548/2017, https://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-dis

play/docweb/7400401; Provvedimento su data breach – 4 aprile 2019, Provvedimento n. 83/2019, https://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/9101974

[9] Il tempo necessario per compiere l’attacco aumenta esponenzialmente all’aumentare della lunghezza della password e della tipologia di caratteri. Per proteggersi da questo tipo di attacco è dunque opportuno utilizzare password molto lunghe e complesse contenenti caratteri maiuscoli, minuscoli, numerici, simboli e spazi. In tal modo il tempo necessario per completare l’attacco potrebbe passare da pochi minuti a settimane o addirittura anni secondo la velocità del calcolatore che esegue i tentativi e il tempo di risposta del server o servizio che si sta attaccando. Sull’argomento si veda A. Carriero, Virus e sicurezza informatica: attacco Brute Force, https://www.matematicamente.it/informatica/informatica-di-base/virus-e-sicurezza-informatica-at   Si veda anche R. Rijtano, Brute force: cosa sono, come fare e prevenire gli attacchi a forza bruta, https://www.cybersecurity360.it/nuove-minacce/brute-force-cosa-sono-gli-attacchi-a-forza-bruta-come-farli-e-prevenirli/

[10] Cfr. Clusit, Rapporto 2017 sulla sicurezza ICT, Milano, 2017, 16.

Exit mobile version