Cloud Privato
Capitolo 3: Business continuity and disaster recovery
3.4. Risk assessment, business impact analysis e cost benefit analysis
Un passo molto importante al fine della redazione del piano di Disaster recovery è la fase di risk management. In essa si possono evidenziare tre elementi fondamentali nella giustificazione delle decisioni che poi vengono poste in essere non solo nel processo di disaster recovery ma anche nel sistema complessivo della gestione della continuità operativa: si tratta della business impact analysis, della cost-benefit analysis e del risk assessment.
19 Wallace, Laurence, The Disaster Recovery Handbook: A Step-by-Step Plan to Ensure Business Continuity and Protect
21
Quando si parla di Disaster recovery, infatti, tendenzialmente l’attenzione va a focalizzarsi su quattro scenari di rischio che possono produrre impatti negativi in termini sia di perdite, sia di incapacità per la banca di condurre la propria operatività:
Perdita di accesso ai servizi; Perdita di dati;
Perdita di funzioni IT; Perdita di capacità.
Il Risk assessment risulta fondamentale perché, per sua natura, va a focalizzarsi dunque sulle tipologie di rischi che possono produrre queste tipologie di effetti. Le procedure nel Risk assessment son tese a valutare l’impatto sulle attività a seguito di interruzioni dovute ad eventi quali incendi, terremoti, inagibilità dei server ipotizzati nelle loro condizioni estreme20. Ciò avviene mettendo in relazione, per ognuno degli eventi considerati, la probabilità di accadimento e l’entità dell’impatto. Come in ogni altra fase, è sempre necessario che tale lavoro avvenga in piena collaborazione tra manager, sponsor, team IT, area risk management, in modo da rendere tale analisi più efficiente possibile grazie a un elevato capitale informativo a disposizione.
Mediante la valutazione, per ogni minaccia o rischio, della sua probabilità e del suo impatto, si può poi andare a classificare l’evento in modo tale da definire che tipo di intervento attuare: High probability, high impact, eventi di elevata probabilità di accadimento e di elevato
impatto per i quali la misura migliore è quella di interventi di mitigazione;
Low probability, low impact, eventi di scarsa probabilità e di ridotto impatto, per i quali si può anche considerare di poter accettare il rischio seppur mantenendoli sotto controllo;
High probability, low impact, eventi per i quali si rende necessario ridurre la probabilità di accadimento mediante interventi finalizzati al contenimento;
High probability, high impact, eventi per cui si richiede di pianificare le azioni di risposta, dato l’elevato impatto che possono provocare.21
20 Kirvan P., Disaster recovery: Risk assessment and business impact analysis, articolo su www.computersweekly.com,
Maggio 2011
21 Stonebumer G. Risk management guide for IT systems, Recommendation of National Institute of Standard and
22
La Business impact analysis, assieme al Risk assessment, diventano fondamentali nella fase di analisi delle situazioni di rischio. Analizzando gli impatti di minacce sulle vulnerabilità esistenti, si permette di garantire le proprietà di integrità, la quale indica che le informazioni sono modificabili solo da chi è in diritto di farlo, confidenzialità, la quale riguarda la garanzia che solo chi sia in diritto di accedere alle informazioni lo possa fare nella misura per cui risulti necessario e disponibilità, la quale si riferisce alla possibilità di lettura e scrittura dei dati quando richiesto.22
Dato l’obiettivo di garantire tali proprietà, si deve prima di tutto capire come sarebbe la situazione in caso di loro mancanza. Andranno quindi osservate quali siano le minacce e quali siano gli impatti che possono aversi. Si procede allora ad un processo di calcolo e valutazione degli impatti stessi, a seconda che siano misurabili in termini di perdite economiche, costi per riparazione del sistema, correzione del sistema operativo, o che si tratti di impatti che non possono essere misurabili con qualche unità di misura ma soltanto ipotizzabili in termini di gravità di impatto.
La distinzione tipica che si effettua tra livelli di impatto è molto simile come logica a quella del caso del Risk assessment, essendo documenti correlati tra loro; essa è data da:
Alto impatto, quando si osserva un livello elevato di perdite economiche, perdite di asset a rilevanza strategica e forti impatti a livello di reputazione e di compliance; Medio impatto, se si tratta di livelli modesti in termini di perdite economiche e perdite
di asset non di rilevanza strategica, con effetti anche a livello reputazionale e di compliance;
Basso impatto, quando invece si hanno perdite di risorse non importanti.
Uno strumento molto usato per analizzare le minacce quantificabili è la Risk-level matrix, la quale determina il livello di gravità della minaccia andando a relazionare l’impatto con la probabilità di accadimento. Ciò permette di evidenziare i casi con probabilità e impatto elevati, imponendo quindi la necessità di immediate misure correttive; si va poi a scalare per urgenza di intervento, andando a intervenire sui rischi medi, per poi andare a valutare se intervenire con misure correttive sui bassi rischi o se accettarne l’esposizione.
Risulta quindi importante che l’analisi qualitativa e l’analisi quantitativa possano essere eseguite congiuntamente, in quanto la concentrazione su l’una o l’altra comporta sicuramente
22 Swanson, Whol, Pope, Grance, Contingency plan for IT systems, Recommendation of National Institute of Standard
23
dei vantaggi, ma anche il rischio di non valutare correttamente una tipologia di rischio e quindi sopravvalutarla, destinandovi eccessive risorse spendibili invece per rischi più importanti, o peggio sottovalutarla, portando poi a una situazione di eccessiva esposizione. Se si osserva l’approccio qualitativo, sicuramente ha il pregio di andare a identificare la priorità di intervento, ma non è capace di andare a identificare una misura di quanto il sistema sia esposto. Per contro, il vantaggio di un approccio quantitativo è quello di saper misurare l’impatto di una esposizione rischiosa e, dunque, di andare a determinare ad esempio l’ammontare di perdite a cui il sistema è esposto. Purtroppo, i risultati ottenuti con l’analisi quantitativa possono risultare poco chiari e richiedono solitamente una rivisitazione per darne una interpretazione.
Tali risultati quindi portano alla definizione di quali siano gli interventi da eseguire, e ciò porta alla valutazione delle possibili soluzioni che permettano di ridurre, eliminare, mitigare i rischi. Lo sviluppo tecnologico ha fatto sì che le situazioni siano molteplici, conseguentemente occorre valutare accuratamente quali siano le più consone date una serie di variabili, in primis il budget e la dimensione operativa della banca.
Diventa quindi fondamentale la Cost-benefit analysis: ogni soluzione proponibile produce benefici certi o meno, ma è assolutamente certo che si dovrà sostenere un costo. Mediante questa fase allora si vanno ad analizzare i benefici che una soluzione produce, quale sia il costo da sostenere e se vi sono soluzioni alternative che permettono di avere un risparmio in termini di spese di implementazione e allo stesso tempo un beneficio di pari livello, o comunque soddisfacente. Si procede quindi a:
Determinare gli impatti sui quali è necessaria l’implementazione dei controlli; Determinare cosa accadrebbe nel caso tali controlli non vengano implementati; Stima dei costi di implementazione;
Valutazione dei benefici ottenibili dall’implementazione.
Nel processo decisionale, quindi, si terrà conto delle soluzioni prese in considerazione per andare a decidere quale sia la soluzione da attuare. In essa si deve tener conto di una serie di criteri:
Andare al di sotto di una determinata soglia di rischio potrebbe comportare un costo eccessivo, per cui risulta più utile andare a ricercare soluzioni alternative;
24
Se a minor costo si permette comunque il rispetto della soglia di rischio, si sceglie la soluzione che permette un costo minore;