L’Incident Management, misura organizzativa per l’adeguamento al GDPR: la guida

Per essere aderente alle richieste del GDPR, un’organizzazione non deve tenere conto solo delle misure tecniche di cyber security, ma anche di procedure volte a una costante verifica, difesa, sorveglianza del patrimonio informativo e dei dati personali in esso presenti: una soluzione potrebbe venire dalla realizzazione di un processo di Incident Management.

Del resto, l’inciso “misure tecniche ed organizzative adeguate a garantire un livello adeguato al rischio” appena descritto ricorre numerose volte all’interno del testo del GDPR, quasi come il ritornello di un tormentone musicale. Lo troviamo ad esempio negli articoli 5, 24, 25, 28, 32, ma spesso quanto chiaramente indicato viene poco considerato. Dall’entrata in vigore del Regolamento e durante le numerose occasioni in cui si è discusso o affrontato l’argomento, troppo spesso questo inciso è stato affrontato solo in parte. Le misure tecniche ed organizzative, in molti casi, vengono identificate con le misure di sicurezza informatica in senso stretto senza, quindi, comprendere appieno quanto più volte ribadito nella normativa.

L’importanza dell’Incident management

Questo tipo di impostazione basata sull’Incident management potrebbe rivelarsi vincente. In molti articoli dalla normativa europea infatti (come la valutazione della necessità dell’esecuzione di una DPIA, il riscontro all’autorità Garante da effettuarsi in caso di tentata/avvenuta violazione dei dati personali, la programmazione dei piani formativi del personale, la necessità di implementazione delle misure di sicurezza) la definizione di un simile processo potrebbe contribuire al rispetto del fondamentale principio di accountability inserito nel regolamento.

Il processo di Incident Management, come prima cosa va identificato come la capacità di gestire in modo efficace eventi avversi inaspettati. Per eventi avversi si intendono accadimenti con conseguenze negative che possono verificarsi su di una rete o di un sistema (crash di sistema, utilizzo non autorizzato di privilegi di sistema, accesso non autorizzato a sistemi o a dati riservati/sensibili, spesso riconducibili a incidenti si sicurezza) con l’obiettivo di minimizzarne gli impatti e mantenere o ripristinare le normali operazioni all’interno di limiti temporali definiti.

Risulta ovvio come, per mettere in atto un tale processo, sia indispensabile che, all’interno dell’organizzazione, vengano allocate risorse umane e materiali a supporto delle operazioni di business per assicurare la continuità del minimo delle operazioni e ridurre al minimo le violazioni di sicurezza sulla base della strategia di gestione del rischio adottata dall’organizzazione (articolo 38 e considerando 97 GDPR).

Gli obiettivi del processo

L’Incident Management riguarda, quindi,  tutte quelle azioni messe in campo prima, durante e dopo il verificarsi di un incidente di sicurezza delle informazioni, che dovrebbero avere, come scopo principale, quello di mitigare l’impatto stesso dell’evento. La corretta realizzazione di in processo di Incident Management dovrebbe portare a:

• avere uno strumento efficace che possa consentire un minimo impatto dell’incidente per l’organizzazione;
• fornire informazioni e indicazioni utili al management per intraprendere azioni efficaci;
• consentire il mantenimento/ripristino/continuità dei servizi;
• fornire una difesa contro gli attacchi;
• fornire “barriere” a monte grazie all’utilizzo di tecnologia, investigazione e azioni successive.

Nell’ottica di un processo di adeguamento al GDPR e in considerazione della frequenza con cui i dati personali (oltre a quelli di business) risultano obiettivo di attacchi, la velocità e l’efficacia di risposta con cui una organizzazione si contrappone a tali eventi risulta oggi un fattore critico. Fondamentale è quindi avere una capacità di risposta tale che consenta di gestire in modo sistematico questi eventi, garantendo tempestività e appropriatezza delle decisioni e, di contro, delle azioni/reazioni.

L’Incident response: cos’è e a cosa serve

Per far questo entra in campo l’Incident Response che, parte del processo di Incident Management, può essere definito come la “capacità operativa dell’Incident Management che identifica, prepara e risponde agli incidenti per controllare e limitare i danni; fornire capacità investigative e mantenere, recuperare e ripristinare le normali operazioni in accordo ai livelli di servizio”.

Avere una puntuale capacità di Incident Response permette di gestire gli incidenti in modo sistematico in maniera tale che siano prese tempestivamente le decisioni appropriate. Una capacità del genere permette anche di migliorarsi nel tempo e di gestire nel migliore dei modi anche le problematiche di natura legale che possono presentarsi durante le fasi di un incidente. Un esempio di processo di Incident Response dovrebbe quanto meno comprendere:

• creazione di una policy e di un piano di Incident Response;
• sviluppo delle procedure per garantire il trattamento dell’incidente e il reporting;
• definizione delle linee guida per comunicare con entità esterne all’organizzazione (ad esempio, Autorità Garante, soggetti interessati ecc.);
• scelta di una struttura di team e un modello operativo;
• stabilire relazioni e linee di comunicazione tra l’Incident Response Team (IRT) e altri gruppi, sia interni (dipartimento legale, DPO, amministratori di sistema) sia esterni (ad esempio, forze dell’ordine, Responsabili del Trattamento, interessati);
• determinare quali servizi dovrebbe erogare l’IRT;
• dedicare appropriate risorse e addestrare il team.

Alcuni dei punti indicati riportano chiaramente a indicazioni presenti all’interno del GDPR con particolare riferimento ad un evento tentato o patito di violazione di dati personali (data breach). Ritroviamo, infatti, all’interno dell’art. 33 e dell’art. 34 chiari riferimenti alle modalità e tempistiche di comunicazione di un evento sia all’autorità di controllo che, eventualmente, ai soggetti coinvolti (il rispetto di queste tempistiche è direttamente collegato alla precisione e correttezza con cui le comunicazioni viaggiano sino ai soggetti deputati a veicolarle all’esterno). All’art. 32, invece, troviamo al comma 1 lett. b) – c) chiari riferimenti alla “disponibilità e la resilienza dei sistemi e dei servizi di trattamento” e “la capacità di ripristinare tempestivamente la disponibilità e l’accesso dei dati personali in caso di incidente”.

L’importanza del monitoraggio

Per fare in modo che un piano di Incident response simile a quello descritto possa correttamente essere applicato e in considerazione degli innumerevoli vettori di attacco cui una organizzazione può essere esposta, è necessario che i sistemi e/o i processi che gestiscono o al cui interno transitano dati personali, siano costantemente monitorati per poter cogliere eventuali segnali di anomalie che potrebbero presagire un eventuale evento negativo. Sistemi atti a queste attività possono essere ad esempio:

• utilizzo di sensori IDS (Intrusione Detection System) o una qualsiasi sonda di sicurezza che rileva attività anomale o attacchi veri e propri generando il relativo allarme;
• software antivirus e antimalware che rileva endpoint infettati da codice malevolo e produce il relativo allarme;
• evidenza di manomissioni (tramite analisi del file di log) alle configurazioni di sistemi, applicazioni, database, sistemi di archiviazione o apparati di rete e sicurezza;
• diversi tentativi di autenticazione falliti da parte di sistemi remoti e sconosciuti;
• aumento esponenziale del traffico di rete;
• acquisizione di notizie dall’esterno (bollettini di sicurezza, segnalazione di bug all’interno di applicativi, pubblicazione di zero-day o exploit ecc.).

Le fasi dell’Incident Response

Il processo di Incident Response così come definito dal NIST è costituito da diverse fasi:

• preparazione: in questa fase rientra ogni azione propedeutica e continuativa finalizzata a creare le condizioni migliori per gestire l’incidente in maniera appropriata. (Risk Assessment periodici, gestione delle configurazioni);
• rilevamento e analisi: in considerazione dell’eterogeneità e del dinamismo dei vettori d’attacco (interni, esterni, tecnologici, di processo, umani) è necessario isolare, per ogni tipologia di attacco, una serie di indicatori. Tali elementi possono essere di natura tecnologica (log, apparati di sicurezza specializzati flussi di traffico di rete), informativa (reperimento delle notizie di vulnerabilità) e umana (segnalazioni provenienti da personale interno o da organizzazioni esterne). Il risultato della fase di analisi è costituito dalla documentazione completa dell’incidente, sulla dimensione di sicurezza dell’informazione interessata (Privacy Breach, perdita di riservatezza, integrità, disponibilità) e nella stima di risorse necessarie al superamento del problema. In questo modo è possibile assegnare la corretta priorità all’incidente indirizzando, di conseguenza, gli sforzi operativi;
• contenimento, sradicamento e ripristino: il contenimento è la fase che fornisce il tempo necessario alla definizione della migliore strategia possibile. Tali strategie sono variabili in funzione di diversi fattori ed è possibile svilupparne diverse in base alla categoria di attacco (contenere un attacco in corso tramite posta elettronica è diverso da contenere un attacco DDoS o un’estrazione indebita di dati sensibili). In questa fase è necessario collezionare ogni evidenza possibile dell’incidente utilizzando strumenti e tecnologie finalizzate a salvaguardare l’integrità dei dati raccolti, provvedendo ad identificare la sorgente dell’attacco e monitorando l’attività. Dopo la fase di contenimento è necessario procedere all’eventuale sradicamento di alcune componenti dell’incidente stesso (codice malevolo, account compromessi) e al ripristino delle normali operazioni. Tali operazioni possono coinvolgere attività sistemistiche backup&restore, installazione da zero di sistemi e applicazioni, installazione di patch critiche e/o di sicurezza, come revisione delle policy dei firewall, modifiche nella produzione di log. Va precisato che maggiore risulta la gravità dell’incidente, l’ampiezza dei sistemi coinvolti, la quantità di dati interessati maggiore sarà il tempo necessario al ripristino;
• attività post incidente: questa fase riguarda l’apprendimento e il miglioramento. Ogni incidente gestito deve essere analizzato al fine di ricavare ogni utile indicatore di miglioramento sulla base delle policy definite e dei comportamenti attuati dalle parti coinvolte.

Conclusione

Ancora oggi, nonostante siano passati diversi mesi dall’avvento del GDPR, ancora troppo spesso viene sottovalutata l’importanza di quelle parti dell’adeguamento che riguardano l’organizzazione e la riorganizzazione dei processi o la stesura di procedure atte a determinare e gestire quella necessaria sorveglianza dei dati e dei trattamenti cui sono sottoposti, all’interno non solo dei sistemi informatici, bensì dell’intero ciclo di vita dell’organizzazione.

Limitarsi ad inserire una serie di misure “tecniche” a difesa/tutela dei dati sottoposti a processi di trattamento non è sufficiente a garantire quanto ripetutamente richiesto dal GDPR e lo sarà ancora meno quando verrà meno lo “scudo” (così definito secondo alcuni) degli otto mesi di applicazione “soft” concessi in sede di emanazione del D.lgs.101/18.

Inserire fra le misure organizzative processi di Incident Response potrebbe, alla luce di quanto previsto all’interno del GDPR e di quanto descritto, essere considerata come una misura adeguata potendo, il titolare o il responsabile, grazie a ciò, non solo attuare una protezione/sorveglianza costante dei dati e dei processi di trattamento, ma anche ottenere informazioni precise e in modo rapido in caso di eventi avversi non solo per la corretta gestione dell’evento stesso, ma anche e se del caso, poter fornire le informazioni necessarie all’Autorità Garante e/o ai soggetti coinvolti in caso di data breach patito.