Cambio server e fornitori - un caso esemplare

Provvedimento del 17 luglio 2024 [10058595]

Stampa Stampa

Trasforma contenuto in PDF

[doc. web n. 10057610]

Provvedimento del 17 luglio 2024

Registro dei provvedimenti
n. 444 del 17 luglio 2024

IL GARANTE PER LA PROTEZIONE DEI DATI PERSONALI

NELLA riunione odierna, alla quale hanno preso parte il prof. Pasquale Stazione, presidente, la prof.ssa Ginevra Cerrina Feroni, vicepresidente, il dott. Agostino Ghiglia e l’avv. Guido Scorza, componenti, e il cons. Fabio Mattei, segretario generale;

VISTO il Regolamento (UE) 2016/679 del Parlamento europeo e del Consiglio, del 27 aprile 2016, relativo alla protezione delle persone fisiche con riguardo al Trattamento dei dati personali, nonché alla libera circolazione di tali dati e che abroga la direttiva 95/46/CE, “Regolamento generale sulla protezione dei dati” (di seguito “Regolamento”);

VISTO il d.lgs. 30 giugno 2003, n. 196 recante il “Codice in materia di protezione dei dati personali”, contenente disposizioni per l’adeguamento dell’ordinamento nazionale al Regolamento (UE) 2016/679 del Parlamento europeo e del Consiglio, del 27 aprile 2016, relativo alla protezione delle persone fisiche con riguardo al Trattamento dei dati personali, nonché alla libera circolazione di tali dati e che abroga la Direttiva 95/46/CE (di seguito il “Codice”);

VISTO il d.lgs. 10 agosto 2018, n. 101 recante “Disposizioni per l'adeguamento della normativa nazionale alle disposizioni del Regolamento (UE) 2016/679 del Parlamento europeo e del Consiglio, del 27 aprile 2016, relativo alla protezione delle persone fisiche con riguardo al Trattamento dei dati personali, nonché alla libera circolazione di tali dati e che abroga la direttiva 95/46/CE”;

VISTO il Regolamento n. 1/2019 concernente le procedure interne aventi rilevanza esterna, finalizzate allo svolgimento dei compiti e all’esercizio dei poteri demandati al Garante per la protezione dei dati personali, approvato con deliberazione del n. 98 del 4/4/2019, pubblicato in G.U. n. 106 dell’8/5/2019 e in www.gpdp.it, doc. web n. 9107633 (di seguito “Regolamento del Garante n. 1/2019”);

VISTA la documentazione in atti;

VISTE le osservazioni formulate dal segretario generale ai sensi dell’art. 15 del Regolamento del Garante n. 1/2000 sull’organizzazione e il funzionamento dell’ufficio del Garante per la protezione dei dati personali, doc. web n. 1098801;

Relatore il dott. Agostino Ghiglia;  

PREMESSO

1. La Violazione dei dati personali e i reclami

Il XX l’Azienda ULSS 6 Euganea, di seguito “Azienda” ha trasmesso all’Autorità, ai sensi dell’art. 33 del Regolamento, una notifica di Violazione dei dati personali -successivamente integrata con note del XX e XX, XX e XX, XX e XX - riguardante un attacco informatico, determinato da un malware di tipo ransomware (XX), ai sistemi informativi della stessa.

Tenuto conto dell’elevato numero di interessati coinvolti e della natura dei Dati personali oggetto di violazione, è stato ritenuto necessario approfondire le circostanze nelle quali si è verificata la predetta violazione dei dati personali, nonché le misure di sicurezza adottate, mediante un’attività ispettiva nei confronti dell’Azienda nel mese di XX.

In ordine alla medesima vicenda, sono pervenute, tra XX e XX, talune istanze da parte di cittadini che, informati dell’evento occorso, si sono rivolti all’Autorità.

2. La violazione dei dati personali

2.1. Il fatto

Le circostanze relative alla Violazione dei dati personali sono state rappresentate dall’Azienda sia nella notifica all’Autorità, effettuata, per fasi, ai sensi dell’art. 33 del Regolamento, sia nel corso della citata attività ispettiva. In particolare, è risultato quanto segue.

2.1.1. La notifica della violazione al Garante

Con la notifica preliminare del XX, l’Azienda ha dichiarato di essere vittima di un “attacco hacker rilevato dai sistemi informativi aziendali alle ore 3.00 del XX che preclude l’accesso e la disponibilità ad alcuni applicativi aziendali (infrastrutturali, ospedalieri, amministrativi, territoriali) la cui precisa identificazione e il cui impatto sono in corso di definizione”, precisando che “ad una prima analisi si evidenzia l'interessamento della server farm della sede periferica ULSS 6 Euganea di Via Marconi […] Monselice (PD) e del Presidio Ospedaliero di Camposampiero (PD)” (v, notifica del XX sez. XX).

Successivamente, con nota del XX, l’Azienda ha aggiornato le informazioni riguardanti la violazione fornendo copia dell’Incident Report della Società XX S.p.A. da cui si evince che “l’attaccante ha effettuato l’accesso alla rete interna tramite la XX […]. Sono presenti anche accessi tramite la VPN Fortinet, ma non sono presenti informazioni utili sui log Fortinet […] server XX identificato dal nome "XX", su cui il programma malevolo "locker_ce066f3fade586a6_ESXI_Linux" ha effettuato operazioni di crittografia delle macchine virtuali e aggiungendo l’estensione "lockbit" ai nomi di tali file […] attraverso l’uso di account di domain admin, l’attaccante ha usato il tool PSEXEC per distribuire, sui sistemi identificati, il tool di cifratura (xxx). Questo tool disattiva vari sistemi di sicurezza e di backup e poi esegue la cifratura dei file. […] L’attaccante ha anche fatto accesso ai sistemi VmWare; in questo caso è stato utilizzato direttamente l’utente root e ha impiegato un programma ad hoc (locker_ce066f3fade586a6_XX Linux), distribuito dal gruppo XX il XX sui canali del dark web. Il tool ha sospeso le varie VM ed eseguito la cifratura dei datastore […] l’attaccante ha distribuito un eseguibile (sender.exe) ad hoc che ha il compito di raccogliere i file (".doc,.docx,.xls,.xlsx,.xlsm,.pdf,.msg,.ppt,.pptx,.sda,.sdm,.sdw,.csv,.zip,.json,.config,.ts,.cs,.sqlite,.aspx,.pst,.rdp,.accdb") che rientrano nelle seguenti condizioni: quelli modificati negli ultimi 6 mesi, quelli più vecchi di un anno, ma modificati negli ultimi 6 anni. Una volta raccolti, questi file sono inviati ad un ip esterno (104.248.142[.]137) tramite SFTP e WebDav” (v. notifica del XX,XX).

In aggiunta a quanto precedentemente notificato, il XX, l’Azienda ha ulteriormente aggiornato, sulla base della “RELAZIONE di 2nd OPINION - Incidente informatico AULSS 6 Euganea - v.1.1 del XX” predisposta da Yarix s.r.l., le informazioni circa la violazione riportando che “l’analisi effettuata, benché influenzata dalla mancanza di alcuni elementi utili, ha permesso di individuare nell’attacco subito […] l’operato, pressoché contemporaneo, di due differenti TA (Threat Actor): nei sistemi attaccati, infatti, sono state rinvenute tracce di due ransomware gang differenti, XX ed XX. […] le prime attività riconducibili a potenziali accessi non autorizzati nell’infrastruttura […] sono state ricondotte al XX, giorno in cui, dagli elementi a disposizione, risulta essere stato effettuato il primo accesso da uno degli indirizzi IP associati agli attaccanti. A partire dal XX (…) sono state invece rilevate le ulteriori attività associate agli attaccanti che hanno portato all’effettiva cifratura dei dati avvenuta la notte del XX. A tal proposito risulta molto singolare l’attacco rilevato […] in quanto (…), i due TA hanno operato in una timeline temporale quasi sovrapponibile, ma hanno avuto accesso ai sistemi da due punti d’ingresso differenti (VPN su apparato Fortigate per XX e VPN su apparato XX per XX) e hanno operato la cifratura su porzioni diverse d’infrastruttura (XX). Le verifiche sull’effettiva esfiltrazione, viziate purtroppo dall’assenza di dati utili (log) in alcuni dei sistemi analizzati, non hanno permesso di determinare con assoluta certezza se questa sia avvenuta, anche se le informazioni di intelligence rilevate dal team di Cyber Threat Intelligence hanno permesso comunque di appurare che il XX e dispone, se non altro, di una lista di file compatibili con quanto presente nei sistemi di AULSS 6 Euganea”. È stato, altresì, rappresentato che “tale short list, che elenca la potenziale esfiltrazione di circa 17.000 documenti contenenti Dati personali e non, è attualmente al vaglio costante dei Sistemi Informativi dell’AULSS 6, al fine di confermare l’effettiva corrispondenza dei file in possesso del TA con quelli aziendali e poter successivamente provvedere all’eventuale precisa comunicazione agli interessati, fornendo altresì strumenti a supporto dei loro diritti e delle loro libertà. Un’analisi dettagliata di tali documenti, potenzialmente esfiltrati, è stata avviata da una task force multidisciplinare, nominata dalla Direzione Aziendale e appositamente formata […]”. L’Azienda, “esaminata la relazione di second opinion di Yarix, e valutato l’elenco degli artefatti non esaminati, è intervenuta con le ditte appaltatrici coinvolte nei servizi connessi alla sicurezza del Perimetro infrastrutturale aziendale (servizi riconducibili al fornitore XX spa) ed ha messo a disposizione di Yarix s.r.l. sette macchine ai fini del completamento delle attività di analisi. Si riportano di seguito i riscontri di Cyber Threat Intelligence come da report di Yarix s.r.l. del XX, parte integrante della relazione sopra richiamata: «Durante le attività di Cyber Intelligence, il team di Cyber Threat Intelligence di Yarix (YCTI) ha identificato per mezzo dei profili sotto copertura dei suoi analisti, la compromissione di tre host con accesso ai seguenti portali interni appartenenti al Perimetro di AULSS6: dalle prime analisi condotte sui dati individuati si evince che le informazioni sono state raccolte da tre istanze info-stealer della famiglia Redline attive sulle macchine per un certo periodo. La trasmissione delle informazioni al C&C è avvenuta rispettivamente nelle seguenti date: Host 1: XX: XX: XX. La data di trasmissione delle informazioni da parte del malware non dimostra che le credenziali siano ancora valide o che siano state usate in quella specifica data: è possibile, per esempio, che il malware abbia prelevato ed inviato al server C2 tutte le credenziali salvate nel browser fino a quel momento. L’host 1 contiene una delle credenziali identificate durante l’analisi dell’incidente del XX come punto di ingresso VPN per il XX(utenza XX), ed è quindi plausibile supporre che la stessa sia stata oggetto di compravendita ai fini dell’attacco stesso»” (v. notifica del XX, XX).

A ulteriore integrazione in merito alla pubblicazione dei dati da parte del gruppo XX, il XX l’Azienda ha inteso allegare il “Cyber Intelligence Report” del XX e la “RELAZIONE di 2nd OPINION - Incidente informatico AULSS 6 Euganea - rev. XX” predisposti da Yarix s.r.l. (v. notifica del XX, sez. XX).

Con nota delXX, infine, l’Azienda ha evidenziato quanto presente nella “RELAZIONE di 2nd OPINION - Incidente informatico AULSS 6 Euganea - rev 1.3 del XX” predisposta da Yarix s.r.l., nella parte in cui veniva riportato che “in data XX, a seguito di alcuni ulteriori dettagli forniti in sede di analisi […] è stato identificato ed acquisito presso la sede di Padova Colli, un sistema di collezionamento LOG FortiAnalyzer (FAZVM64) che risultava in produzione durante l’incidente[…]; le analisi hanno permesso di rilevare la presenza di traffico verso l’IP di esfiltrazione dal firewall FW-SCRO14-DC. Nello specifico, nell’arco temporale compreso tra le ore 00:52:10 e 02:12:28 del giorno XX, è stato rilevato traffico in uscita da 18 client appartenenti al dominio ULSS17 […]; l’analisi del traffico ha permesso di rilevare un trasferimento dati di circa 700 MB” (v. notifica del XX, XX).

2.1.2. Le attività ispettive

Nel corso delle attività ispettive, l’Azienda nel confermare “l’analisi effettuata da YARIX con particolare riferimento alla timeline del documento “Relazione di 2nd opinion - Incidente informatico AULSS 6 Euganea” versione 1.3 - XX”, ha precisato che “i primi accessi dell’attore malevolo, tramite VPN, risalgono al mese di XX, a seguire il threat actor XX ha poi proceduto con le azioni tipiche di una cyber kill chain”; che “il XX alle ore 2.37 l’help desk, a seguito della ricezione di una segnalazione di malfunzionamento del sistema di ticketing, ha attivato il supporto sistemistico reperibile del fornitore della gestione delle infrastrutture. Successivamente è stata coinvolta la società XX del gruppo XX, specializzata in sicurezza informatica” e che “la ULSS, non avendo sistemisti fra il personale dipendente, ha richiesto una second opinion circa l’incidente di sicurezza alla società YARIX, leader di settore, per la sua posizione di terzietà e assenza di conflitto di interessi” (v. verbale del XX, pag. XX).

Per quanto concerne la portata della violazione con riferimento agli applicativi aziendali di ordine sanitario e amministrativo contabile, l’Azienda ha dichiarato che “non sono stati coinvolti gli applicativi amministrativi contabili e risultava cifrata la consolle di virtualizzazione di quelli sanitari nonché parte delle postazioni di lavoro. Nonostante la complessità dell’infrastruttura tecnologica dell’Azienda, composta da numerosi e differenti apparati fisici e virtuali, apparecchiature dell’area biomedicale, apparecchiature per esami delle varie aree specialistiche ospedaliere, è stato possibile ripristinare in breve tempo l’operatività aziendale. Ciò con un piano di service continuity, una continua valutazione delle priorità e dello stato di avanzamento delle attività svolte dai diversi gruppi di lavoro e unità crisi, e con il coinvolgimento di tutte le risorse umane disponibili”. Il Titolare ha, inoltre, inteso precisare che “[i dati pubblicati] non sono stati esfiltrati dai database ma provenivano dalle postazioni di lavoro di dipendenti che avevano salvato in locale documenti personali o liste di lavoro (es. ricoveri, dimissioni) o schede di pazienti talvolta in bozza o incomplete e non catalogati, contrariamente alle istruzioni […] che prevedevano esclusivamente l’utilizzo di “cartelle condivise” o sistemi dedicati”; che “il sito istituzionale dell’Azienda è sempre stato funzionante” e che “l’erogazione dei servizi verso l’utenza e la somministrazione delle prestazioni sanitarie non hanno subito alcuna interruzione poiché sono state adottate le procedure previste in caso di disastro. In ogni caso, a seguito del ripristino dell’infrastruttura tecnologica, sono stati trasferiti tutti i dati relativi alle attività svolte in modalità emergenziale” (v. verbale del XX, pagg. XX e XX).

Per quanto attiene al numero di interessati i cui dati sulla salute sono stati coinvolti dall’attacco l’Azienda ha dichiarato che “la task force è riuscita a delimitare precisamente il Perimetro della violazione in termini di quantità di dati personali, tipologie di Dati personali e tipologie e numero di interessati, rilevando numeri inferiori rispetto a quanto prospettato a inizio data breach (n. interessati 9.520, invece di 23.886 – n. file 5763 invece di 32.555)” (v. notifica del XX, sez. XX).

Da ultimo l’Azienda ha fornito un’integrazione alla relazione tecnica della task force del XX allegata alla notifica del XX, dichiarando che il numero di interessati coinvolti “è sostanzialmente inferiore” (v. nota del XX a scioglimento delle riserve dell’ispezione del XX, allegato XX).

2.2. Le misure in essere al momento della violazione

2.2.1. Notifica della violazione al Garante

Con riferimento alle misure in essere al momento della violazione, l’Azienda ha dichiarato:

-  che “l’AULSS6 deriva dall’unificazione di tre ex ULSS ciascuna con il proprio differente sistema informativo, l’azione più rilevante è stata il consolidamento, unificazione e messa in sicurezza di un unico nuovo dominio AULSS6 Euganea e progressiva cessazione dei vecchi domini e dei sistemi non unificati; la sicurezza perimetrale è garantita dall’uso di IPS, antivirus, web filtering, certification inspection su sistemi dedicati. Nelle postazioni in Dominio AULSS6 vengono installati solo i software definiti e autorizzati e non è consentito l’accesso con Admin Locale. Le modalità di utilizzo delle PDL e più in generale degli strumenti informatici” sono definite “dai regolamenti aziendali. La predisposizione delle macchine (server e pdl) avviene mediante template standard archiviati offline e accessibili solo al personale interessato. L’accesso ai server avviene esclusivamente con utenze amministrative e alle PDL solo previa autorizzazione. Le utenze amministrative hanno Password XX (XX). Per il controllo e monitoraggio delle postazioni è attivo il sistema XX sia client che server, mentre per la parte di inventory si utilizza il sistema XX; il sistema di gestione dei Log (XX gestito da azienda specializzata) è già attivo sui sistemi più rilevanti. In merito alle copie di sicurezza attivo backup giornaliero full e incrementale su tutti i sistemi fisici, virtuali e database: ciò infatti ha consentito il ripristino in tempi rapidi e in sicurezza. Relativamente al vulnerability Assessment è attivo un servizio con ditta specializzata, eseguito con cadenza almeno mensile e conseguenti azioni correttive segnalate ai principali attori al fine di intervenire per superare le vulnerabilità segnalate. Per tutte le nuove postazioni che supportano la funzionalità è stata attivata la funzione di scansione anti malware dei supporti removibili così come il filtro dei messaggi di posta e traffico web mediante i servizi Google Cloud regionale. In particolare le copie di sicurezza sono gestite con i seguenti sistemi: XX con le relative politiche di backup (incrementale quotidiano, settimanale sintetico) per la parte database XX il Backup avviene su piattaforma XX (Backup Full quotidiano e archive log orario). Con Delibera n. 709 del XX è stato adottato il Documento Programmatico della Sicurezza che riporta un intenso piano di miglioramento volto all'innalzamento medio e massimo delle misure di sicurezza con particolare riferimento alla circolare AgID 2/2017 e al FNSI, compreso un piano di formazione di concerto con il dpo a tutto il personale dei sistemi informativi”;

- di aver “intrapreso, già a far data dal 2018, percorsi formativi mirati, indirizzati alla Dirigenza e al personale dipendente, volti ad accrescere e rafforzare le conoscenze e le condotte diligenti da porre in essere in ambito privacy, data protection e sicurezza informativa. Ciò in ragione tanto dell’avvento della normativa unionale di cui al GDPR, quanto a fronte della riorganizzazione del Sistema Sanitario Regionale, di cui alla legge regionale n. 19/2016 ed esecutiva dal 1° gennaio 2017, che ha previsto l’unificazione delle aziende sanitarie AULSS 15, 16 e 17 nella AULSS 6 Euganea e ha comportato l’avvio di un nuovo sistema informativo aziendale e di gestione del dato personale, nonché la definizione di un nuovo sistema privacy aziendale”;

- che “ha implementato e mantiene aggiornate tutte le misure organizzative di cui al GDPR in tema di nomine a persone autorizzate ex artt. 29 GDPR e 2-quaterdecies CP, a Responsabile del Trattamento ex art. 28 GDPR e in relazione alla designazione del DPO, nonché mediante predisposizione di procedure di data breach e di valutazione del rischio, applicate durante il sinistro de quo” (v. notifica del XX, sez. XX, punto XX).

2.2.2. Attività ispettive

Circa le procedure di autenticazione informatica utilizzate nell’ambito dell’accesso in VPN e alle postazioni di lavoro in essere al momento della violazione e le Password policy previste per le diverse tipologie di utenze, l’Azienda, nel corso delle attività ispettive, ha dichiarato che:

− “al momento della violazione dei dati personali, non erano previste procedure di autenticazione informatica a più fattori per l’accesso alla rete e ai sistemi gestiti dalla Azienda tramite VPN”;

− “la ULSS aveva predisposto un regolamento per l’accesso da remoto […] e che il XX era stato approvato un “Documento Programmatico sulla sicurezza” per potenziare le misure di sicurezza e adeguarle alle misure minime AgID […] in tale documento era prevista, tra le altre, la misura dell’autenticazione a due fattori per l’accesso in VPN”;

− “le utenze non privilegiate sono censite nella piattaforma di Identity Management (IM) (XX) del fornitore XX e poi nella Active Directory, le credenziali sono costituite da XX. Il personale che svolge funzioni amministrative ha due utenze, una non privilegiata e una con privilegi amministrativi (XX) e si collegano ai sistemi tramite rdp o SSH”;

− “le utenze non amministrative hanno la seguente Password policy: XX. Il rispetto della policy è assicurato dai controlli della piattaforma di IM. Le utenze privilegiate hanno una Password policy di XX con le medesime regole”;

− “la ULSS a seguito dell’unificazione aveva intrapreso un percorso di normalizzazione delle infrastrutture (oltre XX server), delle postazioni di lavoro (circa XX), dei domini e delle policy che però si è interrotto a causa della pandemia”;

− “le ex ASL 15 e 17 erano dotate di infrastrutture obsolete”;

− “erano ancora presenti, per garantire continuità operativa, i vecchi firewall delle ex ASL e le vecchie VPN, di norma aggiornati dai tecnici, a meno di casi specifici e motivati dai medesimi” (v. verbale del XX, pagg. XX, XX e XX).

Al riguardo l’Azienda ha poi confermato che “il XX, al momento dell’attacco, le logiche per la gestione delle Password degli account con privilegi elevati implementate sul dominio XX rispondevano, conformemente alle best practice AGID, alle regole di security posture che si riportano di seguito: XX” (v. nota del XX a scioglimento delle riserve dell’ispezione del XX, cfr., in particolare, all. n. XX e anche XX e XX).

In riferimento alle misure di sicurezza, in essere al momento della violazione dei dati personali, relative alla segmentazione delle reti, l’Azienda ha dichiarato che “i server delle ASL ex 16 ed ex 17 erano attestati su una VLAN dedicata e diversa da quella dove erano attestate le postazioni di lavoro e si stava predisponendo un nuovo ambiente a partire dai 3 Data Center delle 3 ASL” (v. verbale del XX, pag. XX).

Con riguardo alle misure tecniche e organizzative adottate per garantire la disponibilità e la resilienza dei sistemi e dei servizi di trattamento, nonché il ripristino tempestivo della disponibilità e dell’accesso dei Dati personali in caso di incidente, l’Azienda ha dichiarato che:

− “era presente un sistema di monitoraggio sistemistico ma non una control room”;

− “il servizio SGM di conduzione, manutenzione e gestione apparati non comprendeva un’analisi automatizzata e strumenti di monitoraggio degli eventi di sicurezza”;

− “l’invio settimanale dei log della VPN XX verso la casella XX non era attivo poiché, durante le attività conseguenti l’unificazione e il consolidamento dei sistemi delle 3 ASL, era in corso una riconfigurazione delle comunicazioni mail degli apparati verso un unico punto di raccolta e, pertanto, si ipotizza che il predetto log fosse coinvolto da tale fase di migrazione”;

− “utilizzava dal XX il sistema di backup XX” (v. verbale del XX, pagg. XX e XX).

Successivamente, l’Azienda ha precisato che “al momento dell’attacco erano operative regole eterogenee e differenziate per ciascun firewall in relazione alle capacità di Archiviazione degli apparati e alle regole di registrazione del traffico. Con riferimento alla conservazione dei log, relativi all’attività degli amministratori di sistema, XX in linea con i Provvedimenti in materia impone a tutti i suoi fornitori di “conservare obbligatoriamente copia dei log di accesso e delle operazioni definite per un periodo non inferiore a mesi 6”, come da “Condizioni generali della Sicurezza Informatica relativa a terze parti” nella versione aggiornata al XX. Con riferimento al firewall XX la conservazione dei log di accesso era di 6 mesi. Infine, con riferimento ai log del firewall Fortinet la conservazione era di 60 giorni. Si segnala, inoltre, che già precedentemente alle date dell’attacco, era in corso tra XX e l’Amministrazione, una negoziazione relativa all’ampliamento dello spazio di Archiviazione dei Firewall Fortinet, così come proposto all’amministrazione […] a XX” (v. nota del XX a scioglimento delle riserve dell’ispezione del XX, allegato XX).

2. 3. Le misure adottate a seguito della violazione

2.3.1. Notifica della violazione al Garante

Con riferimento alle misure adottate a seguito della violazione, l’Azienda, nell’ambito della notifica della violazione, effettuata ai sensi dell’art. 33 del Regolamento, ha rappresentato che:

“è stata “interessata prontamente una società informatica esperta nella reazione ad attacchi informatici che sta attualmente e urgentemente operando un’analisi preliminare dell'evento per valutare l'impatto e le conseguenti azioni di rimedio e ripristino per il contenimento e la riduzione degli effetti della violazione” (nota del XX);

“tra le azioni immediate di mitigazione dei danni, oltre al blocco totale dei servizi di rete e dell’accesso ai servizi interni e esterni, si sono prodotte procedure interne per il divieto di utilizzo dei sistemi aziendali e per la riattivazione con metodologie alternative dei servizi essenziali e fornitura di strumenti affidabili, si è organizzata una squadra di oltre 60 tecnici informatici per la bonifica delle postazioni di lavoro, si è istituita una Unità di Crisi con tutte le professionalità necessarie per gestire al meglio sia gli interventi di mitigazione del danno, sia gli interventi organizzativi conseguenti correlati alla pronta ripresa dei servizi sanitari essenziali (Pronto Soccorso, Laboratorio, Anatomia Patologica, Radiologia, etc.). Inoltre, si è proceduto al coinvolgimento di società esperte nel settore di riferimento, tra cui la Scudomed S.r.l., per i profili inerenti alla consulenza privacy e data protection, e la Yarix S.r.l., per i profili informatici e di cyber sicurezza, anche per una attività tecnica di second opinion in merito al data breach. E’ stato costituito un gruppo di lavoro “LAWYERS”, composto oltre che dal Direttore Amministrativo AULSS 6 Euganea, dal Direttore dell’UOC Affari Generali dell’AULSS 6 Euganea, dal dpo dell’AULSS 6 Euganea anche da professionisti esterni di estrazione legale esperti nell’ambito penale, amministrativo, privacy compliance e cybersicurezza per la gestione multidisciplinare dell’incidente e delle notifiche a Enti/organismi diversi; il gdl si riunisce con cadenza giornaliera e relaziona con la medesima tempistica alla Direzione Generale. È stata prontamente informata, già in data XX, la Polizia Postale - Compartimento per il Veneto” (nota del XX);

è stato richiamato, con nota del XX, quanto riportato nella relazione di second opinion del XX predisposta da Yarix s.r.l. che evidenziava che si era proceduto alla “installazione su tutto il Perimetro di uno strumento XDR (eXtended Detection and Response) atto sia a garantire l’identificazione di eventuali minacce latenti presenti all’interno della rete, sia a fornire il supporto necessario alla rimozione di potenziali componenti residue derivanti dalla compromissione”; alla “attivazione di un servizio di monitoraggio continuativo del Perimetro interno di AULSS 6 tramite il Security Operation Center di Yarix operante H24 7/7 per garantire la presa in carico, analisi e gestione di qualsiasi evento di sicurezza si verifichi nel Perimetro sotto controllo”; alla “attivazione di un servizio di monitoraggio continuativo del Perimetro esterno (Cyber-space) relativo al profilo digitale di AULSS 6 mediante il team di Cyber Threat Intelligence di Yarix, al fine di identificare mediante attività OSINT (Open Source INTelligence) e CLOSINT (Closed Source INTelligence) su clear, deep e dark web eventi correlabili all’attacco subito da AULSS 6, nonché potenziali leak di dati e/o altre informazioni esfiltrate”;

tali misure “sono state intraprese e monitorate costantemente dal gruppo ITC aziendale e dalla governance insieme ai consulenti ed alle società coinvolte nella gestione dell’emergenza determinando, volta per volta, una serie di misure in un’ottica by design, in esecuzione di attività di disaster ricovery, al fine di assicurare la piena attuazione del principio di business continuity. Quest’ultima si è resa particolarmente efficace nelle azioni di riavvio dei principali gestionali in grado di assicurare la continuità assistenziale dei pazienti, il reperimento di farmaci salvavita, l’efficienza dei laboratori di analisi e dei Pronto Soccorsi quali principali strutture operative aziendali” (v. notifica del XX, sez. XX punti XX e XX);

“con delibera n.XX del XX è stato adottato il nuovo Regolamento di utilizzo dei sistemi informatici diffuso secondo le modalità previste per la divulgazione documentale aziendale. Sono state altresì revisionate e diffuse procedure e istruzioni operative per porre in essere le policy aziendali. E’ stato altresì aggiornato il piano formativo annuale aziendale inserendo sessioni di approfondimento della nuova policy per tutto il personale aziendale” (v. notifica del XX, sez. XX, punto XX);

a proposito delle misure tecniche e organizzative per prevenire simili violazioni future, sono state indicate le seguenti misure: “a) aggiornamento sistema privacy aziendale […] stante la complessità dell’azienda, per la quale sono ancora in corso attività di revisione dei processi organizzativi derivanti dalla fusione delle tre ex aziende sanitarie padovane (ULSS15 - ULSS16 - ULSS17) e dei trattamenti gestiti, nonché nell’ambito del percorso di miglioramento continuo, previsto e rappresentato anche nel piano delle performance 2022-2024 e nel documento di direttive per l’anno 2022, si è ravveduta la necessità di ridefinire il sistema privacy aziendale nel Sistema di Gestione Aziendale Protezione dei Dati personali (SGA PDP) e di costituire un team multidisciplinare di supporto al fine di dare maggior impulso al cammino intrapreso e garantire un sostegno operativo in grado di puntellare l’impianto di protezione dei dati dimostrando le capacità e l’attitudine dell’intera organizzazione alla valorizzazione e tutela del patrimonio informativo, assicurando il monitoraggio ed il miglioramento continuo dei processi e delle procedure. Al team sono state attribuite funzioni di analisi e supporto all’ufficio aziendale protezione Dati personali (ex ufficio privacy), in raccordo con il DPO. Il fine è garantire un supporto multidisciplinare per non perdere di vista l’obiettivo di protezione e di mantenere efficiente nel tempo il complesso di misure di sicurezza adottato, migliorandolo se e quando necessario. b) Adesione alla PDR 43:2018: La Direzione Aziendale ha attivato il percorso per giungere alla certificazione di adesione alle “Linee guida per la gestione dei Dati personali in ambito ICT secondo il Regolamento UE 2016/679” con l’obiettivo di migliorare le azioni per il corretto Trattamento dei Dati personali del Sistema Gestione Aziendale Protezione Dati Personali, ponendo le basi per meccanismi di certificazione come auspicati dall’art. 42 del Regolamento Europeo n.679/2016. c) Certificazioni ISO 9001:2015 e 27001:2017: La Direzione Aziendale ha avviato il percorso per l’adesione al modello di gestione della qualità per la sicurezza delle informazioni al fine di ridefinire processi e strumenti ad essi collegati nell’ottica della sicurezza delle informazioni ed ottenere la certificazione ISO 9001:2015 e 27001:2017 a seguito di allineamento dell’attività dei sistemi informativi alle indicazioni fornite dalla normativa in materia di protezione dati personali. Ciò al fine di permettere la libera circolazione sicura dei Dati personali nell’ambito del SGA PDP. d) Formazione: sono stati intensificati percorsi formativi diversificati per tutto il personale aziendale nonché per il team multidisciplinare” (v. notifica del XX sez. XX, punto XX).

2.3.2. Attività ispettive

Nel corso delle attività ispettive, l’Azienda ha dichiarato che “successivamente alla violazione, a XX è stata attivata la procedura di autenticazione informatica a più fattori per l’accesso alla rete e ai sistemi gestiti dalla Azienda tramite VPN, con secondo fattore XX” e che “le istruzioni per l’attivazione della VPN con MFA sono state fornite ai dipendenti mediante mail” (v. verbale XX, pag. XX). Inoltre l’Azienda ha rappresentato che “a valle dei suggerimenti di YARIX, contenuti nella relazione di second opinion, è stato attivato un SIEM strutturato che raccoglie i vari log in via di consolidamento, prima con affidamenti temporanei e successivamente nel nuovo contratto vigente con XX”, che “è stato adottato il sistema XDR della società XX” e “a partire da fine XX, sono state attivate una serie di misure di sicurezza fra cui lo strumento di XDR di XX, monitorato H24 dal SOC di YARIX, a protezione degli end point, per risposta e contrasto delle minacce; un sistema SIEM di raccolta dei log per monitorare tutti gli eventi di sicurezza; un servizio di analisi per la raccolta di informazioni di intelligence da sorgenti aperte e chiuse (OSINT e CLOSINT) al fine di identificare eventuali esfiltrazioni dati, compromissioni di account e utenze nonché altre potenziali minacce relative al Perimetro concordato con la ULSS (XX)” (v. verbale del XX, pagg. XX e XX).

Per quanto concerne le misure organizzative l’Azienda ha evidenziato che “il percorso di revisione delle procedure già in corso, ha subito un’accelerazione che ha portato alla definizione di un Sistema di Gestione Aziendale Protezione Dati personali (SGA PDP) […]. A valle dell’incidente, la rete di referenti che si occupava, tra l’altro, di procedure e rischio clinico, ha acquisito l’ulteriore competenza della protezione dati con opportuna formazione per costituire un osservatorio sul campo sia per intercettare anomalie ma anche per meglio regolamentare i nuovi progetti e le attività che possono avere impatto sulla protezione dei dati. La rete attualmente consta di XX persone. È stato inoltre costituito un team multidisciplinare (competenze di protezione dati, sicurezza ICT, medica, risorse umane, etc..), formato con un corso di 80 ore – con moduli specifici su argomenti tra i quali consenso, ricerca scientifica, app mediche, dispositivi medici, intelligenza artificiale - in aggiunta al piano formativo annuale per tutti i dipendenti che prevedeva già argomenti di protezione dati e sicurezza ICT […]. Ha adottato inoltre lo strumento XX che, oltre a mettere a disposizione tutte le procedure e la documentazione necessaria a rendere edotti i dipendenti, raccoglie le segnalazioni provenienti dalla rete dei referenti e che verrà a breve esteso a tutto il personale, per una veloce e centralizzata raccolta dei dati dalle singole UO, convogliati a livello aziendale verso il RPD e la direzione strategica. Tale strumento è utilizzato, quindi, per la sensibilizzazione del personale e distribuzione documentale di tutte le procedure aggiornate di cui i dipendenti devono prendere visione. Le segnalazioni raccolte mediante questo strumento sono analizzate dall’ufficio Qualità che, nel caso, coinvolge il team multidisciplinare e il RPD”, che è stato “costituito un ufficio privacy, separato dal RPD, che si occupa, tra le altre, di attività compliance, prima redazione di VIP, informative, ed è strettamente in contatto con il team multidisciplinare e i vertici aziendali” e che “ha intrapreso un percorso per ottenere la certificazione ISO 27001 e UNI PdR 43:2018” (v. verbale dell’XX, pag. XX).

Con riferimento alle operazioni di ripristino dei dati e dei sistemi, l’Azienda, nel corso delle attività ispettive, ha dichiarato che “dal XX la ULSS ha costituito un’unità di crisi per la gestione dell’incidente”; che “nell’arco di 15 giorni era stato ripristinato tutto ciò che era prioritario, in particolare con impatto sulle cure e prestazioni sanitarie degli assistiti” e che “a fine dicembre la ULSS aveva bonificato tutte le postazioni di lavoro. I diversi sistemi gestionali sono stati resi funzionanti solo a seguito di avvenuto collaudo funzionale, documentato da opportuno verbale firmato dal fornitore e Autorizzato anche dalla direzione dei sistemi informativi. Con l’occasione sono state anche adeguate, laddove ritenuto necessario, alcune misure di sicurezza dei sistemi medesimi. Le attività si sono concluse nell’arco di un mese. L’unità di crisi costituita ha sospeso gli incontri quotidiani il XX poiché la situazione ormai era sotto controllo” (v. verbali del XX, pag. XX e dell’XX pagg. XX e XX).

2.4. La comunicazione della violazione agli interessati

In relazione alla comunicazione della violazione agli interessati, l’Azienda ha preliminarmente rappresentato di aver effettuato una “comunicazione social tramite canale istituzionale Facebook dell’azienda” la mattina del XX riguardante l’attacco hacker e il blocco dei servizi informatici (v. notifica del XX, sez. XX, punto XX) e, successivamente, ha rappresentato che “una task force multidisciplinare (profilo informatico, profilo privacy, profilo sanitario-rischio clinico), appositamente nominata e formata per lo svolgimento dell’attività, sta svolgendo un’analisi dettagliata dei documenti potenzialmente esfiltrati, contenenti Dati personali e non” e ha illustrato “gli ulteriori strumenti pianificati […] per poter provvedere all’eventuale precisa comunicazione agli interessati fornendo altresì strumenti a supporto dei loro diritti e delle loro libertà mediante: una comunicazione di carattere generale, pubblicata nel sito aziendale, suddivisa per cluster in relazione alle diverse tipologie documentali contenenti dati personali, che potrebbero risultare esfiltrati sulla base dell’evidenza della short list; l’attivazione a breve termine di un numero verde multifunzione clusterizzata per ottenere prime sommarie informazioni rispetto alla posizione di ciascun soggetto interessato per l’esercizio dei diritti in merito al Trattamento dei propri Dati personali e le eventuali azioni e i comportamenti eventualmente da adottare ai fini dell’affievolimento dell’impatto dell’incidente sui diritti e libertà degli interessati” (v. notifica del XX, sezz. XX punto XX e XX, punto XX) confermando che gli strumenti pianificati erano stati realizzati (v. notifica del XX, sez. XX, punto XX).

Da ultimo, l’Azienda ha dichiarato che le “analisi di primo e secondo livello effettuate dalla task force multidisciplinare anche con l'ausilio del tool specializzato e alle risultanze in merito al numero degli interessati coinvolti nella violazione informatica nonché alle categorie di Dati personali oggetto del medesimo breach il Titolare del Trattamento ritiene che il rischio per i diritti e le libertà delle persone fisiche sia elevato. Sulla base delle analisi di Terzo e quarto livello anche con l’ausilio del software Esplores (…), la task force è riuscita a delimitare precisamente il Perimetro della violazione in termini di quantità di dati personali, tipologie di Dati personali e tipologie e numero di interessati, rilevando numeri inferiori rispetto a quanto prospettato a inizio data breach […]; tuttavia, data anche l’esposizione sul dark web e le informazioni personali impattate, il Titolare del Trattamento ritiene che il rischio per i diritti e le libertà delle persone fisiche sia elevato ed ha proceduto con gli obblighi informativi ai sensi dell’art. 34 GDPR per informare gli interessati e per fornire supporto a questi ultimi. Ha proceduto con due modalità”. Il Titolare ha, altresì, comunicato di aver proceduto a inoltrare, a oltre 700 dipendenti, in data XX “comunicazioni ex art. 34 del GDPR […] così distinte:

1) dipendenti interessati da pubblicazione di documenti identificativi (carta d’identità, patente di guida, green pass) […]. Si è proceduto in tal senso, considerato il potenziale furto d’identità, al fine di scongiurare per i soggetti interessati eventuali attività illecite perpetrate da terzi; nella comunicazione si consigliavano i dipendenti di recarsi presso l’Autorità Giudiziaria a denunciare l’accaduto. Essendo un numero esiguo i dipendenti sono stati anche contattati preliminarmente dai componenti della task force per anticipare il contenuto della comunicazione stessa. Prima di attivare tale processo la Direzione Aziendale, con la collaborazione del dpo Aziendale e del Referente privacy Aziendale, ha organizzato un incontro con le Organizzazioni Sindacali dei lavoratori per rappresentare gli esiti del lavoro della task force in merito all’analisi dei dati di documenti pubblicati nel dark web, in riferimento alle posizioni di alcuni lavoratori coinvolti nella violazione per la pubblicazione di documenti identificativi, e per rappresentare le misure poste in essere per attenuare gli effetti negativi dell’esfiltrazione sugli interessati. 2) dipendenti interessati dalla pubblicazione di documenti vari: in data XX sono stati raggiunti anche altri 700 dipendenti da comunicazioni ex art. 34 per informare gli stessi del coinvolgimento nella violazione […] tutte le comunicazioni sono andate a buon fine. A seguito delle stesse nr. 20 dipendenti hanno contattato i numeri a disposizione per assumere informazioni in merito all’accesso agli atti. Si specifica che questa azienda ha necessariamente dovuto gestire e adottare due distinte modalità di comunicazione agli interessati coinvolti nella pubblicazione di Dati personali […], per quanto attiene, invece, al restante numero di interessati non raggiungibili da comunicazione ad personam […] si è ritenuto di procedere con una comunicazione generalizzata ex art. 34, lett. c) del GDPR […] mediante affissione di apposita cartellonistica nelle zone di transito e con maggiore affluenza (…).Tale scelta consentirà all’Azienda di reindirizzare le risorse verso un piano di sviluppo (formativo e strutturale) del Sistema Gestione Aziendale Protezione Dati personali che era stato rallentato dagli avvenimenti connessi al COVID che hanno pesantemente interessato tutte le nostre strutture. Inoltre la medesima comunicazione è stata pubblicata nel sito aziendale (XX) al seguente link: XX. La comunicazione generalizzata sarà tenuta in evidenza per 6 (sei) mesi dalla data di diffusione” (v. notifica del XX, sezz. XX punto XX e XX punti XX e XX).

Durante le attività ispettive l’Azienda ha confermato “le azioni intraprese per attenuare gli effetti negativi sugli interessati con riferimento alla comunicazione, ai sensi dell’art. 34 del Regolamento, già riportate nella notifica del XX e le successive integrazioni, precisando che sono state ricevute pochissime richieste puntuali da parte degli interessati tramite i canali di contatto predisposti dall’Azienda (casella del RPD e numero verde dedicato), nonostante le informazioni siano state rese disponibili mediante cartellonistica affissa in tutti gli ospedali, ambulatori e luoghi di passaggio nonché dell’intensa campagna mediatica sviluppatasi nel periodo immediatamente successivo all’incidente” e che “i diversi comunicati stampa […] sono stati predisposti anche [coinvolgendo l’autorità] giudiziaria coinvolta nelle indagini” (v. verbale del XX, pag. XX e del XX pag. XX).

3. Valutazioni del Dipartimento sul Trattamento effettuato e notifica della violazione di cui all’art. 166, comma 5 del Codice

In ordine alla fattispecie descritta, l’Ufficio, sulla base di quanto rappresentato dal Titolare del Trattamento nell’atto di notifica di violazione e di quanto emerso nel corso dell’attività ispettiva, nonché delle successive valutazioni, ha notificato all’Azienda, ai sensi dell’art. 166, comma 5, del Codice, l’avvio di un procedimento per l’adozione dei provvedimenti di cui all’art. 58, par. 2, del Regolamento, invitando il predetto Titolare a produrre al Garante scritti difensivi o documenti ovvero a chiedere di essere sentito dall’Autorità (art. 166, commi 6 e 7, del Codice; nonché art. 18, comma 1, dalla legge n. 689 del 24/11/1981). In particolare, con atto n. XX del XX, l’Autorità ha ritenuto che l’Azienda ha effettuato il Trattamento di Dati personali in questione in violazione del principio di “integrità e riservatezza”, di cui all’art. 5, par. 1, lett. f), del Regolamento e omettendo di mettere in atto misure tecniche e organizzative per individuare tempestivamente una violazione, nonché per assicurare su base permanente la riservatezza, l’integrità, la disponibilità e la resilienza dei sistemi e dei servizi di trattamento, in violazione dell’art. 32 del Regolamento.

L’Azienda ha fatto pervenire le proprie memorie difensive, ai sensi dell’art. 166, comma 6, del Codice. In particolare, con nota del XX, ha dichiarato che:

“l’Azienda nasce il 1° gennaio 2017 in forza della riforma sanitaria della Regione del Veneto avvenuta con la Legge Regionale del 25 ottobre 2016 n. 19 (“Legge Regionale”). Per effetto della Legge Regionale, come successivamente integrata e modificata, l’ex Azienda ULSS n. 16 di Padova modificava la propria denominazione in Azienda ULSS 6 Euganea, incorporando le soppresse ULSS n. 15 Alta Padovana e ULSS n. 17 Este”;

“l’Azienda ad oggi risulta essere una realtà grande e complessa, per un bacino d’utenza di oltre 920.000 assistiti, appartenenti a 101 comuni, in un’estensione territoriale di 2.127 Kmq, con una densità di circa 437 abitanti/Kmq, risultando così l’azienda sanitaria più popolata e con la densità più elevata della Regione del Veneto”;

l’Azienda è organizzata in 5 distretti sociosanitari (3 distretti centrali a Padova e 2 distretti per alta e bassa padovana); in virtù della menzionata Legge Regionale, nell’Azienda, ente a rilevanza provinciale, insistono 4 ospedali spoke: 2 Ospedali nell’alta padovana (…), 1 Ospedale al centro (…) e 1 Ospedale di Rete nella bassa padovana (…) nonché una struttura riabilitativa provinciale”;

“al XX l’Azienda contava 7.166 dipendenti tra cui 1.089 medici e veterinari, 43 altri dirigenti dei ruoli tecnico, professionale e amministrativo, 3.824 infermieri, 1.530 operatori sanitari (OSS e OTAA) e 680 amministrativi”;

“la Legge Regionale ha altresì istituto l’Ente di Governance della Sanità regionale veneta, denominato “Azienda Zero”, anch’esso al di fuori del Perimetro dell’Azienda, al quale la Regione del Veneto ha attribuito le funzioni in materia di gestione di attività tecnico-specialistiche, tra le quali, all’art. 2, c. 1, lett. g) n. 6 funzioni inerenti “la gestione di attività tecnico specialistiche per il sistema e per gli enti del servizio sanitario regionale quali, le infrastrutture di tecnologia informatica, connettività, sistemi informativi e flussi dati in un’ottica di omogeneizzazione e sviluppo del sistema ICT”;

“prima della riforma attuata con la Legge Regionale, le due aziende ex ULSS15 ed ex ULSS17 disponevano ognuna di un proprio sistema informatico, governato e gestito da una Unità Operativa Complessa aziendale (UOC) con a capo, rispettivamente, un Dirigente informatico; ciò in quanto tali aziende erano dotate di autonoma personalità giuridica e organizzativa. L’ex ULSS16, invece, derivava da un modello organizzativo introdotto solo nell’area padovana nel 2003, in cui la gestione della struttura informatica era governata unitamente all’Azienda Ospedaliera di Padova da un “Dipartimento strutturale interaziendale di Information Technology” diretto da un Dirigente informatico nominato di comune accordo dalle due aziende. Tale modello fu successivamente abbandonato. Al momento della riforma introdotta con la Legge Regionale, erano ancora in atto le complesse e onerose procedure di separazione dei sistemi informatici tra le aziende del padovano”;

“la Legge Regionale (…), avendo avocato in capo alla neocostituita Azienda Zero molte funzioni di supporto all’intero sistema sanitario, compresa “l’acquisizione e/o definizione delle infrastrutture di tecnologia informatica, connettività, sistemi informativi e flussi dati in un’ottica di omogeneizzazione e sviluppo del sistema ICT regionale” prevedeva che le nuove aziende, seppur accorpate e di notevoli dimensioni, potessero avere al loro interno, per il governo dell’area informatica, solo strutture organizzative inferiori, ossia Unità Operative cosiddette “Semplici” (UOS)”;

“dal 2017 (…) a seguito della Legge Regionale iniziava un complesso processo che prevedeva da un lato l’unificazione dei sistemi informativi delle tre ex AULSS 15,16 e 17 (“Unificazione”) e dall’altro la prosecuzione della separazione dei sistemi informativi precedentemente in essere per l’ex ULSS16 con l’Azienda Ospedaliera di Padova (“Separazione”). Il processo di Unificazione e Separazione ha poi subito rallentamenti durante la pandemia negli anni 2020-2021, in quanto i sistemi informativi dell’Azienda si sono visti impegnati a dare supporto alle attività destinate all’emergenza sanitaria. Tra le attività dagli stessi svolte si ricordano: realizzazione infrastruttura informatica per gestione dei varchi; supporto alle riorganizzazioni logistiche dei reparti (realizzazione semi-intensive e intensive) coerentemente con i piani emergenziali; supporto al processo di laboratorio analisi per i tamponi: dotazione informatica dei punti prelievo, integrazione delle apparecchiature, adeguamenti software secondo le specifiche regionali, re-indirizzamento degli esami ai diversi laboratori, generazione flussi verso Azienda Zero, ecc.; supporto trasversale all’estrazione ed elaborazione di dati; impegno nella realizzazione dei sistemi di prenotazioni vaccini e tamponi. Il processo di Unificazione, aggravato dall’emergenza pandemica, ha avuto un rilevante impatto sulla riorganizzazione in sicurezza delle reti aziendali”;

“tutti gli acquisti tecnologici necessari alla riorganizzazione e potenziamento delle infrastrutture in sicurezza erano e sono subordinati, in virtù della Legge Regionale, alla previa autorizzazione della Commissione Regionale per gli Investimenti in Tecnologia ed Edilizia (CRITE). In tale contesto, rilevano ai fini della presente memoria difensiva le richieste di autorizzazione agli investimenti in area informatica per ulteriori investimenti in attrezzature informatiche nell’anno XX (..) e per il biennio 2021-2022 (…) effettuate dall’Azienda alla CRITE, relative a finanziamenti per l’acquisto di infrastrutture necessarie all’adozione di misure volte a migliorare la sicurezza delle reti . […] nella richiesta di finanziamenti per il biennio 2021-2022, l’Azienda dava atto di un fabbisogno aggiuntivo di euro 5.658.448 per importanti investimenti, tra cui “il miglioramento della gestione del rischio anche ai sensi delle misure AGID e del GDPR” e, segnatamente, per interventi sulla “infrastruttura per la sicurezza AGID (firewall, sonde IDS, controllo a norma log, vulnerability assessment, penetration test, ecc.)””;

“tuttavia, la CRITE riscontrava parzialmente tali richieste soltanto in data XX (a distanza di un anno dalla prima richiesta) […] rinviando le coperture degli investimenti di importo pari o superiore ad € 200.000,00 alla presentazione alla Commissione delle singole progettualità e con indicazione di aggiornare il Piano degli Investimenti, in ragione delle modifiche intervenute”. Con le limitate risorse a disposizione, in data XX, veniva comunque dato avvio alle attività del Documento Programmatico della Sicurezza aziendale (DDG n. XX del XX) […] che prevedeva tra le altre cose anche l’implementazione delle VPN MFA, oggetto già della prima richiesta di finanziamento per il 2020”;

“l’Azienda ha notificato a codesta Autorità Garante, ai sensi dell’art. 33 del Regolamento, la Violazione dei dati personali in data XX, provvedendo a integrare con successive note del XX e XX, XX e XX, XX e, infine, trasmettendo la chiusura definitiva in data XX. Solo il XX, a distanza di ben 370 giorni dalla chiusura della notifica, (…) l’”Autorità Garante procedeva” (..) a ispezioni (durate tre giorni). (…), deve necessariamente essere rilevata l’illegittimità della durata della fase di accertamento che ha preceduto la notifica della Comunicazione. Come già rilevato la Comunicazione è stata notificata il XX, a distanza di 477 giorni dalla notifica di chiusura del data breach e di 105 giorni dalla fine delle ispezioni condotte da codesta Autorità Garante presso i locali dell’Azienda”;

“anche l’attività sanzionatoria condotta da codesta Autorità Garante è soggetta al rispetto dell’art. 14, comma secondo, della legge n. 689/1981 […]. Giova altresì richiamare la giurisprudenza del Consiglio di Stato” in ordine al termine per la contestazione dell'infrazione da parte dell’Amministrazione (cfr. Cons. Stato, sent. 1330/2015)”;

“il lungo lasso già trascorso è peraltro già superiore ai “180 giorni dalla notificazione della violazione dei dati personali” previsti dal Regolamento 2/2019 di codesta Autorità Garante per la tipologia “Procedimento relativo alla Violazione dei dati personali (articoli 33 e 34 del RGPD)” (cfr. tabella B, parte 1). Si ritiene, pertanto, che il procedimento sanzionatorio avviato con la Comunicazione nasca viziato in modo insanabile in ragione dell’abnorme lasso temporale intercorso tra l’invio della notifica di chiusura del data breach e l’avvio dello stesso”;

nel merito della questione “si consenta di contestare la ricostruzione operata da codesta Ill.ma Autorità Garante in quanto fondata esclusivamente sulle parziali informazioni acquisite durante l’attività ispettiva, nel corso della quale non era presente, poiché dimissionario, colui che, all’epoca della violazione, era il Responsabile dei Sistemi Informativi dell’Azienda e che, precedentemente all’incidente, si era occupato delle attività relative alla messa in sicurezza delle reti. (…). Quanto dichiarato nel verbale del XX a pag. 3 relativamente alle VLAN deve pertanto necessariamente essere integrato con le dichiarazioni, successivamente acquisite dall’Azienda dell’ing. (…) che, in qualità di Responsabile dei Sistemi Informativi, aveva a suo tempo gestito tale aspetto”;

a integrazione di quanto dichiarato durante le attività ispettive “nonostante le difficoltà connesse all’Unificazione di cui al primo paragrafo, alla data dell’incidente, afferma l’ing. (…), con la conferma anche degli allora suoi collaboratori (…), che “alla data del XX, anche in ragione dei finanziamenti disponibili, erano state completate le seguenti attività: - definizione del piano di indirizzamento per tutta l’Azienda, configurazione e segmentazione del nuovo Datacenter di Camposampiero; - messa in esercizio del nuovo dominio AULSS 6. Inoltre erano in fase avanzata di realizzazione: la configurazione dei vari applicativi sul nuovo dominio con contestuale migrazione dai vecchi datacenter, aggiornamento e inserimento in rete nelle varie VLAN definite”;

“pur non essendo completato il piano di partizionamento su tutte le sottoreti delle sedi dell’Azienda va chiarito che al momento dell’incidente era presente in ogni caso una separazione mediante VLAN di tutti i principali flussi di comunicazione dati da e per tutti i datacenter verso le diverse sedi. Peraltro, è possibile affermare con ragionevole certezza che neppure il completamento della segmentazione e segregazione, comunque già in atto, avrebbe potuto impedire il verificarsi dell’incidente, per le ragioni di seguito indicate e per la tipologia dello stesso”;

“le VLAN rappresentano sicuramente un metodo per segmentare un dominio di broadcast in più domini di dimensione ridotta. Al livello OSI 2, ogni VLAN contiene solo il traffico dei dispositivi appartenenti a quella VLAN. Con le VLAN si possono creare gruppi di lavoro con dispositivi ubicati fisicamente in qualsiasi punto di una rete, che possono però comunicare come se fossero sullo stesso segmento fisico, come indicato negli schemi di seguito riportati per chiarezza espositiva. Ne discende che un utente che possieda credenziali di amministratore di una rete informatica può riuscire ad accedere alle “management VLAN” che servono a configurare e manutenere le VLAN negli ambienti complessi e, quindi, è nelle sue facoltà collegarsi alle stesse, modificarle e alla fine bypassarle quali misura di sicurezza per ridurre l’impatto di un attacco quale quello operato dai due attaccanti nell’incidente in questione”;

“tali riflessioni trovano altresì conferma nella dichiarazione di XX, che precisa: “un amministratore di sistema, quale era divenuto l’attaccante, in data XX, avendo facoltà di effettuare movimenti laterali tra i sistemi server e DB poteva accedere alle diverse reti VLAN rendendo per tale fattispecie tale misura di sicurezza meno efficace””;

“l’attaccante ha agito inizialmente con account di utenti senza privilegi e successivamente con account di amministratore di sistema di tipo legittimi, in un lasso di tempo relativamente breve. Per la natura del ruolo assunto dall’attaccante nell’ultima fase, dunque, il completamento del processo di segregazione e segmentazione non avrebbe costituito l’ulteriore misura di sicurezza in grado di prevenire in concreto quanto accaduto. Cionondimeno, come chiarito in sede ispettiva, si conferma che il processo di segregazione e segmentazione era stato ampiamente avviato non appena sono state assegnate le necessarie risorse economiche e comunque prima dell’incidente e che detto iter è stato comunque completato successivamente allo stesso, al fine di minimizzare l’impatto di attacchi informatici di diversa natura rispetto a quello occorso”;

“quanto alla contestata assenza del doppio fattore di autenticazione delle VPN […]  con riferimento alle VPN accessibili con utenze senza privilegi (dunque di tipo non amministratore), nel caso di specie utilizzate dagli attaccanti nel periodo intercorrente tra il XX e XX […] si dà evidenza che al momento dell’incidente il doppio fattore di autenticazione non costituiva neppure una misura prevista al livello massimo da AGID nelle "Misure minime di sicurezza ICT per le pubbliche amministrazioni. (Direttiva del Presidente del Consiglio dei ministri 1° agosto 2015)” di aprile 2017, vigenti ratione temporis”;

“con riferimento alle VPN accessibili con utenze di amministratore di sistema, il cui primo accesso è avvenuto solo in data XX le citate Misure di sicurezza dell’AGID prevedono il doppio fattore di autenticazione solo per le “utenze privilegiate e dei diritti amministrativi”, classificando la relativa misura come un livello “Alto”. E, comunque, si ribadisce che l’implementazione del doppio fattore di autenticazione era in corso per garantire i livelli massimi di cui alle citate misure di sicurezza dell’AGID, posto che l’Azienda aveva fatto richiesta alla CRITE ben due anni prima della data dell’incidente e che aveva ricevuto solo parziale autorizzazione nel XX. A seguito dell’autorizzazione, l’Azienda si era prontamente attivata per implementare tale misura, inserita nel documento programmatico di sicurezza del XX, che tuttavia necessitava di tempistiche di realizzazione tali da non essere in vigore al momento dell’incidente. Si precisa che in ogni caso alla data dell’incidente, seppure non ancora implementata la MFA (Misura 5.6.1) era attiva l’alternativa misura di elevata robustezza delle Password per le utenze amministrative (Misura 5.7.1) da usarsi “quando l’autenticazione a più fattori non è supportata” espressamente indicata come equipollente dalle citate Misure di sicurezza dell’AGID (si veda allegato XX degli scritti difensivi del XX). Inoltre, valga rilevare come successivamente all’incidente tutte le VPN attive, sono state dotate di MFA”;

“ciò che rileva ai fini della tempestiva azione del Titolare del trattamento, il quale è tenuto a notificare all’Autorità Garante la violazione entro 72 ore, è il momento a partire dal quale egli ha avuto conoscenza della divulgazione o dell’accesso non Autorizzato o accidentale ai Dati personali (art. 33 par. 1 del Regolamento). Sul punto occorre altresì richiamare il considerando 87 del Regolamento” e le Linee guida sulla notifica delle violazioni dei Dati personali ai sensi del regolamento (UE) 2016/679, adottate il 3 ottobre 2017, Versione emendata e adottata in data 6 febbraio 2018. WP250;

“il “sospetto di violazione” sussiste solo in presenza di elementi idonei a far presumere (i.e. senza ragionevole certezza), la “divulgazione o accesso non Autorizzato o accidentale ai dati personali” evidenziando che nelle citate Linee guida del 2017 è stato “chiarito che al fine di individuare tempestivamente una violazione è opportuno non sottovalutare, bensì analizzare, i sospetti della stessa, sebbene le misure per porvi rimedio necessitino che il Titolare del Trattamento sia effettivamente “a conoscenza” della violazione. Di conseguenza, il Titolare del Trattamento deve “disporre di procedure interne per poter rilevare una violazione e porvi rimedio. Ad esempio, per rilevare talune irregolarità nel Trattamento dei dati, il Titolare o il Responsabile del Trattamento può utilizzare alcune misure tecniche certe come il flusso di dati e gli analizzatori di registri, dai quali è possibile definire eventi e allerte correlando qualsiasi dato di registro”;

“in questo contesto, il Titolare del Trattamento deve adottare misure tecniche organizzative (ex art. 32 del Regolamento) idonee a individuare, trattare e segnalare tempestivamente una violazione. Ebbene, come risulta dalla lettura della Second Opinion svolta da Yarix (“Second Opinion”), gli attaccanti nel periodo XX - XX hanno avuto accesso ai sistemi dell’Azienda sfruttando VPN con account di utenti senza privilegi […]; il primo accesso alla VPN con privilegi di amministratore di sistema è stato effettuato in data XX alle ore 21.25 e pertanto pochissime ore prima che si concretizzasse la conoscenza effettiva della violazione. L’Azienda, al momento della conoscenza dell’incidente (XX), disponeva di misure tecniche ed organizzative idonee a individuare, trattare e segnalare tempestivamente una violazione alla sicurezza del Perimetro della rete mediante accessi VPN non autorizzati o forzati. Tali misure, tuttavia, non potevano consentire di valutare gli accessi effettuati prima del manifestarsi della violazione come sintomatici di una violazione, in quanto effettuati utilizzando credenziali di accesso valide (…); solo successivamente al manifestarsi della violazione in data XX si è potuto ricostruire che gli accessi in questione fossero in realtà effettuati da soggetti che abusivamente erano venuti in possesso di quelle valide credenziali”;

“le misure adottate dall’Azienda per l’individuazione tempestiva della violazione consistevano, oltre a quanto già precedentemente dichiarato agli atti, anche nelle attività affidate alla società XX, in virtù della Convenzione Consip “Servizio di Gestione e Manutenzione dei Sistemi IP e delle Postazioni di Lavoro” (SGM). In particolare, XX […] doveva svolgere autonomamente una serie di attività volte alla gestione degli apparati di sicurezza […];  le attività oggetto della Convenzione Consip ed affidate a XX risultano in linea con le indicazioni del Gruppo di Lavoro relativamente alla tempestiva individuazione di una violazione, tra cui “Ad esempio, per rilevare talune irregolarità nel Trattamento dei dati, il Titolare o il Responsabile del Trattamento può utilizzare alcune misure tecniche certe come il flusso di dati e gli analizzatori di registri, dai quali è possibile definire eventi e allerte correlando qualsiasi dato di registro”. A tal proposito valga rilevare come XX abbia dichiarato all’Azienda di aver svolto le predette attività previste contrattualmente ed in particolare: “a) servizio di monitoraggio H24, intervento e analisi proattiva anche per le problematiche di sicurezza informatica svolto mediante i sistemi impiegati per la conduzione dei servizi di gestione e manutenzione degli apparati dell’Amministrazione in particolare per gli apparati firewall, router/switch e server; b) analisi periodica dei log per la ricerca di eventi anomali (tentativi di accesso, traffico anomalo, attacchi virali, violazione delle policy, ecc. e qualsiasi evento potenzialmente dannoso). Ciò premesso si ribadisce come i sistemi di monitoraggio in uso fossero configurati per l’alerting in caso di anomalie di funzionamento degli apparati oggetto di convenzione ovvero interruzione delle loro funzionalità e/o degrado delle prestazioni (punto a.) mentre le policy utilizzate per la ricerca di eventi anomali (punto b.) prevedevano warning per XX;

“nel caso di specie l’attaccante ha agito inizialmente con account di utenti senza privilegi e successivamente con account di amministratore di sistema di tipo legittimi, in un lasso di tempo relativamente breve, con limitati tentativi di accessi (no brute force), da nazioni non presenti in black list e senza causare anomalie di funzionamento agli apparati sotto monitoraggio (nessun denial of service è stato rilevato nel periodo antecedente il XX). Tale fattispecie non sarebbe probabilmente stata rilevata neppure da SOC evoluti che non fossero stati dotati di sistemi di machine learning e algoritmi di Artificial Intelligence capaci di rilevare in real time le deviazioni significative dal comportamento “normale” di ciascun utente, dispositivo e/o subnet dell’organizzazione (…); solo dopo ulteriori approfondimenti, in data XX, la Società Yarix, a cui l’Azienda ha commissionato la Second Opinion, ha potuto considerare i precedenti accessi a far data XX quali attività collegate all’incidente”;

“tenuto conto delle modalità dell’incidente e delle attività svolte per prevenirlo e individuarlo, nonché del periodo storico-tecnologico diverso da quello odierno (l’incidente è avvenuto alla fine dell’anno XX), all’Azienda non può essere mosso un rimprovero in termini di assenza di misure idonee alla tempestiva individuazione dell’incidente”;

“tra i parametri che i titolari del Trattamento sono chiamati a prendere in esame nella individuazione delle misure di sicurezza idonee per lo specifico Trattamento rilevano, ai sensi dell’art. 32 del Regolamento, lo “stato dell’arte” e i “costi di attuazione”. Rispetto allo “stato dell’arte” deve ritenersi che lo standard definito dalle Misure di sicurezza dell’AGID del 2017 costituissero per un’amministrazione pubblica come l’Azienda un indubbio parametro di riferimento utile a valutare, con le conoscenze di allora, l’adeguatezza delle misure di sicurezza in essere al momento della violazione. Peraltro, non risulta chiarito nell’atto di contestazione, quali ulteriori misure di sicurezza avrebbe dovuto adottare l’Azienda al fine di prevenire l’incidente verificatosi. Anche l’eventuale disponibilità di ulteriori “log di firewall”, come rilevato nella Comunicazione, non avrebbe infatti consentito di rilevare prima la violazione, al più di provare a risalire all’identità degli attaccanti, attività comunque irrilevante per Codesta Ill.ma Autorità Garante”;

“al contrario, come si è avuto modo di dimostrare, anche in presenza di una control room che monitorasse i flussi di dati non sarebbe stato possibile individuare prima la violazione. Infatti, l’attacco si è verificato utilizzando le credenziali di una utenza senza privilegi e, per di più, accedendo non da Paesi nella c.d. black list. Probabilmente, un attacco così strutturato verrebbe identificato prima solo da una moderna control room in grado di elaborare i dati anche mediante strumenti applicativi di intelligenza artificiale. Ma, si ribadisce, ai fini del presente procedimento deve prendersi in considerazione lo “stato dell’arte” del 2021. A quanto detto si aggiunga necessariamente che le valutazioni sui “costi di attuazione” esulano dalla sfera di competenza dell’Azienda e che, in forza della Legge Regionale, sono di esclusiva competenza della CRITE. L’Azienda, infatti, a più riprese aveva fatto richiesta di implementare ulteriori misure di sicurezza, ma la CRITE non aveva avallato tali richieste […] non assegnando maggiori fondi (…)”;

“sulla violazione del principio di integrità e riservatezza si contesta in toto la ricostruzione operata, essendo l’Azienda all’epoca dell’incidente in linea con le Misure di sicurezza dell’AGID e non essendo peraltro provato che ulteriori, ma non meglio specificate, misure di sicurezza avrebbero scongiurato la violazione occorsa o avrebbero consentito all’Azienda di accorgersi prima della stessa. Inoltre, l’Azienda non era nella materiale disponibilità di implementare misure tecniche differenti da quelle preventivamente approvate dalla CRITE, pena l’incorrere in violazioni di tipo erariale (e finanche di rilievo penale)”;

“il numero degli interessati coinvolti è pari a 9.520 (di cui nr. 8.535 interessati da violazione di dati di salute e nr. 985 interessati da violazione di dati anagrafici, di contatto, di accesso e di identificazione), su un totale di più di 920.000 pazienti afferenti alla Azienda. Pur tuttavia […]  dal riesame dei documenti oggetto di esfiltrazione è emerso che il numero effettivo degli interessati, a cui si riferiscono i dati della salute, sia sostanzialmente inferiore, in ragione di bias ascrivibili al software di intelligenza artificiale utilizzato. Si conferma che i Dati personali esfiltrati e pubblicati in esame si riferiscono a documenti presenti nei PC e non nei server aziendali, in spregio alle policy aziendali esistenti già agli atti”;

“l’Azienda è stata vittima di un attacco hacker ai propri sistemi informativi operato da due distinti threat actor – XX e XX – che hanno agito quasi contemporaneamente. L’Azienda era dotata di misure di sicurezza, tecniche ed organizzative adeguate per il periodo storico-tecnologico in cui è occorsa la violazione (XX), circostanze che escludono la sussistenza di qualsivoglia forma di colpa in capo alla Azienda, anche nella forma più lieve ed eventuale. Al più, si ritiene possa ascriversi all’Azienda un errore in buona fede, avendo la stessa operato nel rispetto della normativa di settore all’epoca vigente e avendo acquisito solo in seguito contezza che fosse necessario integrare dette misure, come peraltro già programmato”;

“all’epoca dell’incidente” erano “operative in seno all’Azienda tutte le misure di sicurezza individuate dall’AGID e (…) la stessa si (…)” era “proattivamente attivata per apportare ulteriori migliorie, sebbene non richieste dalla normativa di settore vigente all’epoca dei fatti” (…), l’errore, se vi è stato, è stato incolpevole, in quanto non suscettibile di essere impedito dall’Azienda, nonostante la (stra)ordinaria diligenza mostrata nel ricercare di porre in essere sempre più evolute misure di sicurezza”, evidenziando lo “straordinario sforzo realizzato dall’Azienda per attenuare gli effetti della violazione per gli interessati. Dopo l’incidente l’Azienda ha immediatamente proceduto a completare il processo di Segmentazione e Segregazione, nonché a prevedere l’autenticazione a due fattori per tutte le utenze. Inoltre, ha attuato tutte le misure tecniche ed organizzative specificate nelle integrazioni di notifica e suoi allegati e ancora verbalizzate durante le attività ispettive e altresì indicate nella Comunicazione”;

“l’Azienda, avvalendosi del supporto dell’Accademia Italiana del Codice di Internet (IAIC), ha erogato tra XX e XX ai dipendenti un corso di formazione e aggiornamento, tarato sulle specifiche attività delle varie categorie dei dipendenti (per i dipendenti del comparto IT pari ad 80 ore), nel quale sono stati coinvolti docenti di primissimo piano e di altissima professionalità. Con lo stesse Ente è in corso di pianificazione un ulteriore corso di formazione”;

“l’Azienda ha cooperato attivamente con l’Autorità Garante sin dalla notifica preliminare effettuata tempestivamente e nelle successive integrazioni, nonché durante l’attività ispettiva” e “ha altresì provveduto a collaborare con le autorità giudiziarie e polizia postale ed effettuato le comunicazioni ex art. 34 del Regolamento (…)”.

Durante l’audizione richiesta, che si è tenuta il XX, l’Azienda, oltre a ribadire sostanzialmente quanto già evidenziato nelle memorie, ha rappresentato che:

- “in ordine alla segmentazione delle reti, alla luce anche delle dichiarazioni rese dagli ingegneri, allegate alle memorie, si evidenzia che il processo di segmentazione, al momento dell’incidente, era in avanzato stato di attuazione; il ritardo, al riguardo, era imputabile ai processi di unificazione e di scorporo delle Aziende afferenti all’odierno titolare; in ogni caso, la segmentazione delle reti non avrebbe impedito i movimenti laterali delle utenze amministrative e non, per le ragioni evidenziate anche dal fornitore XX nel doc. 5, allegato alle memorie; in particolare, i predetti movimenti avrebbero semmai potuto essere individuati solo con SOC molto sofisticati, dotati di sistemi di machine learning e IA, non diffusi nel XX, al momento dell’incidente”;

- “con riferimento alle VPN MFA, erano state adottate le “Misure minime previste per le pubbliche amministrazioni” di Agid nel punto 5.7.1. al livello di attuazione avanzata di robustezza delle Password per le utenze amministrative, da usarsi quando l’autenticazione a più fattori non è supportata quale misura equipollente; cionondimeno, l’implementazione del doppio fattore di autenticazione era comunque stata pianificata e avviata, perché, sin dal XX, era stata richiesta l’autorizzazione all’acquisto e il relativo finanziamento alla CRITE, approvato da quest’ultima solo parzialmente nel XX; nel XX era stato, quindi, presentato dall’Azienda il documento programmatico di sicurezza che prevedeva la MFA, che dava avvio agli investimenti autorizzati; pertanto, a XX era stata avviata tutta l’attività propedeutica alla piena implementazione di tale misura, completata poco dopo l’incidente per tutte le tipologie di utenze”;

- “pur non essendo presente una control room, peraltro non prevista da AGID come misura di sicurezza, la tipologia di Incidente non avrebbe potuto comunque essere rilevata, se non con sofisticati sistemi di IA”;

- “la violazione non ha interessato l’integrità dei dati, ma solo la disponibilità e la riservatezza”;

- “si pone l’attenzione sull’elevato grado di collaborazione con l’Autorità manifestato dall’Azienda, in ogni fase del procedimento, e sulla proattività dimostrata dalla medesima, che ha anche erogato formazione al personale in materia di sicurezza e privacy (si precisa, al riguardo, che il corso con il supporto di IAIC è avvenuto non nel XX, ma nel XX) e ha riorganizzato i ruoli per assicurare un controllo più diffuso e capillare all’interno dell’enorme struttura”;

- “le misure implementate subito dopo l’incidente (cyber e tecniche e organizzative) hanno comportato, ad oggi, una sostanziale riduzione del rischio lordo originario di 12.4 a rischio residuo di 5.58; il risk Assessment è stato effettuato sulla base dei documenti ENISA (Handbook on Security of Personal Data Processing), ISO 27005 e ISO 29134; ciò, a fronte del notevole impegno economico e organizzativo profuso dall’Azienda”;

- “nonostante l’importante campagna stampa, al momento l’Azienda ha ricevuto soltanto 29 richieste di chiarimenti in merito al possibile coinvolgimento nell’attacco informativo e nessuna richiesta risarcitoria”.

4. Esito dell’attività istruttoria

Preso atto di quanto rappresentato dall’Azienda nel corso del procedimento, si osserva che:

si considerano “dati relativi alla salute”, “i Dati personali attinenti alla salute fisica o mentale di una persona fisica, compresa la prestazione di servizi di assistenza sanitaria, che rivelano informazioni relative al suo stato di salute” (art. 4, par. 1, n. 15, del Regolamento);

il considerando n. 35 del Regolamento precisa che i dati relativi alla salute “comprendono informazioni sulla persona fisica raccolte nel corso della sua registrazione al fine di ricevere servizi di assistenza sanitaria”; “un numero, un simbolo o un elemento specifico attribuito a una persona fisica per identificarla in modo univoco a fini sanitari”;

i Dati personali devono essere “trattati in maniera da garantite un’adeguata sicurezza […] compresa la protezione, mediante misure tecniche e organizzative adeguate, da trattamenti non autorizzati o illeciti e dalla perdita, dalla distruzione o dal danno accidentali” (principio di «integrità e riservatezza», art. 5, par. 1, lett. f), del Regolamento);

l’art. 32 del Regolamento stabilisce che “tenendo conto dello stato dell’arte e dei costi di attuazione, nonché della natura, dell'oggetto, del contesto e delle finalità del trattamento, come anche del rischio di varia probabilità e gravità per i diritti e le libertà delle persone fisiche, il Titolare del Trattamento e il Responsabile del Trattamento mettono in atto misure tecniche e organizzative adeguate per garantire un livello di sicurezza adeguato al rischio […]” (par. 1) e che “nel valutare l’adeguato livello di sicurezza si tiene conto in special modo dei rischi presentati dal Trattamento che derivano in particolare dalla distruzione, dalla perdita, dalla modifica, dalla divulgazione non autorizzata o dall’accesso, in modo accidentale o illegale, a Dati personali trasmessi, conservati o comunque trattati” (par. 2);

le “Linee guida 9/2022 sulla notifica delle violazioni dei Dati personali ai sensi del RGPD” adottate dal Comitato europeo per la protezione dei dati il 28 Marzo 2023 -che aggiornano le precedenti “Linee guida sulla notifica delle violazioni dei Dati personali ai sensi del Regolamento (UE) 2016/679” (adottate in ultimo il 6 febbraio 2018 dal Gruppo di lavoro Articolo 29 e fatte proprie dal Comitato europeo per la protezione dei dati il 25 maggio 2018, WP250 rev. 01) esclusivamente per chiarire i requisiti di notifica per i titolari non stabiliti in EU- precisano che “la capacità di individuare, trattare e segnalare tempestivamente una violazione deve essere considerata un aspetto essenziale” delle misure tecniche e organizzative che il Titolare e il Responsabile del Trattamento devono mettere in atto, ai sensi dell’art. 32 del Regolamento, per garantire un livello adeguato di sicurezza dei dati personali;

il considerando n. 87, precisa che “è opportuno verificare se siano state messe in atto tutte le misure tecnologiche e organizzative adeguate di protezione per stabilire immediatamente se c’è stata Violazione dei dati personali e informare tempestivamente l’autorità di controllo e l’interessato”.

5. Valutazioni del Garante e conclusioni.

A fronte di quanto sopra rappresentato, si rileva che i trattamenti effettuati nel contesto in esame richiedono l’adozione dei più elevati standard di sicurezza al fine di non compromettere la riservatezza, l’integrità e la disponibilità dei Dati personali di un numero molto rilevante di interessati. Ciò, tenendo altresì conto delle finalità dei trattamenti e della natura dei Dati personali trattati, appartenenti anche a categorie particolari. Su tale base, gli obblighi di sicurezza imposti dal Regolamento richiedono l’adozione di rigorose misure tecniche e organizzative, includendo, oltre a quelle espressamente individuate dall’art. 32, par. 1, lett. da a) a d), tutte quelle necessarie ad attenuare i rischi che i trattamenti presentano.

Preliminarmente, nel rappresentare che i termini indicati nella tabella 2, allegata al “Regolamento n. 2/2019, concernente l’individuazione dei termini e delle unità organizzative responsabili dei procedimenti amministrativi presso il Garante”, approvato con deliberazione n. 99 del 4 aprile 2019, pubblicato in G.U. n. 107 del 9 maggio 2019 e in www.gpdp.it, doc. web n. 9107640, riguardano gli aspetti relativi agli adempimenti di cui agli artt. 33 e 34 del Regolamento, si evidenzia in ogni caso che, nel caso in cui per la trattazione dell’affare sia necessario lo svolgimento di attività ispettive, il decorso dei termini è sospeso sino alla conclusione delle medesime (art. 6, comma 2, del citato regolamento). Si rileva, inoltre, con specifico riferimento alla contestata tardività dell’avvio del procedimento da parte dell’Autorità, contrariamente a quanto asserito dall’Azienda, l’Ufficio ha notificato lo stesso il XX, nei termini di legge (120 giorni dall’accertamento della violazione), atteso che l’acquisizione di tutte le informazioni rilevanti ai fini di una compiuta valutazione della conformità dei trattamenti in esame con particolare riferimento ai profili della sicurezza, è stata completata soltanto all’esito dell’attività ispettiva, conclusasi l’8 XX e con l’acquisizione degli ultimi elementi, forniti dall’Azienda, con nota del XX a scioglimento delle riserve dell’ispezione.

Alla luce delle valutazioni sopra richiamate, tenuto conto delle dichiarazioni rese dal Titolare del Trattamento nel corso dell’istruttoria e considerato che, salvo che il fatto non costituisca più grave reato, chiunque, in un procedimento dinanzi al Garante, dichiari o attesti falsamente notizie o circostanze o produca atti o documenti falsi ne risponde ai sensi dell’art. 168 del Codice “Falsità nelle dichiarazioni al Garante e interruzione dell’esecuzione dei compiti o dell’esercizio dei poteri del Garante”, gli elementi forniti dal Titolare del Trattamento nella memoria difensiva sopra richiamata e durante l’audizione, seppure certamente meritevoli di considerazione, non consentono di superare del tutto i rilievi notificati dall’Ufficio con il richiamato atto di avvio del procedimento, non ricorrendo, peraltro, alcuno dei casi previsti dall’art. 11 del regolamento del Garante n. 1/2019.

Dall’esame delle informazioni e degli elementi acquisiti nonché della documentazione fornita dall’Azienda è emerso che il Trattamento è stato effettuato in violazione degli artt. 5, par. 1, lett. f), e 32 del Regolamento, in relazione ai seguenti profili:

5.1. Mancata adozione di misure adeguate a rilevare tempestivamente la violazione dei dati personali

Nel corso dell’istruttoria è emerso che il “XX 22:02:12 Primo accesso dalla XX effettuato dall’IP 193.178.169.22 (associato agli attaccanti afferenti al XX) con utilizzo dell’utenza XX” e che i soggetti malintenzionati hanno effettuato una serie di operazioni propedeutiche all’attacco informatico. Le analisi svolte dalla società YARIX non hanno consentito di “risalire alle modalità utilizzate dagli attaccanti per la compromissione degli account privilegiati a causa della cancellazione dei log” e “con riferimento ai log dei firewall (traffico e/o VPN), la limitata retention locale e l’assenza di estrazioni utili (riguardo alcuni di essi) da eseguirsi a ridosso dell’evento, così da evitare la rotazione dei log stessi, non ha permesso l’individuazione di ulteriori evidenze (accessi VPN o traffico verso IP anomali)” (v. report YARIX). L’Azienda ha, inoltre dichiarato che “era presente un sistema di monitoraggio sistemistico ma non una control room”.

Tali elementi non hanno consentito al Titolare del Trattamento di individuare tempestivamente la Violazione dei dati personali occorsa.

Al riguardo, si precisa che le argomentazioni formulate dall’Azienda nelle memorie in ordine all’individuazione del momento in cui il Titolare può considerarsi a conoscenza della violazione e, quindi, a partire dal quale lo stesso è tenuto a effettuare la notifica all’Autorità di controllo, ai sensi dell’art. 33 del Regolamento non rilevano in relazione a quanto contestato nel citato atto di notifica del XX; infatti, il predetto aspetto non è stato oggetto di rilievi da parte dell’Autorità che non ha ravvisato, nei confronti dell’Azienda, un’omissione o un ritardo nella citata notifica di violazione, ai sensi dell’art. 33 del Regolamento. Ciò, che, invece, è emerso è stata l’inadeguatezza delle misure adottate per rilevare tempestivamente la Violazione dei dati personali sulla base di comportamenti anomali, rilevabili dagli accessi in VPN alla rete aziendale (quali, a esempio, l’orario e la frequenza degli accessi, tendenzialmente notturni, la loro provenienza da indirizzi IP di paesi stranieri, che avrebbero dovuto, in ogni caso, essere oggetto di verifica) e dalle operazioni effettuate con gli account di dominio con o senza privilegi amministrativi (quali, a esempio, la disattivazione del software antivirus su alcuni sistemi).

La mancata adozione di misure adeguate a rilevare tempestivamente le violazioni dei Dati personali non risulta conforme alle disposizioni di cui all’art. 5, par. 1, lett. f), e all’art. 32, par. 1, del Regolamento che, nel caso in esame, tenuto conto di quanto previsto dalle Linee guida n. 9/2022 (e dalle precedenti Linee guida sulla notifica delle violazioni dei Dati personali ai sensi del regolamento (UE) 2016/679, adottate il 3 ottobre 2017, Versione emendata e adottata in data 6 febbraio 2018. WP250), richiede che il Titolare e il Responsabile del Trattamento debbano mettere in atto misure per “individuare […] tempestivamente una violazione”.

5.2.2. Mancata adozione di misure adeguate a garantire la sicurezza delle reti

Nel corso dell’istruttoria è emerso che l’Azienda non aveva adottato adeguate misure per segmentare e segregare le reti su cui erano attestate le postazioni di lavoro dei propri dipendenti, nonché i sistemi (server) utilizzati per i trattamenti. Infatti, come evidenziato anche dall’Azienda nel corso delle attività ispettive “i server delle ASL ex 16 ed ex 17 erano attestati su una VLAN dedicata e diversa da quella dove erano attestate le postazioni di lavoro e si stava predisponendo un nuovo ambiente a partire dai 3 Data Center delle 3 ASL”. In relazione a tale aspetto, l’Azienda, a seguito dell’incidente, ha ritenuto necessario implementare “un ambiente con più VLAN isolate e con regole dei firewall”.

Al riguardo, nell’ambito delle attività di analisi della società YARIX, in relazione alla Violazione dei dati personali in esame, è stato rilevato che “questo tipo di minacce si contrasta attuando la cosiddetta defense-in-depth, ovvero l’attivazione di diverse misure di sicurezza su vari strati dell’infrastruttura che separano l’attaccante dall’accesso amministrativo all’intera rete. Sulla base dell'esperienza di Yarix nella sicurezza informatica di tipo tecnologico ed organizzativo, potrà venire analizzato un piano di attività da attuarsi sulla base di priorità concordate, tenendo conto delle peculiarità del settore sanitario in cui molti sistemi informatici vengono certificati dal produttore e non sono modificabili senza perdere la garanzia di corretto funzionamento” (v. all. sez, XX alla notifica del XX).

Al riguardo, si evidenzia che la circostanza che, al momento dell’incidente, l’Azienda aveva avviato alcuni interventi per rafforzare la sicurezza delle reti, non ancora completati a causa dei processi di unificazione e di scorporo delle Aziende afferenti all’odierno titolare, seppur meritevole di considerazione nell’ambito delle valutazioni in ordine alla sussistenza o meno della violazione del principio della protezione dei dati fin dalla progettazione e della protezione dei dati per impostazione predefinita, di cui all’art. 25 del Regolamento, non può essere considerata al fine di ritenere insussistente la violazione dell’art. 32 del Regolamento. La creazione di VLAN - essendo una misura propedeutica a un’efficace segregazione e segmentazione delle reti su cui sono attestate le postazioni di lavoro rispetto a quelle dove sono attestati i sistemi server - deve essere accompagnata da ulteriori misure quali, a esempio, adeguate regole di filtering sui sistemi firewall.

Peraltro, al momento in cui si è verificata la violazione dei dati personali, l’accesso remoto, tramite VPN, alla rete dell’Azienda, avveniva mediante una procedura di autenticazione informatica basata solo sull’utilizzo di username e password. In relazione a tale aspetto, l’Azienda ha specificato che “il XX era stato approvato un “Documento Programmatico sulla sicurezza” per potenziare le misure di sicurezza e adeguarle alle misure minime AgID […] in tale documento era prevista, tra le altre, la misura dell’autenticazione a due fattori per l’accesso in VPN” (v. notifica del XX, sez. XX, punto XX e verbale del XX, pag. XX).

Sul punto, è da rilevare che la circostanza che il doppio fattore di autenticazione costituiva -come sostenuto dalla Azienda nelle memorie difensive- una misura indicata dalle linee guida di Agid, recanti: «Misure minime di sicurezza ICT per le pubbliche amministrazioni” (Direttiva del Presidente del Consiglio dei Ministri 1 agosto 2015), solo per le “utenze privilegiate e dei diritti amministrativi”, non esonera, in generale, il Titolare del Trattamento dall’obbligo di effettuare una valutazione, in concreto, sull’appropriatezza delle misure adottate per garantire la sicurezza del Trattamento tenendo conto del contesto in cui si opera. In particolare, l’adozione delle misure indicate nelle predette linee guida - indicanti, peraltro, le “misure minime di sicurezza per la pubblica amministrazione italiana, avendo ben presente le enormi differenze di dimensioni, mandato, tipologie di informazioni gestite, esposizione al rischio, e quant’altro caratterizza le oltre ventimila amministrazioni pubbliche” - non garantisce, di per sé, il rispetto degli obblighi in materia di sicurezza del trattamento. Le predette linee guida hanno, infatti, lo scopo di “indicare alle pubbliche amministrazioni le misure minime per la sicurezza ICT che debbono essere adottate al fine di contrastare le minacce più comuni e frequenti cui sono soggetti i loro sistemi  informativi”, prendendo le mosse “dall’insieme di controlli noto come SANS 20 […] nella versione 6.0 di ottobre 2015”, e “assicurare il minimo livello di protezione nella maggior parte delle situazioni […] avendo ben presente le enormi differenze di dimensioni, mandato, tipologie di informazioni gestite, esposizione al rischio, e quant’altro caratterizza le oltre ventimila amministrazioni pubbliche”, raccomandando a “ogni amministrazione […] di individuare [al proprio] interno gli eventuali sottoinsiemi, tecnici e/o organizzativi, caratterizzati da omogeneità di requisiti ed obiettivi di sicurezza, all’interno dei quali […] applicare in modo omogeneo le misure adatte al raggiungimento degli obiettivi stessi”. Nello specifico, le Linee guida, essendo state emanate sulla base dello stato dell’arte, delle conoscenze tecniche e delle minacce cibernetiche presenti nel 2015, non potevano tener conto dell’aggravarsi del rischio cibernetico negli ultimi anni anche a causa della diffusione e adozione, durante la pandemia COVID-19, di modalità e strumenti tecnologici per consentire lo svolgimento delle attività (lavorative e non) a distanza. Tale cambio di scenario, visto anche l’aumento significativo degli attacchi da parte dei cybercriminali, avrebbe richiesto, alla fine del XX, una rinnovata valutazione che ponderasse i nuovi e ben più gravi rischi connessi al Trattamento per i diritti e le libertà degli interessati in relazione all’adeguatezza delle misure adottate. La predetta valutazione, non potendo essere cristallizzata e, quindi, conclusa al momento in cui i trattamenti sono stati progettati, avrebbe dovuto essere continuamente effettuata nel corso del tempo, anche alla luce dello sviluppo tecnologico; ciò, anche al fine di maturare una consapevolezza in ordine alla necessità di attenuare i rischi derivanti da violazioni dei dati personali, considerando, altresì, che l’Azienda si avvaleva di due VPN, di diversi fornitori, che hanno costituito, entrambe, il punto di accesso per gli attori malevoli.

L’asserita conformità alle misure indicate nelle predette Linee guida di Agid, quindi, non esaurisce l’obbligo del Titolare del Trattamento di adottare misure adeguate sulla base di una propria valutazione del rischio. Infatti, il Regolamento, in ossequio al principio di responsabilizzazione, demanda al titolare  il compito di individuare e adottare misure tecniche e organizzative idonee a garantire un livello di sicurezza adeguato ai rischi presentati dai trattamenti, che, nel caso di specie risultavano elevati in ragione della natura dei dati trattati, della Larga scala degli interessati, anche vulnerabili, coinvolti, nonché, in caso di violazione, delle possibili conseguenze negative nei confronti degli interessati con particolare riferimento alla compromissione della riservatezza dei dati relativi alla salute loro riferiti.

La mancata realizzazione, al momento della violazione, di misure adeguate a garantire la sicurezza delle reti non risulta pienamente conforme alle disposizioni di cui all’art. 5, par. 1, lett. f), e all’art. 32, par. 1, del Regolamento che, nel caso in esame, richiede che il Titolare e il Responsabile del Trattamento debbano mettere in atto misure per “assicurare su base permanente la riservatezza, l'integrità, la disponibilità e la resilienza dei sistemi e dei servizi di trattamento” (lett. b)).

6. Adozione dell’ordinanza ingiunzione per l’applicazione della sanzione amministrativa pecuniaria e delle sanzioni accessorie (artt. 58, par. 2, lett. i e 83 del Regolamento; art. 166, comma 7, del Codice). 

La violazione degli artt. 5, par. 1, lett. f) e 32 del Regolamento, causata dalla condotta posta in essere dall’Azienda, è soggetta all’applicazione della sanzione amministrativa pecuniaria ai sensi dell’art. 83, par. 4 e 5 del Regolamento.

Si consideri che il Garante, ai sensi degli artt. 58, par. 2, lett. i) e 83 del Regolamento, nonché dell’art. 166 del Codice, ha il potere di “infliggere una sanzione amministrativa pecuniaria ai sensi dell’articolo 83, in aggiunta alle [altre] misure [correttive] di cui al presente paragrafo, o in luogo di tali misure, in funzione delle circostanze di ogni singolo caso” e, in tale quadro, “il Collegio [del Garante] adotta l’ordinanza ingiunzione, con la quale dispone altresì in ordine all’applicazione della sanzione amministrativa accessoria della sua pubblicazione, per intero o per estratto, sul sito web del Garante ai sensi dell’articolo 166, comma 7, del Codice” (art. 16, comma 1, del Regolamento del Garante n. 1/2019).

Alla luce di quanto sopra illustrato e, in particolare, della categoria di Dati personali interessata dalla violazione, del numero di soggetti interessati  e del carattere non intenzionale della violazione, in quanto l’episodio risulta essere stato determinato da un comportamento doloso da parte di soggetti terzi, del quale è stata formalmente interessata la polizia postale, si ritiene che il livello di gravità della violazione commessa dalla Azienda sia alto (cfr. Comitato europeo per la protezione dei dati, “Guidelines 04/2022 on the calculation of administrative fines under the GDPR” del 23 maggio 2023, punto 60).

Ciò premesso, valutati nel loro complesso taluni elementi e, in particolare, che:

- il Garante ha preso conoscenza dell’evento a seguito della notifica di violazione effettuata dall’Azienda, ai sensi dell’art. 33 del Regolamento e da alcune istanze pervenute al Garante sull’accaduto (art. 83, par. 2, lett. h), del Regolamento);

- l’Azienda ha preso in carico la problematica introducendo una serie diversificata di misure, talune già pianificate, volte non solo ad attenuare il danno subito dagli interessati ma anche a ridurre la replicabilità dell’evento occorso (art. 83, par. 2, lett. c) e f) del Regolamento);

- l’Azienda è stata già destinataria di un provvedimento sanzionatorio in relazione a violazioni pertinenti (provv. XX, n. XXX, doc. web n. 9899929) (art. 83, par. 2, lett. e), del Regolamento);

- il Titolare ha cooperato con l’Autorità ben oltre l’obbligo previsto dall’art. 31 del Regolamento in ogni fase dell’istruttoria, ivi compresa quella ispettiva, al fine di porre rimedio alla violazione e attenuarne i possibili effetti negativi (art. 83, par. 2, lett. f), del Regolamento);

si ritiene di determinare l’ammontare della sanzione pecuniaria prevista dall’art. 83, par. 5 del Regolamento, nella misura di euro 22.000,00 (ventiduemila) per la violazione degli artt. 5 e 32 del medesimo Regolamento, quale sanzione amministrativa pecuniaria ritenuta, ai sensi dell’art. 83, par. 1, del Regolamento, effettiva, proporzionata e dissuasiva.

Si ritiene, altresì, che debba applicarsi la sanzione accessoria della pubblicazione sul sito del Garante del presente provvedimento, prevista dall’art. 166, comma 7 del Codice e art. 16 del Regolamento del Garante n. 1/2019, anche in considerazione della tipologia di Dati personali oggetto di illecito trattamento.

Si rileva, infine, che ricorrono i presupposti di cui all’art. 17 del Regolamento n. 1/2019 concernente le procedure interne aventi rilevanza esterna, finalizzate allo svolgimento dei compiti e all’esercizio dei poteri demandati al Garante.

TUTTO CIÒ PREMESSO, IL GARANTE

dichiara l’illiceità del Trattamento di Dati personali effettuato dalla Azienda ULSS n. 6 Euganea, per la violazione dei principi di base del Trattamento di cui all’art. 5, par. 1, lett. f) e degli obblighi di cui all’art. 32 del Regolamento, nei termini di cui in motivazione;

ORDINA

all’Azienda ULSS n. 6 Euganea, con sede legale in Padova, Via Enrico degli Scrovegni, n. 14 – 35131 - C.F./Partita IVA 00349050286, di pagare la somma di euro 22.000,00 (ventiduemila/00) a titolo di sanzione amministrativa pecuniaria, ai sensi degli artt. 58, par. 2, lett. i) e 83 del Regolamento, per la violazione indicata nel presente provvedimento; si rappresenta che il contravventore, ai sensi dell’art. 166, comma 8, del Codice, ha facoltà di definire la controversia mediante pagamento, entro il termine di 30 giorni, di un importo pari alla metà della sanzione comminata;

INGIUNGE

alla predetta Azienda, in caso di mancata definizione della controversia ai sensi dell’art. 166, comma 8, del Codice, di pagare la somma di euro 22.000,00 (ventiduemila/00) secondo le modalità indicate in allegato, entro 30 giorni dalla notificazione del presente provvedimento, pena l’adozione dei conseguenti atti esecutivi a norma dall’art. 27 della legge n. 689/1981;

DISPONE

la pubblicazione per intero del presente provvedimento sul sito web del Garante, ai sensi dell’art. 166, comma 7, del Codice, e ritiene che ricorrano i presupposti per l’annotazione nel registro interno dell’Autorità di cui all’art. 17 del Regolamento n. 1/2019 concernente le procedure interne aventi rilevanza esterna, finalizzate allo svolgimento dei compiti e all’esercizio dei poteri demandati al Garante.

Ai sensi dell’art. 78 del Regolamento, degli artt. 152 del Codice e 10 del d.lgs. n. 150/2011, avverso il presente provvedimento è possibile proporre ricorso dinnanzi all’autorità giudiziaria ordinaria, a pena di inammissibilità, entro trenta giorni dalla data di comunicazione del provvedimento stesso ovvero entro sessanta giorni se il ricorrente risiede all’estero.

Roma, 17 luglio 2024

IL PRESIDENTE
Stanzione

IL RELATORE
Ghiglia

IL SEGRETARIO GENERALE
Mattei