Parliamo di data breach e ransomware.

Il GDPR (art. 4 c. 12) definisce la violazione di dati personali

“la violazione di sicurezza che comporta accidentalmente o in modo illecito la distruzione, la perdita, la modifica, la divulgazione non autorizzata o l’accesso ai dati personali trasmessi, conservati o comunque trattati“;

Ne consegue che tutte le violazioni dei dati personali sono incidenti di sicurezza, ma non tutti gli incidenti di sicurezza sono necessariamente violazioni dei dati personali.

EDPB: European Data Protection Board

È quell’ente che a livello europeo determina le interpretazioni corrette e le linee guida dopo aver affrontato casi “reali” al tavolo di discussione, proponendo delle linee guida comuni e condivise tra tutti i Paesi europei. Ogni elemento è definito da un Working Party (una Tavola di Lavoro – WP) che redige dei documenti resi pubblici sul sito dell’EDPB. Nell’Opinion 3/2014 e nelle linee guida WP250, il WP rilevava che le violazioni possono essere classificate in base a tre principi di sicurezza:

• riservatezza: divulgazione dei dati personali o l’accesso non autorizzato agli stessi
• integrità: modifica non autorizzata o accidentale dei dati personali
• disponibilità: perdita, accesso o distruzione di dati personali

La violazione di dati può provocare danni, materiali o immateriali, tra cui limitazione dei diritti, furto di identità o di progetti coperti da segreto professionale, danno di immagine o reputazione.

Cosa chiede il GDPR

Fondamentalmente gli obblighi derivanti dalla violazione subita sono:

• documentare la violazione dei dati personali (ircostanze, effetti e azioni correttive)
• notifica all’Autorità di Controllo, fatti salvi i casi in cui NON COMPORTI RISCHIO PER GLI INTERESSATI
• comunicazione agli interessati in caso di rischio per i loro diritti

Come detto sopra la notifica di data breach deve essere soggetta ad una valutazione fatta nel momento in cui si viene a conoscenza della violazione, dal Titolare. Se però il Titolare valutasse il rischio come improbabile e poi dovesse materializzarsi, l’Autorità Garante potrà comminare sanzioni amministrative pecuniarie (art. 58 c.2i)).

FORMAZIONE… SEMPRE

È fondamentale quindi che il Personale, dal Titolare che deve redigere un “Manuale di Comportamento in caso di Data Breach”, passando per Responsabili ed Incaricati, sappia come reagire e partecipare alla raccolta delle informazioni relative al Data Breach, al suo riconoscimento e valutazione, alla segnalazione ai Responsabili dell’avvenimento.

Le linee guida 01/2021 dell’EDPB presentano dei casi esempio, proprio per fornire supporto ai Titolari nella valutazione. Particolarmente interessante, soprattutto in questo periodo in cui si succedono frequentemente, il paragrafo dedicato ai Ransomware.

Con le nuove tecniche i Ransomware possono entrare a far parte sia dei problemi relativi a disponibilità (criptano le informazioni rendendole non disponibili) sia della riservatezza(esfiltrano le informazioni per effettuare una fase 2 di ricatto -vedi qui il nostro approfondimento-).

L’interessante fascicolo affronta differenti tipologie di casi che possono verificarsi “nella vita reale”, oggi affronteremo appunto il RANSOMWARE, ma è nostra intenzione affrontare tutti i 18 casi riportati nelle prossime puntate.

VALUTAZIONE PER ESEMPI

Per agevolare a classificazione il Comitato cita infatti diversi scenari di attacco e per ciascuno esegue una analisi esemplificativa, in classico stile anglosassone.

Analizziamo quelli legati ai Ransomware: i primi 4 della lista:

1-Ransomware con backup criptato e senza esfiltrazione
I dati sono colpiti da un ransomware e criptati.

Il Titolare ha utilizzato la cosiddetta encryption at rest (ovvero la crittografia dei dati “a riposo”, cioè direttamente nelle unità di archiviazione locali o remote -es: cloud-). I dati sono backuppati in forma criptata.

La chiave di decriptazione non è stata compromessa, quindi l’attaccante non poteva accedervi o utilizzarla. L’accesso è stato fatto solo ai dati personali in locale, ma né la posta elettronica della società, né i sistemi client utilizzati per accedervi sono stati interessati.

Analizzando i log che tracciano tutti i flussi di dati in uscita dall’azienda (compresa l’e-mail in uscita), ha determinato che l’attaccante ha solo criptato i dati, senza esfiltrarli: non c’è stata, quindi, sottrazione dei dati visto che i log non mostrano alcun flusso di dati verso l’esterno durante l’attacco.

I dati personali si riferiscono a clienti e dipendenti della società, qualche decina di persone complessivamente. Il backup era prontamente disponibile e i dati sono stati ripristinati poche ore dopo l’attacco. La violazione non ha comportato alcuna conseguenza sul funzionamento quotidiano delle attività del titolare. Non c’è stato alcun ritardo nei pagamenti dei dipendenti o nella gestione delle richieste dei clienti.

Ovviamente anche in questo caso sono state adottate misure preventive e valutazione dei rischi rafforzando la sicurezza dell’ambiente di controllo dei dati:

• una corretta gestione delle patch e l’uso di un adeguato sistema di rilevamento anti-malware
• un backup adeguato e separato aiuta a mitigare le conseguenze di un attacco
• una gestione dei log e del traffico entrante/uscente
• un programma di educazione, formazione e sensibilizzazione dei dipendenti sulla sicurezza

Per la valutazione dei rischi è importante che il Titolare indaghi sulla violazione e identifichi la tipologia di ransomware per capire le possibili conseguenze, la più pericolosa delle quali sarebbe l’esfiltrazione dei dati senza lasciare traccia nei log.

In questo caso l’aggressore aveva accesso ai dati personali che però, essendo criptati, non potevano essere letti. La tecnica di criptazione è conforme (adeguata) alla “possibilità di implementazione” e di conseguenza i rischi sono stati ridotti. Avere un sistema di backup, un sistema di analisi dei LOG e un sistema di blocco m(es: endpoint antivirus) rende gli effetti della violazione meno gravi.
Valutando quindi la gravità delle conseguenze, che si possono classificare come “minori” perché

• i dati sono stati ripristinati nel giro di poche ore,
• la violazione non ha comportato alcuna conseguenza nelle attività
• non ci sono effetti sugli interessati (es. pagamenti)

si può classificare la problematica come “NON RILEVANTE AI FINI DEI RISCHI” e si può evitare la notifica sia all’Autorità che agli interessati.
Questo non implica però che non debba essere riportata nel Registro delle Violazioni, in quanto tutte le violazioni di dati devono essere documentate a norma dell’articolo 33.

Inoltre se abbiamo subito un data breach vuol dire che qualcosa è andato storto e comunque sarebbe consigliabile rivalutare ed eventualmente correggere le misure di sicurezza.

SCENARIO 1: CONCLUSIONI

• Documentare la violazione nel registro delle violazioni dei dati personali.
• Non sono necessari né notifica all’Autorità, né la comunicazione agli interessati.

2- data breach Ransomware senza backup criptato
Un computer è stato colpito da ransomware e i suoi dati sono stati criptati.

Anche in questo caso analizzando i LOG (e le e-mail in uscita) viene rilevato che l’attacco ha solo criptato i dati, senza sottrarli. Anche in questo caso i dati personali riguardano i dipendenti e i clienti, nessuna categoria di dati particolari è stata toccata.
MA
Non c’era alcun backup effettuato (ma il risultato sarebbe lo stesso se il backup risalisse a parecchio tempo prima).

Quindi la maggior parte dei dati deve essere ricostruita da documenti cartacei richiedendo diversi giorni di lavoro e comportando alcuni ritardi nella consegna degli ordini ai clienti.

ERRORE GRAVE:
Il Titolare avrebbe dovuto adottare almeno un sistema di backup digitale, e la mancanza di crittografia dei dati presenti sul dispositivo oggetto dell’attacco ne espone la leggibilità.

Questi elementi portano a conclusioni estremamente diverse:

• il ransomware ha criptato i dati personali, che non sono stati però sottratti
• i rischi derivano dalla mancanza della disponibilità dei dati,non essendo compromessa la riservatezza (sebbene sia possibile che l’esfiltrazione possa essere stata camuffata, dato che neanche i LOG erano sotto backup e pertanto non sarebbe escludibile un eventuale caso di questo tipo)
• anche qui non sono interessate categorie di dati particolari, la quantità di dati e il numero di interessati è basso

In assenza di un backup i dati possono essere considerati persi o parzialmente ricostruibili con la documentazione non elettronica.

Questo disagio e la limitazione o il ritardo nei pagamenti o nell’evasione delle richieste è considerato un elemento coerente con la necessità di effettuare la denuncia all’Autorità Garante.

Inoltre da valutare che sia obbligatoria anche la notifica agli interessati qualora il tempo di recupero sia veramente oneroso e comporti disagi notevoli o perdite finanziarie.

SCENARIO 2: CONCLUSIONI

• Documentare la violazione nel registro delle violazioni dei dati personali
• Notifica all’Autorità Garante
• Valutare se necessaria la comunicazione agli interessati

3-data breach Ransomware con backup e senza esfiltrazione dati in un ospedale (dati particolari)
Il sistema informativo di un ospedale/centro sanitario è attaccato da ransomware e una percentuale significativa dei suoi dati viene resa indisponibile.

Sono disponibili LOG che tracciano i flussi di dati in uscita comprese le e-mail la cui analisi determina che l’attaccante ha solo criptato i dati senza esfiltrazione. I backup erano disponibili in forma elettronica.
MA
I dati personali coinvolti riguardano i dipendenti e i pazienti della struttura, ovvero migliaia di individui, per cui tra l’altro, trattandosi di dati particolari, sussiste un rischio residuo di elevata gravità per la riservatezza dei dati dei pazienti.

La maggior parte dei dati è stata ripristinata ma questa operazione è durata 2 giorni lavorativi portando a gravi ritardi nel trattamento dei pazienti.

Nonostante l’esistenza di un backup dei dati, si è in presenza di un rischio elevato per la gravità dei disagi (ritardi)

SCENARIO 3: CONCLUSIONI

• Documentare la violazione nel registro delle violazioni dei dati personali
• Notifica all’Autorità Garante
• Obbligatoria la comunicazione agli interessati (art.34) rendendo pubblico l’attacco

4-data breach Ransomware senza backup e con esfiltrazione
Il server di una compagnia di trasporto pubblico è stato colpito da un attacco ransomware e i suoi dati sono stati criptati.

Secondo i risultati dell’indagine interna, l’autore non solo ha criptato i dati, ma li ha anche esfiltrati.
I dati coinvolti erano dati anagrafici, numeri di carta d’identità e dati finanziari di clienti e dipendenti, nonché di diverse migliaia di persone che utilizzano i servizi della società (ad es. acquistano biglietti online). Inoltre anche il backup è stato criptato.

In un sistema di backup ben progettato questo deve essere conservato in modo sicuro senza possibilità di accesso dal sistema principale proprio per evitare che venga compromesso nello stesso attacco.
La violazione non riguarda solo la disponibilità dei dati, ma anche la riservatezza, configurando un rischio elevato: sono infatti stati sottratti anche documenti di identità e dati bancari come i dati della carta di credito, che potrebbero causari danni finanziari e furto di identità.

È essenziale la comunicazione agli interessati perché possano adottare le misure necessarie per evitare danni materiali (ad es. bloccare le loro carte di credito). Ovviamente va informata anche l’Autorità Garante.

SCENARIO 4: CONCLUSIONI

• Documentare la violazione nel registro delle violazioni dei dati personali
• Notifica all’Autorità Garante
• Obbligatoria la comunicazione agli interessati (art.34) rendendo pubblico l’attacco
• Obbligatoria l’adozione di strumenti di mitigazione/risoluzione del rischio (primo tra tutti il backup)

Ovviamente lo scenario 4 è quasi apocalittico, ma purtroppo REALISTICO…

Molte Aziende infatti non sono ancora pronte o non hanno adottato strumenti aggiornati, nonostante si stiano facendo strada a costi contenuti soluzioni di backup su cloud, rendendo ingiustificabile la mancata adozione di strumenti idonei ed adeguati. Inoltre se vi siete identificati in una delle configurazioni dettate sopra dovete ritenervi “soggetti a rischio” perché le tecniche identificate sono attuali ed ancora circolanti con le varie versioni dei malware più diffusi)

REMINDER

Ovviamente ricordiamo come sempre una piccola lista (non esaustiva) di quelle che sono le “buone pratiche” da adottare per ridurre il rischio, così come ricordiamo che il Titolare ha l’onere di valutare se adottarle o non adottarle, assumendosi in toto l’onere delle conseguenze in caso di mancata implementazione:

• Mantenere aggiornato il sistema operativo e il software (che sia su server, client, o qualsiasi altro dispositivo); sarebbe perfetto se conservasse anche un Registro delle patch
• Segmentare la rete per evitare la diffusione di malware
• Implementare e mantenere adeguata una procedura di backup; i supporti devono essere tenuti separati in luogo sicuro e fuori dalla portata di terzi
• Dotarsi di un software anti-malware “idoneo” (non quelli gratuiti per capirci)
• Usare un firewall e un sistema di rilevamento e prevenzione delle intrusioni, anche nel caso di lavoro da casa o mobile
• Formare i dipendenti a riconoscere gli attacchi: capire se le e-mail sono affidabili, segnalare i problemi al Responsabile
• Per chi ne ha la possibilità: identificare il tipo di codice per intuire le conseguenze
• Salvare o replicare tutti i log in un server centrale di log
• Applicare sistemi di crittografia (Strong encryption) e di autenticazione (es: autenticazione a due fattori, 2FA)
• Eseguire periodicamente attività di vulnerability e penetration test, controlli delle procedure e dei backup
• Creare un Team per le risposte ai problemi, vengono denominati Computer Security Incident Response Team (CSIRT) o Computer Emergency Response Team (CERT). Questi gruppi si possono creare e gestire anche per più aziende consorziate collettivamente; il loro compito fondmentale è studiare dei piani di recovery o continuity efficaci

IMPORTANTE:

Risulta fondamentale puntare sulla formazione ed informazione, e riesaminare l’analisi del rischio periodicamente, anche in base alle nuove tecnologie adottate, perché un hacker non si ferma MAI e nella nostra filosofia

La sicurezza non può essere per molti…

deve essere per TUTTI!

Come detto prima: il documento dell’EDPB analizza ben 18 casi… ci vediamo nelle prossime puntate quando analizzeremo gli altri