No results found
Il GDPR e la gestione del dato personale sono argomenti che coinvolgono tutto l’ambito dell’IT e non solo il cliente; in particolare l’evenienzza che si verifichi una data breach e la gestione di quest’ultima competono spesso a chi ha in gestione l’infrastruttura IT di un’azienda e nel caso si tratti di un Managed Service Provider quest’ultimo viene direttamente coinvolto, sia perché dovrà adottare le procedure del caso, sia perché preventivamente potrà proporre tra i suoi servizi di valore proprio la disponibilità a gestire tali eventualità
In questo tutorial ci si soffermerà sulla gestione della data breach vista dal lato dell’MSP, inquadrando prima di tutto la data breach con un esempio e in questo ci sarà d’aiuto il fumetto proposto nell’immagine seguente.
Ipotizziamo lo studio medico del Dottor Rossi dov'è la segretaria Maria riceve una e-mail apparentemente inviata dal corriere TNT che la invita a scaricare l’allegato file .zip contenente documenti di trasporto, fatture di pagamento ecc. Siccome la segretaria utilizza ogni tanto TNT ritiene l’e-mail, scarica il file e va ad aprirlo, ma non funziona e quindi torna al suo lavoro. Il giorno dopo il Dottor Rossi scopre che non riesce più ad accedere ad alcuno dei suo file ed in particolare al gestionale dei pazienti, quindi non può curare i suoi pazienti, alcuni da visitare con urgenza.
Il Dottore si rivolge all’azienda MSP TECHXIS la quale scopre che si tratta di un attacco con virus wannacry e che lo studio si trova con tutti i dati cifrati e non leggibili; in cambio, l’attaccante chiede un riscatto da pagare in Bitcoin. Il Dottor Rossi chiama la MSP TECHXIS chiedendo di assisterlo tecnicamente anche per gli adempimenti privacy in caso di data breach, perché l’esempio è di questo che tratta.
La situazione descritta può capitare e in casi del genere bisogna essere preparati alla gestione della data breach con procedure efficaci e funzionali. Come può capitare anche che a seguito di un furto venga sottratto un computer o un’unità di storage: anche questo è un caso di data breach, perché un estraneo può accedere ai dati personali ivi conservati.
Siccome il rischio che si verifichi una data breach è probabile, dobbiamo preoccuparci di capire quali strategie adottare per affrontare casi del genere e tali strategie devono tenere conto del fatto che nella sua attività, l’ MSP si trova di fronte a situazioni di vario genere, perché magari ha 10-20-30 società clienti in vari settori di attività.
Per creare un insieme di adempimenti, una sintesi degli adempimenti GDPR, un primo profilo che dobbiamo elaborare è una procedura di gestione data breach che comporta anche un manuale di gestione data breach in cui dobbiamo gestire i casi, le fasi, la tempistica, i responsabili e fare le sintesi delle modalità operative e quindi questo è uno dei primi tasselli, ma è assolutamente facile da fare. Più esattamente, le regole basilari sono le seguenti:
L’unità organizzativa può essere considerata il “comitato data breach” che si occupi 365 giorni all’anno della gestione delle data breach, perché i tempi di reazione dal punto di vista normativo sono di 72 ore e quindi ai tempi strettissimi.
Per controlli proattivi si intende qualcosa di diverso dai controlli finalizzati a impedire il realizzarsi della minaccia, ma quelli che devono scattare a minaccia già concretizzata: per esempio se c'è già stato da parte di un cyber-criminale un attacco al server (la penetrazione del server) un controllo proattivo può consistere nell’isolare il server dalla rete aziendale o nel forzare le password.
Quanto elencato è in sintesi quello che un MSP deve porre in essere, perché egli ha una responsabilità enorme in quanto sostanzialmente ha le chiavi dell'azienda: se preme il pulsante sbagliato può cancellare tutti i dati dell'azienda o se glielo schiaccia qualcuno che perde i suoi sistemi.
Tutto questo ci dice che un MSP deve avere un metodo di lavoro per affrontare la data breach, perché si potrebbe trovare nella situazione in cui deve prendere delle decisioni in poco tempo, senza quindi avere margine per improvvisare; questo perché delle decisioni prese in caso di incidente, l’MSP potrebbe doverne rendere conto al cliente, al Garante o alla Guardia di Finanza
Esaminiamo quindi un caso pratico proponendo un metodo, schematizzato nell’immagine seguente.
Il primo approccio consiste nell’identificare la Natura della violazione cui ci si trova di fronte: se è stata una perdita di riservatezza del dato, una perdita integrità, una perdita disponibilità; allo scopo occorre prima fare gli accertamenti.
Natura della violazione è un termine che si trova anche nei formulari del Garante quindi è importante conoscere la terminologia utilizzata nell’ambito della privacy perché poi a chi domanda qual è la natura della violazione disogna saper rispondere sapendo di cosa si tratta.
Il secondo passaggio consiste nel fare un’analisi delle contromisure, sia quelle adottate prima dell’evento, sia quelle da adottare al verificarsi della data breach. Quindi è necessario compiere un’analisi del rischio e questa si rivela fondamentale per riuscire a individuare quali sono le contromisure che sono state adottate in relazione a quel determinato sistema informatico; in questa fase bisogna anche decidere quali sono le contromisure da adottare dopo che è stato individuato qual è la Data breach o comunque il problema che si è verificato, perché non è detto che necessariamente un incidente di sicurezza si concretizzi in una data breach: un incidente di sicurezza è in generale la violazione di una regola di sicurezza che ha adottato l'organizzazione. Nel momento in cui c'è una violazione dei sistemi e quindi un incidente di sicurezza, l’MSP deve agire secondo determinate procedure per verificare qual è il problema e una volta che ha accertato che c'è stata una violazione dei dati o comunque un dubbio a riguardo, deve far scattare una procedura per identificare le misure che ha adottato prima e quelle che hi adottato dopo che si è verificato il problema. Di tutto questo l’MSP deve rendere conto.
Il terzo passo consiste nel capire qual è il rischio per gli interessati in relazione ai dati che sono stati violati e quindi quali possono essere i dati i danni patrimoniali e non patrimoniali; bisogna anche capire qual è il livello di rischio e allo scopo occorre stabilire un metodo per individuare il livello di rischio.
Alla fine di tutto questo bisogna decidere se, relativamente all’incidente di sicurezza, fare la notifica al Garante, la comunicazione agli interessati o a seconda dei casi comunicare magari al cliente l’avvenuta data breach, perché l’MSP è un responsabile del trattamento e quindi a seconda della situazione in cui si trova trovi deve reagire conseguentemente e in termini molto stretti .
Aiutandoci con l’esempio dello studio del cardiologo che abbiamo visto prima, andiamo ad estendere il concetto di natura della violazione, che può non essere una sola: potrebbe esserci stata una perdita riservatezza; trattandosi di un attacco wannacry, probabilmente non c’è stata una perdita di riservatezza perché quel tipo di virus non determina necessariamente una perdita e riservatezza ma l’indisponibilità dei dati. Ma l’MSP deve fare un approfondimento per capire se i dati sono stati anche trafugati.
Certamente potrebbe esserci una perdita integrità, perché i dati sono stati cifrati e non sono più come quelli di prima, quindi c’è una perdita di integrità e di disponibilità, perché l’utente non ha più l’accesso ai dati, almeno momentaneamente.
Questo va valutato indipendentemente dalle misure preventive quali magari l’esistenza di un backup, perché i dati nel server sono comunque stati compromessi.
Poi occorre valutare le contromisure esistenti, quindi per esempio se è stata fatta un’analisi del rischio, quali le misure esistenti o che bisogna adottare; tra quelle esistenti per esempio dovrebbe esserci stata un’analisi del rischio e una formazione del personale riguardo ai sistemi antivirus e al backup, ai sistemi monitoraggio e quant'altro. Tra le misure da adottare una volta che è stato accertato il problema, c’è ancora verificate quelle erano le misure esistenti e adottare quelle contromisure per rimediare e se non sia possibile impedire il danno, quantomeno ridurlo. Tra queste, isolare il server o spegnerlo del tutto, perché spegnendolo non va avanti il programma di cifratura scatenato dal virus.
Poi magari prendere altri provvedimenti come verificare l’estensione della data breach, ossia quanti dati e di che tipo, sono stati compromessi; o anche fare una copia del server, la copia dei dati che sono stati compromessi e con essi fare un report applicando una data certa per conservare le prove della data breach.
Si può quindi ripristinare i sistemi, ma non prima di aver conservato i dati che sono stati compromessi, perché quelli sono prove anche a livello giudiziale, nel caso si voglia valutare la denuncia penale, che in questo caso è meglio fare presso la Polizia di Stato.
Alla fine di tutta la vicenda si potrebbe rifare un’analisi del rischio per capire dove sono stati lasciati punti deboli
In caso di data breach, bisogna valutare il rischio per le persone fisiche e quindi capire chi sono gli interessati coinvolti nell’effrazione, compromissione o sottrazione dei dati personali: potrebbero essere i pazienti di uno studio medico ma anche altri soggetti individuabili dalle cartelle cliniche, dove magari oltre al nome del paziente potrebbe esserci il nome del parente o di altri medici.
Oltre a capire chi sono gli interessati occorre anche capire quali danni possono essere determinati da quell’evento e non sono solo i danni da perdita dei dati: per esempio se anche avessimo il backup ma il backup lo facessimo settimanalmente, tutti gli eventi intercorsi in quell’arco temporale e aggiornati in tempo reale nel computer soggetto alla data breach, potrebbero non esserci nel backup.
Quindi occorrerebbe avvisare esempio i pazienti che le analisi o i dati sanitari che hanno a disposizione sono vecchi di una settimana e vanno aggiornati; una situazione del genere potrebbe determinare per esempio problemi se quei pazienti nella settimana intercorsa dall’ultimo backup hanno fatto delle visite o esami i cui referti erano memorizzati nel computer, perché questo significa richiamare i pazienti e avvertirli di rifarli.
Quindi il preoccuparsi di quali sono le conseguenze per gli interessati è fondamentale, perché in mancanza di un intervento per avvisarli si può incorrere in una serie di problematiche legali di notevole peso, perché implicano anche un rischio di risarcimento del danno.
Ricollegando questo alla valutazione del livello di rischio, bisogna considerare cosa si rischia in caso di data breach.
Quindi in relazione alle misure tecniche adottate in precedenza e a seguito dell’evento, si esegue una valutazione del rischio per l’interessato; per esempio se abbiamo un sistema alternativo che si attiva immediatamente al verificarsi della data breach e abbiamo verificato che non ci sono particolari esposizioni di dati o problematiche di riservatezza perché i dati non sono usciti dall’azienda, a quel punto il danno per gli interessati non sussiste. E magari si può anche dedurre che non c'è stato neanche un probabile danno, perché se il contenuto dei dati non è uscito dal server non occorre fare la notifica al Garante, ovvero fare comunque tale notifica ma fare la comunicazione agli interessati perché nei loro confronti non c'è stato nessun danno.
Chiaramente le valutazioni sul fare o meno la notifica al Garante perché c’è un rischio probabile o non c'è un rischio probabile, devono essere svolte entro le 72; idem per la comunicazione agli interessati, considerando che se c’è un rischio elevato occorre devo procedere senza ingiustificato ritardo, quindi dovrei anche prima delle 72 ore lasciate dal GDPR: è il caso di esami o accertamenti fatti dallo studio medico e che possono influire sull’esito di una terapia o di un imminente intervento chirurgico.
Come vedete ci si trova nella situazione che a fronte dell’evento bisogna fare tutta una serie di adempimenti e per l’eventuale notifica al Garante è necessario seguire una procedura ben chiara e precisa, compilando un modulo abbastanza complicato che racchiude tutte queste informazioni e anche altre; bisognerà anche comunicare al Garante tutta una serie informazioni come la natura della violazione e indicare quei contenuti che sono necessari al Garante per consigliarci cosa fare in relazione al sinistro (data breach): ad esempio rifare le analisi, ricercare copia (se esiste) delle cartelle cliniche perché si sono perse p perché magari il backup non ha funzionato, indicare magari al medico le allergie perché la cartella è smarrita e quanto altro la legge contempla.
Quindi tutto questo diventa assolutamente necessario perché le multe che il Garante commina in caso di inadempienza sono veramente elevate.
Una domanda che può sorgere spontanea è: “fino a che punto è un analisi di rischio può essere definita qualcosa di oggettivo e non soggettivo”? Cioè, quando l’analisi del rischio può essere concreta e non a discrezione? Questa domanda è utile a capire come può agire eventualmente il Garante nei nostri confronti.
Nel determinarlo, la questione tecnica diventa fondamentale e quindi per evitare di incorrere in sanzioni o di perdere una causa, bisogna offrire comunque una soluzione difendibile, cioè ragionevole; con questo s’intende qualcosa che risponda ad aspetti tecnici indiscutibili.
Quindi la metodologia deve appoggiarsi su soluzioni tecniche condivise dalla comunità scientifica di riferimento, perché quando una soluzione è condivisa dalla comunità scientifica di riferimento, che di solito si esprime con linee guida o comunque da organizzazioni che codificano certi parametri condivisi dalla comunità scientifica di riferimento, possiamo quantomeno difenderci affermando di aver seguito delle regole in buona fede.
Per esempio se dobbiamo gestire una cifratura di dati combinata per esempio con impronta hash e allo scopo utilizziamo un algoritmo di cifratura come l’AES256 o l’AES con chiavi a 128 bit, stiamo utilizzando un algoritmo che è considerato sicuro dalle più grandi organizzazioni ed enti pubblici che si occupano proprio di queste problematiche, perché la scienza matematica la ritiene attualmente una soluzione affidabile. Quindi nel momento in cui utilizziamo un hash SHA256 non solo la normativa lo richiama, ma tale algoritmo è considerato attualmente inviolabile dal punto di vista matematico e quindi considerato sicuro, ragion per cui se nelle nostre procedure di sicurezza lo implementiamo, nessuno potrà mai accusarci di non aver fatto un’analisi oggettiva del rischio.
Quindi la raccomandazione, a fronte di determinate tematiche, è di attenersi alle eventuali linee guida, per esempio dell’Agenzia per l'Italia Digitale o delle linee guida della NSA (National Security Agency) ecc. perché il Garante fa riferimento, nelle proprie valutazioni, a tali linee guida.
L’analisi del rischio per un MSP ha il duplice obiettivo di “metterlo a posto” sia con la proprie coscienza che professionalmente, quindi una volta redatto e consegnato al cliente l’MSP è a posto; se poi cliente non vuole fare ciò che gli viene raccomandato bisogna decidere se proseguire il rapporto con esso, giacché costituisce una “spada di damocle” e può coinvolgere da un momento all’altro in una controversia inerente al GDPR.
Quindi se siete MSP producetee un documento deve riportare la situazione a quel momento, indicando rischio e relativa percentuale, ma anche i punti di criticità che devono essere fatti affrontati e che nel dettaglio possono significare sostituire il firewall, implementare backup e aggiornare l'antivirus ma tante altre cose. Nel momento in cui avete documentato la situazione, il cliente ne è informato e deve decidere che cosa fare, ma voi siete a posto sotto tutti gli aspetti, anche legali, perché normalmente in caso di controversia che porti in Tribunale, se il Giudice vede che una parte (l’MSP, in questo caso) si è comportata con diligenza ad esempio elaborando il piano di rischio e facendo una serie di adempimenti, offrendo la collaborazione ecc., essa si trova in una posizione migliore perché il Giudice stesso chiederà l'altra parte come ha agito a fronte di tutto ciò
Quindi se il cliente che sarà incorso in sanzioni o richieste di danni cercherà di coinvolgere l’MSP, quest’ultimo sarà certamente scagionato, tanto più se potrà dimostrare che a seguito della consegna della relazione il cliente risponde per iscritto che non vuole fare ciò che gli è stato raccomandato o che comunque è stato informato e non ha risposto.
Chiaro che bisogna valutare ogni situazione nello specifico: ad esempio se il cliente tratta dati molto particolari e non dispone dei sistemi minimi di tutela come per esempio firewall o un sistema di backup, se non si adegua, un MSP può valutare l’idea di risolvere il rapporto; immaginate cosa accade se a un cliente debitamente informato dalla vostra analisi del rischio capita una data breach perché il cliente non ha il firewall: dovete notificargli che c’è stata una data breach perché ai sensi dell'articolo 33, 2° paragrafo del GDPR il responsabile del trattamento deve avvisare il proprio cliente titolare del trattamento che poi deve fare tutta l’attività di gestione data breach e questo non la fa. Sicuramente per scansare i guai l’avvocato del cliente chiama voi in tribunale e prova a coinvolgervi, per questo è opportuno che l’MSP si faccia fare una manleva dal cliente.
Per quanto riguarda le soluzioni che un MSP deve adottare quando tratta dati contemplati nel GDPR, cosa insita nella dinamica della gestione IT della clientela, sono svariate e passano prima di tutto attraverso la formazione in materia di data breach, che deve riguardare la normativa e la prassi di riferimento e quindi l’MSP deve individuare normativa e documenti che riguardano la data breach, emessi dalle Autorità competenti.
Capire come gestire concretamente la tematica e come approcciare a una gestione concreta permette di arrivare a soluzioni personalizzate per la propria organizzazione, integrando le procedure data breach nelle procedure aziendali.
Permette inoltre di valutare quando e come fare le notifiche e le comunicazioni relativamente alla prassi, che un MSP sicuramente è in grado di fare in virtù delle proprie competenze in informatica.
Altro punto fondamentale è redigere il registro delle data breach e saperlo utilizzare all’occorrenza, sia perché serve nel rapporto con il cliente, sia perché può dover essere presentato alle Autorità.
Ultimo consiglio per l’MSP è elaborare e tenere a disposizione una serie di esempi pronti (casi applicati a singoli clienti o categorie di clientela) che ipotizzino scenari e soluzioni, così da orientarsi in caso di sinistro: questo è utile perché spesso quando emerge un problema c’è pochissimo tempo per decidere e se avete un “prontuario” sapete anche come affrontarlo.
Riguardo alla valutazione del rischio, esistono standard come quelli contemplati nella norma ISO 27001, che però per un MSP possono essere eccessivi e sicuramente sono pensati più per chi deve rilasciare certificazioni
Però un MSP può e deve formarsi sulla materia e sotto questo aspetto l’aver frequentato un corso ed aver ottenuto un attestato da un esperto può essere un buon modo per partire; a riguardo, Coretech mette a disposizione un corso sulla data breach tenuto dall’Avvocato Gianluca Dalla Riva, esperto di privacy e GDPR, articolato come nel prospetto seguente.
Il corso è sulla gestione della data breach e fornisce tutti gli elementi del caso e si conclude con esercizi e quiz, superando il quale si riceverà un attestato che certifica la formazione e quantomeno l’acquisizione delle nozioni sul GDPR.
Esiste un ulteriore momento formativo sulla gestione del rischio, sempre corredato da video, quiz e consulenza.
Tutte le informazioni del caso sono disponibili alla pagina https://www.coretech.it/it/service/event/Corso-Gestione-Rischio-e-Data-Breach.php.