Molte discussioni ha generato la recente sanzione di 50.000 euro all’Associazione Rousseau, con il provvedimento del Garante Privacy del 4 Aprile 2019 (i), per problemi di sicurezza relativi alla gestione del noto sistema di e-voting.
Pur non volendo in questa sede entrare nel merito della correttezza del provvedimento, è interessante analizzare quali siano le verifiche e i rilievi effettuati in sede ispettiva, come riportate nel provvedimento, per capire se vi siano elementi da cui le aziende possano trarre lezioni, adottando conseguenti misure interne di controllo e di prevenzione.
Tipologia di verifiche effettuate
Prima di tutto, riepiloghiamo di seguito in sintesi le principali tipologie di misure di sicurezza che, secondo la valutazione del Garante Privacy, avrebbero dovuto essere realizzate, come desunte da quanto indicato nel provvedimento del 4 Aprile (i) di cui abbiamo parlato.
E’ bene comunque tenere presente che quanto rilevato appartiene allo specifico contesto in cui le verifiche sono state effettuate, e potrebbero essere diverse in contesti differenti, soprattutto su trattamenti di dati personali con altre finalità, gestiti in ambienti differenti e con livelli di rischio meno elevati.
Misure di Sicurezza del Data Center
- Sicurezza perimetrale / vulnerability assessment
Dopo aver identificato le principali Vulnerability dei sistemi, quelle classificate come Critiche, Alte e Medie, devono essere risolte prima di rendere il servizio accessibile agli utenti. - Robustezza dei sistemi di memorizzazione delle Password
L’encryption delle Password debole non è adatta per applicazioni ad alto rischio.
In tal caso è opportuno utilizzare un meccanismo di encryption forte. - Obsolescenza dei sistemi , che rendono impossibili applicare patch di sicurezza
Sistemi obsoleti rendono difficoltoso, se non impraticabile, il Patching dei sistemi, con conseguente diminuzione del livello generale di sicurezza.
Gestione dei Rischi
- Minimizzazione dei rischi per gli utenti
Le misure adottate per la minimizzazione dei rischi per gli utenti, che dovrebbero cancellare o trasformare in forma anonima i dati identificativi delle persone dopo il trattamento, devono essere sufficienti. La rimozione parziale (magari del solo numero telefonico), non elimina totalmente il rischio che l’utente possa essere identificato da altri particolari, soprattutto in presenza di ulteriori identificativi univoci (ID utente).
Misure di Gestione delle utenze Privilegiate
- Log di sistema:
Il tracciamento su log di sistema (Database log; Application Logs ; Raccolta e correlazione dei logs, protezione dei logs raccolti) relativi ad attività monitorate ( ad esempio failed login, login successful , richieste di estrazioni dati da database, richieste di modifica / cancellazione dati , ..) non copre tutte le situazioni critiche. - Utenze Privilegiate condivise
Le utenze con privilegio di Amministrazione sono condivise tra più utenti, rendendo impossibile risalire alle responsabilità precise di chi ha fatto cosa. - Misure di Auditing, per controllare le attività svolte dagli utenti privilegiati
L’assenza di capacità di auditing degli utenti privilegiati, ed anche, la mancata generazione di eventi funzionali all’auditing degli stessi, eludono le verifiche successive, ed espongono a potenziali rischi di violazione dei dati personali senza possibilità di controllo. - Mancata separazione delle attività di Amministrazione per aree definite
Se le utenze privilegiate possono accedere a più aree, impedendo di attribuire le azioni a un determinato incaricato, il titolare viene privato della possibilità di controllare l’operato di tali utenze, creando un rischio rilevante.
Valutazione del rischio e misure di sicurezza
Prima di tutto, è necessario chiarire quanto il Trattamento oggetto del provvedimento del 4 Aprile (i) sia particolarmente delicato, oltre a coinvolgere un numero di utenti elevato, e per questi motivi è stato considerato dal Garante come particolarmente a rischio.
Non avendo riscontrato misure di sicurezza e protezione degli utenti adeguate a tale rischio, il Garante, ha sanzionato il responsabile del trattamento, cioè l’Associazione Rousseau, considerandola responsabile della mancata attuazione di tali misure adeguate per la sicurezza e protezione degli utenti ( Ex Art. 32 e 83 ).
Inoltre il Garante ingiunge, ai sensi dell’Art, 58, sia al Titolare del trattamento sia al Responsabile, di attuare tutte le misure di sicurezza sopra indicate, e, in aggiunta, di realizzare una valutazione di impatto per l’analisi dei rischi.
La valutazione di impatto sulla privacy (Privacy Impact Assessment), è elemento fondamentale durante la fase di progettazione per identificare i rischi sia relativi all’applicazione che all’intero sistema, ovverosia, l’intera “catena del trattamento”.
Non deve essere limitata, quindi, ai soli aspetti dell’applicazione (in questo caso quella di eVoting) ma anche a tutto il contesto di elaborazione ed alle misure di sicurezza e auditing messe in opera per garantire la sicurezza dell’intero ambiente in cui l’applicazione viene eseguita durante tutto il ciclo di vita della applicazione stessa.
Pur essendo obbligatoria solo in presenza di rischi elevati per le persone, è comunque una “best practice” anche quando potrebbe sembrare non necessario.
Il Privacy Impact Assessment, infatti, è utile anche per rendersi meglio conto dell’adeguatezza delle misure di sicurezza adottate rispetto al trattamento, anche in presenza di rischi non elevati.
E’ da notare che molte aziende quando realizzano la valutazione di impatto sulla privacy, tendono a confondere varie tipologie di rischio, tutte valide, ma spesso con valenze diversa rispetto al rischio che corrono le persone fisiche.
Infatti, non di rado capita che si tenda a considerare molto rilevante il rischio per la sicurezza del proprio Centro Servizi (Security Risk) e il relativo rischio corso dal proprio business (Business Risk) anche ai fini del rischio privacy.
Mentre, secondo GDPR, ci si dovrebbe piuttosto concentrare sul rischio che corrono durante il ciclo di vita dell’intero trattamento i soggetti del trattamento in relazione ai possibili impatti alla propria libertà personali ed ai propri diritti fondamentali.
E’ questa l’unica valutazione che conti realmente ai fini del GDPR, per valutare l’adeguatezza delle misure di sicurezza tecniche e organizzative.
Solo dopo una valutazione corretta del Rischio Privacy, sarà possibile capire quali misure di sicurezza siano veramente necessarie e adeguate per proteggere i dati trattati, ed eventualmente accettare il rischio residuo (la parte di Rischio che non è possibile eliminare, ridurre o mitigare).
A proposito di rischio residuo, è ormai sempre più diffusa l’abitudine di dotarsi di polizze assicurative che coprano i rischi residui, cosiddetti rischi cyber, e alcune di esse coprono alcuni aspetti legati alla mancata protezione dei dati personali, o mancanza di conformità alle leggi sulla privacy.
Possono essere ottime soluzioni, per ridurre i propri rischi, quindi siano benvenute.
Attenzione però a cautelarsi facendo un’accurata valutazione della propria situazione e del proprio livello di rischio, assicurando solo le voci per cui il rischio residuo sia elevato, per evitare di caricarsi di costi assicurativi più elevati di quanto sarebbe necessario.
Una baseline di sicurezza in linea con la valutazione del rischio
Alcune delle misure di sicurezza evidenziate dal Provvedimento del Garante (i), sono misure che possono essere adottate direttamente dal Titolare, nel caso in cui gestisca direttamente il Trattamento, ma nel caso di specie, sembrerebbero essere state delegate al Responsabile ed a più subResponsabili (tra cui il Service Provider).
Ciò premesso, le misure di sicurezza adottate devono essere robuste, con un livello di sicurezza tanto più elevato quanto più è alto il rischio per le persone fisiche interessate dalla tipologia di trattamento, (Titolare e Responsabile del Trattamento mettono in atto misure tecniche e organizzative adeguate per garantire un livello di sicurezza adeguato al rischio, come definito all’Art. 32) .
E’ il Titolare che, dopo la valutazione di impatto sul rischio privacy, ha la responsabilità di definire adeguatamente i contratti di servizio (che costituiscono le istruzioni vincolanti) verso il Responsabile del Trattamento e, per suo tramite, verso i subResponsabili (Service Provider), ed eventualmente modificarli per adattare il livello di sicurezza alle proprie esigenze ed a quelle delle persone interessate dal Trattamento.
Il Titolare in effetti ha tutte le possibilità per poter tranquillamente cambiare l’intera catena di fornitura fino al Service Provider, nel caso in cui le misure da essa realizzate non fossero adeguate.
Per questo motivo, il Titolare, quando sceglie i Responsabili del Trattamento, dovrebbe avere già ben chiara in mente quella che io chiamo la “baseline di sicurezza” appropriata per i livelli di Rischio Privacy di cui abbiamo parlato poc’anzi.
La “baseline di sicurezza” rappresenta, in sostanza, l’insieme di misure di sicurezza tecniche ed organizzative adeguato rispetto alla Azienda, alla tipologia di trattamento, alla tipologia di dati personali , ai volumi di dati trattati ed al livello di rischio, una volta che il livello di rischio sia stato completamente valutato, ed eventuali misure di riduzione del rischio siano state adottate .
Il Titolare ha quindi l’obbligo di contrattualizzare con i Responsabili del Trattamento, e verificarne l’applicazione, che le misure di sicurezza lungo tutta la catena di fornitura (fino al Service Provider ) siano in linea (o di livello superiore) con la propria “Baseline di Sicurezza”, per la protezione dei dati, anche quando vi siano diverse entità legali coinvolte.
Per questo è opportuno che la “Baseline di sicurezza” che va utilizzata per il trattamento sia nota prima della stesura degli accordi contrattuali, per poterne includere i requisiti verso i fornitori.
L’attribuzione delle responsabilità, quindi, può dipendere molto dalla formulazione dei contratti di fornitura e dagli impegni in termini di adeguatezza delle misure di sicurezza che i vari Responsabili (o subResponsabili) del Trattamento prendono nei confronti del Titolare.
Ma anche dai meccanismi di controllo che il Titolare attua, o non attua, per verificarne l’effettività.
Senza meccanismi di controllo e verifica, la gestione dei soli aspetti contrattuali copre solo gli aspetti formali, ma non copre gli aspetti “sostanziali” dei meccanismi di protezione delle persone fisiche .
Nel caso in cui il Responsabile (subResponsabile) del Trattamento sia un Service Provider, esso ha, a mio avviso, comunque degli obblighi aggiuntivi impliciti sul mantenimento di un livello generale accettabile di Sicurezza all’interno dell’infrastruttura del proprio Centro Servizi.
In particolare, il service provider deve garantire ai clienti che l’intera gestione non venga compromessa da un livello di sicurezza inferiore applicato ad altri server o ad altre applicazioni proprie o di altre aziende clienti, che sono residenti nello stesso centro servizi, o da comportamenti inappropriati dei propri dipendenti o collaboratori, il cui controllo è al di fuori delle possibilità di controllo delle Aziende Clienti, ma compromette la sicurezza generale del centro servizi.
A questo scopo il service provider a mio avviso, deve applicare tutte le precauzioni possibili (e ragionevoli) per evitare che la compromissione di un sistema, comprometta altri sistemi, anche se l’azienda cliente non l’avesse chiesto esplicitamente nel contratto.
La non corretta gestione delle misure di sicurezza del Centro Servizi stesso, può quindi, a buon diritto, già considerarsi di per sé una violazione delle condizioni di esercizio concordate con tutti i Titolari (aziende clienti) che affidano al Service Provider le loro applicazioni ritenendo il Centro Servizi “sicuro” (come previsto dall’Art.32 , Sicurezza del Trattamento” ).
Protezione dei dati lungo tutta la Supply Chain
Quando si sceglie un fornitore (Service Provider) per gestire l’hosting dei propri sistemi, spesso non si verificano che le condizioni di sicurezza assicurate dal fornitore siano in linea con le nostre esigenze.
E come si determinano quali siano in realtà le nostre esigenze di sicurezza?
E’ semplice: quelle relative alla “Baseline di Sicurezza”, di cui abbiamo parlato poc’anzi .
Una corretta valutazione del rischio privacy, e, a seguire, delle “baseline di sicurezza” sono centrali per guidare poi tutto il processo di delivery ed operation della propria applicazione in hosting, assicurandone poi l’implementazione ed una corretta gestione nel tempo ?
Il ragionamento vale ovviamente per tutti i casi di fornitura in cui una terza parte gestisce per nostro conto dei dati personali.
Ad ogni modo è importante che il Titolare condivida con il Responsabile del Trattamento, e prima della messa in opera del servizio, le misure di sicurezza che dovranno essere applicate e verifichi preliminarmente l’effettiva adeguatezza delle misure disponibili presso il Provider con le proprie esigenze.
Verifica della sicurezza dei trattamenti tramite monitoraggio e auditing
Come prima anticipato, vi sono una serie di attività che ogni Titolare del Trattamento dovrebbe prevedere per il monitoraggio costante e l’auditing non solo sulla corretta attuazione delle misure di sicurezza, ma anche come misura di prevenzione di comportamenti illeciti o non appropriati dal personale.
Tali misure, rammentateci in questa occasione dalla tipologia di verifiche effettuate dal Garante, sono normalmente considerate “best practice” ed inserite in diverse standardizzazioni di controlli di sicurezza (ad esempio ISO27001) .
Rientrano in questa casistica sia i vulnerability test, sia le verifiche periodiche sul livello di patching di sicurezza ed infine il monitoraggio sull’utilizzo delle utenze privilegiate.
Vale per le misure di verifica sulla sicurezza del trattamento, quanto detto prima per la loro implementazione.
Ogni Titolare, infatti, pur essendone responsabile, può definire se gestire il monitoraggio dell’intera catena di trattamento in proprio o demandare tutta o parte dell’attività di tale monitoraggio al Responsabile o a subResponsabili.
Tipicamente è consigliabile demandare, anche contrattualmente, per quanto possibile il monitoraggio di attività legate all’infrastruttura al Service Provider di turno che la gestisce.
Possono entrare in questa categoria, sia i controlli legati al Vulnerability test, che il Patching degli ambienti di sistema (infrastruttura, Sistemi Operativi, Virtual Machines , ..) , ma anche il monitoraggio dei comportamenti delle Utenze Privilegiate di Sistema.
E’ opportuno assicurarsi nel contratto che i componenti dell’infrastruttura utilizzati presso il Service Provider siano aggiornabili, e siano aggiornati periodicamente, e la Vulnerabilità da attacchi esterni o da comportamenti illeciti dall’interno della infrastruttura sia verificata e monitorata nel tempo, allo scopo di mantenere un livello di sicurezza adeguato nel tempo dell’intera infrastruttura che sia consistente per tutti i sistemi in uso.
Per quanto riguarda il monitoraggio delle attività legate alle applicazioni, è consigliabile invece che sia demandato al Gestore dell’Applicazione (in genere Responsabile del Trattamento per conto del Titolare).
Rientrano in questa categoria anche il monitoraggio dei comportamenti delle Utenze Privilegiate Applicative, ma anche la verifica del Patching di Sicurezza Applicativo.
Solo chi gestisce l’applicazione, infatti, può eventualmente confermare se sia possibile, realizzare il Patching di scurezza per moduli usati dall’applicazione senza che questo crei impatti per le funzionalità applicative (ad esempio qualora sia utilizzato software Open Source o di terze parti).
In tutti i casi, a chiunque tali misure siano state demandate, il Titolare ha il dovere di assicurarsi che tali misure siano attuate regolarmente.
E’ fondamentale quindi che il Titolare le inserisca il più esplicitamente possibile come requisiti all’interno dei contratti con la propria catena di fornitura, specificando sia la tipologia di Monitoraggio e Auditing da effettuare, la Tipologia dei report che devono essere forniti per assicurarne il funzionamento e la periodicità dell’aggiornamento delle stesse.
Nel caso invece in cui il Titolare eserciti tali funzioni direttamente, occorre invece prevedere policy di comportamento che le regolino, ed assegnare uno o più team di persone con skills adeguati per effettuarle.
Inoltre, occorre creare un sistema interno di reporting, che consenta di controllare, e dare evidenza, che questi controlli vengono effettuati .
Che lezioni trarre dalla multa a Rousseau
Indipendentemente dalla propria opinione personale sull’opportunità delle sanzioni, ognuno può riflettere se le misure di sicurezza adottate al proprio interno, rispondano effettivamente ai requisiti sin qui elencati.
Inizialmente, è fondamentale identificare il livello di rischio corso dalle persone fisiche durante il trattamento dei loro dati personali.
In seguito è importante creare, con una buona dose di consapevolezza e competenza, una propria “Baseline di Sicurezza”, adatta al livello di rischio dei propri trattamenti, né sovradimensionata, e quindi probabilmente irragionevolmente costosa, né sottodimensionata, e quindi probabilmente inefficace.
Estendendo il discorso ai numerosi requisiti posti dal GDPR, che sono stati solo marginalmente toccati da questa breve esposizione, è opportuno lavorare molto sui contratti con i fornitori, e rivederli di frequente, perché contengano indicazioni quanto più precise possibile sulle misure di Sicurezza che ci si aspetta che siano implementate.
Infine non è opportuno limitarsi alla stesura del contratto.
E’ auspicabile accompagnare le indicazioni sui requisiti a un sistema di verifica, che includa i controlli necessari per assicurarsi che le misure richieste vengano implementate, perché in ultima analisi, è il Titolare ha l’obbligo di verificare se i fornitori e i Service Provider abbiano misure di sicurezza adeguate alle proprie esigenze.
