VEDI ANCHE Newsletter del 10 aprile 2024

 

[doc. web n. 10002287]

Provvedimento del 21 marzo 2024

Registro dei provvedimenti
n. 196 del 21 marzo 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 “Codice in materia di protezione dei dati personali, recante 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 “Codice”);

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 Garante 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, in www.gpdp.it, doc. web n. 1098801;

RELATORE la prof.ssa Ginevra Cerrina Feroni;

PREMESSO

1. L’attività istruttoria

Il XX la Regione Lazio (di seguito “Regione”) ha trasmesso all’Autorità, ai sensi dell’art. 33 del Regolamento, una notifica di violazione dei dati personali, riguardante un attacco informatico, determinato da un malware di tipo ransomware, ai sistemi informativi gestiti da LAZIOcrea S.p.a. (di seguito “Società” o “LAZIOcrea”) in qualità di responsabile del trattamento per conto della Regione e di diversi enti del servizio sanitario regionale (notifica successivamente integrata in data XX e XX) .

In considerazione dell’elevato numero di interessati coinvolti e della natura dei dati personali oggetto di violazione, l’Ufficio ha richiesto informazioni alla predetta Società in merito alla citata violazione dei dati personali, nonché alle misure di sicurezza adottate, con particolare riferimento alle misure tecniche e organizzative adottate per garantire la disponibilità e la resilienza dei sistemi e dei servizi di trattamento e il ripristino tempestivo della disponibilità e dell’accesso dei dati personali in caso di incidente (note del XX e XX, a cui LAZIOcrea ha fornito riscontro con note del XX e XX, XX e XX).

Successivamente, è stata effettuata un’attività ispettiva nei confronti della predetta Società nei mesi di XX e XX.

Con la notifica del XX, la Regione ha dichiarato di aver “subìto un attacco informatico che ha compromesso la funzionalità dei servizi offerti dal CED regionale; è in corso in queste ore una verifica tecnica di quanto accaduto, al momento non si è in grado di determinare se ci sia stata perdita dati, le categorie e il numero approssimativo di registrazioni dei dati personali in questione e le eventuali conseguenze della violazione dei dati personali”.

Con nota del XX, LAZIOcrea, in riscontro alla citata richiesta di informazioni formulata dall’Ufficio, ha dichiarato che:

“a seguito dell’attacco informatico occorso nella notte del 31 luglio u.s. (determinato da Malware di tipo ransomware) sono stati disattivati alcuni sistemi informatici della Regione Lazio rendendo temporaneamente indisponibili i relativi servizi, i dati e le informazioni trattate”;

era “impegnata a fornire supporto alle attività di indagine in corso di svolgimento da parte delle forze dell’ordine e delle altre Autorità competenti per la sicurezza nazionali”;

erano “in corso le attività di analisi volte ad appurare l’ambito e la portata della violazione dei dati personali trattati […] una volta appresa nel dettaglio la dinamica degli eventi anche sotto il profilo storico e tecnico”;

si rendeva “necessario operare in parallelo per ripristinare i servizi ponendo in essere tutti i presidi e le cautele atte ad impedire che i sistemi stessi possano subire un ulteriore attacco”.

Successivamente, con nota del XX, LAZIOcrea ha rappresentato che:

“l’attacco è iniziato nella tarda serata del 31 luglio ma se ne è avuta evidenza nelle prime ore della mattina del 1 agosto quando alcune macchine virtuali sono risultate inutilizzabili. Si tratta di un attacco informatico finalizzato alla propagazione di un malware appartenente alla famiglia nota come “RansomEXX”, alias “Defray777” che è stato prontamente segnalato dal nostro servizio di sicurezza informatica al CSIRT ed al CNAIPIC con informativa/esposto a mezzo mail del 1 agosto alle ore 10.22. L’attacco ha riguardato lo strato applicativo della virtualizzazione del data center costringendo la Società a mettere off line tutti i sistemi proprio per garantire che non venisse compromessa l’integrità e la riservatezza dei dati”;

“i servizi essenziali relativi alle attività di emergenza del 112, del 118, dei centri trasfusionali, del Pronto Soccorso e della Protezione Civile non sono mai stati interrotti né compromessi anche nel corso delle attività investigative volte ad appurare la dimensione dell’incidente. In parte perché segregati rispetto alle altre applicazioni”;

“tutti gli altri servizi ed applicativi residenti sul data center sono stati ripristinati o saranno ripristinati […] dopo aver verificato l’avvenuta bonifica da ogni contaminazione residua e/o possibile ed aver riconfigurato i sistemi rispetto all’architettura di sicurezza preesistente. A puro titolo conoscitivo le attività di vaccinazione contro il Covid sono proseguite così come il servizio di prenotazione dei predetti vaccini è stato rispristinato in quattro giorni prima che si rendessero disponibili i nuovi slot di somministrazione. Slot che al momento dell’incidente erano per l’appunto già occupati sino al successivo 13 agosto. A partire dal 16 agosto p.v. i terzi fornitori di applicativi residenti nel data center avranno la possibilità di reinstallare i loro sistemi per riprendere la fornitura dei correlati servizi”;

“l’origine dell’incidente sembra, allo stato, potersi ricondurre all’inoculazione, su uno o più computer client che operavano da remoto tramite VPN, di software malevoli che hanno creato un canale di comunicazione (backdoor) tra i computer client infettati e il gruppo di cyber criminali. I cyber criminali, sfruttando le stesse credenziali, sono così riusciti successivamente ad accedere alla rete aziendale e da là a muoversi “lateralmente” anche all’interno delle c.d. sotto reti effettuando una escalation su utenze amministrative che sono state probabilmente individuate intercettando a basso livello i pacchetti di dati che su quella rete avvenivano al momento del login degli utenti. Detti criminali sembrerebbe abbiano utilizzato le competenze di un altro gruppo di hacker cui sono state passate le password criptate. Quest’ulteriore gruppo di criminali, sfruttando una presumibile vulnerabilità del sistema operativo, è riuscito a decrittare una password che è poi stata abbinata ad uno dei quattro user id con privilegio di amministratore individuati in precedenza dagli hacker”;

“da parte degli esperti sono state poi effettuate verifiche per valutare se l’attacco, che non ha compromesso l’integrità e la riservatezza dei dati, avesse consentito agli intrusi di appropriarsi degli stessi attraverso tecniche di esfiltrazione e/o trasferimento. Le analisi hanno confermato che ad oggi può essere esclusa l’esfiltrazione atteso che nel periodo dell’attacco non si riscontrano flussi dati verso l’esterno”;

“i file ritrovati nelle directory temporanee sono infatti derivanti da automatismi dei tool utilizzati per l’attacco e volti principalmente a verificare l’architettura di sistema e l’inventario delle applicazioni presenti per poi predisporre meglio l’attacco a seconda delle configurazioni di sistema rilevate. Per di più le policy dei firewall attive nel corso dell’attacco non consentivano l’utilizzo dei protocolli FTP, SSH e SFTP dall’interno del perimetro del data center verso Internet. In ogni caso sono tutt’ora in corso attività di “Cyber Threat Intelligence” da parte dei consulenti ingaggiati per verificare che non vengano rese pubbliche informazioni appartenenti a Laziocrea anche se riferite a dati già noti prima dell’attacco. Al momento nonostante la scadenza dell’ultimatum nessuna nuova informazione è stata resa disponibile su web ed in particolare su quello illegale c.d. “darkweb””;

“i dati e le informazioni presenti sui database sono pertanto risultate indisponibili per il tempo necessario al ripristino delle applicazioni ed alla messa in sicurezza del perimetro del data center riconfigurazione dello stesso. Per alcuni sistemi le informazioni rimarranno indisponibili sino alla riattivazione che avverrà in maniera completa nell’arco dei prossimi giorni. Non si ravvedono perciò gravi limitazioni alle libertà ed ai diritti fondamentali degli interessati”.

Da ultimo, con la notifica del XX, LAZIOcrea ha fornito l’elenco delle applicazioni e dei servizi coinvolti nella violazione – con l’indicazione di quelli ripristinati nell’immediato e in corso di ripristino – e l’elenco di quelli rimasti attivi in quanto segregati dall’infrastruttura oggetto di attacco, rappresentando che:

sulla base “delle indagini condotte dalla struttura di Sicurezza Informatica interna, dal CSIRT, dal CNAIPIC e dalla società Leonardo S.p.A. risulta che l'attacco, iniziato alle ore 15:05 del pomeriggio del 31 luglio 2021, è stato originato dalla compromissione di un account appartenente a un dipendente regionale le cui credenziali di accesso sono state sottratte per mezzo di artefatti malevoli (back door) installati sul computer personale dallo stesso utilizzato per i collegamenti da remoto alla rete aziendale necessari per il lavoro in smart working”;

“le attività di analisi forense hanno appurato che gli artefatti sono stati inoculati il 25 marzo 2021 e che gli stessi non erano rilevabili sul computer ospite dai software antivirus e malware. In sede di analisi forense della copia del computer in questione lo scan ha dato comunque esito negativo nonostante il c.d. “database delle firme” del software antivirus/malware fosse stato aggiornato dagli investigatori forensi alla più recente data del 10 agosto. I collegamenti remoti dell’utente con la rete aziendale erano comunque protetti da una VPN”;

“sono emersi anche tentativi di accessi anomali nei confronti di sei account di utenti sull’interfaccia OWA dei sistemi di posta a partire dal 12 aprile 2021 e sino al 26 luglio 2021. Tali tentativi non sembrano però collegati all’incidente e si sono per lo più risolti, con l’eccezione di una utenza, con il diniego di accesso al servizio di posta”;

“in conclusione, l'attacco è stato sferrato nel pomeriggio di sabato 31 luglio 2021 utilizzando il primo account compromesso ed è emerso in maniera percepibile quando nelle prime ore della mattina del 1° agosto si sono cominciati a verificare i primi malfunzionamenti di alcune macchine virtuali del Data Center”;

“l’attacco ha riguardato le macchine ubicate nella Sala “B” [del data center gestito dalla Società], dove presenti diverse tipologie di hardware sia per la parte computazionale che in termini di storage e apparati di rete (sostanzialmente Cisco, Dell, Fortigate, etc. etc.). Trattandosi di macchine modulari e comunque scalabili in termini di dotazioni e caratteristiche computazionali e di storage, le stesse sono gestite da firmware proprietari su cui sono stati installati gli ambienti operativi di virtualizzazione Microsoft Active Directory Hosts e VMWare & Microsoft Hyper-V environment. Su tale ambiente di virtualizzazione sono state configurate ed installate macchine virtuali con sistemi operativi Windows Server e Linux poste a servizio dei servizi e delle applicazioni necessarie ai trattamenti svolti da LAZIOcrea sia come Titolare che come Responsabile di altri Titolari, ed in particolare della Regione Lazio”.

Nel corso delle richiamate attività ispettive LAZIOcrea ha inoltre dichiarato, come indicato nel verbale delle operazioni compiute, che:

“all’esito delle analisi forensi svolte, risulta che, nel mese di marzo 2021, un soggetto malintenzionato ha introdotto all’interno del PC portatile aziendale in uso [… a un] dipendente della Regione Lazio, una backdoor – non nota e non rilevata, né all’epoca né nel corso delle analisi, da più comuni software antivirus e antispyware – che è stata probabilmente utilizzata per acquisire le credenziali di autenticazione” attribuite al dipendente;

“il 31 luglio 2021 le predette credenziali di autenticazione sono state utilizzate per accedere da remoto alla rete della Società e per condurre le azioni prodromiche all’attacco informatico. In particolare, i soggetti malintenzionati hanno effettuato una serie di attività di scansione, finalizzate all’acquisizione di informazioni sulla rete e sui sistemi server ivi presenti. Nell’ambito di tali attività i medesimi hanno individuato il server con hostname “RLWSIRIFT01” su cui era installato software di base per cui non erano più disponibili aggiornamenti o patch di sicurezza del produttore. Tale circostanza era dovuta alla necessità di garantire il funzionamento di un’applicazione web legacy che richiedeva una particolare versione del sistema operativo e dell’application server. Sfruttando vulnerabilità note del software di base presente sul citato server i soggetti malintenzionati sono riusciti a venire in possesso di credenziali di autenticazione con privilegi amministrativi […] utilizzate nelle successive fasi dell’attacco informatico”;

“la Società è venuta a conoscenza dell’attacco informatico mediante una segnalazione di un operatore sanitario che, non riuscendo ad accedere a taluni servizi erogati dalla Società, alle ore 05:00 circa del 1° agosto 2021, ha contattato telefonicamente il sistemista reperibile per i servizi dell’area sanitaria. A seguito della segnalazione e delle prime analisi svolte, il sistemista ha constatato la rilevanza dell’incidente di sicurezza e ha provveduto a contattare altri sistemisti, alcuni dei quali si sono recati immediatamente presso il data center. Alle ore 06:15 circa del XX la segnalazione è stata portata all’attenzione del direttore della Direzione Sistemi infrastrutturali della Società”;

“con riferimento alle iniziative assunte a seguito del rilevamento di “attività ostili” (2.189 allarmi) da parte della “console Microsoft Windows Defender ATP” nella serata del 31 luglio 2021, […] nelle more dell’attivazione del servizio SOC di Leonardo S.p.a., tale strumento di monitoraggio non era presidiato H24” e, pertanto, “non si è potuto gestire tali allarmi con “maggiore” tempestività””.

Nel corso dell’istruttoria LAZIOcrea ha altresì fornito l’elenco dei titolari, ivi inclusa la Regione Lazio, per conto dei quali effettuava i trattamenti di dati personali coinvolti nella violazione.

1.1 Le misure in essere al momento della violazione

Con riferimento alle misure in essere al momento della violazione la Regione, con la notifica integrativa del XX, ha dichiarato che “fermo restando che il Data center e le procedure di LazioCrea S.p.A. per la sicurezza e protezione dei dati sono certificate ISO 27001, si rappresenta che con determinazione dirigenziale n. XX del XX Regione Lazio ha disciplinato l'assegnazione e l'utilizzo delle dotazioni ICT per il personale in servizio […]. Inoltre, nell'ambito del Regolamento di organizzazione degli uffici e dei servizi della Giunta regionale n. 1/2002 e s.m.i. è disciplinato il modello organizzativo in tema di protezione dei dati personali ai sensi degli articoli 473, 474 e successivi. Infine, all'interno della intranet regionale sono disponibili delle frequently asked questions (FAQ) concernenti l'utilizzo dei dispositivi informatici durante lo smart working straordinario”.

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, la Società ha fornito copia delle procedure di backup, del piano di business continuity e disaster recovery, del processo di gestione degli incidenti e della procedura di gestione delle violazioni di dati personali in essere alla data del 31 luglio 2021.

Nel corso delle attività ispettive LAZIOcrea ha dichiarato che:

“utilizza come sistema di autenticazione informatica l’Active Directory di Microsoft. Tale sistema è utilizzato per l’autenticazione degli utenti della Società, della Regione e di altri enti esterni per l’accesso ai sistemi attestati al dominio (postazioni di lavoro e server) e ad alcune applicazioni web, nonché per l’accesso remoto, tramite VPN, alla rete della Società” precisando che “al momento in cui si è verificata la violazione dei dati personali, non era prevista una procedura di autenticazione informatica a più fattori per l’accesso VPN”;

“ha definito password policy differenti per le diverse tipologie di account in uso al personale della Società, della Regione Lazio e di altri enti. In particolare, al momento in cui è avvenuta la violazione dei dati personali, le password degli account senza privilegi amministrativi dovevano essere composte da un numero minimo di 8 caratteri, contenere caratteri di almeno tre categorie (lettere maiuscole, lettere minuscole, numeri, caratteri speciali), non coincidere con le ultime quattro password, ed essere modificate al massimo ogni 90 giorni; le password degli account con privilegi amministrativi dovevano invece essere composte da un numero minimo di 20 caratteri, contenere caratteri di almeno tre categorie (lettere maiuscole, lettere minuscole, numeri, caratteri speciali), non coincidere con le ultime quattro password, ed essere modificate al massimo ogni 30 giorni”;

“ha posto in essere misure per segregare i sistemi che sono presenti all’interno del data center. In particolare, i server che ospitano le diverse banche dati sono attestati a reti segregate rispetto alle altre reti, motivo per cui l’attacco informatico di fine luglio non ha coinvolto i dati conservati all’interno di tali server. Analoghe misure di segregazione sono applicate ai server che erogano servizi particolarmente critici […] o dedicati a specifici clienti […]”;

“con riferimento alle misure di sicurezza relative alla segregazione delle reti, in essere al momento della violazione dei dati personali, “sono presenti due livelli di firewalling: il primo è dedicato al filtraggio delle comunicazioni tra le reti su cui sono attestate le postazioni di lavoro dei dipendenti della Regione Lazio e della Società (attestate su reti LAN accessibili presso le sedi degli uffici regionali e della Società) e quelle su cui sono attestati i sistemi server; il secondo è invece utilizzato per il filtraggio del traffico di rete da e verso il data center e delle comunicazioni tra le reti su cui sono attestati i sistemi server. In particolare, le regole di firewalling sono configurate sulla base delle indicazioni fornite dai diversi responsabili di progetto. In alcuni casi, il filtraggio del traffico di rete è attuato anche tra i diversi layer architetturali di un sistema (front-end, back-end, database) o per i diversi ambienti (sviluppo, collaudo e produzione). Alcuni sistemi o servizi critici […] sono invece attestati a reti dedicate e separate, anche fisicamente, rispetto agli altri sistemi presenti nel data center”;

“a fine luglio 2021, quando si è verificato l’incidente di sicurezza oggetto dell’accertamento ispettivo, le regole di filtering non impedivano, a livello di rete, la raggiungibilità dei sistemi server compromessi dalla rete utilizzata per l’accesso VPN dei dipendenti della Regione Lazio, tra i quali [… l’account del dipendente]. Per tale ragione, i soggetti malintenzionati sono riusciti a effettuare una ricognizione dei sistemi server visibili dalla rete utilizzata per l’accesso VPN, nonché a individuarne uno con sistema operativo obsoleto (“RLWSIRIFT01”) affetto da alcune vulnerabilità note. […] una di queste vulnerabilità è stata poi sfruttata per acquisire le credenziali di autenticazione con privilegi amministrativi […] utilizzate nelle successive fasi dell’attacco informatico”;

“fino al 30 giugno 2021, si avvaleva di un servizio di Security Information and Event Management (SIEM), basato su tecnologia IBM e fornito da Fastweb S.p.a. nell’ambito di una convenzione Consip. Dal 1° luglio 2021 la Società ha attivato un nuovo servizio SIEM, basato su tecnologia Microsoft (Sentinel). Al momento in cui si è verificato l’attacco informatico la Società non disponeva di personale (interno o esterno) dedicato all’analisi H24 degli alert generati dal SIEM di Microsoft, in attesa dell’attivazione di un servizio di security operations center (SOC) fornito da Leonardo S.p.a., poi avvenuta nei primi giorni di agosto 2021”;

“al momento dell’incidente di sicurezza, utilizzava come sistema di gestione dei backup il prodotto Data Domain di Dell. Non erano state definite specifiche procedure di gestione dei backup, ma era previsto che ciascun referente di progetto comunicasse, al momento del rilascio in esercizio, mediante un apposito modello, fra le altre, anche informazioni sul tipo e sulla retention dei backup da effettuare. La periodicità dei backup era giornaliera (con avvio alle ore 20:00 circa)”;

ha eseguito attività di audit sul processo di gestione degli incidenti e ha fornito copia dei piani e dei rapporti di audit;

“con cadenza annuale, effettua attività di audit interno su ciascuno dei processi previsti dal SGSI […] La Società ha pianificato, nell’ambito del programma di audit dell’anno 2022, l’esecuzione di una specifica attività di audit sull’incidente di sicurezza verificatosi a fine luglio 2021, anche al fine di chiudere l’osservazione formulata dall’organismo di certificazione (Apave Certification Italia S.r.l.) nel corso della visita di sorveglianza per il mantenimento della certificazione ISO 27001 avvenuta il XX e il XX” .

1.2 Le misure adottate a seguito della violazione

Con riferimento alle misure adottate a seguito della violazione, la Regione, con la suddetta notifica del XX, ha inteso rimandare “alla documentazione allegata da LazioCrea alla notifica finale del XX”. La Società, con la richiamata notifica del XX, ha rappresentato che:

“al momento dell’incidente unitamente alla messa off line dei sistemi si è provveduto a porre in essere azioni correttive tra cui: i) la costituzione di un team di crisi; ii) l’arruolamento di consulenti esterni esperti nelle attività specialistiche di incident response, cyber security e bonifica dei sistemi; iii) la riattivazione di ogni sistema applicativo previa compatibilità con le attività di indagine e la verifica della sicurezza degli applicativi medesimi anche ricorrendo ad installazioni ponte su ambienti Cloud forniti da provider CSP certificati Agid; iv) l’attivazione di tutte le attività ed i controlli necessari a garantire il perimetro di sicurezza fisica e logica del data center; v) l’individuazione di una serie di azioni di rimedio per aumentare la sicurezza dei sistemi e la conseguente protezione dei dati personali, ciò nonostante i livelli di sicurezza ante attacco rispondessero già agli standard di settore avendo la Società ottenuto la certificazione ISO 27001”;

“in tutti i casi è stata fatta una comunicazione sia sul sito istituzionale della Regione Lazio che su quello di Laziocrea per informare tutti gli utenti e gli interessati dell’effettiva portata del disservizio e dei rischi inerenti i dati personali”;

“sono state ripristinate tutte le applicazioni sia di Titolarità di Laziocrea che gestite da Laziocrea quale Responsabile della Regione Lazio o degli altri Titolari […]. Il trattamento gestito per conto della Regione come Responsabile […] (REG 09 – RES065 nell’ambito di trattamento DSINF 45 -Sviluppo, Manutenzione, Amministrazione, Assistenza all'utente del sistema di Gestione Avvisi e Bandi di Regione Lazio per la Cultura) è stato ripristinato dal back-up e per i Bandi Cine Produzione e Cine Promozione pur contenendo tutte le istanze presentate ha dato alcuni problemi con il ripristino della documentazione allegata alle predette istanze. Il problema riguarda le pratiche finanziate per gli anni 2017-2018-2019 e 2020 che sono circa 1.800, per alcune di queste non è stato possibile ripristinare dai back up tutti gli allegati delle istanze oramai archiviate […]. Vi è comunque la possibilità che parte dei documenti non sia ripristinabile perché corrotto il file ripristinato”;

“al momento non c’è evidenza di esfiltrazione di dati strutturati pur non potendo escludere con assoluta certezza che non possano essere stati visionati o consultati nel corso dell’attacco file contenenti informazioni. Nell’arco temporale in cui è avvenuta la propagazione del ransomware non sono state osservate connessioni verso l’esterno che lascerebbero presupporre un possibile trasferimento non controllato di informazioni”.

Per effettuare le operazioni di ripristino dei dati e dei sistemi, LAZIOcrea, in assenza di strumenti per la decifratura dei “file cifrati dal ransomware”, ha recuperato “porzioni di file di grandi dimensioni mediante l’utilizzo di strumenti di data carving”.

Nel corso delle attività ispettive la predetta Società ha dichiarato che:

“a seguito dell’incidente è stata attivata la procedura con doppio fattore di autenticazione, basata sull’utilizzo di username/password e di una one time password (OTP)”;

“a seguito della violazione dei dati personali, le password policy degli account senza privilegi amministrativi sono state modificate, incrementando la lunghezza minima a 10 caratteri”;

“sulla base delle indicazioni fornite dalla Regione in termini di priorità nel ripristino dei servizi e compatibilmente con le esigenze investigative manifestate dall’autorità giudiziaria, la Società ha provveduto a reinstallare tutti i server del dominio, inclusi i domain controller, utilizzando le copie integre delle diverse applicazioni. Nell’ambito di tale attività di ripristino, la Società si è avvalsa anche della consulenza di Microsoft che ha certificato l’assenza di cc.dd. “utenze civetta” sull’Active directory che potevano essere state create dai soggetti malintenzionati durante l’attacco informatico”;

“adottato un nuovo sistema di gestione dei backup basato su tecnologia Commvault, che è ubicato on premises presso il data center della Società, ma che consente, ove necessario, di utilizzare anche il servizio cloud offerto dal fornitore. Il nuovo sistema consente una più semplice gestione e monitoraggio del backup dei dati e dei sistemi. Tuttora è previsto che ciascun referente di progetto comunichi, al momento del rilascio in esercizio, mediante un apposito modello, fra le altre, anche informazioni sul tipo e sulla retention dei backup da effettuare”;

“a seguito dell’incidente di sicurezza, alcuni servizi e sistemi sono stati ripristinati, e tuttora sono erogati, in ambiente cloud, in particolare: sul cloud AWS di Amazon (data center ubicato in Lombardia) il sistema di prenotazione delle prestazioni sanitarie (ivi inclusi i vaccini e i tamponi anti-SARS-CoV-2) e l’Anagrafe vaccinale regionale; sul cloud Azure di Microsoft (data center ubicato in Irlanda) il sistema di Identity and access management (IAM) e diversi portali web istituzionali (es. portale della Regione Lazio)”;

“a seguito dell’incidente di sicurezza verificatosi a fine luglio 2021 […] ha avviato una serie di iniziative volte a rivedere e rafforzare le regole di filtering applicate alle comunicazioni tra e verso i sistemi server”;

“l’accesso remoto ai sistemi e servizi presenti nel data center avviene mediante VPN (basata su tecnologia Pulse Secure). In tale caso, un primo livello di policy di filtering è effettuato dai concentratori VPN che applicano privilegi e regole diverse in base ai gruppi di dominio di cui l’utente è membro”;

“ha individuato i (pochi) server che, per garantire il funzionamento di alcuni servizi legacy, utilizzano ancora sistemi operativi obsoleti e ha provveduto ad adottare opportune misure di segregazione, a livello di rete, nonché di monitoraggio degli eventi di sicurezza”.

Dalla documentazione in atti si evince che, a seguito dell’attacco informatico in esame, la Regione ha subito la temporanea indisponibilità di numerosi sistemi informativi, attraverso alcuni dei quali sono trattati dati sulla salute degli assistiti del Servizio sanitario regionale (es. sistemi deputati alle prenotazioni sanitarie, alla vaccinazione Covid-19, al teleconsulto, al deposito dei referti relativi ad esami di laboratorio – compresi quelli relativi ai tamponi da Covid-19 – alla ricetta digitale, nonché il sistema dell’anagrafe regionale vaccinale, il portale Salute Lazio). La mancata disponibilità di accesso ai dati conservati sui predetti sistemi, che configura una violazione dei dati personali, è stata, da un lato, una conseguenza diretta dell’attacco informatico (che, cifrando il contenuto di alcuni sistemi server, li ha resi indisponibili) e, dall’altro, una sua conseguenza indiretta derivante dalla scelta di LAZIOcrea di spegnere tutti i sistemi server nell’impossibilità di determinare quali fossero compromessi e, stante l’assenza di una loro segregazione, di evitare un’ulteriore propagazione del malware.

1.3 Il procedimento avviato da parte dell’Autorità

Sulla base di quanto sopra rappresentato, con nota del XX (prot. n. XX) l’Ufficio ha effettuato una notifica di violazione di cui all’art. 166, comma 5, del Codice alla Regione Lazio in quanto è stato rilevato che il trattamento di dati personali in esame è stato effettuato:

in maniera non conforme al principio di “integrità e riservatezza”, in violazione dell’art. 5, par. 1, lett. f), del Regolamento;

omettendo di mettere in atto misure tecniche e organizzative per individuare tempestivamente una violazione dei dati personali, 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;

in maniera non conforme al principio della “protezione dei dati fin dalla progettazione” di cui all’art. 25, par. 1, del Regolamento.

Con nota del XX, la Regione ha chiesto la proroga del termine per presentare le memorie difensive, che è stata concessa dall’Ufficio in ragione della dichiarata “complessità dei sistemi e dei servizi gestiti da LAZIOcrea per conto dell’Ente Regionale Lazio e degli altri titolari” e tenuto conto che “con D.M. del 9 dicembre 2022 è stata fissata la data delle elezioni regionali per il Lazio al 12 e 13 febbraio 2023”.

Con nota del XX, la Regione ha inviato le proprie memorie difensive, nell’ambito delle quali – in via preliminare – dopo aver precisato che “l’incidente accaduto nella notte tra sabato 31 luglio e domenica 1 agosto 2021 ha avuto una enfasi mediatica di gran lunga superiore alle effettive conseguenze dell’attacco informatico sui diritti e le libertà degli interessati”, ha illustrato ruoli e rapporti “della Giunta Regionale (Titolare del trattamento) e di LAZIOcrea spa (Responsabile del Trattamento)”, specificando, al riguardo, che:

“LAZIOcrea S.p.A. è una società per azioni, interamente partecipata dalla Regione Lazio e costituita ai sensi dell’art. 5 della L.R. n. 12 del 24 novembre 2014 secondo il modello organizzativo dell’in-house providing”, la quale presta servizi e attività “alle strutture della Giunta Regionale”, con riferimento, in particolare, ad ambiti di intervento quali: “supporto tecnico-amministrativo, organizzativo e gestionale, connessi all’esercizio delle funzioni amministrative regionali […]; progettazione, realizzazione e gestione della strategia regionale di Agenda digitale, incluso il Sistema Informativo Regionale”;

“l’amministrazione regionale esercita nei confronti della stessa funzioni di programmazione, indirizzo strategico-operativo e controllo. La Regione Lazio esercita nei confronti di LAZIOcrea il c.d. “controllo analogo” e definisce gli obiettivi strategici e operativi. […] La Giunta Regionale, inoltre, approva con propria deliberazione le direttive in ordine alle attività di indirizzo e controllo anche ai fini dell’esercizio del controllo analogo sulla società in house”;

in base anche a quanto definito nello statuto, “la gestione del Sistema Informativo Regionale e del Data Center è, pertanto, totalmente demandata alla Società LAZIOcrea S.p.A”, per cui quest’ultima, “nell’ambito delle proprie competenze, rende disponibili l’infrastruttura e il sistema informativo agli enti aderenti al Sistema Informativo Regionale, allo scopo di dotarli dei servizi informatici necessari al raccordo dei loro sistemi informatici con il predetto Sistema Informativo Regionale”;

“in virtù del fatto che LAZIOcrea, effettuando per conto della Giunta Regionale, trattamenti strumentali all’erogazione di servizi essenziali, opera quale Responsabile del trattamento dei dati personali per la gestione del Data Center per conto del Titolare, è stata formalmente designata in tale ruolo con DGR 797/2017 e DGR 840/2018”, e tale designazione “è stata effettuata avendo evidenza che lo stesso fornisse garanzie ampiamente sufficienti per l’implementazione delle misure di sicurezza tecniche e organizzative adeguate, in termini di conoscenze specialistiche (competenze tecniche in materia di misure di sicurezza e violazioni dei dati), affidabilità e risorse disponibili”.

Con la medesima nota è stato evidenziato che:

“in merito alla individuazione, trattazione e tempestiva segnalazione della violazione, si ritiene che la condotta del Titolare del trattamento sia stata corretta ed adeguata. L’analisi delle tempistiche evidenzia infatti che, a fronte della violazione avvenuta tra il 31 luglio ed il 1° agosto 2021 (vale la pena di ricordare che il 31 luglio era sabato), il Titolare del trattamento, già nella serata del 1° agosto ha provveduto a mezzo PEC, per il tramite del proprio DPO pro tempore, ad informare codesta Autorità sull’incidente, ed in data XX, ha effettuato la notifica preliminare della violazione dei dati personali attraverso la procedura on line disponibile sul sito istituzionale del Garante: tutto ciò pertanto, senza ingiustificato ritardo e nel termine delle 72 ore prescritte dall’art. 33 del Regolamento. Sul punto si specifica inoltre che il Titolare del Trattamento, nell’ambito della sua funzione di controllo, all’epoca dell’accadimento, aveva evidenza del fatto che il Responsabile designato avesse già adottato i più elevati standard di sicurezza al fine di non compromettere la riservatezza, l’integrità e la disponibilità dei dati personali trattati per conto del Titolare”, avendo “conseguito in data 11 dicembre 2020 (data ben antecedente alla violazione in oggetto) la certificazione degli standard di sicurezza per la tutela delle informazioni UNI CEI EN ISO/IEC 27001:2017 per il tramite dell’Ente certificatore, APAVE Certification Italia S.R.L.”;

“in considerazione del fatto che lo stesso Regolamento incoraggia l’utilizzo delle certificazioni da conseguire attraverso appositi organismi di certificazione (artt. 42 e 43 del RGPD), si ritiene che la Giunta Regionale abbia operato conformemente al Regolamento sia nella fase di verifica della sussistenza in capo al Responsabile delle garanzie sufficienti per mettere in atto misure tecniche e organizzative volte ad assicurare trattamenti che presentino adeguata tutela dei diritti dell'interessato (acquisizione della certificazione), sia nella fase di implementazione delle misure e di miglioramento del sistema di sicurezza e di protezione dati, traducendo nel POA 2021 le osservazioni del certificatore in azioni di miglioramento finanziate con appositi stanziamenti di bilancio. Nell’ottica sopra evidenziata il Titolare si è assicurato che gli standard di qualità certificati sul sistema Informativo Regionale e sul Data Center fossero mantenuti anche nella gestione post incidente; al riguardo si evidenzia infatti che, grazie all’adeguamento dei sistemi di sicurezza ed all’adozione delle azioni di miglioramento finanziate nel POA 2021, LAZIOcrea ha conservato la certificazione ISO 27001 anche a seguito delle visite di mantenimento rispettivamente avvenute in data 26-29 novembre 2021 e 24-25 novembre 2022 e conseguito [ulteriori] certificazioni […]. Vale concludere precisando che, nell’ottica di miglioramento, in capo al Responsabile, del sistema di sicurezza e di mantenimento della capacità di porre in essere misure tecniche ed organizzative adeguate, alla data odierna, il Data Center gestito da LAZIOcrea per conto della Regione Lazio risulta anche accreditato presso l’Agenzia per la Cybersicurezza Nazionale (ACN). In assenza di un codice di condotta applicabile, si ritiene che l’adesione del Responsabile del Trattamento ai meccanismi di certificazione sopra richiamati, su input del Titolare, costituisca piena evidenza di sufficienti garanzie per l’attuazione di misure tecniche e organizzative in termini di conoscenze specialistiche, di competenze tecniche in materia di misure di sicurezza e di violazione dei dati e di grado di affidabilità”;

“relativamente alle specifiche istruzioni che il Titolare fornisce al Responsabile del Trattamento, oltre alla designazione della società con DGR 797/2017 e DGR 840/2018 […], rilevino, nell’ambito del rapporto giuridico tra la Giunta Regionale e LAZIOcrea S.p.A., anche i progetti approvati e finanziati in tema cybersecurity contenuti nel Piano Operativo Annuale 2021 di cui alla DGR n. 1024/2020 […]. Con specifico riferimento alla DGR n. 840/2018 si evidenzia poi che nell’allegato G, […] il Titolare, nell’esercizio della sua funzione, ha provveduto a impartire specifiche istruzioni anche in tema di sicurezza del trattamento dati personali”;

con riferimento alla mancata adozione di misure adeguate a rilevare tempestivamente la violazione dei dati personali:

LAZIOcrea, “per conto del Titolare, all’epoca dell’incidente accaduto a luglio 2021 si era già [dotata] della console Microsoft Windows Defender ATP e del Security Information and Event Management (SIEM) di Microsoft i quali hanno correttamente inviato “alert” in merito alla rilevazione di possibili attività malevole. Gli strumenti di rilevazione sopra richiamati erano già in esercizio all’epoca della violazione e sono stati adottati all’interno di una più ampia pianificazione delle attività relative alla cybersecurity che risale a periodo antecedente all’incidente e che, come previsto nell’Allegato B sezione B1 al POA per l’anno 2021 (DGR 1024/2020), avrebbe condotto all’implementazione del servizio denominato “CYBERSECURITY - Implementazione Servizio SOC Interno”; nella citata DGR la suddetta attività è stata finanziata ed è stato effettuato il relativo impegno sull’apposito capitolo di bilancio. […] Vale la pena sottolineare che il Titolare, nell’ottica di adottare misure sempre più adeguate a rilevare tempestivamente potenziali violazioni dei dati personali, ha cooperato con LAZIOcrea per accelerare la messa in operatività del SOC anticipando il completamento della progettazione preliminare degli interventi ai primi mesi del 2021, nonostante, per le pubbliche amministrazioni, l’ordinamento vigente a tutt’oggi ancora non preveda l’obbligo di attivazione di un SOC presidiato continuativamente h24. Pertanto, si intende sottolineare che il comportamento del Titolare e del Responsabile, basato sui principi della prudenza e della cautela, risulta rispondente al principio di conformità al sistema di protezione dati personali sin dalla progettazione e che quindi le azioni poste in essere possono ritenersi tempestive”;

“nelle prime fasi dell’offensiva, il superamento delle misure di sicurezza in atto al momento dell’incidente da parte degli attaccanti non è avvenuto a causa dell’inadeguatezza delle stesse, ma piuttosto a causa dell’utilizzo di strumenti particolarmente sofisticati e non rilevabili in quanto sconosciuti agli antivirus, come avvenuto anche in altre circostanze simili […]. Tali elementi, evidentemente, non possono essere noti prima dell’individuazione della minaccia e, solo in seguito a questa, vengono inclusi nei test di rilevazione da parte degli strumenti di protezione, a seguito degli aggiornamenti rilasciati dal produttore degli stessi. […] Nel caso di incidenti di rilevante complessità, come nel caso di che trattasi, la rilevazione di una violazione di dati personali richiede approfondite e specifiche indagini tecniche prima della conclusione delle quali il titolare non può essere completamente a “conoscenza della violazione” (cfr. Linee guida sulla notifica, p. 12). Quanto sopra dichiarato, unitamente – come giova ripetere - alla tempestività della notifica avvenuta prima con PEC nella serata del XX e successivamente con la notifica preliminare attraverso la procedura on line dal sito istituzionale di codesta Autorità in data XX, dimostra inequivocabilmente l’adeguatezza delle misure adottate in ordine alla immediata rilevazione dell’incidente informatico ed alla successiva valutazione della violazione. Ciò anche a riprova della operatività delle procedure di rilevazione e della cooperazione e comunicazione tra Titolare e Responsabile”;

con riferimento alla mancata adozione di misure adeguate a garantire la sicurezza delle reti:

“le misure di sicurezza in essere al momento dell’attacco hanno consentito un ripristino dei dati a partire dai backup che, evidentemente, non erano stati compromessi in virtù proprio dei sistemi di segregazione in atto. In riferimento alla adeguatezza delle misure relative alla segmentazione e segregazione delle reti, in considerazione che trattasi di argomento di natura tecnica e peraltro di specifica competenza della società in house, come da norma statutaria di quest’ultima, si rinvia integralmente […] a quanto riportato nelle memorie del Responsabile”;

“la separazione logica e la segregazione fisica delle reti, predisposte dal Responsabile del Trattamento, hanno impedito agli hacker di esfiltrare i dati presenti nel Data Center e che non si è determinata alcuna limitazione ai diritti ed alle libertà degli interessati e che l’incidente non ha arrecato danni materiali o immateriali”;

“nell’ambito delle valutazioni sulla garanzia e adeguatezza delle misure adottate dal Responsabile in capo al Titolare si richiama quanto già evidenziato infra, al punto 3.1, in merito alla adesione del responsabile ai meccanismi di certificazione ISO 27001”;

con riferimento all’obsolescenza dei software di base installati su alcuni sistemi di trattamento, nel rinviare sul punto a quanto riportato nelle memorie di LAZIOcrea, viene aggiunto che “nella valutazione del bilanciamento del rapporto costi/benefici, rispetto all’aggiornamento di servizi informatici in produzione, rientrano considerazioni in ordine all’importanza di assicurare continuità ai progetti in essere, tenuto conto delle risorse disponibili e che sarebbe necessario investire, nonché delle effettive disponibilità e del miglioramento che sarebbe possibile conseguire. Al contempo, il fatto di mantenere in esercizio un'applicazione gestita da un sistema che ha raggiunto il termine di “fine vita”, per il quale non sono più disponibili patch o aggiornamenti di sistema, non costituisce in sé una violazione di sicurezza, poiché tale applicazione può opportunamente essere isolata all’interno di un perimetro volto ad assicurarne il funzionamento. Infatti, la vulnerabilità sfruttata dall’agente esterno in relazione alla “privileges escalation” non era esposta all’esterno della rete regionale, come dichiarato nelle memorie del Responsabile”;

con riferimento alla mancata adozione di misure adeguate ad assicurare la disponibilità e la resilienza dei sistemi e dei servizi di trattamento, nel ritenere che “non si possa configurare, in capo al Titolare, la violazione delle disposizioni di cui agli artt. 5, par. 1, lettera f) e 32, par. 1, lettera b)”:

anche in base a quanto emerso durante l’accertamento ispettivo presso la Società, “il backup dei dati veniva in realtà effettuato giornalmente”;

“la certificazione degli standard di sicurezza per la tutela delle informazioni ISO 27001, che contiene specifici item relativi alla gestione dei backup, è stata conseguita dal Responsabile in epoca antecedente all’incidente di che trattasi e che appare evidente che l’Ente certificatore abbia ritenuto le procedure di backup, all’epoca in atto, conformi agli standard di sicurezza. Anche sul punto, pertanto, non può che ribadirsi che la Giunta Regionale, nella sua qualità di Titolare del trattamento dei dati personali, all’epoca dell’incidente avesse specifica evidenza dell’adeguatezza delle misure tecniche e organizzative adottate dal Responsabile volte a garantire la disponibilità e la resilienza dei sistemi. A riprova dell’efficacia dei sistemi di conservazione e recupero dei dati da parte del Responsabile si evidenzia che le procedure di backup in atto al momento dell’attacco si sono rivelate adeguate e funzionanti, tanto che gli applicativi coinvolti dall’incidente sono stati correttamente reinstallati e ripristinati. Per le specifiche misure adottate e per la descrizione dei sistemi di backup in atto, si rinvia integralmente alle memorie del Responsabile”;

“il fatto che il Responsabile successivamente all’incidente si sia dotato di un nuovo sistema di backup non evidenzia affatto l’inadeguatezza di quello già in essere, ma piuttosto la capacità di adeguare, con continui interventi migliorativi, le misure tecniche ed organizzative poste in essere a seguito di continue valutazioni del livello del rischio connesso al trattamento. L’implementazione di ulteriori misure di sicurezza tecniche e organizzative post incidente da parte di LAZIOcrea rientra invero in un più ampio progetto di adeguamento, peraltro, come già detto in prcedenza, in larga parte programmato ed affidato dal Titolare con tempistiche antecedenti all'incidente, che ricomprende tra l’altro sistemi e procedure di backup, disaster recovery e business continuity, volte a migliorare il livello di sicurezza al fine di proteggere le operazioni di trattamento effettuate sui propri sistemi e di mitigare i rischi”;

con riferimento alla protezione dei dati fin dalla progettazione:

“la contestazione in relazione alla protezione dei dati fin dalla progettazione da parte di questa Autorità, non sia contestualizzata nella descrizione di specifici fatti, atti od omissioni ascrivibili ad eventuali condotte non adeguate del Titolare, ma piuttosto costituisca un richiamo alla normativa vigente in merito”;

“il Titolare ha operato nei confronti del Responsabile, tramite l’acquisizione delle certificazioni più volte richiamate, valutazioni in merito all’adeguatezza dei sistemi ed alle misure di contrasto adottate […]. Il Titolare, in considerazione del fatto che l’incidente è avvenuto sfruttando una tipologia di malware non rilevabile dai sistemi/applicativi antivirus disponibili all’epoca (a riprova di ciò, si ricorda che lo stesso non è stato rilevato nemmeno dagli esperti nell’ambito dell’indagine forense quasi due settimane più tardi con sistemi di rilevazione aggiornati al 10 agosto 2021), ha adottato misure tecniche e organizzative che sono da ritenersi oggettivamente adeguate ad individuare tempestivamente possibili violazioni se rapportate al quadro noto all’epoca dei fatti, in tema di cybersecurity. Inoltre, i sistemi di sicurezza in essere presso il Responsabile risultavano idonei ad assicurare su base permanente la riservatezza, l'integrità, la disponibilità e la resilienza dei sistemi e dei servizi di trattamento, nel rispetto, di fatto, anche del principio della “protezione dei dati fin dalla progettazione” di cui all’art. 25, par. 1, del Regolamento. Vale al riguardo osservare che lo stesso art. 25, par 3, del Regolamento ammette che il meccanismo di certificazione possa essere utilizzato come elemento per dimostrare la conformità ai requisiti di cui ai paragrafi 1 e 2 del medesimo articolo”;

“nonostante alcuni dei sistemi coinvolti nell’incidente fossero preesistenti all’entrata in vigore del Regolamento, il Titolare ed il Responsabile, ognuno per la propria competenza, si sono adoperati a revisionare e adeguare le misure di sicurezza in atto in relazione alla protezione dei dati personali. Rimandando alle motivazioni sopra esposte e sottolineando le limitate conseguenze post incidente, si ritiene di fatto che le verifiche e gli adeguamenti operati anche sui sistemi precedenti al RGPD abbiano dato prova di adeguate garanzie sui diritti degli interessati”;

con specifico riferimento al dovere di valutare i rischi per la sicurezza dei dati personali, considerando l’impatto sui diritti e le libertà degli interessati, e contrastare efficacemente quelli identificati, “il sistema di valutazione dei rischi adottato dal Responsabile è da ritenersi adeguato se rapportato alle minacce note all’epoca dell’incidente; in particolare erano presenti sia sistemi antivirus che sistemi di alert. Tuttavia, si ribadisce che il malware, da cui ha avuto origine l’incidente, era di fatto non identificabile tanto da essere sfuggito ai migliori sistemi/applicativi antivirus disponibili nel periodo, anche a quelli adottati per l’indagine forense. […] Il Titolare del Trattamento, inoltre, nell’ambito della sua funzione di controllo, all’epoca dell’accadimento aveva evidenza del fatto che il Responsabile del Trattamento designato avesse adottato i più elevati standard di sicurezza al fine di non compromettere la riservatezza, l’integrità e la disponibilità dei dati personali trattati per suo conto”, sottolineando ancora una volta l’elemento del conseguimento delle menzionate certificazioni da parte della Società;

con specifico riferimento al dovere di tenere conto non appena possibile dei requisiti di sicurezza nella progettazione e nello sviluppo del sistema, integrando e svolgendo costantemente test pertinenti, “la Giunta Regionale ha recepito prontamente le osservazioni contenute nella certificazione conseguita dal Responsabile del Trattamento in data 11 dicembre 2020 e le ha tradotte in concrete azioni di miglioramento nel Programma Operativo Annuale 2021 (POA 2021), approvato con D.G.R 1024 del 22 dicembre 2020”;

con specifico riferimento al dovere di definire il trattamento dei dati in modo tale che un numero minimo di persone abbia bisogno di accedere ai dati personali per svolgere le proprie funzioni, e limitare l’accesso di conseguenza, “l’autenticazione per l’accesso da remoto, tramite “VPN Pulse secure” a singolo fattore, risultava infatti adeguata al quadro generale noto all’epoca dei fatti relativamente alle possibili vulnerabilità dei sistemi ed ai possibili vettori di attacco. Non si rilevano da parte dell’ente certificatore per lo standard ISO 27001:2017 prescrizioni in relazione all’accesso alla VPN con singolo fattore di autenticazione. Come già noto, infatti, gli attaccanti, dopo aver avuto accesso alla rete interna, per poter sferrare l’attacco, hanno dovuto effettuare un movimento laterale per apprendere le credenziali di un utente che avesse i privilegi di amministratore e che consentisse loro l’accesso ad altre sottoreti. Come risulta dalle memorie del Responsabile gli accessi degli amministratori di sistema alla sottorete (diversa da quella degli utenti ordinari), avvenivano, all’epoca dell’incidente, attraverso l’utilizzo di password particolarmente robuste e complesse (20 caratteri contenenti lettere maiuscole, minuscole e caratteri speciali, da rinnovare ogni 30 giorni, e non coincidenza della password in uso con le ultime quattro utilizzate) e, inoltre, la configurazione della rete antecedente all’attacco prevedeva il necessario accesso diretto di tutti gli utenti al server di autenticazione nel dominio. Qualora le reti non fossero state adeguatamente configurate e segregate in termini di accessi e filtraggio le conseguenze dell’attacco avrebbero avuto un impatto rilevante sui diritti e le libertà degli interessati. È opportuno sottolineare che le misure di sicurezza minime previste dall’AgID, prevedono tre diversi livelli (Minimo, Standard, Alto) e, relativamente all’“Uso appropriato dei privilegi di amministratore”, classificano il doppio fattore di autenticazione per gli accessi degli AdS come una misura di livello “Alto”, (si ricorda che le misure obbligatorie sono quelle classificate di livello “Minimo”, cfr. Circolare AgID n. 2/2017 ABSC 5 - CSC 5). Sono considerate, tra l’altro, di livello “Alto” le password di almeno 14 caratteri: pertanto la password di 20 caratteri, prevista per l’accesso ai sistemi da parte degli Amministratori può essere considerata assolutamente ed indiscutibilmente robusta”;

con specifico riferimento al dovere di proteggere i dati personali da modifiche e accessi non autorizzati e accidentali, sia durante il loro trasferimento che durante la loro conservazione, “il Titolare aveva evidenza di adeguate garanzie da parte del Responsabile in particolare in relazione al possesso di certificazioni del sistema di gestione della sicurezza basate su standard internazionali (in particolare ISO 27001:2017 che si fonda su approfonditi controlli di sicurezza in ordine alla disponibilità, confidenzialità ed integrità del dato). In particolare, tutti gli accessi ai sistemi avvenivano tramite protocolli criptati (HTTPS/TLS) che garantiscono la crittografia dei dati in transito”;

con specifico riferimento al dovere di registrare gli eventi rilevanti ai fini della sicurezza delle informazioni e monitorandoli per rilevare in modo tempestivo eventuali incidenti di sicurezza, “il Responsabile all’epoca dell’incidente era dotato di misure adeguate a rilevare tempestivamente le violazioni di dati personali; nello specifico i sistemi relativi alla console Microsoft Windows Defender ATP e al SIEM di Microsoft hanno correttamente inviato alert in merito a possibili attività malevole”;

con specifico riferimento al dovere di garantire il ripristino dei sistemi informatici in caso di disastro e la continuità operativa, assicurando la disponibilità dei dati personali a seguito di incidenti di sicurezza rilevanti, “le misure di sicurezza adottate sia nella fase pre che nella fase post-incidente hanno permesso di ripristinare gli applicativi tramite le copie dei back-up offline. Al riguardo si precisa che è stata garantita la continuità operativa delle applicazioni ed in particolare degli strumenti di supporto alla campagna vaccinale e alla prenotazione delle prestazioni sanitarie, come del resto già esplicitato nella documentazione in possesso di codesta Autorità. Tale ripristino è stato possibile grazie alla configurazione dei sistemi ed alla progettazione del data center che pertanto, sol per questo, rispettano i principi stabiliti dall’art. 25 del Regolamento. Si ritiene dover sottolineare che la temporanea indisponibilità del dato personale (limitata al tempo strettamente necessario al ripristino delle applicazioni) non ha comportato alcun pregiudizio per le libertà ed i diritti degli interessati ed è stata determinata dalla messa in atto da parte del Responsabile delle procedure necessarie a fronteggiare l’attacco al fine di evitare conseguenze peggiori. Non è da sottovalutare il fatto che il citato tempestivo ripristino è stato realizzato proprio perché, grazie alla configurazione dell’architettura dei sistemi ed alla progettazione del Data Center (nel rispetto dei principi dell’art. 25 RGPD), per il quale era prevista una suddivisione in reti e sale logicamente e/o fisicamente separate, i dati personali sono rimasti protetti”;

con specifico riferimento al dovere di disporre di adeguate procedure per gestire le violazioni dei dati personali, comprese procedure per la loro documentazione, “la pronta attivazione da parte della Giunta Regionale e della Società ed il contenimento della potenziale portata dell’incidente, nonché il ripristino dei servizi temporaneamente sospesi (esclusivamente per le verifiche tecniche necessarie) sono tutti elementi che dimostrano ex se la conformità dei sistemi al requisito menzionato”;

in merito agli elementi per le valutazioni di cui all’art. 83, par. 2, del Regolamento:

“l’incidente non ha comportato esfiltrazione di dati e non ha causato nessun danno ai diritti ed alle libertà degli interessati. Come più volte ricordato, l’incidente non ha determinato alcuna perdita di riservatezza ed integrità del dato. Riguardo alla disponibilità, si rileva che la stessa è stata circoscritta al tempo necessario all’Ente per la valutazione dell’incidente e per la messa in atto delle necessarie azioni di mitigazione e remediation. Pertanto, alla luce di quanto sopra, il quadro si riferisce senza dubbio ad una violazione non grave. La durata della violazione, inoltre, è da ritenersi estremamente contenuta rispetto al potenziale impatto che si sarebbe generato in assenza dell’adozione di tutte le operazioni di contenimento dei rischi ampiamente descritte. La temporanea indisponibilità dei servizi regionali non è infatti da inquadrare nell’ambito di una violazione dei diritti e delle libertà degli interessati, ma piuttosto nell’ambito di una necessaria e immediata azione di mitigazione dei possibili rischi proprio a tutela dei diritti e delle libertà degli interessati stessi. A riprova di quanto affermato si ribadisce che gli interventi post incidente non hanno determinato sospensioni ai servizi di emergenza (Ares 118, Protezione civile, NUE 112) e non hanno ostacolato in alcun modo la campagna vaccinale, in quanto la temporanea indisponibilità della piattaforma vaccinale non ha generato alcun ritardo nel sistema di prenotazione che, al momento della sua riattivazione, ha permesso di utilizzare gli slot di prenotazione già disponibili in fase pre-incidente”;

“il fatto che l’attacco hacker sia originato esternamente all’Amministrazione, la natura del malware più volte evidenziata e le modalità di attacco supportano la tesi che gli elementi psicologici in esame non rilevino in alcun modo né in capo al Titolare e né in capo al Responsabile. Pertanto, nelle condotte adottate non si rilevano gli elementi di dolo o colpa”;

“nonostante […] il virus fosse sconosciuto ai migliori e più aggiornati sistemi di rilevazione del periodo, le misure adottate si sono rivelate adeguate ed efficaci ad impedire l’ulteriore propagazione del malware. Pertanto, i fatti descritti supportano efficacemente la tesi dell’adeguatezza delle misure di sicurezza tecniche e organizzative messe in atto ai sensi degli artt. 25 e 32 del Regolamento, ivi comprese le misure di mitigazione post incidente”;

“non risultano precedenti attacchi informatici contro i sistemi della Regione Lazio, pertanto non esistono precedenti violazioni pertinenti ed ascrivibili alla fattispecie di che trattasi”;

“il Titolare ha sempre adottato nei confronti di codesta Autorità un atteggiamento collaborativo e proattivo improntato ai principi di correttezza, lealtà, trasparenza. Valgano in proposito la prima e le successive notifiche inviate periodicamente a codesta Autorità”;

“il Titolare ha provveduto ad effettuate tempestiva segnalazione della violazione. A fronte della violazione avvenuta tra il 31 luglio ed il 1° agosto 2021, il Titolare, infatti nella serata del 1° agosto ha provveduto a mezzo PEC, per il tramite del proprio DPO pro tempore, ad informare codesta Autorità sull’incidente, ed in data XX, ha effettuato la notifica preliminare on line della violazione dei dati personali tramite il portale del Garante, senza ingiustificato ritardo e nel termine delle 72 ore prescritte dall’art. 33 del Regolamento”;

“non sono mai state notificate violazioni relative a questioni dello stesso oggetto, pertanto, non risultano disposti da parte di codesta Autorità i provvedimenti di cui all'articolo 58, paragrafo 2 né nei confronti del Titolare, né nei confronti del Responsabile”;

“in assenza di un codice di condotta approvato ed applicabile alla fattispecie, il Responsabile del Trattamento, su impulso del Titolare, ha conseguito in data 11 dicembre 2020 (data antecedente alla violazione in oggetto), la certificazione degli standard di sicurezza per la tutela delle informazioni UNI CEI EN ISO/IEC 27001:2017. Tale certificazione è stata confermata a seguito delle visite di mantenimento (post incidente) […]. Nel periodo successivo all’incidente, inoltre il Responsabile ha conseguito le ulteriori seguenti certificazioni: ISO 27017 in data 20 luglio 2022 (standard di riferimento per i controlli di sicurezza generali per gli utilizzatori e i fornitori di servizi cloud); ISO 27018 in data 20 luglio 2022 (standard per i controlli per i fornitori di servizi cloud pubblici che agiscono come responsabili del trattamento)”.

2. Esito dell’attività istruttoria.

Con riferimento alla disciplina applicabile, si osserva che:

ai sensi del Regolamento 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 poi 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”;

il Regolamento prevede che i dati personali siano essere “trattati in maniera da garantire 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 («integrità e riservatezza»)” (art. 5, par. 1, lett. f), del Regolamento);

in virtù del richiamato principio di “integrità e riservatezza” (art. 5, par. 1, lett. f), del Regolamento), il titolare deve (cfr. le “Linee guida 4/2019 sull’articolo 25 - Protezione dei dati fin dalla progettazione e per impostazione predefinita”, adottate dal Comitato europeo per la protezione dei dati – di seguito “Comitato” – il 20 ottobre 2020, spec. punto 85):

valutare i rischi per la sicurezza dei dati personali, considerando l’impatto sui diritti e le libertà degli interessati, e contrastare efficacemente quelli identificati;

tenere conto non appena possibile dei requisiti di sicurezza nella progettazione e nello sviluppo del sistema, integrando e svolgendo costantemente test pertinenti;

definire il trattamento dei dati in modo tale che un numero minimo di persone abbia bisogno di accedere ai dati personali per svolgere le proprie funzioni, e limitare l’accesso di conseguenza;

proteggere i dati personali da modifiche e accessi non autorizzati e accidentali, sia durante il loro trasferimento che durante la loro conservazione;

registrare gli eventi rilevanti ai fini della sicurezza delle informazioni e monitorandoli per rilevare in modo tempestivo eventuali incidenti di sicurezza;

garantire il ripristino dei sistemi informatici in caso di disastro e la continuità operativa, assicurando la disponibilità dei dati personali a seguito di incidenti di sicurezza rilevanti;

disporre di adeguate procedure per gestire le violazioni dei dati personali, comprese procedure per la loro documentazione;

l’art. 32 del Regolamento, concernente la sicurezza del trattamento, 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” (di seguito “Linee guida sulla notifica”), adottate dal Comitato il 28 marzo 2023, evidenziano che “un incidente di sicurezza che determina l’indisponibilità dei dati personali per un certo periodo di tempo costituisce una violazione, in quanto la mancanza di accesso ai dati può avere un impatto significativo sui diritti e sulle libertà delle persone fisiche” (sez. I.B.2);

art. 25, par. 1, del Regolamento prevede che “tenendo conto dello stato dell'arte e dei costi di attuazione, nonché della natura, dell'ambito di applicazione, del contesto e delle finalità del trattamento, come anche dei rischi aventi probabilità e gravità diverse per i diritti e le libertà delle persone fisiche costituiti dal trattamento, sia al momento di determinare i mezzi del trattamento sia all'atto del trattamento stesso il titolare del trattamento [debba mettere] in atto misure tecniche e organizzative adeguate, quali la pseudonimizzazione, volte ad attuare in modo efficace i principi di protezione dei dati, quali la minimizzazione, e a integrare nel trattamento le necessarie garanzie al fine di soddisfare i requisiti del presente regolamento e tutelare i diritti degli interessati” (cfr. anche conss. 75 e 78 del Regolamento);

sulla base del richiamato principio della “protezione dei dati fin dalla progettazione”, i titolari dovrebbero effettuare revisioni periodiche delle misure di sicurezza poste a presidio e tutela dei dati personali, nonché della procedura per la gestione delle violazioni dei dati. L’obbligo di mantenere, verificare e aggiornare, ove necessario, il trattamento si applica anche ai sistemi preesistenti. Ciò implica che i sistemi progettati prima dell’entrata in vigore del Regolamento devono essere sottoposti a verifiche e manutenzione per garantire l’applicazione di misure e garanzie che mettano in atto i principi e i diritti degli interessati in modo efficace. Tale obbligo si estende anche ai trattamenti svolti per mezzo di un responsabile del trattamento. Infatti, le operazioni di trattamento effettuate da un responsabile dovrebbero essere regolarmente esaminate e valutate dal titolare per garantire che continuino a rispettare i principi e permettano al titolare di adempiere gli obblighi previsti dal Regolamento (cfr. le citate “Linee guida 4/2019 sull’articolo 25 - Protezione dei dati fin dalla progettazione e per impostazione predefinita”, spec. punti 7, 38, 39 e 84).

Preso atto di quanto rappresentato dalla Regione nella documentazione in atti e nelle memorie difensive, si osserva che:

in generale, la titolarità dei trattamenti di dati personali comporta comunque una responsabilità in capo al soggetto che riveste tale ruolo e, quindi, nel caso di specie, alla Regione in ordine alle scelte effettuate con riferimento a finalità e mezzi degli stessi trattamenti. Infatti, come anche indicato nelle Linee guida 07/2020 sui concetti di titolare del trattamento e di responsabile del trattamento ai sensi del GDPR (adottate il 7 luglio 2021 dal Comitato ), anche se il servizio offerto dal responsabile viene da quest’ultimo definito preliminarmente in modo specifico, spetta comunque al titolare adottare la decisione finale con cui si approvano le modalità di esecuzione del trattamento nonché chiedere eventuali modifiche (cfr. punto 30); inoltre, con specifico riferimento alle misure adottate dal responsabile, sulla base delle istruzioni impartite del titolare, al fine di assicurare il rispetto degli obblighi di sicurezza di cui all’art. 32 del Regolamento, resta comunque fermo che il titolare rimane responsabile dell’attuazione di misure tecniche e organizzative adeguate per garantire, ed essere in grado di dimostrare, che il trattamento è effettuato conformemente al Regolamento, come richiesto dall’art. 24 del medesimo (cfr. punti  37 e 135). D’altronde, oltre agli imperativi obblighi di vigilanza, le responsabilità in capo al titolare non si esauriscono con la stipula dell’atto giuridico di cui all’art. 28, par. 3, del Regolamento e con la disposizione delle istruzioni relative al trattamento, ma durano per tutto il tempo in cui il responsabile tratta i dati per suo conto. Pertanto, sia il titolare che il responsabile possono essere oggetto di sanzioni in caso di inadempimento degli obblighi stabiliti dal Regolamento poiché entrambi sono direttamente tenuti ad assicurarne il rispetto (cfr. punto 9 delle citate Linee guida); in tal caso gli eventuali interventi correttivi sono modulati con differenti gradi di afflizione sulla base delle responsabilità effettive e del grado di autonomia decisionale nel caso concreto;

sempre in generale, con riferimento alle ricorrenti argomentazioni fondate sul possesso, da parte di LAZIOcrea, della certificazione del sistema di gestione per la sicurezza delle informazioni (SGSI) in conformità alla norma UNI CEI EN ISO/IEC 27001:2017, con estensione ai controlli della ISO 27017 e ISO 27018, si evidenzia che tale certificazione non rientra, al momento, tra quelle previste dall’art. 42 del Regolamento. In ogni caso, la certificazione ai sensi dell’art. 42 del Regolamento, seppur possa essere utilizzata, da titolari o responsabili, come elemento per dimostrare il rispetto degli obblighi del Regolamento, non ne implica automaticamente il rispetto. Inoltre, occorre considerare che la certificazione di un SGSI può essere limitata a specifici ambiti (servizi e/o sedi) dell’organizzazione (riportati sinteticamente nel certificato rilasciato dall’organismo di certificazione) e che il processo di certificazione di un SGSI, basato principalmente sui risultati degli audit (verifiche documentali e sul campo), contiene elementi di incertezza sia perché legato al concetto di rischio sia perché svolto su un campione dei processi che l’organizzazione, ferma restando la sua buona fede, sottopone a certificazione. La certificazione di un SGSI basato sulla ISO/IEC 27001, quindi, non garantisce, di per sé, livelli di sicurezza, controlli o misure di sicurezza stabiliti o fissati a priori, ma assicura l’adozione dei controlli che l'organizzazione ha identificato e ritenuto adeguati sulla base di una propria valutazione del rischio. Il titolare del trattamento, pertanto, quando si avvale di un responsabile del trattamento certificato, secondo meccanismi di certificazione, a prescindere che siano approvati o meno ai sensi dell’art. 42 del Regolamento, dovrebbe sempre verificare se le garanzie offerte dal medesimo responsabile siano efficaci e adeguate ai trattamenti a quest’ultimo affidati;

con riferimento alla violazione del principio di cui all’art. 5, par. 1, lett. f), e degli obblighi di cui all’art. 32 del Regolamento:

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, anche sulla salute, di milioni di interessati assistiti. 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. Al riguardo, si osserva che, con riferimento alle criticità relative ai trattamenti effettuati dalla Società per conto della Regione, spetta in ogni caso al titolare del trattamento “mettere in atto misure adeguate ed efficaci [e a …] dimostrare la conformità delle attività di trattamento con il […] Regolamento, compresa l’efficacia delle misure” adottate (cons. 74 del Regolamento), anche qualora si avvalga di un responsabile per lo svolgimento di alcune attività di trattamento, al quale deve impartire specifiche istruzioni, anche sotto il profilo della sicurezza (cons. 81 e art. 32, parr. 1, lett. d), e 4, del Regolamento). Infatti, il titolare rimane responsabile dell’attuazione delle misure tecniche e organizzative adeguate per garantire ed essere in grado di dimostrare che il trattamento è effettuato in conformità al Regolamento (artt. 5, par. 2, e 24 del Regolamento; cfr. le menzionate Linee guida 07/2020 sui concetti di titolare del trattamento e di responsabile del trattamento ai sensi del GDPR, spec. punto 41);

sulla mancata adozione di misure adeguate a rilevare tempestivamente la violazione di dati personali:

- il 31 luglio 2021, dalle ore 16:49 i soggetti malintenzionati hanno effettuato una serie di operazioni propedeutiche all’attacco informatico, a seguito delle quali, alle ore 21:12, “le piattaforme di sicurezza Microsoft generavano un incidente di sicurezza di severity High denominato Multi-stage incident involving Execution & Command and control on multiple endpoints reported by multiple sources, composto da un totale di 2189 allarmi. L’incidente segnalava la rilevazione, su molteplici sistemi, di attività malevole”. Dalle ore 00:00 del 1° agosto 2021 è stata “avviata la routine di cifratura dei sistemi”;

- la Società ha avuto “evidenza nelle prime ore della mattina del 1° agosto quando alcune macchine virtuali sono risultate inutilizzabili”; al riguardo, la stessa ha dichiarato che “a seguito del rilevamento di “attività ostili” (2.189 allarmi) da parte della “console Microsoft Windows Defender ATP” nella serata del 31 luglio 2021, […] tale strumento di monitoraggio non era presidiato H24” e, pertanto, “non si è potuto gestire tali allarmi con “maggiore” tempestività””. Ciò anche in quanto al momento in cui si è verificato l’attacco informatico la Società “non disponeva di personale (interno o esterno) dedicato all’analisi H24 degli alert generati dal SIEM di Microsoft, in attesa dell’attivazione di un servizio di security operations center (SOC) fornito da Leonardo S.p.a., poi avvenuta nei primi giorni di agosto 2021”;

- risulta, pertanto, accertato che l’inadeguata gestione dei predetti allarmi non ha consentito alla Società, e quindi alla Regione, di venire tempestivamente a conoscenza della violazione dei dati personali occorsa; al riguardo, non rileva, infatti, quanto sostenuto dalla Regione nelle memorie difensive in ordine alla circostanza che “per le pubbliche amministrazioni, l’ordinamento vigente a tutt’oggi ancora non preveda l’obbligo di attivazione di un SOC presidiato continuativamente h24”, in quanto, sotto il profilo della protezione dei dati, il Regolamento, in ossequio al principio di responsabilizzazione, demanda al titolare e al responsabile 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 all’esercizio del diritto all’accesso alle cure sanitarie;

con riguardo alla mancata adozione di misure adeguate a garantire la sicurezza delle reti:

- la Società non aveva adottato adeguate misure per segmentare e segregare le reti su cui erano attestate le postazioni di lavoro dei propri dipendenti, quelle dei dipendenti della Regione Lazio, nonché i sistemi (server) utilizzati per i trattamenti effettuati in qualità di titolare o di responsabile anche per conto della Regione. In particolare, le regole di filtering configurate sui sistemi firewall presenti nel data center gestito dalla Società, limitate solo a specifici sistemi o servizi critici, non hanno impedito la propagazione del malware su circa 180 sistemi;

- nell’ambito delle attività di analisi condotte da Leonardo S.p.a. in relazione alla violazione dei dati personali in esame, è stato definito un “Mitigation, Eradication & Improvement Plan” (di seguito “Piano”) che prevede l’adozione, tra le altre, di specifiche azioni volte alla segregazione e messa in sicurezza dei diversi sistemi gestiti dalla Società. In particolare, tali azioni prevedono la “segmentazione delle reti evitando subnet eccessivamente ampie e limitando, di fatto, la possibilità per un potenziale attaccante di eseguire movimenti laterali”, la “reinstallazione completa di tutti i sistemi server e contestuale posizionamento in segmenti di rete suddivisi per layer di sicurezza (Tier), ad accesso limitato e amministrabili solo da un numero limitato di workstation, a loro volta isolate dalle altre reti (PAW, Privileged Access Workstation)”, nonché la “riprogettazione della network […] favorendo il principio del privilegio minimo”;

- peraltro, al momento in cui si è verificata la violazione dei dati personali, l’accesso remoto, tramite VPN, alla rete della Regione, avveniva mediante una procedura di autenticazione informatica basata solo sull’utilizzo di username e password. In relazione a tale aspetto, la Regione e la Società, a seguito dell’incidente, hanno ritenuto necessario attivare una procedura con doppio fattore di autenticazione, come previsto anche dal predetto Piano;

- quanto sostenuto dalla Regione nelle memorie difensive non consente di superare le criticità rilevate nell’atto di avvio del procedimento in quanto, anche se “la separazione logica e la segregazione fisica delle reti […] hanno impedito agli hacker di esfiltrare i dati presenti nel Data Center”, questo non ha impedito a soggetti non autorizzati di accedere e compromettere, rendendoli indisponibili, molti sistemi server che, come dichiarato dalla Società nel corso dell’accertamento ispettivo, al momento della violazione, potevano essere raggiunti a partire dalla rete utilizzata per l’accesso VPN dei dipendenti della Regione Lazio;

con riguardo all’obsolescenza dei software di base istallati su alcuni sistemi di trattamento:

- dalla documentazione in atti è emerso che il server con hostname “RLWSIRIFT01” è stato “uno dei principali punti di snodo utilizzati dall’attaccante nella fase finale dell’attacco” informatico alla base della violazione dei dati personali in esame. La Società ha evidenziato che sul “server con hostname “RLWSIRIFT01” […] era installato software di base per cui non erano più disponibili aggiornamenti o patch di sicurezza del produttore. Tale circostanza era dovuta alla necessità di garantire il funzionamento di un’applicazione web legacy che richiedeva una particolare versione del sistema operativo e dell’application server. Sfruttando vulnerabilità note del software di base presente sul citato server i soggetti malintenzionati sono riusciti a venire in possesso di credenziali di autenticazione con privilegi amministrativi […] utilizzate nelle successive fasi dell’attacco informatico”. In particolare, è emerso che sul sistema di trattamento in questione era installato un sistema operativo obsoleto (Windows Server 2008 R2 Standard) per il quale il produttore (Microsoft) aveva cessato la distribuzione degli aggiornamenti di sicurezza. Ciò rendeva particolarmente difficile il patching di tale sistema, richiedendo l’adozione, realisticamente non tempestiva, di eventuali accorgimenti ad hoc in grado di fronteggiare nuove vulnerabilità;

- solo a seguito della violazione dei dati personali, la Società “ha individuato i (pochi) server che, per garantire il funzionamento di alcuni servizi legacy, utilizzano ancora sistemi operativi obsoleti e ha provveduto ad adottare opportune misure di segregazione, a livello di rete, nonché di monitoraggio degli eventi di sicurezza”;

- quanto riportato dalla Regione nelle memorie difensive non consente di superare i rilievi dell’Ufficio in ordine all’utilizzo di software di base obsoleti, per i quali non sono più disponibili aggiornamenti di sicurezza, anche in considerazione del fatto che i sistemi server su cui tali software erano installati, diversamente da quanto asserito, non erano adeguatamente isolati da altri sistemi server mediante i quali erano effettuati trattamenti di dati anche relativi alla salute degli assistiti del Servizio sanitario regionale;

con riguardo alla mancata adozione di misure adeguate ad assicurare la disponibilità e la resilienza dei sistemi e dei servizi di trattamento:

- la Società, al momento dell’incidente di sicurezza, utilizzava un sistema di gestione dei backup e che “non erano state definite specifiche procedure di gestione dei backup, ma era previsto che ciascun referente di progetto comunicasse, al momento del rilascio in esercizio, mediante un apposito modello, fra le altre, anche informazioni sul tipo e sulla retention dei backup da effettuare. La periodicità dei backup era giornaliera”;

- la gestione dei backup veniva effettuata mediante una “tabella contenente l’elenco di progetti per cui era effettuato il backup con l’indicazione dei referenti, del nome dello schema, degli host e delle relative policy di retention”;

- solo a seguito della violazione dei dati personali, la Società ha adottato un nuovo sistema di gestione dei backup che consente una più semplice gestione e monitoraggio del backup dei dati e dei sistemi sulla base di quanto indicato da ciascun referente di progetto, al momento del rilascio in esercizio;

- quanto affermato dalla Regione nelle memorie difensive non consente di superare i rilievi dell’Ufficio in ordine alle modalità adottate per assicurare la disponibilità e la resilienza dei sistemi e dei servizi di trattamento, inclusa la gestione del backup, in quanto le stesse risultavano non in linea con le migliori pratiche di settore e non adeguate al contesto dei trattamenti svolti dalla Società per conto della Regione Lazio;

- la violazione ha determinato l’impossibilità di utilizzare molti sistemi informativi della Regione, alcuni dei quali trattano dati sulla salute, tra cui si segnalano: ASUR – Anagrafe sanitaria unica regionale; nuovo RECUP – Gestione prenotazioni, accettazioni, disdette; ESCAPE, per la gestione dei referti relativi ad esami di laboratorio; pagamenti prestazioni afferenti attività specialistica ambulatoriale compreso pagamenti on line tramite PAGOPA; Sistema regionale invio flussi per debito informativo afferente prestazioni specialistiche in carico al SSN, prestazioni intramoenia, domiciliari e prestazioni effettuate presso i consultori, ricoveri ospedalieri, accessi di Pronto Soccorso; RICDIG – Sistema registrazione ricetta dematerializzata per prescrizione farmaci e prestazioni ambulatoriali; attività di screening neonatali e oncologici; Piattaforma regionale di sorveglianza Covid-19; ADVICE – Sistema di teleconsulto per consulenze verso i DEA di secondo livello; Sistema AVR – Anagrafe Vaccinale Regionale;

- i predetti sistemi informativi, attraverso i quali sono trattati dati sulla salute degli assistiti del Servizio sanitario regionale, sono stati indisponibili per un arco temporale che si estende, in alcuni casi, per una durata di alcuni mesi; la società LAZIOcrea ha infatti provveduto a ripristinare gli stessi, in ambiente cloud, in via graduale dando priorità a quelli maggiormente critici (es. vaccinazione Covid-19) per completare il completo ripristino nel mese di ottobre 2021 (cfr. notifiche della società LAZIOcrea del 10 settembre e 29 ottobre 2021 – cui rinvia espressamente la Regione con la notifica del XX – nonché riserve del verbale degli accertamenti ispettivi del XX);

- la mancata disponibilità di accesso ai dati conservati sui predetti sistemi è stata determinata:

i) direttamente dall’attacco informatico che, compromettendo lo strato applicativo del sistema di virtualizzazione, ha quindi reso indisponibili circa 180 sistemi server virtuali e inaccessibili i dati ivi trattati;

ii) indirettamente dalla scelta di LAZIOcrea di spegnere tutti i sistemi server in quanto, al momento dell’attacco informatico, non era in grado né di determinare quali fossero compromessi, né di evitare un’ulteriore propagazione del malware stante l’assenza di una segregazione delle reti su cui gli stessi erano attestati;

- pertanto, qualora LAZIOcrea avesse provveduto a segregare adeguatamente le reti su cui erano attestati i sistemi server e le postazioni di lavoro dei propri dipendenti e della Regione Lazio, la stessa Società non avrebbe dovuto procedere allo spegnimento dei citati sistemi server, e quindi le strutture sanitarie non avrebbero subito l’indisponibilità di accesso a numerosi sistemi informativi e ai relativi dati;

- la segregazione delle reti è peraltro una delle più comuni misure adottate nell’ambito di data center che ospitano sistemi informatici deputati al trattamento di diverse categorie di dati personali, anche relativi allo stato di salute, che LAZIOcrea - in qualità di società che opera nel settore ICT secondo il modello in house providing - avrebbe senz’altro dovuto assicurare tenuto conto del contesto e delle caratteristiche dei trattamenti in relazione ai quali è stata designata responsabile dalla Regione e dalle strutture sanitarie;

con riferimento alla violazione del principio di cui all’art. 25, par. 1, del Regolamento:

l’art. 25 del Regolamento richiede che le misure e le garanzie individuate e adottate dal titolare siano specificamente connesse all’attuazione dei principi di protezione dei dati nell’ambito dei trattamenti in concreto svolti; le misure e le garanzie devono essere concepite per essere robuste e il titolare del trattamento deve essere in grado di attuarne ulteriori al fine di far fronte a un eventuale aumento dei rischi. L’efficacia o meno delle misure dipende dal contesto del trattamento e degli altri elementi che il titolare deve tenere in considerazione all’atto della determinazione dei mezzi del trattamento;

in merito alle argomentazioni fondate sul possesso, da parte di LAZIOcrea, della certificazione del (SGSI) in conformità alla norma UNI CEI EN ISO/IEC 27001:2017, si richiama quanto sopra osservato circa i doveri in capo al titolare del trattamento nell’adozione, fin dalla progettazione, di misure efficaci e adeguate ai trattamenti anche se affidati a un responsabile del trattamento; peraltro, anche nel caso in cui “un trattamento sia certificato ai sensi dell’articolo 42, il titolare è comunque tenuto a garantire il monitoraggio costante e il miglioramento della conformità ai criteri della DPbDD” (cfr. “Linee guida 4/2019 sull’articolo 25 - Protezione dei dati fin dalla progettazione e per impostazione predefinita”, punto 91);

la valutazione dei rischi effettuata dal responsabile può essere utilizzata, ma non è di per sé sufficiente, per consentire al titolare del trattamento di progettare adeguatamente i trattamenti al fine di integrare le garanzie a tutela dei diritti e delle libertà degli interessati e di adottare misure -anche organizzative- ulteriori rispetto a quelle individuate dal responsabile del trattamento;

quanto riportato dalla Regione nelle memorie difensive non consente di superare i rilievi dell’Ufficio in ordine alla violazione del principio di protezione dei dati fin dalla progettazione con particolare riferimento all’adeguatezza e all’efficacia delle misure adottate in relazione al contesto e all’ambito dei trattamenti svolti dal titolare.

3. Conclusioni.

Alla luce delle valutazioni sopra richiamate, tenuto conto delle dichiarazioni rese dalla Regione Lazio nel corso dell’istruttoria e considerato che, salvo che il fatto non costituisca più grave reato, chiunque, in un procedimento dinanzi al Garante, dichiara o attesta falsamente notizie o circostanze o produce 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 nelle memorie difensive non consentono di superare i rilievi notificati dall’Ufficio con l’atto di avvio del procedimento, non ricorrendo, peraltro, alcuno dei casi previsti dall’art. 11 del Regolamento del Garante n. 1/2019.

Per tali ragioni, si rileva l’illiceità del trattamento di dati personali effettuato dalla Regione Lazio, nei termini di cui in motivazione, in violazione degli artt. 5, par. 1, lett. f), 25, par. 1, e 32 del Regolamento.
In tale quadro, considerato che sono state adottate misure volte a superare le criticità sopra descritte non ricorrono i presupposti per l’adozione delle misure correttive di cui all’art. 58, par. 2, del Regolamento.

4. 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), 25, par. 1, e 32 del Regolamento, causata dalla condotta posta in essere dalla Regione Lazio, è soggetta all’applicazione della sanzione amministrativa pecuniaria ai sensi dell’art. 83, parr. 3, 4 e 5, del Regolamento.

Si consideri che il Garante, ai sensi 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).

La predetta sanzione amministrativa pecuniaria, in funzione delle circostanze di ogni singolo caso, va determinata nell’ammontare tenuto conto dei principi di effettività, proporzionalità e dissuasività, indicati nell’art. 83, par. 1, del Regolamento, alla luce degli elementi previsti all’art. 85, par. 2, del Regolamento.

Con specifico riguardo alla natura e alla gravità delle violazioni (art. 83, par. 2, lett. a), d) e g), del Regolamento), occorre considerare che la numerosità e delicatezza dei servizi colpiti e, in ragione di ciò, l’elevato numero di interessati coinvolti e le tipologie di dati personali oggetto di violazione (comprese categorie particolari di cui all’art. 9 del Regolamento, o altri dati connotati da particolare delicatezza quali dati retributivi e dati bancari), e ciò a prescindere dalla mancata esfiltrazione dei dati medesimi.

Alla luce di tali circostanze, si ritiene che, nel caso di specie, il livello di gravità delle violazioni commesse dal titolare del trattamento sia alto (Guidelines 04/2022 on the calculation of administrative fines under the GDPR, adottate dal Comitato il 23 maggio 2023, punto 60).

A ciò si aggiunga, ai sensi dell’art. 83, par. 2, lett. e), del Regolamento, che la Regione è già stata destinataria di alcuni provvedimenti correttivi e sanzionatori.

Inoltre, ai sensi dell’art. 83, par. 2, lett. h), del Regolamento, l’Autorità ha preso conoscenza dell’evento dalla tempestiva notifica della violazione trasmessa dalla Regione.

In senso favorevole al titolare occorre comunque considerare, ai sensi dell’art. 83, par. 2, lett. c) e f), del Regolamento, che la Regione ha cooperato con l’Autorità introducendo, nella concomitanza del contesto emergenziale da Covid-19, misure idonee a superare le criticità sopra evidenziate.

In ragione dei suddetti elementi, valutati nel loro complesso, si ritiene di determinare l’ammontare della sanzione pecuniaria prevista dall’art. 83, parr. 3, 4 e 5, del Regolamento, nella misura di euro 120.000,00 (centoventimila) per la violazione degli artt. 5, par. 1, lett. f), 25, par. 1, e 32 del Regolamento o, 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 dall’art. 16 del Regolamento del Garante n. 1/2019, anche in considerazione del numero di interessati coinvolti, della tipologia di dati personali oggetto di violazione e dell’ampiezza e dell’impatto sulla disponibilità dei servizi colpiti.

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 Regione Lazio per la violazione degli artt. 5, par. 1, lett. f), 25, par. 1, e 32, del Regolamento nei termini di cui in motivazione.

ORDINA

ai sensi degli artt. 58, par. 2, lett. i), e 83 del Regolamento, nonché dell’art. 166 del Codice, alla Regione Lazio, codice fiscale 80143490581, in persona del legale rappresentante pro-tempore, di pagare la somma di euro 120.000,00 (centoventimila) a titolo di sanzione amministrativa pecuniaria per le violazioni indicate 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 Regione Lazio, in caso di mancata definizione della controversia ai sensi dell’art. 166, comma 8, del Codice, di pagare la somma di euro 120.000,00 (centoventimila) 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

ai sensi dell’art. 166, comma 7, del Codice, la pubblicazione per intero del presente provvedimento sul sito web del Garante e l’annotazione del presente provvedimento nel registro interno dell’Autorità, previsto dall’art. 57, par. 1, lett. u), del Regolamento, delle violazioni e delle misure adottate in conformità all'art. 58, par. 2, del Regolamento.

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, 21 marzo 2024

IL PRESIDENTE
Stanzione

IL RELATORE
Cerrina Feroni

IL SEGRETARIO GENERALE
Mattei