È possibile evidenziare alcuni vistosi limiti dell’approccio tradizionale alla continuità operativa legato all’uso di buone pratiche e standard di riferimento. Ad esempio, nell’articolo: RTO e RPO, i limiti nella pianificazione della continuità operativa: ecco le soluzioni evidenziavo come l’RTO e RPO di un processo siano considerati in tali documenti come immutabili, mentre nella realtà la criticità di un processo può variare nel tempo (in funzione del giorno del mese o dell’ora del giorno) allorquando si avvicina una scadenza improrogabile.
Quindi, anche RTO molto stingenti, ad esempio di due ore, non sono sufficienti se l’interruzione del servizio/processo avviene ad esempio a pochi minuti da un cut off relativo ad una scadenza fondamentale.
Nell’articolo I rischi nascosti del disaster recovery: che fare per garantire la continuità del business aziendale evidenziavo, invece, come l’abitudine di predisporre dei siti di Disaster Recovery sotto dimensionati rispetto al sito primario e soprattutto senza requisiti di alta disponibilità, rende di fatto affidabili tali soluzioni solo per un periodo di tempo limitato, inversamente proporzionale alla complessità delle architetture ed al numero di componenti presenti.
Conoscendo alcuni parametri come l’ MTBF (Mean Time Between Failures) dei vari componenti (ad esempio dei dischi rigidi) e la loro numerosità, è anche possibile prevedere dopo quanto tempo sia probabile che ci sia un guasto (le cui conseguenze sono ovviamente legate allo specifico servizio/applicativo supportato da tale componente) che possa portare anche al blocco dell’erogazione di servizi critici.
Affrontiamo con lo stesso tipo di approccio un altro tema fondamentale nell’ambito della continuità operativa: la corretta esecuzione della Business Impact Analysis (BIA), il cui compito è valutare la criticità di un processo/servizio.
Analisi dei rischi e BIA per la continuità operativa: impianti normativi e soluzioni pratiche
Indice degli argomenti
Cos’è e quando eseguire una Business Impact Analysis
La Business Impact Analysis (BIA)va effettuata su tutti i processi aziendali (o meglio su quelli che riguardano la parte delle attività di un’azienda che si è stabilito, per legge o per opportunità, debba disporre di un piano di continuità operativa).
È infatti tramite tale strumento che si determina il loro livello di criticità e quindi le conseguenze derivanti dalla loro mancata esecuzione secondo diversi criteri, quali ad esempio le perdite economiche, le conseguenze legali e sanzionatorie, la perdita di immagine… che subirà l’azienda in conseguenza della loro interruzione.
È evidente che sul lungo periodo tutti i processi sono importanti per l’azienda e quindi la BIA serve a determinare quali siano quelli da ripristinare con maggiore urgenza e quanto l’azienda possa sopravvivere se non vengono erogati determinati processi.
La BIA non è l’analisi dei rischi, dalla quale differisce in quanto si valuta il solo impatto e non anche la probabilità di accadimento di un evento, che in questa analisi si considera certo.
I piani di continuità operativa intervengono infatti dopo che un evento avverso è occorso, per il ripristino della normale operatività, anche se l’attuale tendenza è di operare anche per i processi in un’ottica di rafforzamento della loro resilienza, analogamente a quanto avviene da sempre nell’ambito dell’ICT.
Questo articolo non vuole essere esaustivo di tutte le azioni che è necessario intraprendere per svolgere una BIA, ma vuole limitarsi ad evidenziare alcuni aspetti, spesso trascurati.
Le metodologie per eseguire una BIA
Esistono diverse metodologie per l’esecuzione di una BIA e come sempre è opportuno trarre spunto da una visione di insieme di quello che offre il mercato, avendo però consapevolezza che approcci troppo semplificati possono portare a errate valutazioni circa la reale criticità di un processo.
La metodologia del BCI (Business Continuity Institute)
La metodologia del BCI (Business Continuity Institute), ad esempio, propone l’esecuzione di 4 diverse tipologie di BIA, sempre più focalizzate e puntuali, che partono da una valutazione iniziale che copre l’intera organizzazione (dove gli interlocutori sono i vertici aziendali) fino ad arrivare ad una valutazione delle singole attività (dove gli interlocutori sono i responsabili delle medesime), passando per una BIA che riguarda prodotti e servizi e successivamente per una BIA che riguarda i processi.
Questo modo di procedere è ovviamente molto razionale, in quanto permette di capire effettivamente, da un lato, quali siano gli elementi più importanti per la sopravvivenza di un’organizzazione, dall’altro il dettaglio della rilevanza della singola attività.
Per quanto possa sembrare lungo e dispendioso, questo tipo di approccio consente di elaborare i vari livelli di BIA coinvolgendo le giuste risorse come interlocutori e affinando, se il caso lo richiede, le analisi di dettaglio più elevato solo sulle aree di maggior interesse e con interlocutori che necessariamente sono diversi dai precedenti.
Il BCI non entra nei dettagli su come eseguire una BIA e quindi è utile rifarsi per tale scopo ad altri standard molto più dettagliati su tale tema.
Lo standard 100-4 della BSI
In particolare la tedesca BSI (Federal Office for Information Security) ha prodotto lo Standard 100-4 (liberamente scaricabile dal sito della BSI) che, pur essendo un po’ datato, è sicuramente uno dei più validi e molto più operativo che non uno qualunque degli standard ISO che riguardano tale tema.
Tale standard, ad esempio, è l’unico, a mia conoscenza, che prende in considerazione la variazione dell’RTO di un processo in funzione del periodo dell’anno di riferimento; molto lontano da quanto in realtà sarebbe necessario fare secondo quanto evidenziato nel mio articolo prima citato, ma quantomeno è un inizio.
Un altro aspetto particolarmente importante trattato da tale standard riguarda la valutazione, nell’ambito della conduzione di una BIA, della correlazione esistenti fra i vari processi.
La valutazione iniziale della criticità di un processo
Si è già evidenziato in precedenza come la BIA debba essere svolta su tutti i processi, tuttavia la valutazione iniziale circa la criticità di un processo preso singolarmente può cambiare nel momento in cui si considerano i processi nel loro complesso, individuando relazioni e corrispondenze.
Nella predisposizione dei piani di continuità operativa è necessario individuare tutte le risorse necessarie per l‘esecuzione dei processi, quali ad esempio dati, documenti, persone, applicazioni, edifici e nel caso in si tratti di processi di processi di produzione anche di impianti, materie prime e via dicendo.
Nell’individuazione di questi componenti è fondamentale individuare quando questi elementi siano prodotti da processi interni all’azienda stessa.
Non è infrequente che un processo, anche molto critico, dipenda per la sua esecuzione ad esempio da un documento prodotto da un altro processo.
Il processo che produce tale documento potrebbe aver ricevuto una valutazione iniziale tale per cui viene considerato come poco importante per la continuità operativa dell’azienda.
Tuttavia nel contesto complessivo appare chiaro che tale processo, in quanto fonte indispensabile di un componente per l’esecuzione di un processo critico, diventi a sua volta critico.
Tale analisi deve essere ovviamente estesa a cascata e può portare a ridefinire la valutazione iniziale di molti processi.
Lo standard si spinge oltre quanto appena rappresentato.
Infatti per una corretta definizione dei piani sarebbe opportuno valutare il livello di interdipendenza fra i vari processi, in quanto tale interdipendenza potrebbe essere anche solo parziale.
Sia in un caso (considerando solo interdipendenze assolute), sia nell’altro (considerando il reale livello di interdipendenza) si determina una vera e propria catena di relazioni fra processi che influenza i rispettivi valori di RTO ed RPO (sempre con i limiti più volte evidenziati rispetto a tali valori) che può portare a ridefinire i valori attribuiti durante una valutazione iniziale sui singoli processi.
Quanto è importante tale valutazione?
Se non si è in grado di stabilire il livello di interdipendenza fra processi è ovviamente opportuno in via prudenziale attribuire al processo alimentante lo stesso livello di criticità del processo ricevente.
Il vero rischio è il non individuare tale relazione e quindi di considerare insignificante un processo che in realtà è indispensabile per garantire la continuità di un processo critico per l’azienda.
Scenari di rischio da valutare nella conduzione di una BIA
Da ultimo presento un tema già trattato in un precedente articolo: gli scenari di rischio che è utile valutare nell’ambito della conduzione di una BIA.
Al riguardo sia la Circolare 285 di Banca d’Italia, sia i documenti emessi dalla PA fanno riferimento ad un ristretto elenco di scenari basati su una serie di eventi, indipendentemente dalla causa che li ha generati:
- distruzione o inaccessibilità di strutture nelle quali sono allocate unità operative o apparecchiature critiche;
- indisponibilità di sistemi informativi critici;
- indisponibilità di personale essenziale per il funzionamento dei processi aziendali;
- interruzione del funzionamento delle infrastrutture (tra cui energia elettrica, reti di telecomunicazione, reti interbancarie, mercati finanziari);
- alterazione o perdita di dati e documenti critici.
Tuttavia l’uso di scenari di rischio basati solo sul risultato, come ad esempio l’indisponibilità di un edificio indipendentemente dalla causa che la produce (un terremoto o un allarme bomba) è valido solo per la costruzione di piani di continuità a breve termine (anche se questo non vale per i sistemi informativi per i quali la causa ha impatti anche sulle soluzioni a breve termine essendo diverso, ad esempio, il piano settoriale relativo alla gestione della indisponibilità di un CED da quello relativo ad un attacco ransomware), ma se si devono considerare le conseguenze e quindi gli interventi sul lungo periodo è necessario anche considerare le cause scatenanti.
Quindi è necessario predisporre piani sia per il breve sia per il lungo periodo, come del resto richiesto dalla normativa bancaria.
È inoltre importante considerare che lo stesso evento, come ad esempio un attacco ransomware, porta alla contemporanea attivazione di più di uno degli scenari prima descritti. La cifratura di file può infatti comportare sia l’indisponibilità di sistemi informativi critici, sia di dati e documenti critici.
Tuttavia la predisposizione di piani a lungo termine è condizionata dalla causa dell’interruzione.
È quindi necessaria un’analisi molto più approfondita e una individuazione delle possibili minacce che possono portare ad una interruzione dei processi aziendali al fine di costruire adeguati piani di intervento o quantomeno di linee guida per poter affrontare i vari scenari. Potrebbe infatti risultare impossibile definire soluzioni per tutte le possibili cause, ma quello che è fondamentale per un’azienda è l’avere delle indicazioni su come comportarsi per affrontarle.
Più che soluzioni pronte per tutte le infinite casistiche quindi, per i piani a lungo periodo è opportuno individuare strategie di comportamento e disponibilità di budget e risorse per poter pianificare adeguatamente la loro risoluzione.
Conclusioni
La redazione di una BIA è un processo articolato e complesso e non può essere improvvisato, coinvolge figure a vari livelli e deve tenere conto di molteplici fattori.
In caso contrario si rischia di considerare come poco importanti processi senza i quali l’azienda non può operare con le relative conseguenze in caso del verificarsi di un reale evento avverso.
