Ci stiamo abituando male, anzi malissimo. Nelle ultime settimane sono usciti articoli che descrivevano alcuni data breach subiti da aziende italiane, due in particolare hanno destato curiosità e clamore: il primo verso un’azienda di trasporti e il secondo verso un’azienda sanitaria pubblica. Dopo l’uscita delle notizie si sono lette molte opinioni mentre altre non sono emerse con la giusta forza e da questa riflessione è nato il presente articolo.
La questione della correttezza nella comunicazione
La comunicazione fatta a seguito di un data breach deve essere chiara e completa. Le informazioni rilasciate nel comunicato della “vittima” non sono fornite per “gentile concessione” ma sono dovute. Sono dovute agli utenti, sono dovute alle autorità, sono dovute ai fornitori, sono dovute agli interessati e il termine “dovuto” indica proprio che si tratta di un obbligo. Un obbligo che si realizza fornendo le informazioni nel modo più completo possibile: omettere nel comunicato l’orizzonte temporale del data breach è una mancanza importante. L’utente finale, colpito dalla violazione di sicurezza, potrebbe aver acquistato, ad esempio, biglietti per conto terzi (magari per conto di un soggetto istituzionale) mesi prima del data breach ed è lecito chiedersi se già all’epoca il sistema fosse compromesso. Magari, invece, il data breach ha interessato un orizzonte temporale più breve (diciamo qualche settimana) ed il pericolo è più contenuto. Come può un utente stimare il livello di rischio per i suoi dati se l’orizzonte temporale non è specificato nel comunicato, nemmeno in forma generica? Eppure, il tempo è un fattore rilevante, anzi essenziale, nelle notifiche alle autorità (ACN, Garante, etc.…). Si sono letti e sentiti commenti molto positivi su quel comunicato solo per il fatto che era “meno peggio” della media di comunicati similari. È bene tenere presente che non esiste il “meno peggio”, esiste ciò che è dovuto per legge: se si dimentica questo fatto, si finisce con l’accettare passivamente anche una comunicazione mediocre solo perché leggermente più rifinita di un’altra.
La questione dei dati sanitari
I dati sanitari sono dati personali di categoria particolare: sono dati così tanto delicati e così tanto importanti da richiedere specifiche modalità di protezione per il loro trattamento. A questo proposito è bene ricordare che per disposizioni di legge il trattamento di dati personali è possibile solo se l’organizzazione che li deve trattare si è adeguatamente preparata al trattamento. Leggere frasi come:
per gli utenti con e senza privilegi amministrativi, le credenziali di autenticazione utilizzate per l’accesso remoto in VPN erano le stesse utilizzate per l’accesso ai sistemi di dominio (server e postazioni di lavoro).
Significa non aver capito nulla di quanto sta avvenendo nel campo privacy e cybersecurity e non certo dal punto di vista “nozionistico” ma dal punto di vista dei principi giuridici ed etici. Ciò che s’intende affermare è che una misura di sicurezza non è un mero problema tecnico, bensì è un aspetto nevralgico che travalica l’ambito tecnico-operativo. Leggere, nel 2026, frasi come “non erano previste procedure di autenticazione informatica a più fattori”, significa ignorare le disposizioni NIS 2 di cui all’art. 24 c.2 lettera L) che riporta proprio l’obbligo di utilizzare
soluzioni di autenticazione a più fattori o di autenticazione continua, […]
Non è quindi un caso che lo stesso Garante, in merito a tale mancanza riscontrata in fase istruttoria, scriva che:
Tale assetto, tenuto conto del contesto, della tipologia di dati trattati e della notoria esposizione del settore sanitario al rischio cyber, non può ritenersi conforme al livello di sicurezza richiesto dall’art. 32 del Regolamento.
È nelle parole “notoria esposizione” la parte più delicata, perché obbliga a fare una valutazione di merito oltre che di forma. Tra l’altro bisognerebbe menzionare anche le ulteriori lettere dell’art. 24 c.2 con particolare riguardo a quelle che fanno riferimento alla catena di fornitura da mettere in sicurezza, soprattutto quando sono i fornitori esterni a gestire i sistemi informativi (si ricordi la faccenda della ASST Rhodense). C’è poi da osservare quanto dichiara il Garante sulle risultanze ispettive, secondo le quali sarebbero emerse una pluralità di comportamenti dannosi da parte degli hacker e non opportunamente notati dai tecnici, tra cui:
- l’utilizzo di strumenti per l’estrazione di credenziali,
- attività di ricognizione della rete interna e delle utenze di dominio,
- esfiltrazione progressiva di dati,
- connessioni anomale in orari notturni,
- modifiche di chiavi di registro,
- creazione di file eseguibili malevoli
- attivazione di un’utenza privilegiata appartenente al gruppo “Domain Admins”.
Con riferimento all’ultimo comportamento elencato, a mero titolo di esempio, sarebbe opportuno far notare, che nel momento in cui viene generata un’utenza privilegiata, sarebbe necessario notificare tale evento (è una disposizione di legge prevista dalla Circolare 2/2017 di AgID)1.
Una riflessione e una proposta “critica” di soluzione
L’utente non si deve “accontentare” di un comunicato mal scritto, incompleto o comunque non puntuale: è un diritto dell’utente essere informato ed è un dovere dell’organizzazione informare correttamente. Ogni allontanamento da questo equilibrio non è solo assurdo e sbagliato ma è anche foriero di una cattiva educazione a cui è meglio non assoggettarsi.
La soluzione non può essere nei 10.000 euro di multa comminata dal Garante al soggetto pubblico (multa che, tra l’altro, pagheranno i cittadini). Nè la soluzione può essere la standardizzazione di tutti i modelli documentali esistenti per la notifica del data breach, la valutazione d’impatto (DPIA) e così via; la standardizzazione aiuta, agevola, facilità ma non risolve perché la causa del problema non è una carenza tecnica ma etica, professionale, organizzativa. E allora che fare?
Si pensi di condurre un’istruttoria approfondita, al termine della quale le evidenze oggettive mostrino una perdurata e diffusa negligenza nella gestione della sicurezza informatica e del trattamento dei dati. Sarebbero evidenze certe, di natura quantitativa, dimostrabili e delle quali si chiede conto al dirigente responsabile che, a quel punto, si troverebbe a pagare la multa in prima persona avendo causato un danno produttivo (ed erariale) all’organizzazione in oggetto oltre che ai suoi clienti/utenti/fornitori. Al di là della mera questione economica e sanzionatoria e della relativa critica scritta sopra, vi è un problema più rilevante: raramente “chi sbaglia, paga”. Le evidenze dei data breach spesso mostrano una situazione di degrado tecnico-organizzativo di cui i dirigenti responsabili dovrebbero rendere conto. Si tenga in considerazione ciò che le Misure di Sicurezza di Base della NIS stabiliscono.
Gli amministratori di sistema dei sistemi informativi e di rete sono individuati previa valutazione dell’esperienza, capacità e affidabilità e devono fornire idonea garanzia del pieno rispetto della normativa in materia di sicurezza informatica. [GV.PO-01-1]
È bene notare che il concetto di “esperienza” e di “capacità” può essere attribuito alla conoscenza nozionistica acquisita (capacità) e sviluppata nel tempo (esperienza) dall’amministratore di sistema, ma il concetto di “affidabilità” prescinde dalla conoscenza tecnica e si basa sulla capacità di fornire “garanzia di funzionare bene” (Treccani). La parola “affidabilità” fa riferimento al metodo di lavoro, all’etica applicata alla componente nozionistica e non solo alle informazioni tecniche in possesso dal soggetto. Questa “affidabilità” si raggiunge, quindi, certamente con la conoscenza tecnico-nozionistica ma anche con un’adeguata e seria postura nei confronti delle politiche tecnico-organizzative di sicurezza. In ultima istanza, quando in un’azienda è presente una procedura applicata, ma non la relativa procedura di gestione, è necessario domandarsi a cosa stia pensando l’amministratore dei sistemi informativi. Ed è bene notare che l’assenza di documentazione costituisce una violazione in piena regola di quanto prescritto dall’ACN nelle Misure di Sicurezza di Base. Quando si legge, ad esempio, che:
In accordo al piano di gestione dei rischi per la sicurezza informatica […] è eseguita e documentata la valutazione del rischio posto alla sicurezza dei sistemi informativi e di rete…
Significa che la procedura non deve essere solo applicata ma anche documentata e questa formalizzazione è importante, perché fa capire che tale procedura è stata pensata e scritta prima ancora di essere resa operativa. C’è ancora molta strada da fare in ambito cybersecurity perché gli obiettivi sono ben lontani dall’essere raggiunti, anzi si potrebbe dire che devono essere ancora capiti.
Note
- La Circolare 2/2017 prevede il controllo 5.4.2 “Generare un’allerta quando viene generata un’utenza amministrativa” e 5.4.3 “Generare un’allerta quando vengono aumentati i diritti di un’utenza amministrativa”. Le Misure di Sicurezza di Base della NIS2 prevedono, invece, il controllo ↩︎
