I provvedimenti del Garante contro Unicredit e NTT Data
Apr 09 2024 Riccardo AbetiIl doppio Provvedimento verso Unicredit (Provvedimento dell'8 febbraio 2024 [9991020]) e verso NTT Data (Provvedimento dell'8 febbraio 2024 [9991064]), è piuttosto articolato.
Si premette che chi scrive espone le proprie riflessioni allo stato delle fonti rappresentate dai Provvedimenti citati e senza aver preso alcuna cognizione delle memorie e dei documenti prodotti nell’ambito del procedimento innanzi al Garante.
A prima vista sembra che i Provvedimenti, autonomamente e in coordinamento reciproco, pecchino, in alcuni passaggi, di rigore logico.
Proviamo a esporre la dinamica dei fatti e dei rapporti. Analizziamo il tutto partendo dalla violazione:
> I sistemi di Unicredit hanno subito un attacco da cui è conseguita una violazione dei dati.
> Unicredit ha effettuato la notificazione al Garante ex art. 33 ritenendo, in un primo tempo, non necessaria la comunicazione agli interessati ex art. 34 del GDPR.
> Unicredit ha notificato la violazione in termini ma il Garante ha ravvisato nelle cause del “breach” la carenza di misure adeguate e la violazione dell’art. 5, par. 1, lett. f), del GDPR.
Prima considerazione personale, in linea di massima credo che si debba essere sempre molto cauti nel sanzionare un Titolare che ha fatto la notificazione perché, specie di fronte a vere e proprie “macchine da guerra” (in termini di sicurezza informatica), sanzionare un soggetto che adempie (chissà quanti data breach non vengono notificati) rischia di essere controproducente.
Tuttavia, visto il tipo di vulnerabilità, il numero di soggetti interessati (quasi 800000) e viste le potenziali conseguenze per i cittadini, credo che il Garante non potesse esimersi dal farlo.
Focalizzandoci sulla vulnerabilità, la stessa andrebbe approfondita (ma magari è stato fatto e non si evince questo dettaglio) per capire se le vulnerabilità erano: risalenti e facili da scoprire (come sembra).
Risalenti. Il fatto che la vulnerabilità sia stata provocata da una modifica del sistema può implicare, in un sistema complesso come quello di Unicredit, la necessità di un più o meno lungo processo di verifica.
Facili da scoprire. Il fatto che fosse “di facile scoperta” è la risposta alla domanda “bastava inserire una UserId con password sbagliata per vedere restituito nome, cognome e codice fiscale?”
Se la risposta a questa domanda è sì, il Titolare è colpevole di non averlo rilevato, dato l’apparato che dispiega, non solo in termini specificamente dedicati alla sicurezza IT ma anche, semplicemente, di utenti “interni”.
Rapporti tra i soggetti coinvolti
Analizzati i fatti, soffermiamoci sui rapporti tra i soggetti coinvolti. In apparenza abbiamo un titolare, Unicredit, un responsabile, UBIS, un sub-responsabile, NTT Data e un sub-responsabile “abusivo”, Truel IT. Questa non è la realtà ma l’apparenza di quanto si evince dai Provvedimenti.
Mi spiego meglio: se un titolare subisce un attacco, i responsabili che rilevano non sono tutti quelli che trattano i dati per suo conto ma coloro che lo supportano nella sorveglianza dell’infrastruttura e che possono e debbono rilevare una violazione.
Non so se UBIS fosse deputata in tal senso (ovvero alla sorveglianza dell’infrastruttura) ma NTT Data non lo era, neanche indirettamente (sempre allo stato di quanto ci è dato sapere).
Perimetro di attività
Vediamolo meglio analizzando i rispettivi perimetri delle attività. Unicredit titolare, sembra di capire, aveva designato UniCredit Services S.c.p.a. e questa, a sua volta, aveva designato NTT Data come sub-Responsabile.
Dunque, in virtù dell’accountability, a poco serve la contestazione che NTT non avesse rapporto con Unicredit.
Il punto semmai è l’oggetto dell’attività richiesta, sembra che Unicredit e il Garante analizzino il fenomeno e il coinvolgimento delle parti, prescindendo dall’effettivo trattamento dei dati da parte di NTT Data nell’ambito dell’esecuzione del Contratto tra le parti e, conseguentemente, mal attribuiscano gli obblighi che sorgono in virtù del DPA sottoscritto, l’attività è quella di condurre “sessioni di vulnerability assessment e penetration test” e non di “sorvegliare il sistema di Unicredit”.
Ecco che, guardando i rapporti e analizzando il perimetro di attività, NTT Data non è un responsabile pertinente rispetto alla violazione subita da Unicredit.
Malcostumi ricorrenti
Voglio fare un paio di considerazioni che sono utili per prevenire situazioni come quelle oggetto dei provvedimenti del Garante. Per prima cosa, è un malcostume ricorrente quello di utilizzare in fase di test, dati reali, in assenza di questa cattiva abitudine il DPA, probabilmente, non sarebbe stato neanche da sottoscrivere.
Altro malcostume che spesso contrappone Titolari e Responsabili, è quello secondo il quale il titolare si arroga il diritto di condurre audit su perimetri non inclusi nel Contratto di fornitura, cioè, per dirla in modo colloquiale, “il Responsabile accede per eseguire il proprio incarico, a un pacchetto di dati personali che tratterà con un PC residente presso il Titolare e il Titolare per tutta risposta si arroga il diritto di condurre audit su macchine, Data Center, strumenti e sedi, estranee al trattamento”.
Nel caso specifico, l’attività oggetto del DPA non era la sorveglianza del sistema Unicredit ma era l’applicazione di una serie di test e simulazioni in un ambiente che non è stato violato e, se anche fosse stato violato il dataset usato in fase di test, solo di quello avrebbe dovuto rispondere il responsabile/sub-responsabile.
Per questo è evidente che il DPA non poteva che vertere sul trattamento dei dati oggetto dell’attività e non anche “di tutti i dati trattati da Unicredit”.
Attenzione, se, invece, in modo scellerato, Unicredit ha fatto condurre i test sul sistema in produzione, facendo trattare a NTT Data dati personali in violazione di presupposti di legittimità ma anche del criterio di minimizzazione, necessità e pertinenza dei dati trattati, allora la portata della violazione della normativa vigente, da parte di Unicredit, è ancora più grave di quanto emerso dai Provvedimenti.
Natura dell’attività
Passando alla natura dell’attività commissionata a NTT Data, la lettura che ne viene data, sembra, forzatamente, ultronea. Anche a livello contrattuale, non credo che l’attività di NTT Data fosse di “verifica e allarme immediato”, un’attività periodica o estemporanea è di per sé priva di caratteristiche di immediatezza né si vede come un’attività di PT&VA debba o possa, improvvisamente, diventare veicolo per gestire l’emergenza.
A nulla rileva il fatto che NTT Data si sia impegnata a comunicare immediatamente secondo l’Annex 3 citato “l’obbligo, in caso di rilevamento di vulnerabilità con gravità di livello critical o high, di informare immediatamente il titolare al fine di consentire alla stessa una rapida rimozione di tali vulnerabilità (cfr. Annex 3 dell’agreement)”, infatti l’attività implica dei controlli e delle verifiche. Per affermare, in un report da inviare a un cliente, che una serie di rilevazioni rappresentino un certo livello di criticità, tale gravità deve essere rilevata effettivamente, pertanto solo alla consegna ufficiale del report si può parlare di comunicazione e solo se fosse stata preparato il documento in veste definitiva e non fosse, per qualche ragione, stato spedito si potrebbe parlare di carenza dell’immediatezza.
In altre parole, l’immediatezza, come peraltro sostiene NTT Data era sempre da intendersi a cognizione avvenuta ovvero a seguito dei vari passaggi di verifica di falsi positivi e quant’altro.
Ecco perché chi scrive suggerisce di approfondire e capire da quanto esistesse la vulnerabilità citata, inoltre andrebbe verificato sui piani di remediation di Unicredit, quanti giorni si prende la banca per porre rimedio alle criticità Gravi e Gravissime. Anzi, la verifica andrebbe condotta sia sui piani di remediation (teorici) che sulle carte/email/comunicazioni che dimostrano la discrasia tra i tempi programmati e l’effettiva gestione della criticità.
Questo perché non si fa sicurezza “con il senno di poi”.
Perché quello di Unicredit sembra trattarsi di un tentativo ex post di attribuire al fornitore (o almeno "condividere con il fornitore") una propria carenza nella “detection” degli attacchi.
Coinvolgimento di NTT Data
In questo scenario, il Garante contesta a NTT Data di aver “informato tardivamente Unicredit dell’avvenuta violazione dei dati personali e, pertanto, non avrebbe ottemperato all’obbligo di cui all’art. 33, par. 2, del Regolamento” ma ciò è privo di ogni fondamento di realtà dato che:
1) NTT Data non è venuta a conoscenza di alcuna violazione (dato che operava in ambiente di test);
2) l’unica violazione sulla quale NTT Data avrebbe avuto l’obbligo di “notifica”, era quella dei dati usati per il test, dato che era quello, in virtù del DPA, il perimetro di trattamento dei dati personali di NTT Data.
Insomma, se le cose stanno come sembra, il Provvedimento rappresenta, in questa parte, un bell’abbaglio per l’Autorità.
Di converso, non sono convinto che l’aver attribuito la “sub-responsabilità” a un terzo (come ha fatto NTT Data con Truel IT) senza avere l’autorizzazione del Titolare del trattamento, sia un “errore veniale” come sostiene NTT Data, in quanto l’attribuzione “abusiva” determina:
1) Un trattamento illegittimo perché privo di presupposto di legittimità;
2) Un rallentamento nella rilevazione (non avente tanto impatto in termini di trattamento dei dati quanto di adempimento del Contratto).
Concludendo
Per concludere, si ritiene utile dare evidenza alle indicazioni di miglioramento che emergono, in ogni caso, da questi Provvedimenti. Sicuramente non sottovalutare la necessità di mantenere una solida sequenzialità nella catena titolare-responsabile-sub-responsabile nonché una chiarezza sia del perimetro/oggetto del Contratto che del trattamento dei dati personali operato da ciascun attore.
Tale solidità viene minata da tante situazioni ed eventi, sicuramente la transnazionalità dei trattamenti non fa che aumentare la complessità (fenomeno che in questo caso non si è verificato ma che è spesso parte del problema della regolamentazione dei rapporti).
Nell’ottica dei Titolari le regolamentazioni “per eccesso” non sono per forza profittevoli in quanto se poi, alla prova dei fatti, il fornitore non è coinvolto effettivamente in una parte rilevante del trattamento, il fatto di forzare l’estensione dei controlli non arricchisce e non migliora la qualità della sequenzialità e copertura dei rapporti.
Da parte del Responsabile, andrebbero regolamentati meglio i limiti dell’attività condotta e preteso di operare in ambienti con dati fittizi, esplicitando che l’attività di VA&PT è un’attività “statica” che fotografa un momento e da essa non può scaturire un’attribuzione di supporto all’emergenza, per lo meno in termini di responsabilità.
In ultimo, credo che il coinvolgimento del “terzo” sia da parte di Unicredit che da parte di NTT Data, sia stato in qualche modo inopportuno.
Per Unicredit perché il frettoloso tentativo di scaricare il barile su NTT Data, in presenza del principio di accountability, come se fosse su un’altra “barca” non si è rivelata una strada proficua. Questa linea difensiva non teneva conto del fatto che avrebbe mascherato solo in parte le eventuali carenze del Titolare. Dico eventuali perché credo sarebbe stato più opportuno insistere sul fatto che una “violazione” non significa che il sistema non è adeguato ma semplicemente che è fallibile, come tutti i sistemi da quelli per la sicurezza dei lavoratori a quelli per la sicurezza ambientale, la cybersecurity o la “231”.
Dunque, piuttosto si sarebbe dovuto puntare (come si è fatto solo in parte) sul fatto che Unicredit è dotata di misure di sicurezza allo stato dell’arte e che magari la vulnerabilità era emersa solo in tempi recentissimi a causa, ad esempio, dell’aggiornamento di alcuni sistemi che aveva esposto o introdotto la criticità che ha consentito la violazione notificata.
Ma lo scarica barile non ha funzionato neanche per NTT Data perché affrettarsi a dire “Truel IT me lo ha comunicato solo in data 19 ottobre 2018”, quando si sapeva che il sub-responsabile non era autorizzato, non è stata una scelta premiata, meglio sarebbe stato puntare sul fatto che l’attività richiesta è costituita da un processo di “cognizione” elaborato e non predisposto per fungere da “IDS” (Intrusion Detection System) ma pensato per dare una reportistica ragionata e “a freddo”.
Infine, da parte dell’Autorità si auspica un atteggiamento da un lato maggiormente supportato da rigore logico e dall’altro maggiormente calzato nella realtà e nelle complesse dinamiche che i titolari affrontano e che, a mio parere, troppo spesso vengono viste come risolvibili in modo ovvio senza che in realtà tale “ovvietà” sussista.
