Dagli incidenti alla continuità operativa Di Giancarlo Butti
Sono molteplici gli “incidenti” che possono compromettere il normale svolgimento dell’attività di una qualunque organizzazione e che, nei casi più gravi, possono comportare l’attivazione del piano di continuità operativa. È quindi importante saperli individuare e gestire.
Premetto che in questa sede ci limitiamo a considerare unicamente gli incidenti che hanno impatti sul sistema informativo o comunque su dispositivi informatizzati (la crescente diffusione
dell’automazione e degli IOT ha spostato i confini dell’IT rispetto ai tradizionali componenti costituiti da reti, server, mainframe, postazioni utente ad una moltitudine di componenti…).
Partiamo innanzi tutto da qualche definizione.; una delle più significative definizioni di incidente è quella proposta da ITIL (Information Technology Infrastructure Library):
Indicent - Un' interruzione non pianificata di un servizio IT o una riduzione della qualità di un servizio IT.
Anche il malfunzionamento di un elemento della configurazione che non ha ancora impattato un servizio viene considerato un incident.
Rispetto alla abituale concezione del concetto di indicente tale definizione è particolarmente significativa sotto diversi aspetti.
Per capirlo è utile consultare la definizione di incidente riportata da alcune normative che riguardano il settore finanziario, uno di quelli che dovrebbe avere maggiormente a cuore la resilienza dei sistemi informativi.
Al riguardo una delle normative italiane più significative del settore bancario, la Circolare 285 di Banca d’Italia cita:
— “incidente di sicurezza informatica”: ogni evento, o serie di eventi collegati, non pianificati dalla banca che interessa le sue risorse informatiche e che i) ha o potrebbe avere un impatto negativo sull’integrità, la disponibilità, la riservatezza, l’autenticità e/o la continuità dei servizi o dei processi dell’intermediario; oppure ii) comunque implica la violazione o l’imminente minaccia di violazione delle norme e delle prassi aziendali in materia di sicurezza delle informazioni (ad es., frodi
informatiche, attacchi attraverso internet e malfunzionamenti e disservizi);
Appare evidente una grossa limitazione di tale definizione rispetto a quella di ITIL.
Nelle oltre 700 pagine che costituiscono l’attuale versione della Circolare (che norma fra gli altri la gestione e la sicurezza del sistema informativo degli istituti bancari) l’unica definizione degli incidenti riguarda quelli di sicurezza.
Tale limitazione viene in parte risolta da EBA, nel suo documento Orientamenti in materia di segnalazione dei gravi incidenti ai sensi della direttiva (UE) 2015/2366 (PSD2), nel quale più correttamente gli indicenti sono individuati come appartenenti almeno a due diverse categorie, tramite la seguente definizione:
Incidente operativo o di sicurezza
Singolo evento o serie di eventi collegati non pianificati dal prestatore di servizi di pagamento che ha o probabilmente avrà un impatto negativo su integrità, disponibilità, riservatezza, autenticità e/o continuità dei servizi connessi ai pagamenti.
La definizione di ITIL e di EBA sono molto interessanti e richiedono un’analisi più approfondita.
Innanzi tutto ITIL utilizza il termine: riduzione della qualità mentre EBA utilizza il termine: impatto negativo, anche se successivamente a tale definizione precisa che tale impatto riguarda l’
integrità, disponibilità, riservatezza, autenticità e/o continuità dei servizi, termini che in realtà suggeriscono impatti che riguardino essenzialmente la sfera della sicurezza, riducendo in tal modo la portata della iniziale apertura sugli incidenti operativi (di fatto la parte finale della definizione di EBA è del tutto analoga a quella di Banca d’Italia sugli incidenti di sicurezza).
Sembra quasi che per la normativa in ambito finanziario un incidente sia tale solo se in qualche modo ha impatti sulla sicurezza. Una visione limitata rispetto ad ITIL che, nella sua stringata definizione, non impone limitazioni alle conseguenze di un incidente.
Inoltre entrami i termini, riduzione della qualità e impatto negativo, non introducono in prima istanza una valutazione sull’entità delle conseguenze dell’incidente.
Non è rilevante quindi quanto sia la riduzione della qualità o quanto sia grande l’impatto negativo per poter parlare di incidente.
Perché questo è importante?
Perché la gestione degli incidenti si deve occupare di tutte le situazioni nelle quali un evento, qualunque esso sia, possa ridurre la qualità di un servizio (usando la definizione di ITIL), mentre la continuità operativa1 (la business continuity) si preoccupa di gestire le situazioni nelle quali un incidente mette a rischio la continuità del business (o, nel caso di questo articolo, delle
componenti ICT).
È quindi fondamentale che chi gestisce gli incidenti e chi gestisce la business continuity siano fra loro perfettamente coordinati e reciprocamente consapevoli di quali siano i propri ambiti di intervento e che le relative procedure di gestione siano chiaramente definite, note e sperimentate in tutte le loro componenti.
Tuttavia tale suddivisione non può essere considerata assoluta, ma dovrebbero essere valutate le situazioni di possibili sovrapposizioni, nelle quali ad esempio, il degrado della qualità sia tale che, pur in assenza di una reale interruzione del servizio, l’uso di soluzioni ideate per garantire la continuità operativa possa essere risolutivo per una specifica situazione.
Nella realtà infatti non è opportuno legare l’uso delle soluzioni ideate per la business continuity unicamente ad una dichiarazione formale di uno stato di crisi, salvo il fatto che una tale azione sia effettivamente necessaria al fine di attribuire gli opportuni poteri e responsabilità ai soggetti che devono gestire la soluzione individuata.
Non va infatti dimenticato che l’obiettivo finale è garantire la qualità e la continuità.
Ci si potrebbe chiedere perché in questo articolo, dedicato essenzialmente agli incidenti in ambito ICT si continua a parlare di business continuity e non di disaster recovery.
1 La Business Continuity ha come finalità il garantire la continuità del servizio nel suo insieme, non solo della componente ICT, ma anche delle altre risorse coinvolte, quali persone, edifici, processi, documenti…
In realtà la risposta è molto semplice: la maggior parte degli incidenti ICT, per quanto gravi siano, non trova la propria soluzione nell’attivazione di un Piano di DR.
Anzi, pensare di essere in grado di garantire la continuità del proprio sistema informativo2 solo perché si dispone di un piano di DR è miope.
Sarà sufficiente un attacco ransomware portato prima ai propri presidi di backup3 e poi ai sistemi primari per capirlo.
Parliamo quindi di business continuity anche per l’ICT in quanto un’azienda deve disporre di diversi piani settoriali per poter fronteggiare le situazioni di indisponibilità del sistema informativo.
Del resto anche Banca d’Italia nella Circolare 285, fra gli scenari da fronteggiare si riferisce a:
indisponibilità di sistemi informativi critici, anche con riferimento ai sistemi funzionali alla prestazione dei servizi di pagamento;
indipendentemente da quali siano le cause della loro indisponibilità che potrebbe consistere, molto banalmente, nel non corretto funzionamento di un’applicazione.
Inoltre, sebbene la Circolare 285 cita espressamente, oltre al Piano di continuità operativa, il solo Piano di DR, riporta anche la presenza di Piani settoriali.
L’azienda dovrebbe quindi disporre di una serie di piani in grado di fronteggiare gli scenari scaturiti dai più comuni eventi che possano causare incidenti che hanno impatti sull’ICT.
In considerazione della molteplicità dei possibili eventi non sarà possibile effettuare una definizione esaustiva di tutte le possibili situazioni, ma sarà sicuramente possibile:
• limitare frequenza ed impatto di accadimento di alcuni eventi, grazie ad una adeguata analisi dei rischi che tenga conto di tutti i possibili impatti diretti e indiretti (impatto sulle informazioni, sulla continuità dei servizi, sui diritti e libertà delle persone fisiche, legali, reputazionali, contrattuali…) e successiva implementazione delle corrispondenti contromisure
• definire un processo di gestione dell’incidente allocando le opportune risorse e competenze al fine di individuare le possibili soluzioni là dove si presenti uno scenario inedito o non presidiato (ad esempio perché ritenuto poco probabile, come una pandemia).
Giova inoltre ricordare che, la disponibilità del sistema informativo va intesa in senso esteso.
Deve cioè comprendere non solo i sistemi che erogano i servizi, ma anche quelli che consentono agli utenti di usufruire dei medesimi.
A tal riguardo la pandemia in corso ha evidenziato quanto sia importante per gli utenti il poter disporre delle proprie postazioni di lavoro, anche da remoto, se non sono raggiungibile quelle utilizzate abitualmente.
Di fatto la pandemia ha reso una larghissima parte del sistema informativo, le postazioni utente abitualmente utilizzate, non disponibili, per cui si è dovuto ricorrere a soluzioni alternative.
2 Usiamo tale semplificazione, ma ci si riferisce a tutti i dispositivi ICT, IOT…
3 Indipendentemente dal tipo di soluzione, compresa quelle in cloud, salvo disporre delle specifiche soluzioni pensate per questa tipologia di attacco o di copie aggiornate offline
Un concetto questo che, per quanto banale, non è per nulla scontato nemmeno presso personale ICT altamente qualificato4.
In tale contesto molti scenari che non sono considerati specificatamente ICT devono essere presi in considerazione al fine di garantirne la continuità dei sistemi informativi.
Fra questi l’indisponibilità, per i più svariati motivi, di un edificio che ospita componenti del sistema informativo, o la mancanza di personale rilevante per il corretto funzionamento del sistema, come in parte ricordavano anche le Linee guida per il disaster recovery delle pubbliche amministrazioni (edizione 2013) dalle quali è tratta l’immagine qui riportata.
4 Un paio di slide del mio corso sulla business continuity (2014) illustrano il tema.
In conclusione quindi, gestire incidenti e continuità operativa richiede rigore, formalizzazione, buone pratiche e standard di riferimento, ma anche un po' di creatività e soprattutto esperienza e
sperimentazione.
