Garantire la continuità del business richiede l’impostazione di numerose soluzioni al fine di rispondere alla mancanza o degrado di uno o più degli elementi che consentono l’erogazione dei servizi, quali ad esempio gli edifici, il personale, i dati, i documenti, il sistema informativo: è dunque importante individuare quelli che sono gli eventi che possono portare a problemi alla continuità operativa in ambito ICT.
Inoltre, molte di queste interruzioni derivano da ciò che all’origine viene considerato un incidente e dunque è utile anche chiedersi cosa sia un incidente.
Indice degli argomenti
Continuità operativa e ICT: cosa si intende per incidente
Anche limitandoci all’ambito dell’ICT, non esiste una definizione univoca e condivisa di incidente; se facciamo riferimento alla normativa abbiamo che Banca d’Italia nella Circolare 285 riporta la seguente definizione, limitando l’ambito alla sicurezza informatica:
“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)”.
EBA, l’Autorità bancaria europea, negli Orientamenti in materia di segnalazione dei gravi incidenti ai sensi della direttiva (UE) 2015/2366 (PSD2) amplia il perimetro includendo gli incidenti operativi:
“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”.
Ancora diversa è la definizione che riporta il nuovo Regolamento relativo alla resilienza operativa digitale per il settore finanziario, (ancora in fase di predisposizione), il così detto DORA:
“incidente connesso alle TIC (tecnologie dell’informazione e della comunicazione): un evento imprevisto identificato, verificatosi nella rete e nei sistemi informativi e derivante o meno da attività dolose, che compromette la sicurezza della rete e dei sistemi informativi, delle informazioni da essi trattate, conservate o trasmesse, o che ha effetti avversi sulla disponibilità, la riservatezza, la continuità o l’autenticità dei servizi finanziari forniti dall’entità finanziaria”.
Se invece facciamo riferimento a standard o buone pratiche come ITIL (V.3) la definizione riportata è la seguente:
“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. Per esempio il malfunzionamento di un disco in un set di dischi mirrorati”.
La definizione di ITIL è in realtà quella che meglio rispecchia l’approccio descritto in questo articolo in quanto è focalizzato sia sull’interruzione di un servizio sia, in modo esplicito, sulla riduzione della qualità dello stesso.
Business continuity, migliorare performance e resilienza aziendale: soluzioni pratiche
Continuità operativa e ICT: le soluzione da mettere in atto
In funzione del tipo di incidente le soluzioni da mettere in atto sono diverse e, limitandoci a considerare quelli che possono avere impatti significativi sugli aspetti di continuità operativa, vanno al di là di quanto prevedono normalmente gli attuali piani di business continuity e di disaster recovery.
In effetti, solo uno specifico e limitato scenario è coperto dai piani di disaster recovery (DR) e in particolare il ricorso a questo tipo di soluzione dovrebbe avvenire in casi estremi, allorquando l’indisponibilità del sito primario sia determinata, ad esempio, da una distruzione fisica del sito.
Situazioni di “crisi” più limitate, come quelle derivanti dalla mancanza di alimentazione elettrica o dell’impianto di condizionamento dovrebbero essere gestite grazie alla predisposizione di adeguate misure preventive, che da un lato garantiscano la continuità dei servizi di supporto (alimentazione elettrica, connessione di rete, condizionamento ecc.), dall’altro garantiscono l’assenza di single point of failure delle componenti del sistema informativo, grazie a una ridondanza (e adeguata collocazione) dei vari componenti (router, server, dischi, alimentatori ecc.).
Sia le misure preventive, sia il disaster recovery non sono tuttavia in grado di prevenire una serie di scenari che in condizioni normali sono gestiti da altri processi ICT, ma che in situazioni eccezionali possono portare anche al blocco temporaneo o prolungato della erogazione dei servizi ICT nel loro complesso o, in forma più limitata, di singole componenti ed applicazioni.
Quest’ultimo caso non è tuttavia da sottovalutare.
La rilevanza dei processi aziendali nel piano di business continuity
È infatti buona prassi, in sede di redazione di un piano di business continuity, definire tramite una BIA (Business Impact Analysis) la rilevanza dei vari processi aziendali, secondo una scala di criticità legata agli impatti derivanti dalla portata temporale della loro mancata erogazione.
La valutazione si basa considerando le conseguenze per il business (in termini di perdite operative, di immagini, legali) derivanti dalla mancata erogazione di un servizio per un periodo di tempo crescente.
In realtà, come ha ben evidenziato la pandemia, qualunque processo aziendale è di per sé critico (salvo che sia del tutto inutile la sua esecuzione, ma questo è un altro tema), ma ci sono processi la cui mancata erogazione ha impatti immediati, altri il cui impatto diventa significativo dopo una interruzione di 4 ore, altri dopo una interruzione di 8 e così via. Alcuni processi potrebbero essere critici anche dopo molto tempo (ad esempio, il pagamento degli stipendi).
Va anche considerato che la criticità di alcuni processi può essere variabile in funzione dell’ora del giorno, del periodo dell’anno, del giorno del mese, tutti parametri che dovrebbero essere presi in considerazione anche se in realtà sono per lo più ignorati dalla maggior parte di chi si occupa della redazione di una BIA.
È evidente che, limitandoci a considerare gli aspetti ICT, sono analogamente critiche le infrastrutture e le applicazioni sottostanti ai vari processi e quindi, un’applicazione che permette l’erogazione di un processo il cui impatto è rilevante dopo un tempo limitato di interruzione, deve poter continuare a funzionare ininterrottamente.
Analisi dei rischi e BIA per la continuità operativa: impianti normativi e soluzioni pratiche
Gli scenari che possono determinare interruzioni di servizi
Dopo questa doverosa dissertazione torniamo a considerare quali siano gli scenari che possono determinare una interruzione dei servizi che normalmente vengono gestiti dagli operatori di primo e secondo livello e che difficilmente porta ad una escalation verso le strutture che gestiscono la business cotinuity; ad esempio il già citato malfunzionamento di un’applicazione.
Se un’applicazione software smette di funzionare per un qualunque motivo intrinseco all’applicazione stessa difficilmente si pensa di invocare uno scenario di crisi. Lo stesso avviene se vi è un rallentamento prolungato sui tempi di risposta della rete a causa di un sovra carico (chi non ha sperimentato le conseguenze di un accesso simultaneo di un rilevante numero di connessioni in VPN da parte dei neo smart worker durante il primo lock down?).
Sono situazioni, queste, di solito gestite nella normale operatività e quindi non considerate e non gestite nei piani di business continuity.
Ma cosa succede se l’applicazione che non funziona per un problema intrinseco è quella che supporta un processo particolarmente critico?
Al riguardo è necessario effettuare anche un’altra considerazione.
I processi aziendali non vivono di vita propria, ma in genere fanno parte di un sistema più articolato e complesso.
In altre parole sono fonte di dati ed informazioni per altri processi a valle e sono a loro volta alimentati da processi che li precedono.
Una BIA ben condotta non può prescindere da tali valutazioni e quindi un processo che di per sé stesso non crea criticità se non viene erogato per tempi limitati, potrebbe in realtà esserlo se è una fonte di informazioni indispensabili per un processo critico posto a valle dello stesso.
I limiti di intervento delle aziende
Ecco, quindi, che le applicazioni il cui corretto funzionamento è indispensabile si moltiplicano e quindi anche un “semplice” malfunzionamento che si protrae nel tempo diventa significativo.
Il fatto è che, di norma, le aziende non sono pronte ad affrontare situazioni di questo tipo; non rientra nei loro piani di intervento l’affrontare un “semplice” malfunzionamento applicativo.
Non hanno, utilizzando la terminologia utilizzata da Banca d’Italia nel capitolo della Circolare 285 dedicato alla “Continuità operativa”, uno specifico piano settoriale.
In realtà Banca d’Italia nel sopra citata Circolare si esprime correttamente.
Quello che chiede alle banche di fare ed è essere in grado di affrontare l’indisponibilità di sistemi informativi critici, ed in effetti tale formulazione è molto ampia e comprende qualunque causa scatenante l’indisponibilità. Peccato che poi citi espressamente, fra i piani settoriale, solo quello sul disaster recovery.
La convinzione che la continuità dell’ICT sia gestita dal piano di disaster recovery è purtroppo una convinzione comune e quindi le aziende non sono preparate ad affrontare situazioni di crisi generate da altri eventi che coinvolgono l’ICT, quali appunto un semplice malfunzionamento applicativo o un attacco cyber.
Continuità operativa e ICT: i possibili eventi avversi
In effetti, sono diversi gli eventi che possono minare la continuità del business e che rientrano nella “normale “operatività.
L’aggiornamento dei software aziendali
Ad esempio gli aggiornamenti del software a qualunque livello, dal sistema operativo agli applicativi.
I produttori rilasciano spesso nuove release dei loro software o patch per sanare qualche anomalia o per introdurre nuove funzionalità.
Moltissimi software ricevono aggiornamenti talmente frequentemente che vengono configurati per svolgere in autonomia tale attività, verificando la presenza di aggiornamenti sul sito del produttore e provvedendo alla loro installazione, spesso in background alla normale operatività degli utenti.
Questo è vero soprattutto per le postazioni client.
La maggior parte delle volte tale attività di aggiornamento non produce controindicazioni, ma quando queste si manifestano la loro gestione può essere molto onerosa e comportare, nel peggiore dei casi, ad un ritorno alla precedente versione del software.
Il tutto con evidenti disagi e interruzioni del servizio per gli utenti.
È importante considerare che i malfunzionamenti generati non necessariamente devono riguardare gli aspetti principali di un processo, ad esempio la parte che riguarda l’elaborazione dei dati, ma può riguardare il malfunzionamento di qualche periferica indispensabile per la conclusione del processo (ad esempio una stampante), per la quale non sono disponibili i driver corrispondenti alla nuova release di un sistema operativo.
Attivazione di nuove applicazioni e migrazione dei dati
Altre attività che possono comportare fermi prolungati comprendono l’attivazione di nuove applicazioni in sostituzione di quelle in uso, con conseguente migrazione dei dati e l’introduzione di nuove o diverse funzionalità.
Il primo rischio in questo caso riguarda il mancato funzionamento della nuova applicazione secondo le aspettative previste, con la conseguente mancata erogazione di uno o più servizi o quantomeno il rallentamento degli stessi a livelli inaccettabili.
Al riguardo sono numerosi i casi presenti in letteratura e tutti noi abbiamo sperimentato di persona più di una volta situazioni di questo tipo.
Ad esempio qualche anno fa, per me pendolare che utilizza i mezzi pubblici, furono particolarmente fastidiose le conseguenze del cambio del software per la gestione dei turni del personale; ai cronici ritardi per diversi giorni si aggiunsero ulteriori ritardi e cancellazioni.
Le motivazioni di possibili disservizi in questi casi sono legate a numerosi fattori; si va da una errata valutazione del carico sulla infrastruttura che deve supportare l’applicazione ad una errata migrazione dei dati, alla mancata valutazione di situazioni gestite medianti prassi messe in atto dagli utenti, per sopperire alle carenze del software attivo in precedenza, ma non documentate.
Spesso le attività sopra descritte si avvalgono di “fermi programmati” e quindi gli utenti sono precedentemente avvisati del fermo o degrado del servizio. Il problema è che tale fermo può andare ben oltre l’intervallo di tempo programmato trasformandolo in un disservizio.
Conclusioni
Quelli citati sono solo alcuni esempi di eventi che possono comportare il fermo o il degrado di un servizio.
La business continuity deve quindi ampliare i propri confini per quanto attiene il mondo ICT e sembra che il nuovo regolamento DORA, prima citato, vada anche in questa direzione.
È necessaria una maggiore integrazione fra tutte le strutture che gestiscono i processi ICT, la definizione di piani di intervento che comprendano un numero maggiore di scenari di indisponibilità o degrado dei sistemi e la capacità di apprendere dall’esperienza, anche di altri.
