Provvedimento dell'11 settembre 2025 [10184654]
Provvedimento dell'11 settembre 2025 [10184654]
Condividi[doc. web n. 10184654]
Provvedimento dell'11 settembre 2025
Registro dei provvedimenti
n. 488 dell'11 settembre 2025
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. Angelo Fanizza, segretario generale;
VISTO il Regolamento (UE) 2016/679 del Parlamento europeo e del Consiglio, del 27 aprile 2016, relativo alla protezione delle persone fisiche con riguardo al trattamento dei dati personali, nonché alla libera circolazione di tali dati e che abroga la direttiva 95/46/CE, “Regolamento generale sulla protezione dei dati” (di seguito “Regolamento”);
VISTO il d.lgs. 30 giugno 2003, n. 196 recante il “Codice in materia di protezione dei dati personali”, contenente disposizioni per l’adeguamento dell’ordinamento nazionale al Regolamento (UE) 2016/679 del Parlamento europeo e del Consiglio, del 27 aprile 2016, relativo alla protezione delle persone fisiche con riguardo al trattamento dei dati personali, nonché alla libera circolazione di tali dati e che abroga la Direttiva 95/46/CE (di seguito il “Codice”);
VISTO il d.lgs. 10 agosto 2018, n. 101 recante “Disposizioni per l'adeguamento della normativa nazionale alle disposizioni del Regolamento (UE) 2016/679 del Parlamento europeo e del Consiglio, del 27 aprile 2016, relativo alla protezione delle persone fisiche con riguardo al trattamento dei dati personali, nonché alla libera circolazione di tali dati e che abroga la direttiva 95/46/CE”;
VISTO il Regolamento n. 1/2019 concernente le procedure interne aventi rilevanza esterna, finalizzate allo svolgimento dei compiti e all’esercizio dei poteri demandati al Garante per la protezione dei dati personali, approvato con deliberazione del n. 98 del 4/4/2019, pubblicato in G.U. n. 106 dell’8/5/2019 e in www.gpdp.it, doc. web n. 9107633 (di seguito “Regolamento del Garante n. 1/2019”);
VISTA la documentazione in atti;
VISTE le osservazioni formulate dal segretario generale ai sensi dell’art. 15 del Regolamento del Garante n. 1/2000 sull’organizzazione e il funzionamento dell’ufficio del Garante per la protezione dei dati personali, doc. web n. 1098801;
Relatore l’avv. Guido Scorza;
PREMESSO
1. La violazione dei dati personali
Il XX Cerba HealthCare Campania S.r.l. (già Centro Diagnostico Basile s.p.a.), di seguito la “Società” ha trasmesso all’Autorità, ai sensi dell’art. 33 del Regolamento, una notifica di violazione dei dati personali riguardante l’attacco al “sito web istituzionale appartenente al sistema informativo (…)” che ha causato “compromissioni (..del) server che ospitava il sito e i database a supporto dell’applicazione CUP (Centro Unico Prenotazioni) e Magazzino” e che ha comportato l’esfiltrazione dei dati ivi contenuti. La notifica è stata successivamente integrata in data XX
Con le note del XX e del XX, l’Ufficio ha richiesto informazioni alla Società, al fine di acquisire elementi di dettaglio riguardanti, in particolare, le misure di sicurezza adottate a protezione delle credenziali delle diverse tipologie di interessati, le modalità di accesso ai sistemi oggetto di violazione, le funzionalità disponibili alla pagina “www.centrobasile.it/...” risultata vulnerabile ad attacchi di tipo XX, nonché lo stato di avanzamento delle misure tecniche e organizzative adottate per prevenire simili violazioni future. La Società ha fornito riscontro, rispettivamente, con note del XX e XX.
2. Il fatto
Preliminarmente, con la notifica del XX, è stato dichiarato che “in data XX è stato notato un primo accesso esterno dell’IP malevolo” e che “sono state rilevate diverse modifiche di cartelle e file. In particolare si è rilevata la presenza delle cartelle “XX” e “XX” (contenti dati anomali e script per eseguire query) e creazione di file all'interno delle cartelle XX. Tali azioni hanno permesso la navigazione del server stesso, creando un export dei dati presenti sullo stesso. La vulnerabilità sfruttata è di tipo XX, che ha permesso di accedere alla wwwroot, mappando il filesystem del server, potendo così navigare e visualizzare solo le cartelle con i permessi di lettura e scrittura. Diamo atto di aver ricevuto 3 e-mail intimidatorie con minacce di diffusione/pubblicazione dei dati, anche sanitari, dei nostri pazienti. Sono state individuate ed estratte le comunicazioni sui canali Telegram utilizzati per divulgare i dati estratti. Tuttavia, i moderatori di entrambe le chat hanno eliminato immediatamente i dati e bloccato l'utente”. Tali informazioni sono state confermate con l’integrazione del XX.
Dal documento “Consulenza Tecnica redatta nell'ambito delle investigazioni difensive ai sensi dell'art. 327 bis c.p.p.” della società XX (di seguito “relazione tecnica”) si evince che “in data XX è stata effettuata un’attività malevola sul sito web istituzionale appartenente al sistema informativo del Centro Basile. L’effettiva realizzazione dell’attacco è stata tecnicamente verificata giorno XX alle ore XX CEST in ragione dell’analisi condotta sui sistemi dal personale interno, avviata a seguito della ricezione di una e-mail inviata dal threat actor la sera prima” e che “le tecniche utilizzate da WebAudit Alpha hanno permesso al threat actor di esfiltrare i dati dal database CUP e Magazzino e, successivamente, eseguire dei comandi sulla macchina consentendogli di prelevare taluni referti medici. Sono state coinvolte le seguenti categorie di soggetti interessati: pazienti, dipendenti, ex dipendenti e consulenti/collaboratori, pazienti di Clienti e dipendenti di Clienti. Per alcuni di essi le informazioni esfiltrate riguardano l’ambito personale, per altri l’ambito sanitario e, in alcuni casi, anche l’intersezione dei due” (v. notifica XX, relazione tecnica allegata alla sez. H, pag. 7).
Per quanto riguarda le modalità di conduzione dell’attacco la Società ha rappresentato che “l’attaccante ha iniziato a utilizzare tecniche di info fuzzing sul parametro “XX” presente nella pagina “XX” che, dopo qualche richiesta, è risultato vulnerabile ad attacchi di tipo XX (…e…) ha esfiltrato, riga per riga, i dati riferiti alla tabella Utenti del Database CUP” (v. relazione tecnica pagg. 17 e 19)
Per quanto attiene al numero di interessati i cui dati sono stati coinvolti dall’attacco e alla tipologia delle informazioni violate, la Società ha dichiarato che i “dati personali comuni dei dipendenti (nome, cognome, email, password_web) e i dati personali comuni e particolari dei pazienti (nome, cognome, sesso, email, numero di telefono, codice fiscale, indirizzo di residenza/domicilio, password_web, data di nascita, dati sanitari (referti di analisi cliniche) […] il numero di dati sanitari (referti) esfiltrati è di 464” e che “i risultati degli esami riportati nei referti non attengono a prestazioni sanitarie particolarmente delicate in merito alle quali l'ordinamento vigente ha posto specifiche disposizioni a tutela della riservatezza e della dignità dei soggetti interessati, quali indagini genetiche o affezioni da HIV” (v. notifica del XX, sez. XX, punto XX e sez. XX punto XX). Inoltre la Società ha precisato che “WebAudit Alpha ha dichiarato di avere esfiltrato un numero di file superiore ma non si hanno elementi per confermare o smentire quanto affermato dal threat actor. Da un’analisi più approfondita, si è anche scoperto che il Database “centrobasile.mdb” conteneva anche informazioni sugli amministratori del sito web, e-mail e password (in chiaro) per la parte di Content Management” e che si ha “evidenza anche dell’esfiltrazione di 12 tabelle appartenenti ai XX, CUP (Centro Unico Prenotazione) e Magazzino. In particolare, le tabelle esfiltrate dal Database CUP vengono riportate di seguito: XX, mentre le tabelle recuperate dal Database Magazzino sono: XX, mentre dal XX è stata esfiltrata la tabella XX, contenente informazioni sugli utenti che gestiscono il Database che non sono correlati a dipendenti o pazienti” (v. relazione tecnica, pag. 32).
3. Le misure in essere al momento della violazione
Con riferimento alle misure tecniche in essere al momento della violazione la Società ha dichiarato che: “l'architettura di rete esposta su Internet del Centro Basile è dotata di un Firewall perimetrale XX. Il Firewall in questione è stato messo a protezione dell’infrastruttura interna permettendo il traffico dall’esterno solo verso l’application server che eroga il servizio del sito web, XX. Inoltre, lo stesso Firewall fa anche da concentratore VPN XX prevalentemente per operazioni di gestione da parte del gruppo degli amministratori di rete/di sistema e dal fornitore “XX” a cui era affidata la gestione e la manutenzione sia della parte sistemistica che della parte applicativa del prodotto “XX” (…). I dipendenti del Centro Basile non sono abilitati al collegamento dall’esterno per raggiungere i sistemi aziendali interni diminuendo, di fatto, la superficie d’attacco del servizio. Al momento dell’incidente, la versione del dispositivo XX. Altro servizio esposto su Internet è il servizio XX. Oltre al concentratore VPN del firewall XX veniva usato un altro software per l’accesso sicuro da remoto, XX. I servizi esposti su Internet, che venivano veicolati sui server interni, al momento dell’incidente erano: XX. La macchina XX (…) era dotata di un firewall locale (XX) con delle regole create ad-hoc a protezione dell’asset”. È stato, altresì, dichiarato che “tutte le postazioni di lavoro erano dotate di Software Antivirus XX mentre sui Server XX era presente XX ed era stato abilitato il Firewall locale, tranne sul sistema dell’applicazione “XX” per politiche del fornitore. Sui Server XX veniva utilizzato anche un programma Anti-Malware standalone prodotto dallo stesso Vendor. Sul sistema NAS era installato l’Antivirus XX per controllare i file caricati attraverso l’applicazione “XX”. Sul sistema PACS era installato l’Antivirus XX ed era attivo il Firewall di XX” (v. relazione tecnica pagg. 10 e 13).
Circa le procedure di autenticazione informatica utilizzate per le diverse tipologie di utenze la Società ha dichiarato che “sui Server e sulle Postazioni di Lavoro si usavano le credenziali di dominio. Facevano eccezione solo 2 postazioni, destinate alla refertazione, alle quali era consentito l’accesso anche con account locali. In tutti i sistemi XX era abilitato l’account locale XX. Anche l’accesso in VPN dall’esterno, sul Firewall XX, avveniva tramite credenziali (username e password) locali al Firewall stesso. L’accesso non era consentito ai dipendenti del Centro Basile ma solo al reparto IT per la gestione da remoto e alla Società “XX” per la gestione e manutenzione del server su cui veniva erogato il servizio “XX” (…). Al Server NAS si accedeva solo tramite utenze locali. Su XX esistevano utenze locali ma era predisposto ad archiviare solo i documenti provenienti da “XX”. Su PACS accedeva solo il fornitore “XX” tramite il software di controllo remoto “XX”. Infine, sui sistemi XX venivano utilizzate esclusivamente utenze locali” (v. relazione tecnica pagg. 13 e 14).
Circa gli strumenti di monitoraggio degli eventi di sicurezza utilizzati per il rilevamento in tempo reale degli incidenti di sicurezza, con particolare riferimento ai software di monitoraggio, la Società ha dichiarato che “aveva acquistato un servizio per il monitoraggio della parte Network erogato dal XX. Inoltre, il reparto IT interno erogava un servizio di supporto ai dipendenti a seguito di alert di sicurezza generati dal Software Antivirus XX, XX, XX o XX” (v. relazione tecnica pag. 14).
Con riguardo alle modalità di accesso ai sistemi oggetto di violazione, la Società ha dichiarato che “il portale 'www.centrobasile.it' condivideva il database con un altro applicativo web per la gestione delle prenotazioni, raggiungibile all’URL 'cup.centrobasile.com', a cui accedeva il personale interno; l’accesso avveniva inserendo in XX 2 parametri, username e password. La scelta di non implementare MFA era dettata da una valutazione delle esigenze operative e dalla necessità di mantenere l'usabilità e l'efficienza del sistema. All'epoca, l'assenza di MFA era una scelta che rifletteva le pratiche comuni del settore e teneva conto di un equilibrio tra sicurezza e praticità per gli utenti”.
Per quanto concerne le modalità di accesso all’account XX, la Società ha precisato che il predetto account “era fornito dal provider Aruba e l'indirizzo veniva utilizzato sia come indirizzo mittente dai sistemi oggetto di violazione, sia come recapito per assistenza ai pazienti. La casella di posta era accessibile dalla webmail di Aruba (webmail.aruba.it) su cui non era abilitata la MFA, in ogni caso, Cerba non aveva optato per tale misura, nella fattispecie, la possibilità di MFA sulla tipologia di account acquistato, volendo privilegiare l’usabilità per il paziente. L’account era anche accessibile da un client XX, anch'esso configurato senza l’utilizzo di MFA, a cui accedeva un solo operatore, per dare riscontro alle richieste dei pazienti provenienti dal web. Anche in questo caso, la scelta di non implementare MFA era dettata da una valutazione delle esigenze operative, pur tenendo sempre presenti le dovute misure di sicurezza adeguate a proteggere i dati e garantire la sicurezza degli accessi” (v. nota del XX in riscontro alla richiesta di informazioni del XX, pagg. XX e XX).
Riguardo le misure di sicurezza adottate a protezione delle credenziali delle diverse tipologie di interessati la Società ha dichiarato che “le credenziali (…) erano protette mediante algoritmo XX” (v. nota del XX in riscontro alla richiesta di informazioni del XX, pag.XX).
4. Le misure adottate a seguito della violazione
Con riferimento alle misure adottate a seguito della violazione, la Società ha rappresentato che “accertata la violazione, sono state attivate le seguenti azioni mitigatrici: (i) attivazione di un servizio anti DDOS; (ii) blocco dell'IP attaccante; (iii) blocco di tutti gli IP proveniente al di fuori dello stato italiano; (iv) modificazione di tutte le password amministrative e di gestione. Inoltre, al fine di garantire l’adozione di tutte le misure tecniche necessarie ad interrompere l’evento dannoso e scongiurare il protrarsi della violazione, è stato incaricato un consulente tecnico (XX), che unitamente alla funzione interna di IT, ha messo in atto le soluzioni più idonee ad accertare e contrastare l'attacco informatico. In ultima istanza, in data XX, il web server è stato spento, con conseguente sospensione dei servizi offerti al paziente (prenotazione degli esami e refertazione online)” e che “sono in corso di definizione le modalità di spostamento dei servizi Web e del Domain Controller installati dal server presente presso la sede su differente location, così da poter procedere alla dismissione del server interessato. Naturalmente, compatibilmente con le tempistiche necessarie per definire impatti, possibili rischi aggiuntivi e apertura a ulteriori vulnerabilità” (v. notifica del XX, sez. XX, punti XX e XX).
Inoltre, la Società ha dichiarato di aver proceduto a “spegnere il server web (in modo da renderlo inaccessibile al threat actor), eliminare i file ritenuti malevoli caricati dall’attaccante sul sito www.centrobasile.it e, solo a seguito di queste azioni mitigatrici, è stato fatto ripartire il servizio. Altra contromisura iniziale implementata per contenere l’attacco è stata quella di consentire l’accesso al sito solo da indirizzi IP provenienti dall’Italia (considerato che l’attaccante ha utilizzato nodi di uscita situati in Portogallo, Repubblica Ceca e Spagna), bloccando tutte le connessioni esterne al perimetro nazionale direttamente sul firewall di frontiera XX, per non avere impatti sulla disponibilità del servizio erogato verso i pazienti del Centro. Applicando questa soluzione, WebAudit Alpha non ha più potuto utilizzare i server impiegati in precedenza per attaccare l’infrastruttura del Centro Basile perché è stata inibita la connessione non solo agli indirizzi IP puntuali, ma a tutti quelli che WebAudit Alpha avrebbe potuto utilizzare al di fuori dell’Italia. Le soluzioni adottate hanno mitigato in parte l’attacco del threat actor perché il giorno XX l’attaccante ha ripreso a esfiltrare dati dal Database da un indirizzo IP italiano appartenente a uno dei nodi di uscita di NordVPN. Si è quindi stabilito di spegnere direttamente l’application server rendendo, di fatto, inaccessibile a chiunque il sito, e inserire una comunicazione che informava gli utenti del disservizio in corso fornendo, come alternativa al sistema delle prenotazioni, sia il telefono che l’e-mail del Centro Basile. In parallelo si è provveduto a compiere il reset delle password di tutti gli utenti del Domain Controller e anche il reset delle password utilizzate dagli utenti del sito compromesso. È stata eseguita un’attività di Vulnerability Assessment da Internet per verificare eventuali ulteriori esposizioni a rischi cyber su un altro dominio (www.centrodiagnosticobasile.it). In forma cautelativa si è stabilito di rendere inaccessibile anche questo sito. Il giorno XX i legali del Centro Basile hanno presentato una denuncia alla Polizia Postale contro ignoti. Sin dai primi contatti c’è stata forte collaborazione e un confronto costruttivo con le autorità coinvolte dal punto di vista tecnico. A seguito delle comunicazioni intercorse, si sono forniti log, evidenze e informazioni su ogni aspetto della gestione dell’incidente di sicurezza. Per consentire al personale interno di continuare a effettuare le prenotazioni si è stabilito di migrare il programma “Agenda” dal sito compromesso su un computer (laptop) adibito esclusivamente all’erogazione di questo servizio, una volta epurato da tutte le funzionalità non necessarie. Per questa migrazione è stata seguita una procedura ad-hoc che garantisse l’integrità dei file copiati, l’assenza di malware (verifica effettuata utilizzando diverse tecniche come, per esempio, antivirus, yara rules, sigma rules, etc.) e la robustezza della macchina ospitante (XX). Per mitigare ulteriormente il rischio, questa macchina è stata resa raggiungibile solo internamente dalle postazioni di lavoro dei dipendenti. Anche il programma che si occupa di gestire le licenze di alcuni software medicali di cardiologia, XX, è stato migrato su un nuovo sistema per consentire la continuità operativa, mantenendo lo stesso livello di sicurezza descritto precedentemente grazie all’utilizzo di procedure basate sulle best practices di settore, ripresi dai framework di cybersecurity di XX, XX, XX, XX, XX. Precedentemente era ospitato sul Server “XX”. Completata la migrazione, il servizio in esecuzione sulla macchina compromessa è stato spento. Analizzando i file e le tabelle che sono state coinvolte nell’esfiltrazione dei dati […] è stata redatta una lista di contatti (pazienti) a cui è stata inviata una comunicazione per effettuare il cambio della password. La trasmissione del messaggio è avvenuta sia tramite e-mail che tramite SMS. Per tutti i pazienti di cui non è stato possibile recuperare riferimenti è stata prevista la pubblicazione di un comunicato su due quotidiani che offrono un'ampia diffusione. L’applicazione “XX” (nome della nuova versione dell’applicazione “XX” […]) è stata migrata XX. Attualmente la nuova applicazione eroga solo il servizio di prenotazione e accettazione, mentre la parte di refertazione risiede sempre sul server di “XX” interno. Durante la fase di contenimento, per ridurre ulteriormente la superficie d’attacco, sono state spente altre macchine, come per esempio il server di Backup del XX […], il server legacy per la contabilità e, infine, anche l’host Linux che ospitava il Database compromesso. Anche per la bonifica del NAS è stata applicata una procedura di sicurezza ad-hoc per scongiurare l’eventualità che fossero stati copiati software malevoli (la verifica ha dato esito negativo) ed è stata implementata una politica di aggiornamento costante. Inoltre, sul NAS è installato l’Antivirus XX e gli alert generati vengono gestiti prontamente dal gruppo IT. Al fine di ridurre il rischio del “password reuse”, è stato forzato il cambio password anche delle credenziali su XX di tutti i dipendenti del Centro Basile, comunque rimaste sempre segregate rispetto al Domain Controller interno. Anche per la migrazione sul nuovo dominio è stata seguita una procedura basata sulle best practices di sicurezza. In questo contesto si sono presentati due scenari: macchine create “from scratch” (da zero) e macchine che sono state scollegate dal dominio legacy, formattate e incluse nel nuovo dominio XX su cui sono stati installati i programmi di utilità lavorativa. In questo contesto è compresa la parte di provisioning del software operativo e dell’EDR XX. Tutta la fase di migrazione dei PC è stata ultimata il giorno XX. Inoltre, in data XX è stata creata una nuova utenza dedicata ai client del Software XX. In data XX è stato scollegato il Database XX dal Domain Controller legacy ed il cambio delle credenziali amministrative del Data Base. Il XX è stata prontamente abilitata la registrazione dei log di tutto il traffico in ingresso e dei log classificati come “security” in uscita dal Firewall XX, con una retention di 90 giorni. È stato contattato il cloud storage Mega[.]NZ per chiedere la rimozione dei dati caricati dal threat actor giorno XX. A distanza di poche ore dalla richiesta tutti i file sono stati eliminati” (v. relazione tecnica pagg. 35 – 37).
Con riguardo ai presidi tecnici e organizzativi adottati al fine di prevenire futuri attacchi informatici e ulteriormente rafforzare la protezione dei dati personali, nella relazione tecnica è stato rappresentato che è stata effettuata “una migrazione XX ereditando, di fatto, tutte le impostazioni di sicurezza precedentemente implementate. Inoltre, si è proceduto con l’aggiornamento dei sistemi operativi: sono stati eliminate le macchine con XX ed è stato previsto l’aggiornamento a XX e XX. Sulle nuove postazioni di lavoro sarà installato l’EDR (Endpoint Detection and Response) XX […] in aggiunta a quanto precedentemente installato, XX è stata creata una nuova macchina virtuale che viene utilizzata per fare il backup del XX dell’applicazione “XX” in Esercizio tramite il software XX. Questa nuova aggiunta consente di poter ripristinare, in tempi brevi, il XX in caso di problematiche in corso […] si precisa che il servizio VPN non ha avuto alcuna parte nell’incidente di sicurezza trattato. Oltre a quanto già citato, sono state proposte ulteriori attività per innalzare la postura di sicurezza come, per esempio: la disattivazione del Domain Controller (è attivo ma non più esposto e isolato); penetration test, sia applicativi e che infrastrutturali, sia da rete interna che esterna; corsi di awareness per i dipendenti; invio dei log dei firewall verso il SOC francese” (v. relazione tecnica pag. 39). Sul punto, la Società, in riscontro alla richiesta di informazioni del Dipartimento del XX, ha riportato lo stato di avanzamento delle misure tecniche e organizzative per innalzare la postura di sicurezza dichiarando di aver proceduto alla “dismissione completa del portale www.centrobasile.it; spegnimento del Domain Controller e migrazione di tutti i PC in XX; pianificazione di penetration test sull’applicazione XX (….); in fase di finalizzazione l’acquisto di una licenza annuale per awareness e simulazione di campagne di phishing per tutti i dipendenti Cerba Italia; l’invio dei log dei firewall verso il SOC francese è in fase di implementazione, sono in corso analisi sugli impatti e relativa gestione da parte del fornitore XX e del SOC” (v. nota del XX in riscontro alla richiesta di informazioni del XX, pag. XX).
5. Valutazioni del Dipartimento sul trattamento effettuato e notifica della violazione di cui all’art. 166, comma 5 del Codice
In ordine alla fattispecie descritta, l’Ufficio, sulla base di quanto rappresentato dal titolare del trattamento nell’atto di notifica di violazione e nei riscontri alle richieste di informazioni dell’Autorità, nonché delle successive valutazioni, ha notificato alla Società, ai sensi dell’art. 166, comma 5, del Codice, l’avvio di un procedimento per l’adozione dei provvedimenti di cui all’art. 58, par. 2, del Regolamento, invitando la stessa a produrre al Garante scritti difensivi o documenti ovvero a chiedere di essere sentita dall’Autorità (art. 166, commi 6 e 7, del Codice; nonché art. 18, comma 1, dalla legge n. 689 del 24 novembre 1981). In particolare, con atto n. XX, del XX, l’Autorità ha ritenuto che la Società aveva posto in essere trattamenti in violazione del principio di “integrità e riservatezza”, di “protezione dei dati fin dalla progettazione” (art. 5, par. 1, lett. f), e 25 del Regolamento) nonché degli obblighi in materia di sicurezza del trattamento, di cui all’art. 32 del Regolamento.
La medesima Società ha fatto pervenire le proprie memorie difensive, ai sensi dell’art. 166, comma 6, del Codice. In particolare, con nota del XX a quanto già comunicato, ha aggiunto che:
- “il data breach occorso (…) ha riguardato (…) 467 file PDF (464 file univoci) contenenti dati sanitari degli utenti; 102.948 interessati, avuto riguardo ai soli dati anagrafici e di contatto. A fronte del flusso dei pazienti che usufruiscono delle prestazioni sanitarie del gruppo Cerba, si vuole evidenziare come l’attacco informatico subito risulta un caso isolato che ha riguardato un gruppo circoscritto di pazienti, tra i quali (…) non figurano soggetti minori. In particolare, per quanto riguarda il perimetro della Campania in cui svolge attività il Centro Basile, su un totale di 465.033 pazienti registrati nel XX, solo 102.948 sono stati coinvolti nell'incidente, corrispondendo a una percentuale di incidenza del 22,14%”;
- “all’esito di attività di monitoraggio interno (…) non sono emersi danni di alcun genere in capo agli interessati coinvolti. L’incidente conseguente all'attacco hacker subito - di natura evidentemente dolosa (…)- è stato gestito con la massima serietà e urgenza, con il risultato che gli effetti della violazione sono stati notevolmente contenuti, non essendo stata registrata ulteriore diffusione dei dati verso terzi, e con una minimizzazione, pertanto, del rischio per i pazienti coinvolti”;
- “a più di un anno dall'incidente, non risulta che siano stati ricevuti reclami circa danni subiti da parte dei pazienti nei confronti di Cerba a seguito dell’incidente di sicurezza. (…) non sono state avanzate richieste risarcitorie da parte dei pazienti nei confronti del Centro a seguito della violazione, a dimostrazione del fatto che non risulta che questi ultimi abbiano subito alcun danno”;
- “il trattamento dei dati colpiti da data breach ha avuto, inoltre, un carattere meramente locale, in quanto limitato ai pazienti del Centro Diagnostico Basile Spa, che opera su scala provinciale”;
- “la contestata violazione non solo non era evidentemente voluta (neppure in termini di accettazione del rischio) da parte del Centro, ma lo stesso aveva improntato la propria cultura aziendale e la propria attività di prevenzione proprio al fine di evitare eventi di tale tipologia. Più nel dettaglio, già prima della data dell’attacco malevolo, il Centro aveva messo in atto diverse misure di sicurezza. Tra queste, si può citare la migrazione del firewall a XX (XX) che rappresenta un passo significativo nella protezione delle reti. Il progetto avviato con XX (XX) per l’integrazione dell’SD-WAN su tutte le sedi Cerba prevede infatti alcuni benefici, il primo dei quali è legato alla “business continuity”. Grazie all’implementazione di due connettività ben distinte su ciascuna sede Cerba, questa tecnologia stabilisce in modo intelligente il percorso che meglio soddisfa le esigenze prestazionali ideali di una specifica applicazione; dopodiché, il traffico viene indirizzato attraverso il percorso WAN ideale, a differenza di quanto accade nelle architetture WAN tradizionali che hanno solo la possibilità di indirizzare tutte le applicazioni tramite una singola connettività prestabilita”;
- “usando il portale XX (…) è possibile gestire i dispositivi XX (firewall) con connettività SD-WAN installati su tutta la rete Cerba. È possibile altresì aggiornare e distribuire firmware e policy aziendali per la WAN a tutte le sedi o riconfigurare singoli dispositivi. Da segnalare anche che, da contratto, XX (XX) offre anche un servizio di “Patch Management” che garantisce l’implementazione delle patch (correzioni o aggiunte) nei sistemi, favorendo il corretto e costante aggiornamento dei servizi, proteggendoli da potenziali minacce e risolvendo eventuali bug. Il processo, infatti, si occupa di correggere eventuali errori di codice, gestire le vulnerabilità nei sistemi e migliorare le funzionalità esistenti”;
- “gli accessi agli applicativi erano protetti tramite username e password, garantendo così un livello base di sicurezza. Inoltre, le utenze XX erano gestite da un dominio locale in XX, che successivamente è stato dismesso e migrato su XX durante il periodo dell'attacco”;
- “era stato implementato l’antivirus XX, che fornisce una protezione aggiuntiva contro le minacce informatiche. È importante sottolineare che le modalità di accesso agli applicativi sono state chiaramente definite e comunicate più volte all'interno dell’organizzazione. Infine, anche l'accesso ai locali tecnici era rigorosamente limitato, un altro indicativo della volontà del Centro di mantenere alti standard di sicurezza e protezione dei dati”;
- “il Centro ha sostenuto significativi costi sia pre che post incidente (…) evidenziando ulteriormente l’attenzione e la serietà con cui è stato affrontato il problema. I costi includono: - Investimenti Pre-Incidente: Spese per l’implementazione delle misure di sicurezza, acquisto di software antivirus, aggiornamenti dei sistemi e formazione del personale; - Spese Post-Incidente: Costi legati all’assistenza legale, alla comunicazione con le autorità competenti, al ripristino dei sistemi e all’implementazione di ulteriori misure di sicurezza per prevenire futuri attacchi”;
- “per suggerire tempestivamente agli interessati le contromisure da adottare, sono state effettuate comunicazioni specifiche ai sensi dell’art. 34 GDPR (…). Più precisamente, le comunicazioni agli interessati sono state fatte tramite pubblicazione di un comunicato stampa sul sito ‘diagnosticabasile.it’ il XX e sui giornali "Il Mattino" e “Il Corriere del Mezzogiorno” in data XX, tramite e-mail, sms, posta raccomandata nelle date XX, XX, XX e XX; le comunicazioni ai dipendenti sono state inviate in data XX. Di seguito si riportano nel dettaglio le comunicazioni inviate alle diverse categorie di interessati, suddivise per modalità di invio:
• dei 464 pazienti di cui sono stati esfiltrati anche dati sanitari:
n. 126 sono stati avvisati tramite e-mail in data XX;
n. 221 tramite sms in data XX;
n. 18 tramite raccomandata in data XX;
• dei 102.948 pazienti di cui risultano esfiltrati soltanto dati comuni:
15.804 sono stati avvisati tramite e-mail, inviate tra il XX e il XX;
21.393 sono stati avvisati tramite sms in data XX”;
- “al fine di raggiungere la restante parte dei pazienti (in mancanza di indirizzo mail, numero di telefono e indirizzo telefonico) la comunicazione è avvenuta tramite pubblicazione sul sito aziendale e sul giornale “Il Mattino” e “Corriere del Mezzogiorno” in data XX. Inoltre, poiché è stato accertato che tra i pazienti vi erano anche pazienti/dipendenti di Clienti, la circostanza è stata comunicata anche agli 11 Clienti tramite e-mail inviata agli stessi in data XX. Tutti i 97 dipendenti sono stati avvisati tramite e-mail inviate il XX. Dei 57 ex dipendenti, 43 sono stati avvisati tramite SMS e 4 tramite e-mail. Sia le e-mail che i messaggi sono stati inviati in data XX. I restanti 10 non sono stati avvisati per mancanza dei relativi riferimenti (indirizzo, e-mail o numero di telefono); dei 45 Consulenti, (i) 20 sono stati avvisati tramite comunicazione inviata a mezzo e-mail in data XX e (ii) 25 tramite comunicazione inviata a mezzo posta sempre in data XX”;
- “gli interessati sono stati invitati a prestare la massima attenzione in caso di ricezione di telefonate, e-mail, lettere e/o altre comunicazioni postali apparentemente provenienti da operatori sanitari, organizzazioni assicurative o previdenziali e altri soggetti sconosciuti e/o estranei e/o comunque non accertati, avvisandoli che si sarebbe potuto trattare di soggetti malintenzionati, intenzionati a sfruttare informazioni già in proprio possesso o ulteriormente acquisite, ai fini di attività fraudolente. Non si è avuta alcuna notizia circa eventi successivi che abbiano coinvolto la sfera giuridica degli interessati”;
- “in relazione alla violazione dei dati, si comunica che, al momento dell’incidente, l'infrastruttura informatica era protetta da un sistema di firewall fornito da XX, e ciascun PC, così come il server centrale, era dotato di un sistema antivirus (XX). Per quanto riguarda la componente applicativa, il fornitore garantiva la gestione del software rilasciato in ambiente produttivo, assicurando bonifiche adeguate”;
- “XX è una soluzione di gestione cloud degli endpoint che gestisce l'accesso degli utenti e semplifica la gestione di un’ampia gamma di dispositivi, inclusi i dispositivi mobili, i computer desktop e gli endpoint virtuali. Tra i software monitorati grazie a XX, XX. Come ulteriore misura di controllo, i dispositivi del centro Basile sono stati raggruppati in XX, nel gruppo ‘Centro Basile’ (…), a fini di monitoraggio, per completezza (…). I firmware dei firewall del gruppo sono stati inoltre aggiornati all’ultima versione ‘mature’ disponibile, che risulta essere, al momento in cui si scrive, XX (…). Nel contesto delle recenti iniziative di potenziamento della sicurezza informatica, Cerba ha adottato il sistema XX, rappresentando un'evoluzione significativa rispetto alle tradizionali soluzioni di EDR (Endpoint Detection and Response)”;
- in relazione alla pianificazione di penetration test sull’applicazione XX, “la piattaforma XX è stata inclusa nel piano annuale di Vulnerability Assessment e Penetration Test di Cerba Healthcare (…). Tale piano è concepito con l’obiettivo di valutare il livello di sicurezza degli applicativi considerati a rischio critico per l’azienda, consentendo di identificare e correggere tempestivamente le vulnerabilità eventualmente riscontrate (…)”;
- “da anni Cerba nell’organizzare la formazione ai propri dipendenti inserisce un modulo sulla prevenzione degli attacchi informatici nella consapevolezza del loro aumento esponenziale in termini di quantità, sofisticatezza ed efficienza, in particolare nel settore sanitario. Al fine di incrementare il livello di consapevolezza sui temi cybersecurity della propria popolazione aziendale, Cerba HealthCare Italia ha acquistato, tramite il reseller XX, per tutte le società del Gruppo, una licenza annuale per la piattaforma di Cyber Security Awareness CyberGuru”;
- “i corsi annuali di CyberSecurity Awareness sono organizzati in 12 moduli (…), ciascuno comprendente 36 lezioni, e vengono erogati a tutta la popolazione aziendale interna. Per valutare il livello di preparazione dei dipendenti Cerba, sono previsti 36 test di apprendimento, uno alla fine di ciascuna lezione, e 4 test di consolidamento. Il livello di coinvolgimento della popolazione aziendale viene verificato mensilmente dalla funzione HR e sollecitato mediante comunicazioni a tutta la popolazione aziendale interna (…). Dopo l’avvenuto completamento di tutti e 12 i moduli dell’annualità, l’utente ha la possibilità di scaricare il proprio attestato di partecipazione. I corsi coprono gli argomenti di sicurezza informatica necessari ai dipendenti Cerba per ampliare drasticamente la conoscenza di temi cruciali (…)”;
- “la piattaforma CyberGuru presenta anche un innovativo servizio di simulazione di campagne di phishing, basato sul principio della gamification, attivato per tutta la popolazione aziendale interna. Tale sistema permette di simulare complesse campagne di phishing raccogliendo analitiche dettagliate, offrendo la possibilità di reportistica avanzata e organizzando gli utenti in squadre, al fine di incrementarne il livello di coinvolgimento e migliorarne l’apprendimento. Durante l’annualità è possibile organizzare 12 campagne di phishing (…), la cui durata standard risulta essere 3-4 settimane. Sulla base dei risultati emersi dalle analitiche raccolte, è possibile organizzare campagne mirate sui cluster di utenti che hanno maggiore bisogno di essere sensibilizzati sul tema Cyber Security, in modo da rafforzarne il livello di resistenza agli attacchi”;
- “oltre all'attività formativa di tipo "frontale", la società si impegna costantemente nella sensibilizzazione del personale interno sui temi inerenti alla cyber security attraverso l'invio periodico di comunicazioni a carattere formativo (…). Tra le iniziative intraprese, si segnalano le periodiche notifiche relative a tentativi di phishing, come esemplificato dall’avviso [Phishing Alert XX].eml (…), attraverso le quali si informa tempestivamente il personale riguardo alle minacce in atto da parte di soggetti malintenzionati. Ulteriormente, si forniscono specifiche linee guida operative e comportamentali per garantire una condotta conforme agli standard di sicurezza aziendale”;
- “Cerba Healthcare Italia ha completato con successo l’attivazione del flusso di invio al SOC (…)”;
- “unitamente alla predetta integrazione, il Centro ha depositato una relazione tecnica (…) contenente elementi cruciali per l'ulteriore sviluppo delle indagini, che attualmente sono ancora in corso. Questa azione non è da intendersi solo come una misura di autoprotezione, ma come un contributo attivo alla sicurezza collettiva. La nostra cooperazione con le forze dell'ordine mira a prevenire il verificarsi di situazioni analoghe in futuro, proteggendo non solo i nostri sistemi, ma anche quelli di altre organizzazioni e la popolazione in generale, dunque, orientata a garantire un’efficace gestione della cybersecurity. Abbiamo fornito tutte le informazioni necessarie per facilitare le indagini, consapevoli che il nostro coinvolgimento non si limita alla nostra realtà, ma si estende all'intera comunità. Infatti, eventi di sicurezza informatica possono avere ripercussioni ben più ampie, potenzialmente coinvolgendo altre entità e cittadini”;
- “in data XX il Centro ha, altresì, segnalato l’evento alla Agenzia per la Cybersicurezza Nazionale (ACN) (…). Tale condotta dimostra il forte spirito di collaborazione da parte del titolare del trattamento dei dati, il quale ha prontamente adottato tutte le misure necessarie per contenere e gestire l’incidente di data breach, sotto un profilo anche più ampio di quanto strettamente previsto come obbligatorio dalla normativa vigente in materia di protezione dei dati personali”;
- “la violazione ha riguardato dati personali comuni anagrafici (nome, cognome, sesso, data di nascita, luogo di nascita, codice), dati di contatto (indirizzo postale o di posta elettronica, numero di telefono fisso o minclusioneobile), dati di accesso e di identificazione (username, hashed passwords, cleartext passwords, customer ID, sessionid, tokens), dati relativi alla salute (solo limitatamente a 476 interessati)”;
- “tutte le pagine ASP del sito www.centrobasile.it e dell’applicativo CUP (XX) risultavano protette da attacchi di tipo "XX" (..) ad eccezione di quella specificamente compromessa e sfuggita al controllo. La protezione delle stringhe di XX (parametri di query mediante metodi GET/POST) veniva garantita attraverso XX. Inoltre, tutte le pagine che richiedevano accesso al database erano ulteriormente protette tramite XX (…). Questo sistema assicurava che solo gli utenti correttamente autenticati potessero accedere alle pagine protette, mentre coloro che non risultavano loggati venivano automaticamente reindirizzati alla pagina di login. Tali misure dimostrano l’esistenza di un’architettura di sicurezza implementata, che ha limitato l’estensione della violazione e che può essere considerata come fattore attenuante nel contesto dell’art. 83 del GDPR”;
- “l'applicativo CUP era originariamente progettato per essere utilizzato esclusivamente all'interno di una rete Intranet. Di conseguenza, l'accesso era consentito solo a PC o workstation i cui indirizzi IP locali (LAN) rientravano obbligatoriamente nella medesima subnet, garantendo così una segregazione logica degli accessi. Questa configurazione limitava l'utilizzo dell'applicativo alle sole risorse interne all'organizzazione, riducendo significativamente il rischio di accessi non autorizzati dall'esterno. Tale scelta architetturale, pensata per garantire un livello di sicurezza elevato fin dalla progettazione, rappresenta un ulteriore fattore attenuante che può essere considerato ai sensi dell'art. 83 del GDPR”;
- “vengono riportati di seguito dettagli attenuanti sulle tabelle esfiltrate per i vari DB violati:
1. DB CUP - Tabella UTENTI: La tabella conteneva le informazioni relative alle utenze dei dipendenti interni della sede campana, i quali utilizzavano il software di prenotazione di prestazioni specialistiche (XX). È importante sottolineare che tali utenze non disponevano di accesso diretto al database, ma interagivano esclusivamente tramite l’applicativo web. Anche nel caso di utenti con privilegi amministrativi, non era possibile visualizzare le password dei pazienti, poiché queste risultavano oscurate nella visualizzazione a schermo.
A ulteriore protezione, era implementato un meccanismo di controllo sulla scadenza delle password (…) qualora una password risultasse scaduta, il paziente era obbligato a rinnovarla in autonomia attraverso il front-end del sito www.centrobasile.it. Gli operatori interni non avevano alcuna possibilità di impostare o modificare le password dei pazienti, garantendo così l’indipendenza del processo di gestione delle credenziali.
Inoltre, ciascun utente del sistema era associato a un profilo specifico, definito in base al ruolo ricoperto, che limitava l’accesso e l’utilizzo del software solo a determinate funzioni autorizzate. Questo sistema di gestione dei permessi rappresenta un ulteriore fattore di mitigazione del rischio, in quanto limitava il potenziale impatto derivante dalla compromissione dei dati, e può essere considerato come attenuante ai sensi dell'art. 83 del GDPR.
L'accesso al sistema online era inoltre costantemente monitorato tramite un sistema di log attivo sul medesimo database (…). Tale sistema registrava in modo dettagliato ogni accesso, sia riuscito che fallito, nonché tutte le operazioni di modifica delle password, inclusi i tentativi falliti, e i download dei referti. (…) le tabelle esfiltrate non contenevano password, riducendo così il rischio di compromissione diretta delle credenziali degli utenti.
2.DB Magazzino: Il database Magazzino era collegato a un applicativo di tipo Client/Server, non esposto su internet, utilizzato esclusivamente per la gestione di ordini e delle giacenze di magazzino. Le tabelle contenute in questo database non includevano dati anagrafici dei pazienti, bensì informazioni di carattere gestionale, nello specifico:
• La tabella XX conteneva la ragione sociale della società HUB;
• La tabella XX memorizzava dati descrittivi delle sedi SPOKE, necessari per l’emissione dei documenti di trasporto relativi alla consegna e all’evasione degli ordini;
• La tabella XX conteneva le utenze dei dipendenti interni della sede, i quali non avevano accesso diretto al database. A ogni utenza era associato un profilo di sicurezza in base al ruolo, e la creazione e gestione degli utenti era riservata esclusivamente agli amministratori.
3. XX - Tabella 'XX': La tabella 'XX' nel database XX conteneva le utenze abilitate all'accesso ai singoli database. Le password erano cifrate mediante funzioni di hashing di XX, garantendo così un elevato livello di protezione.
Il server che ospitava i database era una macchina XX, protetta da un firewall configurato con regole XX. L'accesso remoto tramite l'account XX era disabilitato grazie all'opzione "XX" nel servizio XX, prevenendo così accessi non autorizzati da remoto. Inoltre, il firewall gestiva XX. La porta del servizio XX era anch’essa bloccata in XX, consentendo l'accesso unicamente dalla rete locale LAN.
La manutenzione dei database era affidata a un unico amministratore di sistema, il quale verificava periodicamente l'integrità dei backup programmati tramite script XX. I backup venivano conservati su un server NAS situato in un'altra sala tecnica, a distanza di sette piani dall’ubicazione del server principale, garantendo così una separazione fisica delle copie di sicurezza. Lo stesso amministratore di sistema, unico dipendente autorizzato ad accedere fisicamente al locale tecnico, monitorava costantemente i log di sistema e XX.
A seguito dell’incidente di sicurezza, sono state tempestivamente adottate le seguenti misure per mitigare le conseguenze e migliorare la protezione dei sistemi informativi.
In conformità alle raccomandazioni sulla postura di sicurezza fornite da XX, è stato immediatamente deciso di escludere XX dal sistema. Di conseguenza, tutti i client del Centro Diagnostico Basile sono stati XX sotto il dominio cerbahealthcare.it, garantendo così un’infrastruttura di autenticazione più sicura e robusta”;
- “quanto al server fisico virtualizzatore, esso è ancora in uso (…), al fine di ospitare una macchina virtuale (con a bordo middleware di XX) che invia in cloud XX le timbrature provenienti da due marcatempo”.
Durante l’audizione richiesta dalla parte e che si è svolta in data XX, la Società ha inteso precisare, tra l’altro, che:
- “l’attacco ha riguardato il sistema di prenotazione on line della struttura Centro Basile che gestisce circa 465.000 pazienti all’anno; i dati sanitari esfiltrati hanno riguardato referti riconducibili a 464 interessati, di cui nessun minorenne; ciò, ad evidenziare una modesta incidenza percentuale dell’attacco (1 per mille). I restanti dati coinvolti sono dati anagrafici e, considerato che la società è specializzata anche in attività di prevenzione sanitaria, si ritiene che tali ultimi dati non siano collegati o collegabili a una prestazione sanitaria specifica”;
- “la società era già dotata di misure di sicurezza al momento dell’attacco”;
- “CerbaHealthCare ha risposto con professionalità, tempestività e grande impegno economico. La società aveva già investito 2,9 milioni euro dal XX al XX, per dare avvio ad un nuovo ecosistema, che comprende un sistema prenotazione “IN.CERBA”, che risulta uno dei più avanzati a livello nazionale ed europeo e rispetto al quale è stata effettuata la DPIA e il Penetration Test”;
- “l’impegno profuso è stato dedicato, altresì, al supporto all’autorità investigativa, mettendo a disposizione, a proprie spese (di circa 210.000 euro) un team di professionisti, tra cui un avvocato specialista in diritto penale, che ha contribuito a fornire elementi funzionali all’individuazione dei responsabili dell’attacco”;
- “si chiede di valutare, secondo il principio dell’assorbimento, l’impegno della società in relazione agli investimenti effettuati anche a supporto della collettività, ove fossero rilevati gli estremi per comminare una sanzione amministrativa”;
- “nell’ambito delle attività investigative, sono stati individuati due server chiave coinvolti nell’attacco (rispettivamente in Repubblica Ceca e in Svizzera), di cui è stato richiesto il sequestro da parte dell’autorità giudiziaria, la quale è in attesa di riscontro da parte delle autorità estere”.
6. Esito dell’attività istruttoria
Preso atto di quanto rappresentato dalla Società nel corso del procedimento, si osserva che:
si considerano “dati relativi alla salute”, “i dati personali attinenti alla salute fisica o mentale di una persona fisica, compresa la prestazione di servizi di assistenza sanitaria, che rivelano informazioni relative al suo stato di salute” (art. 4, par. 1, n. 15, del Regolamento);
i dati personali devono essere “trattati in maniera da garantite un’adeguata sicurezza (…) compresa la protezione, mediante misure tecniche e organizzative adeguate, da trattamenti non autorizzati o illeciti e dalla perdita, dalla distruzione o dal danno accidentali” (principio di «integrità e riservatezza», art. 5, par. 1, lett. f), del Regolamento);
l’art. 32 del Regolamento, 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” adottate dal Comitato europeo per la protezione dei dati il 28 Marzo 2023 (di seguito “Linee guida sulla notifica”) chiariscono che la capacità di individuare, trattare e segnalare tempestivamente una violazione deve essere considerata un aspetto essenziale delle misure tecniche e organizzative che il titolare e il responsabile del trattamento devono mettere in atto, ai sensi dell’art. 32 del Regolamento, per garantire un livello adeguato di sicurezza dei dati personali (punto 41);
secondo il principio della “protezione dei dati fin dalla progettazione”, enucleato nell’art. 25, par. 1, del Regolamento, il titolare del trattamento, “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 (…)” deve 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 Considerando n. 75 del Regolamento);
il Considerando n. 78 del Regolamento suggerisce una responsabilità dei titolari, ossia quella di valutare costantemente se stiano utilizzando, in qualunque momento, i mezzi appropriati di trattamento e se le misure scelte contrastino effettivamente le vulnerabilità esistenti. Inoltre, 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 (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 il 20 ottobre 2020, spec. punti 38, 39 e 84). In tale quadro, il titolare è tenuto a:
valutare i rischi per la sicurezza dei dati personali, considerando l’impatto sui diritti e le libertà degli interessati, e contrastare efficacemente quelli identificati, nonché, ai fini dell’utilizzo nella valutazione dei rischi, sviluppare e gestire una «modellizzazione delle minacce» esaustiva, sistematica e realistica e un’analisi della superficie di attacco riferita al software specifico così da ridurre i vettori di attacco e le opportunità di sfruttare eventuali punti deboli e vulnerabilità;
tenere conto non appena possibile dei requisiti di sicurezza nella progettazione e nello sviluppo del sistema, integrando e svolgendo costantemente test pertinenti;
rivedere e verificare periodicamente il software, l’hardware, i sistemi e i servizi, ecc. per scoprire eventuali vulnerabilità dei sistemi di supporto del trattamento;
effettuare revisioni periodiche delle misure di sicurezza poste a presidio e tutela dei dati personali;
tenere conto non appena possibile dei requisiti di sicurezza nella progettazione e nello sviluppo del sistema, integrando e svolgendo costantemente test pertinenti;
proteggere i dati personali da modifiche e accessi non autorizzati e accidentali, sia durante il loro trasferimento che durante la loro conservazione (cfr. le citate “Linee guida 4/2019 sull’articolo 25 - Protezione dei dati fin dalla progettazione e per impostazione predefinita”, punto 85).
7. Conclusioni: dichiarazione di illiceità del trattamento.
Alla luce di quanto sopra rappresentato, si rileva che i trattamenti effettuati nel contesto in esame richiedono l’adozione dei più elevati standard di sicurezza al fine di non compromettere la riservatezza, l’integrità e la disponibilità dei dati personali di un numero molto rilevante di interessati. Ciò, tenendo altresì conto delle finalità dei trattamenti e della natura dei dati personali trattati, appartenenti anche a categorie particolari e, in particolare, a dati sulla salute. A tal riguardo, gli obblighi di sicurezza previsti dal Regolamento impongono 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.
Sulla base delle valutazioni sopra richiamate, tenuto conto delle dichiarazioni rese dal titolare del trattamento nel corso dell’istruttoria e considerato che, salvo che il fatto non costituisca più grave reato, chiunque, in un procedimento dinanzi al Garante, 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 dal titolare del trattamento nella memoria difensiva sopra richiamata, seppure meritevoli di considerazione, non consentono di superare i rilievi notificati dall’Ufficio con il richiamato atto di avvio del procedimento, non ricorrendo, peraltro, alcuno dei casi previsti dall’art. 11 del regolamento del Garante n. 1/2019.
Dall’esame delle informazioni e degli elementi acquisiti nonché della documentazione fornita è risultato che il trattamento è stato effettuato dalla Società in violazione degli artt. 5, par. 1, lett. f), 25 e 32 del Regolamento, in relazione ai profili di seguito riportati.
7.1. Mancata adozione di misure per garantire la sicurezza applicativa
Nel corso dell’istruttoria è emerso che la Società, al momento in cui si è verificata la violazione dei dati personali, non aveva adottato misure adeguate a eliminare talune vulnerabilità del codice della pagina “www.centrobasile.it/...”. In particolare, tale pagina è risultata vulnerabile ad attacchi di tipo XX mediante “tecniche di info fuzzing sul parametro “XX””. Con tale tecnica di hacking, gli attaccanti sono riusciti ad accedere e acquisire, in modo illecito, la struttura (c.d. schema) dei database ivi presenti e a esfiltrare i dati contenuti, in particolare, nelle tabelle denominate “XX” del database CUP “XX” del database Magazzino e “XX” del database XX. L’assenza di adeguate misure a presidio della sicurezza applicativa non risulta conforme alle disposizioni di cui all’art. 5, par. 1, lett. f), e all’art. 32, par. 1, del Regolamento, che stabilisce che il titolare e il responsabile del trattamento debbano mettere in atto misure per “assicurare su base permanente la riservatezza, l’integrità, la disponibilità e la resilienza dei sistemi e dei servizi di trattamento” (lett. b)) e per “testare, verificare e valutare regolarmente l’efficacia delle misure tecniche e organizzative al fine di garantire la sicurezza del trattamento” (lett. d)).
7.2. Mancata adozione di misure adeguate alla conservazione delle password degli utenti
Dalla documentazione in atti, è emerso, altresì, che, al momento in cui si è verificata la violazione dei dati personali, le password degli utenti erano conservate previa applicazione di una funzione di hashing (“XX”) mentre quelle degli utenti amministratori del sito web erano addirittura conservate in chiaro. La citata funzione di hashing risulta non robusta in termini crittografici e il suo utilizzo non rappresenta una misura efficace per proteggere le password degli utenti in quanto sono note, già da diversi anni, gravi vulnerabilità di tale funzione che consentono di risalire, a partire da un digest, alla password che lo ha generato. Al riguardo, si rileva come la conservazione delle password mediante l’utilizzo di tecniche crittografiche allo stato dell’arte sia una delle misure comunemente adottate per proteggere le password degli utenti di un sistema informatico o di un servizio online; ciò tenuto conto degli elevati rischi in caso di accesso non autorizzato alle stesse o di loro divulgazione, in ragione dell’abitudine degli utenti di utilizzare, anche a distanza di tempo, le medesime password, o password simili tra loro, per lo stesso o per altri sistemi informatici o servizi online (c.d. password reuse).
La conservazione delle password degli utenti senza l’adozione di tecniche crittografiche, allo stato dell’arte, si pone, quindi, in contrasto con l’art. 5, par. 1, lett. f), e con l’art. 32 del Regolamento che, al par. 1, lett. a), individua espressamente la cifratura come una delle possibili misure di sicurezza idonee a garantire un livello di sicurezza adeguato al rischio (v. anche cons. 83 del Regolamento che recita che “il titolare del trattamento (…) dovrebbe valutare i rischi inerenti al trattamento e attuare misure per limitare tali rischi, quali la cifratura”).
7.3. Mancato rispetto del principio della protezione dei dati fin dalla progettazione
Alla luce di quanto sopra considerato, risulta, altresì, che la Società non abbia adottato, fin dalla progettazione, adeguate misure per garantire l’effettiva applicazione del principio di “integrità e riservatezza”, tenendo conto anche dei rischi per i diritti e le libertà degli interessati derivanti dai trattamenti in esame.
Tutto ciò premesso, si rileva che il trattamento di dati personali in questione è stato effettuato in violazione dei principi di “integrità e riservatezza”, di “protezione dei dati fin dalla progettazione” (art. 5, par. 1, lett. f), e 25 del Regolamento) nonché degli obblighi in materia di sicurezza del trattamento, di cui all’art. 32 del Regolamento.
Si ritiene che ricorrano i presupposti di cui all’art. 17 del Regolamento del Garante n. 1/2019.
8. 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 e 32 del Regolamento, causata dalla condotta posta in essere dalla Società, comporta l’applicazione della sanzione amministrativa pecuniaria ai sensi dell’art. 83, par. 4 e 5 del Regolamento.
Il Garante, ai sensi dell’art. 58, par. 2, lett. i) del Regolamento e 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”, mediante l’adozione di una ordinanza ingiunzione (art. 18 legge 24 novembre 1981, n. 689), in relazione al trattamento dei dati personali effettuato dalla Società, di cui è stata accertata l’illiceità, nei termini sopra esposti.
Ritenuto di dover applicare il par. 3 dell’art. 83 del Regolamento laddove prevede che “se, in relazione allo stesso trattamento o a trattamenti collegati, un titolare del trattamento […] viola, con dolo o colpa, varie disposizioni del presente Regolamento, l’importo totale della sanzione amministrativa pecuniaria non supera l’importo specificato per la violazione più grave”, l’importo totale della sanzione è calcolato in modo da non superare il massimo edittale previsto dal medesimo art. 83, par. 5.
Alla luce di quanto sopra illustrato e, in particolare, della categoria di dati personali interessata dalla violazione, che, per loro natura, sono particolarmente sensibili sotto il profilo dei diritti e delle libertà fondamentali, si ritiene che il livello di gravità della violazione commessa dalla Società sia alto (cfr. Comitato europeo per la protezione dei dati, “Guidelines 04/2022 on the calculation of administrative fines under the GDPR” del 23 maggio 2023, punto 60), nonostante il carattere non intenzionale della violazione (l’episodio risulta essere stato determinato da un comportamento doloso da parte di un soggetto terzo, denunciato formalmente alla polizia postale).
Considerato il fatturato della Società, sono, altresì, valutati gli ulteriori elementi previsti dall’art. 83, par. 2, del Regolamento e, in particolare, che:
- il Garante ha preso conoscenza dell’evento a seguito della notifica di violazione effettuata dalla Società, ai sensi dell’art. 33 del Regolamento e non sono pervenuti reclami o segnalazioni in ordine alla violazione oggetto del presente provvedimento (art. 83, par. 2, lett. h) e k) del Regolamento);
- il titolare, al fine di evitare la ripetizione dell’evento occorso, si è impegnato nell’introduzione di misure volte a ridurre la replicabilità dell’evento occorso e ha cooperato con l’Autorità in ogni fase dell’istruttoria, al fine di porre rimedio alla violazione e attenuarne i possibili effetti negativi (art. 83, par. 2, lett. c) e f) del Regolamento);
Alla luce degli elementi sopra indicati e delle valutazioni effettuate, si ritiene, nel caso di specie, di determinare l’ammontare della sanzione pecuniaria nella misura di euro 8.000,00 (ottomila/00) per la violazione degli artt. 5, 25 e 32 del medesimo Regolamento, in ragione dei principi di effettività, proporzionalità e dissuasività ai quali l’Autorità deve attenersi, ai sensi dell’art. 83, par. 1, del Regolamento.
In tale quadro si ritiene, altresì, che, ai sensi dell’art. 166, comma 7, del Codice e dell’art. 16, comma 1, del Regolamento del Garante n. 1/2019, si debba procedere alla pubblicazione del presente capo contenente l’ordinanza ingiunzione sul sito Internet del Garante. Ciò, in considerazione della tipologia di dati personali oggetto di illecito trattamento e del rilevante numero di interessati coinvolti.
TUTTO CIÒ PREMESSO IL GARANTE
ai sensi degli artt. 57, par. 1, lett. f) e 83 del Regolamento, rileva l’illiceità del trattamento effettuato dalla Società Cerba HealthCare Campania S.r.l., con sede legale in Viale Michelangelo 13 - 80129 Napoli, C.F.: 03171950631, nei termini di cui in motivazione, per la violazione degli artt. 5, 25 e 32 del Regolamento;
ORDINA
ai sensi dell’art. 58, par. 2, lett. i) del Regolamento, alla medesima Società, in persona del legale rappresentante pro-tempore, di pagare la somma di euro 8.000,00 (ottomila/00) a titolo di sanzione amministrativa pecuniaria per la violazione indicata nel presente provvedimento.
INGIUNGE
alla predetta Società di pagare la somma di euro 8.000,00 (ottomila/00) secondo le modalità indicate in allegato, entro 30 giorni dalla notificazione del presente provvedimento, pena l’adozione dei conseguenti atti esecutivi a norma dall’art. 27 della legge n. 689/1981. Si rappresenta che ai sensi dell’art. 166, comma 8 del Codice, resta salva la facoltà per il trasgressore di definire la controversia mediante il pagamento -sempre secondo le modalità indicate in allegato- di un importo pari alla metà della sanzione irrogata entro il termine di cui all’art. 10, comma 3, del d. lgs. 1° settembre 2011, n. 150 previsto per la proposizione del ricorso come sotto indicato.
DISPONE
a) ai sensi dell’art. 166, comma 7, del Codice e dell’art. 16, comma 1, del Regolamento del Garante n. 1/2019, la pubblicazione dell’ordinanza ingiunzione sul sito internet del Garante;
b) ai sensi dell’art. 154-bis, comma 3 del Codice e dell’art. 37 del Regolamento del Garante n. 1/2019, la pubblicazione del presente provvedimento sul sito internet dell’Autorità;
c) ai sensi dell’art. 17 del Regolamento del Garante n. 1/2019, l’annotazione delle violazioni e delle misure adottate in conformità all’art. 58, par. 2 del Regolamento, nel registro interno dell’Autorità previsto dall’art. 57, par. 1, lett. u) 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, 11 settembre 2025
IL PRESIDENTE
Stanzione
IL RELATORE
Scorza
IL SEGRETARIO GENERALE
Fanizza
