Come prevedere una procedura di incident response secondo le vigenti normative

Al fine di prevenire e ridurre gli incidenti informatici, società, organizzazioni, enti, che sono connessi in rete, devono prevedere una procedura di incident response (IR).

La predisposizione di una procedura incident response rappresenta la pianificazione di un insieme di criteri, e risorse, capaci di rilevare il prima possibile attacchi, rimuoverne le cause, contenere gli effetti e ripristinare i sistemi allo stato originale.

Al fine di minimizzare l’impatto della minaccia sugli asset societari, sia dal punto di vista economico, che dal punto di vista reputazionale, sia per quanto riguarda i diritti e le libertà delle persone interessate alla violazione, rispondendo alle esigenze e agli obblighi dell’art. 33 del GDPR 679/2016.

In un’ottica di accountability, il Titolare, redigendo il piano di incident response, risponde agli obblighi di cui all’art 32 GDPR 679/2016 par. 1 comma c, il quale determina che quest’ultimo – il titolare – debba mettere in atto misure tecniche specifiche per l’organizzazione con lo scopo di ripristinare i sistemi in tempi rapidi, di garantire procedure di verifica dell’asset di difesa, e quindi di avere un metodo di business continuity.

L’organizzazione deve dotarsi di tale procedura per intervenire su attacchi informatici, data breach o qualsiasi altro agente malevolo che possa determinare un rischio di operatività continuativa.

Un incidente informatico è un evento che può essere anche il prodromo di una serie successiva di eventi che, violando le organization defense policy, riesce a insinuarsi in una rete o in un sistema collegato alla rete, al fine di determinare un danno o un vantaggio per l’attaccante. Premesso che l’attacco può essere effettuato anche dall’interno, da un insider, i dati costituiscono un grande patrimonio per l’organizzazione e, preservare la CIA triad, la disponibilità, l’integrità e la riservatezza, rientra tra gli obblighi dei titolari.

Gli incidenti possono essere classificati in diverse categorie:

1. Allarme livello 0
2. Incidente di livello 1: riguarda solo l’interno dell’organizzazione;
3. Incidente di livello due: ha ripercussioni all’esterno dell’organizzazione;
4. Incidente di livello 3: rischio elevato per i diritti delle persone fisiche e le loro libertà.

Misure organizzative

Oltre a dotarsi di strumenti automatizzati, grazie ai quali l’impresa riesce a rilevare quelli che sono gli errori di sistema, i cosiddetti allarmi di sistema, come gli IDS (Intrusion Detection System), i SIEM (Security Information Alert Management, e gli antivirus di ultima generazione, detti NGAV (Next Generation Antivirus), l’organizzazione dovrà adeguatamente formare il personale, nominare un responsabile dei sistemi informativi (RSI), e allorquando si ritenga che la gestione dell’incidente non possa essere gestita all’interno dell’organizzazione, dovrà essere affidata in outsourcing a una società specializzata nel settore.

Dal momento in cui verrà scoperto l’incidente, inciderà anche il fattore tempo, è compito del titolare e del RSI gestire operativamente al meglio il rischio di impatto organizzativo.

Altro step importante sarà quindi la policy che governa la risposta agli incidenti, diversa per ogni organizzazione, che dovrà quindi definire le entità coinvolte, la struttura organizzativa con i ruoli e le responsabilità, i requisiti di gestione degli incidenti, la definizione di gravita degli stessi, e le tipologie dei report.

La normativa

GDPR (General Data Protection Regulation) n. 679/2016

Il regolamento entrato in vigore il 25 maggio del 2018, obbliga, ex art. 33, l’organizzazione a comunicare all’autorità di controllo l’avvenuta violazione dei dati personali entro un termine di 72 ore dalla scoperta, allorquando si ritenga che possa determinare una minaccia per i diritti e le libertà delle persone a cui i dati fanno riferimento.

L’art. 34 stabilisce inoltre la comunicazione, alle persone interessate, dell’avvenuto data breach nel caso in cui ci sia un alto rischio per i loro diritti e le loro libertà.

Direttiva NIS 1148/2016/UE- D.Lgs. 65/2018

Nel caso in cui la violazione coinvolga una infrastruttura critica, si dovrà tener conto degli art 12 e 14 del D.lgs. 65/2018, attuativo della direttiva.

Inoltre grazie alla “Computer Security Incident Handling Guide” resa pubblica dal NIST, vi è un framework da seguire, volto alla creazione di un CSIRT “Computer Security Incident Response Team” per rispondere efficacemente a un incidente.

Incident response: misure organizzative di adeguamento

Le misure organizzative di adeguamento di risposta agli incidenti possono essere classificate nella procedura e suddivise in 4 fasi:

1. Detection
2. Analisi
3. Gestione
4. Ripristino

a) Fase di detection

La fase di rilevazione rappresenta il presupposto per la gestione della risposta agli incidenti.

In questa fase sono comprese tutte le azioni necessarie volte a creare le condizioni migliori per gestire l’incidente.

Grazie a un’attenta configurazione dei sistemi si potrà garantire e gestire il monitoraggio degli stessi per individuare gli allarmi. Tra le attività consigliate per le società rientra il monitoraggio di:

• autenticazione ai server
• anomalie sui log
• report del firewall
• ricezione di posta indesiderata
• anomalie sul sito web

Definiti gli attori coinvolti sul piano organizzativo, e le loro responsabilità, tra le figure di maggior spicco c’è quella del RSI, il responsabile dei sistemi informativi, il quale avrà responsabilità sul monitoraggio continuativo degli eventi, sulla loro classificazione, sulla gestione degli allarmi, nel coordinare le misure organizzative atte a minimizzare l’incidente, con eventuali altri soggetti come il tavolo tecnico, la sala operativa, composta dai referenti di altre organizzazioni, il DPO, se nominato, e l’Autorità Garante.

Avrà altresì responsabilità nelle fasi di monitoraggio dell’attività di ripristino, reportistica e sessioni post-incidente, oltre alla chiusura degli stessi e alle analisi post incidente.

Il processo di gestione dell’incidente si attiva nel momento in cui gli attori preposti al monitoring rilevano l’incidente in tempo reale, in seguito ad una verifica, registrano comportamenti sospetti, raccolgono da fonti esterne nuovi pericoli di vulnerabilità.

b) Fase di analisi

Nella seconda fase, quella dell’analisi, in considerazione dell’eterogeneità dei vettori d’attacco, avvalendosi di matrici diagnostiche e procedure operative, il team preposto effettua una diagnostica.

La componente d’analisi, sarà complessa e si dividerà in altre azioni da intraprendere:

• nel caso in cui vengano identificati tali incidenti come falsi positivi, si tenderà alla registrazione degli eventi ed al trattamento degli stessi;
• in caso di rilevamento di eventi anomali, che presentino un impatto di rischio di livello 0,1,2,3,4 si aprirà la relativa scheda di gestione allarme e dovrà essere gestito il sotto processo interno o se collegato ad altri soggetti esterni, e se quindi meritevole di alto rischio per i diritti e le libertà delle persone, dovranno essere coinvolti nel processo oltre all’obbligo di comunicazione all’Autorità Garante.
• nel caso in cui gli eventi anomali non riescano ad essere gestiti, sarà possibile informare e chiedere supporto agli organismo istituzionali.

Verrà quindi classificato l’evento e attivata la fase di gestione dei sotto processi aziendali a seconda del livello di incidente trattato.

c) Fase di gestione

Nella fase di gestione si attivano i sotto flussi corrispondenti agli incidenti.

Bisogna opportunamente distinguere i livelli incidentali e le azioni da intraprendere:

Incidente livello 0-1

Gli incidenti riconosciuti di livello 0 e di livello 1 saranno gestiti internamente all’azienda, con coinvolgimento ed interazione del RSI e dei vertici dell’organizzazione.

Il RSI, una volta accertati gli eventuali danni, ha il compito di definire la strategia migliore da adottare, tenendo conto che tali operazioni non dovranno arrecare danno all’operatività organizzativa, ne comportarne maggiori.

Durante l’intera fase il RSI si potrà confrontare con altre unità operative per il perseguimento delle procedure di trattamento degli incidenti.

Terminata questa fase viene redatto il piano di intervento, che sarà coordinato dallo stesso RSI, al termine del quale sarà valutata la chiusura dell’incidente in seguito a ulteriori verifiche di sicurezza.

Al termine di tali verifiche

1. se l’incidente sarà rientrato si chiuderà con la redazione di un report riportante l’intera gestione dell’evento, precisamente data e ora di apertura e chiusura delle schede di gestione, codice dell’incidente, documentazione degli interventi. Se risulterà di livello 0 non verrà fatta alcuna comunicazione al vertice aziendale, in caso sia di livello 1 sarà necessario inviare una comunicazione ai vertici.

2. In caso in cui l’incidente non risulti essere chiuso, si adegueranno ulteriori attività di gestione, un nuovo piano di intervento ed una ri-classificazione dell’incidente con la relativa gestione di sotto flusso.

Incidente livello 2

Dall’istante in cui viene riconosciuto un’incidente di livello 2, il RSI convocherà il tavolo tecnico, al quale parteciperanno gli stakeholder coinvolti, e al quale sottoporrà l’analisi reportistica dell’incidente, con le indicazioni di maggior rilievo, e il piano operativo di intervento in cui saranno decise, anche in questo caso le attività da seguire per il contenimento, le azioni suggerite in funzione al sistema sottoposto a incidente.

Il tavolo tecnico supporterà l’RSI per tutta la durata della gestione dell’incidente.

Riclassificato l’incidente al tavolo tecnico avremo diversi scenari:

1. se l’incidente sarà declassificato a falso positivo, sarà verbalizzata l’analisi effettuata, con i motivi del declassamento;
2. se l’incidente sarà riclassificato a livello 0 e 1 e 3 saranno attivati i sotto-processi sopra descritti, con le eventuali segnalazioni;

Nella gestione dell’evento livello 2, dal momento in cui l’incidente coinvolga altre aziende, esterne all’organizzazione, come precedentemente anticipato, il tavolo tecnico dovrà inviare loro una comunicazione sui rischi di impatto. I referenti aziendali esterni analizzate le segnalazioni, se queste non comportano rischi per la propria organizzazione, invieranno un report al tavolo tecnico, qualora venga rilevato un ‘incidente non scoperto in precedenza invierà comunque un report restando in connessione con il tavolo, come parte operativa.

Il tavolo tecnico, analizzato il piano integrato invierà il piano di gestione dell’incidente all’RSI e ai referenti esterni, restando in contatto per l’intera durata del piano con gli stessi, e redigendo il report di rendicontazione che permetterà al tavolo tecnico di capire se l’incidente sarà rientrato.

Al termine delle attività il tavolo tecnico procederà alla chiusura dell’incidente, redigendo il report di chiusura contenete le informazioni principali all’incidente tra cui il codice, la data e ora di apertura e chiusura delle schede di gestione, i report di classificazione.

Incidente livello 3

A differenza dell’incidente di livello 2, nella fase di gestione di livello 3, manifestandosi un’inadempienza con un rischio per le violazioni delle libertà e dei diritti delle persone, che può essere anche elevato, oltre alla convocazione del tavolo tecnico, e della sala operativa, composta dai referenti delle organizzazioni coinvolte, si procederà alla comunicazione al DPO, allorquando presente.

Il tavolo tecnico avrà il compito dunque di valutare l’impatto sulla protezione dei dati personali degli interessati coinvolti, e nel caso in cui la violazione presenti un elevato rischio dei diritti e le libertà delle persone fisiche, dovrà comunicare al Garante circa la violazione.

In questo caso avrà 72 ore per la comunicazione, ed entro 48 ore dovrà convocare una riunione straordinaria con tutti i referenti della sala operativa, con lo scopo della redazione del modello per la comunicazione del data breach, nel quale sarà descritto minuziosamente l’evento incidentale, le categorie dei dati interessati, le misure tecniche-organizzative utilizzate, nonché una stima d’impatto della violazione e l’eventuale decisione di comunicazione agli interessati.

A questo punto, a seguito delle riunioni continuative tra tavolo tecnico e sala operativa, e in seguito all’adozione del piano di contenimento avremo due scenari

– l’incidente sarà declassificato a livello 2 con relativo verbale di report;

– nel caso in cui l’emergenza non risulti rientrata, si susseguiranno nuovi piani di intervento e di minimizzazione dell’incidente.

Terminata la fase di contenimento, seguirà la comunicazione ai vertici aziendali relativi alla gestione, per avviare la fase di analisi post-incidente, nella quale saranno attori il tavolo tecnico e l’RSI, che comprenderà la raccolta dei dati relativi all’incidente, l’analisi degli asset coinvolti, la valutazione degli impatti.

Al termine della fase di analisi post-incidente, ci sarà la chiusura dello stesso che porterà al piano di ripristino.

d) Fase di ripristino

In seguito al contenimento dell’incidente si avvierà la fase di ripristino, che consisterà nello sradicamento dello stesso e al ripristino delle normali operazioni.

Il ripristino potrà coinvolgere attività di natura sistemistica, come il backup and restore, una installazione da zero dei sistemi operativi e applicazioni, ed attività che riguardano la sicurezza, come la recisione delle politiche intraprese, dei firewall, del monitoring.

Il piano di ripristino deve contenere l’elenco delle unità coinvolte nell’incidente, il piano di rientro, le funzioni e le responsabilità coinvolte, e non di poco conto le presumibili date di rientro, il tempo costituisce un elemento importantissimo nell’incident response.

Attori del piano di ripristino saranno ancora il RSI e il tavolo tecnico che coordineranno e monitoreranno lo stato di avanzamento, al termine del quale ci sarà la chiusura definitiva dell’incidente redigendo il report di chiusura che sarà poi inviato ai vertici aziendali.

Al termine della gestione di chiusura sarà auspicabile una formazione del personale coinvolto a tutti i livelli di procedura di incident response.

Misure organizzative: la Business continuity

Una precisa amministrazione della Business continuity consente a un’organizzazione di continuare a erogare i propri prodotti e servizi anche a seguito di un evento critico. Nelle grandi organizzazioni, o in contesti laddove, al verificarsi di un’interruzione, l’interesse primario da tutelare sia diverso o ulteriore rispetto all’erogazione di prodotti e servizi, e dunque rispetto al business, o che gestiscono ingenti operazioni, parallelamente alla procedura di incident response, viene prevista una procedura di continuità operativa, al fine di gestire la resilienza durante gli incidenti e mantenere l’operatività organizzativa.

Tale processo deve individuare gli obiettivi da raggiungere durante il piano di recovery che possono essere così classificati:

– RTO: Recovery Time Objective, che si riferisce al lasso di tempo entro cui effettuare il ripristino,

– RPO: Recovery Point Objective, che si riferisce al punto di ripristino e la massima perdita accettabile di dati

– MAO: Maximum Acceptable Outage, che si riferisce al tempo massimo di interruzione tollerabile

– MBCO Minimum Business Continuity Objective che si riferisce al livello minimo di performance.

Questi valori avranno come esito la BIA, Business impact analysis, che rappresenterà la metodologia utilizzata durante il risk assessment.

Le misure di adeguamento alla business continuity possono essere di vario tipo:

1. il backup, attraverso il quale si effettuano le copie dei dati
2. l’utilizzo di una seconda infrastruttura di emergenza, lo stand by di emergenza che consente la replica sincrona, ovvero la stessa copia dei dati originali sincronizzati, e la replica asincrona, che è differisce dalla prima per la mancanza della sincronizzazione, oltre che possibile effettuare delle tecniche miste
3. la struttura a cluster distribuito, un insieme di connessioni di computer che lavorano insieme su diversi nodi. A differenza dei computer di rete, i cluster di computer hanno per ognuno un nodo organizzato per compiere la stessa operazione, controllato e programmato tramite software.
4. un nuovo sistema di trattamento

Valutato il piano non resterà che da valutare le dipendenze, e sarà necessario esaminare per ogni flusso di trattamento le funzionalità di dipendenza.

Tutto il piano di Business continuity, per essere adeguatamente efficace, deve essere testato, simulando anche scenari d’attacco.

La principale norma di riferimento del settore è la ISO 22301 (Societal Security – business continuity management systems).