Le piccole guide di TAI Solutions
3 Piccola guida alla
Business Continuity
Piccola guida alla
Business Continuity
Prefazione Per business continuity (gestione della continuità operativa o continuità aziendale) si intende la capacità dell'organizzazione di continuare ad esercitare il proprio business a fronte di eventi avversi che possono colpir-
Contenuti
la.
Gestione e valutazione dei rischi..5
La pianificazione della continuità operativa e di servizio si chiama business
BIA—Business Impact Analysis....8
continuity plan (BCP) (in italiano "piano di continuità del business") e vie-
Business continuity plan............11
ne comunemente considerata come un processo globale che identifica i
Disaster Recovery ………………...14
pericoli potenziali che minacciano l'organizzazione, e fornisce una struttura che consente di aumentare la resilienza e la capacità di risposta in maniera da salvaguardare gli interessi degli stakeholders, le attività produttive, l'immagine, riducendo i rischi e le conseguenze sul piano gestionale, amministrativo, legale.
Il Disaster Recovery Plan, che è mirato ai servizi informatici, è un sottoinsieme del business continuity plan.
Il progetto del piano di business continuity Focus La predisposizione di sistemi di Continuità Operativa è normata a livello legislativo per determinate attività in ambito bancario, fiscale e delle infrastrutture informatiche critiche. I Sistemi di Gestione della Continuità
Operativa
sono
volontari, per i quali può essere conseguita una certificazione. In particolare, BS 25999 - Busi-
ness continuity management è la prima norma al mondo per la operativa,
sviluppata
dall’Ente di normazione inglese BSI (ved. Pag. 12).
4
procedere attraverso un progetto articolato in 4 fasi principali:
1. gestione e valutazione dei rischi; 2. business impact analysis - BIA; 3. definizione della strategia di mitigazione dei rischi;
regolati
anche da standard internazionali
continuità
Per la realizzazione del piano di gestione della continuità operativa è necessario
4. sviluppo del piano di business continuity e disaster recovery.
Gestione e valutazione dei rischi La gestione del rischio (risk management) è il processo mediante il quale si misura o si stima il rischio e successivamente si sviluppano delle strategie per governarlo. Di regola, le strategie impiegate includono il trasferimento del rischio a terze parti, l'evitare il rischio, il ridurre l'effetto negativo ed infine l'accettare in parte o totalmente le conseguenze di un particolare rischio.
Priorità
In una gestione del rischio ideale sono trattati per prima cosa i rischi correlati ad una grande perdita e una grande probabilità di accadere, invece i rischi con bassa probabilità di occorrenza e basse perdite sono trattati con ritardo. In pratica il processo può essere estremamente complesso, infatti rischi con alta probabilità di occorrenza, ma con bassa perdita, e rischi con alta perdita, ma bassa probabilità di occorrenza, possono essere mal governati. La gestione del rischio molto spesso si confronta con la difficoltà di allocare propriamente le risorse; questo concetto si dice costo di opportunità. Tempo e risorse spese per la gestione del rischio potrebbero essere spese per attività più redditizie. Inoltre la gestione del rischio ideale spende un ammontare di risorse il minimo indispensabile nel processo di riduzione degli effetti negativi dei rischi.
5
I passi del processo di gestione del rischio Cinque sono i passi del processo di gestione del rischio: •
Stabilire il contesto
•
Identificare i rischi
•
Analizzare i rischi
•
Valutare i rischi
•
Controllare i rischi
Spesso il passo "Controllare i rischi" viene diviso in una fase di preparazione ed approvazione del Piano di azione dei rischio (Risk Action Plan) ed in una fase di esecuzione, controllo e modifica del piano. In parallelo col processo centrale, sono richieste doti di comunicazione e di consultazione. Monitorare e revisionare è parte intrinseca del processo in modo da assicurare che venga eseguito tempestivamente; l'identificazione, l'analisi, la valutazione ed il controllo sono sempre aggiornati. La gestione del rischio è quindi un processo ricorsivo, soggetto ad aggiornamenti, e non si esaurisce nell'identificazione iniziale del rischio.
Stabilire il contesto Stabilire il contesto include pianificare il residuo del processo, l'identità e lo scopo sono fondamentali, le basi sulle quali il rischio sarà valutato e definire lo scheletro per il processo, l'agenda per l'identificazione e l'analisi.
Identificare i rischi Dopo aver stabilito il contesto, il passo successivo nel processo di controllo è quello di identificare i rischi potenziali. I rischi sono connessi a eventi che quando si verificano causano problemi. Pertanto l'identificazione del rischio può iniziare dalla causa dei problemi o dal problema stesso. Analisi della causa: la sorgente di rischio può essere interna od esterna al sistema oggetto della gestione del rischio. Esempi di sorgente di rischio sono: i partecipanti a un progetto, i dipendenti di un'azienda oppure il tempo atmosferico nei cieli di un aeroporto. Analisi del problema: i rischi sono collegati all'identificazione dei pericoli (o minacce). Ad esempio: il pericolo di perdere soldi, il pericolo di violazione di informazioni riservate od il pericolo di errori umani, incidenti od infortuni. Le minacce possono essere correlate a vari soggetti, le più importanti sono connesse con gli azionisti, i clienti e le autorità governative. Quando sono note le origini o i problemi, l'evento che un'origine può attivare o l'evento che può condurre ad un problema possono essere oggetto di approfondimento. Per esempio, i soci che partecipano a un progetto che si ritirano durante lo svolgimento dello stesso possono mettere in pericolo il finanziamento del progetto; informazioni riservate possono essere sottratte dai dipendenti autorizzati anche se la rete informatica è protetta da intrusioni esterne; un fulmine può colpire un aereo durante il decollo e ferire tutti i passeggeri a bordo.
6
Quando sono note le origini o i problemi, l'evento che un'origine può attivare o l'evento che può condurre ad un problema possono essere oggetto di approfondimento. Per esempio, i soci che partecipano a un progetto che si ritirano durante lo svolgimento dello stesso possono mettere in pericolo il finanziamento del progetto; informazioni riservate possono essere sottratte dai dipendenti autorizzati anche se la rete informatica è protetta da intrusioni esterne; un fulmine può colpire un aereo durante il decollo e ferire tutti i passeggeri a bordo. Il metodo per identificare i rischi può dipendere dalla cultura, dalla pratica d'industria e dall'accondiscendenza. I metodi d'identificazione sono formati da template o dallo sviluppo di template per l'identificazione della sorgente, problema o evento. I più comuni metodi di identificazione del rischio sono:
Basato su obiettivi: le organizzazioni ed i team di progetto hanno degli obiettivi. Ogni evento che può mettere in pericolo l'acquisizione parziale di un obiettivo è identificato come rischio.
Basato sullo scenario: nell'analisi dello scenario differenti scenari sono creati. Ogni evento che attiva uno scenario alternativo indesiderato è identificato come un rischio.
7
BIA – Business Impact Analysis La BIA o Impatto sul business (business impact analysis) individua quali processi devono essere funzionanti per garantire il business e quali possono essere sospesi per un certo periodo di tempo. Questo porta alla definizione di una strategia di mitigazioni e di recupero. Al fine di effettuare la BIA, è necessario prendere in esame tutti i processi, le funzioni e le risorse e valutarne l’impatto sull’azienda dal punto di vista operativo, finanziario e legale. La BIA inizia con l’identificazione di tutti i processi, le funzioni e le risorse (compresi quelli esterni, qualora siano critici per lo svolgimento delle attività aziendali) e con l’attribuzione della relativa criticità, anche in considerazione delle interdipendenze esistenti. I risultati della BIA vengono incrociati con gli scenari di disastro e i rischi correlati, che emergono dal documento di Valutazione dei Rischi. Al termine di questa valutazione, è poi possibile decidere, per ciascun processo, quali rischi dovranno essere mitigati, quali trasferiti e quali, eventualmente, accettati (strategia di mitigazione dei rischi). La criticità dei processi serve per determinare il Recovery Time Objective ed il Recovery Point Objective e poter conseguentemente stabilire, nel piano di business continuity e disaster recovery, le azioni da intraprendere nel caso si verifichino eventi avversi.
RTO Il Recovery Time Objective (RTO) è il tempo necessario per il pieno recupero dell'operatività di un sistema o di un processo organizzativo in un sistema di analisi Business Critical System (ad esempio implementazioni di politiche di Disaster Recovery nei Sistemi Informativi). È in pratica la massima durata, prevista o tollerata, del downtime occorso. Aspetto di primaria importanza riveste il fatto che il valore di RTO sia definito, conosciuto e verificato, tenendo presente che se un downtime lungo danneggia la possibilità di fruire del servizio più di uno breve, il danno maggiore deriva dall'inconsapevolezza di quanto possa essere il tempo previsto per il ripristino dei servizi danneggiati. La tabella riporta un esempio della scala dei valori per la valutazione dell’RTO.
VALORE
CRITICITA’ della Funzione
Tempo massimo di ripristino
1
Minore (funzioni auspicabili)
> 3 giorni
2
Necessaria (funzioni importanti)
1 – 3 giorni
3
Vitale (funzioni essenziali)
13 -24 ore
4
Fondamentale (funzioni indispensabili per la sopravvivenza)
0 – 12 ore
8
RPO Il Recovery Point Objective (RPO) è uno dei parametri usati nell'ambito delle politiche di disaster recovery per descrivere la tolleranza ai guasti di un sistema informatico. Esso rappresenta il massimo tempo che intercorre tra la produzione di un dato e la sua messa in sicurezza (ad esempio attraverso backup) e, conseguentemente, fornisce la misura della massima quantità di dati che il sistema può perdere a causa di guasto improvviso. Al diminuire dell'RPO richiesto si rendono necessarie politiche di sicurezza sempre più stringenti e dispendiose, che possono andare dal salvataggio dei dati su supporti ridondanti tolleranti ai guasti fino alla loro pressoché immediata replicazione su un sistema informatico secondario d'emergenza (soluzione in grado di garantire, in linea teorica, valori di RPO prossimi allo zero).
9
Esempio di tabella di valutazione per la BIA Parametro
Descrizione
Dipendenza altri processi
Definire la dipendenza del processo in esame da altri processi / risorse Definire le competenze del personale addetto al processo Definire la periodicità del processo (continuo, periodico, ecc..) Definire le risorse umane e tecnologiche necessarie per il recovery Definire i tempi necessari per il recovery
Competenze del personale Periodicità del processo Risorse necessarie per il recovery Tempo necessario per il recovery SLA
Verificare se sono stati definiti SLA (interni o contrattualizzati) per il processo in esame
Tecnologia utilizzata (sw, hw, server, network…)
Definire la tecnologia utilizzata dal processo in esame Riportare, se esistenti, le soluzioni e procedure per il recovery Verificare la possibilità di svolgere il processo in remoto da altre sedi Verificare la possibilità di spostare il processo, in via momentanea fino alla ripresa delle normali attività, su altre aree aziendali
Soluzioni e procedure esistenti per il DR Possibilità di svolgere il processo da remoto Possibilità di spostare il processo su altre aree
Documentazione critica
Verificare l’esistenza di documentazione critica (in elettronico ed in cartaceo) legata al processo in esame
Obblighi normativi
Verificare eventuali obblighi normativi (scadenze, procedure, ecc…) legate al processo in esame Definire le funzioni aziendali e le risorse umane fondamentali per la continuità del processo in esame Definire la criticità del processo in esame attraverso il suo Recovery Time Objective (RTO)
Funzioni / Risorse fondamentali
Criticità del processo
10
Business continuity plan Il Business Continuity Plan (BCP) o Piano di continuità aziendale è il documento principale che contiene le attività, le azioni ed i piani relativi alla continuità operativa (business continuity) di un'azienda.
Finalità Si tratta di un piano logistico finalizzato a documentare il modo in cui un'organizzazione può far tornare operative le sue funzioni critiche entro un predeterminato periodo di tempo dopo un disastro o un grave danno. In altri termini il BCP costituisce lo strumento attraverso cui una organizzazione si prepara per futuri incidenti che possono minacciare le sue funzioni vitali e la sua sopravvivenza a lungo termine. Gli incidenti da prevedere sono svariati, tra essi gli incendi, i terremoti o anche malattie epidemiche. Il BCP può essere parte del processo organizzativo attraverso cui si cerca di ridurre il rischio operativo e può essere integrato nelle attività di miglioramento della sicurezza informatica e della gestione del rischio. Nelle grandi organizzazioni i processi di gestione della continuità operativa comprendono anche il cosiddetto disaster recovery (che normalmente è riferito soprattutto al ripristino delle funzionalità dei sistemi informatici) e la gestione delle crisi (che riguarda invece ogni tipo di crisi). Redigere un BCP consente di: Reagire per assicurare il ripristino della situazione ottimale, in caso di processi critici Guidare le scelte in caso di crisi Stabilire le procedure alternative per garantire l'operatività. Minimizzare il tempo di interruzione dei processi aziendali critici. Garantire l'efficacia delle procedure di ripristino.
Efficacia L'efficacia di un BCP si basa sull'accettazione del fatto che esista sempre un elemento di rischio e sul modo di reagire allo stesso, valutandolo, stimandone gli effetti e stabilendo se e come assumerselo. Tutte queste operazioni permettono di garantire la continuità operativa, analizzando e definendo processi essenziali e di supporto, per stabilire un piano di continuità. Nel mondo degli affari lo scenario è molto competitivo e ciò influenza continuamente il business, con fattori endogeni (riassetto organizzativo) ed esogeni (reazioni a cambiamenti del mercato). Pertanto, il BCP è valido solo fino a quando i suoi elementi non cambiano. Detto ciò, si comprende che un piano di continuità nasce dell'esigenza di affidabilità dei sistemi, sia come risposta a problemi IT, sia come disponibilità dei sistemi a supporto dei processi di business. Un piano di continuità aziendale dev'essere continuamente testato ed aggiornato per ottenere la massima aderenza alle esigenze del business. Una soluzione di BC non aggiornata è completamente inutile, in quanto basta una piccola variazione di un qualsiasi componente base del processo per far crollare tutto il piano.
11
La garanzia di successo di un BCP dipende da alcuni fattori connessi tra loro, tra i quali: •
Tempo
•
Aggiornamento continuo delle soluzioni
•
Valutazione continua del rapporto tra costo/complessità della soluzione e tra valore/priorità del business e normativa del processo protetto.
•
Costi complessivi
•
Ampiezza dell'impatto tra le funzioni coinvolte.
Il maggior elemento di criticità, invece, è costituito dal seguire di pari passo l'evoluzione della tecnologia, del mercati e della clientela, tutti fattori in la cui velocità di cambiamento è impressionante. L'unica maniera per ridurre la complessità portandola ad una dimensione gestibile ed efficace, mantenendo costi controllati, è la gradualità nella soluzione sia come numero di processi considerati, sia come profondità e dettaglio dell'analisi. L'aumento tout-court del numero di risorse dedicate (sia interne, che esterne) e del budget economico ha un andamento inferiore rispetto al volume di soluzioni prodotte, in quanto la fruibilità delle soluzioni (condizione necessaria per essere effettivamente tale) rischierebbe di scontrarsi con una struttura non pronta a recepirle e ad attuarle in caso di necessità.
Standard di riferimento Nel dicembre 2006 è stata pubblicata dal British Standards Institute una nuova norma standard, la BS 25999. Prima della sua pubblicazione si faceva riferimento prevalentemente allo standard per la sicurezza informatica BS 7799 che trattava la continuità operativa solo in modo sommario in funzione esclusivamente della gestione della sicurezza informatica. Lo standard BS 25999 si applica a tutte le organizzazioni indipendentemente dal tipo, dimensione e settore di appartenenza, private o pubbliche.
Contenuti del piano Il piano include: •
la descrizione del response team, le responsabilità e l’organizzazione;
•
definizione dello staff di supporto e di coordinamento;
•
individuazione della sede ed equipaggiamento del Centro di emergenza (crisi)
Il BCP può essere anche costituito da più piani dipartimentali integrati tra loro; occorre quindi stabilire meccanismi di manutenzione e integrazione dei vari piani, allocando i vari task e le responsabilità, identificando contatti, fornitori, risorse, canali di comunicazione interna ed esterna. Il piano contiene le procedure di continuità, in particolare i processi mission critical e le funzioni vitali dell’organizzazione, quali sono le risorse disponibili e come devono essere utilizzate per assicurare la continuità. Si indicheranno: •
l'uso e la locazione e protezione di informazioni critiche;
•
gli strumenti di telecomunicazione;
•
i requisiti del personale necessari per garantire il livello prefissato di servizio.
12
Struttura di un piano tipo Il BCP ha una struttura del tipo:
Introduzione •
Obiettivi
•
Responsabilità
•
Esercitazione e manutenzione
Attivazione del piano •
Dichiarazione di disastro o di incidente
•
Valutazione del danno
•
Procedure di azione e continuità
•
Organizzazione del team e responsabilità
•
Centro di Emergenza o Crisi
Comunicazioni •
Soggetti da informare
•
Contatti
•
Messaggi
Fornitori •
Lista dei fornitori di recovery
•
Dettagli dei contratti
Il documento deve essere costantemente aggiornato con la gestione dei processi secondo la logica del Ciclo di Deming.
13
Disaster Recovery Per Disaster Recovery (brevemente DR) si intende l'insieme di misure tecnologiche e organizzative/logistiche atte a ripristinare sistemi, dati e infrastrutture necessarie all'erogazione di servizi di business per imprese, associazioni o enti, a fronte di gravi emergenze che ne intacchino la regolare attività. L'impatto di tali emergenze è tale che si stima che la maggior parte delle grandi imprese spendano fra il 2% ed il 4% del proprio budget IT nella pianificazione della gestione dei disaster recovery, allo scopo di evitare perdite maggiori nel caso che l'attività non possa continuare a seguito della perdita di dati ed infrastrutture IT. Delle imprese che hanno subito disastri con pesanti perdite di dati, circa il 43% non ha più ripreso l'attività, il 51% ha chiuso entro due anni e solo il 6% è riuscita a sopravvivere nel lungo termine. I disastri informatici con ingenti perdite di dati nella maggioranza dei casi provocano quindi il fallimento dell'impresa o dell'organizzazione, ragion per cui investire in opportune strategie di recupero diventa una scelta quasi obbligata.
Disaster Recovery Plan Il Disaster Recovery Plan (DRP) (in italiano, Piano di disaster recovery) è il documento che esplicita tali misure. Esso fa parte del più ampio Business Continuity Plan (BCP). Affinché una organizzazione possa rispondere in maniera efficiente ad una situazione di emergenza, devono essere analizzati:
•
I possibili livelli di disastro
•
La criticità dei sistemi/applicazioni.
Per una corretta applicazione del piano, i sistemi devono essere classificati secondo le seguenti definizioni: Critici Le relative funzioni non possono essere eseguite senza essere sostituite da strumenti (mezzi) di caratteristiche identiche. Le applicazioni critiche non possono essere sostituite con metodi manuali. La tolleranza in caso di interruzione è molto bassa, di conseguenza il costo di una interruzione è molto alto. Vitali Le relative funzioni possono essere svolte manualmente, ma solo per un breve periodo di tempo. Vi è una maggiore tolleranza all'interruzione rispetto a quella prevista per i sistemi critici, conseguentemente il costo di una interruzione è inferiore, anche perché queste funzioni possono essere riattivate entro un breve intervallo di tempo (generalmente entro cinque giorni). Delicati Queste funzioni possono essere svolte manualmente, a costi tollerabili, per un lungo periodo di tempo. Benché queste funzioni possano essere eseguite manualmente, il loro svolgimento risulta comunque difficoltoso e richiede l'impiego di un numero di persone superiore a quello normalmente previsto in condizioni normali. Non-critici Le relative funzioni possono rimanere interrotte per un lungo periodo di tempo, con un modesto, o nullo, costo per l'azienda, e si richiede un limitato (o nullo) sforzo di ripartenza quando il sistema viene ripristinato.
14
Le procedure applicative, il software di sistema ed i file che sono stati classificati e documentati come critici, devono essere ripristinati prioritariamente. Applicazioni, software e file classificati come critici hanno una tolleranza molto bassa alle interruzioni. La criticità di applicazioni, software di sistema e dati, deve essere valutata in funzione del periodo dell'anno in cui il disastro può accadere.
Un piano d'emergenza deve prevedere il ripristino di tutte le funzioni aziendali e non solo il servizio ICT centrale. Per la definizione del DRP devono essere valutate le strategie di ripristino più opportune su: siti alternativi, metodi di back up, sostituzione degli equipaggiamenti e ruoli e responsabilità dei team. La prolungata indisponibilità del servizio elaborativo derivante in particolare situazione di disastro, e quindi dei servizi primari, rende necessario l'utilizzo di una strategia di ripristino in sito alternativo.
Tecniche di Disaster Recovery Allo stato attuale, la tecnologia offre la possibilità di realizzare varie soluzioni di continuità e Disaster Recovery, fino alla garanzia di fatto di un’erogazione continua dei servizi IT, necessaria per i sistemi (es. finanziari o di monitoraggio) definiti mission critical. In pratica i sistemi e i dati considerati importanti vengono ridondati in un "sito secondario" o "sito di Disaster Recovery" per far sì che, in caso di disastro (terremoto, inondazione, attacco terroristico, ecc.) tale da rendere inutilizzabili i sistemi informativi del sito primario, sia possibile attivare le attività sul sito secondario nel più breve tempo e con la minima perdita di dati possibile. Chiaramente quanto più stringenti saranno i livelli di continuità tanto più alti saranno i costi di implementazione della soluzione. In particolare, i livelli di servizio sono usualmente definiti dai due parametri Recovery Time Objective (RTO) e Recovery Point Objective (RPO). Replica sincrona La replica sincrona garantisce la specularità dei dati presenti sui due siti poiché considera ultimata una transazione solo se i dati sono stati scritti sia sulla postazione locale che su quella remota. In caso di evento disastroso sulla sede principale, le operazioni sul sito di Disaster Recovery possono essere riavviate molto rapidamente (basso RTO e RPO praticamente nullo). La replica sincrona è limitata dalla incapacità dell'applicazione di gestire l'impatto del ritardo di propagazione (vincolo fisico quindi, e non tecnologico) sulle prestazioni. In funzione della sensibilità dell'applicazione e della tecnologia di comunicazione tra i due siti, l'efficacia della copia sincrona inizia a diminuire a una distanza variabile tra i 35 km e i 100 km. Replica asincrona Per far fronte al limite di distanza tra i due siti imposto da tecniche sincrone, si ricorre spesso alla tecnica di copia asincrona. In questo caso il sito che si occuperà della replica può trovarsi anche a distanze notevoli. In questo modo è possibile affrontare anche disastri con ripercussioni su larga scala (come ad esempio forti scosse sismiche) che altrimenti potrebbero coinvolgere entrambi i siti (se questi si trovano nelle vicinanze). Un ulteriore vantaggio della copia asincrona è la possibilità di essere implementata via software non dovendo necessariamente ricorrere a sofisticate e costose tecnologie di storage.
15
Fonti e autori delle voci Gestione della continuità operativa Fonte: http://it.wikipedia.org/w/index.php?oldid=56711146 Autori:: Arriano60, Avesan, Condor33, Eumolpo, Giampfrank, Pastore Italy, Squattaturi, Stefanuzz1986, Theirrulez, Veneziano, 11 Modifiche anonime Business continuity plan Fonte: http://it.wikipedia.org/w/index.php?oldid=56303885 Autori:: Ary29, Bultro, Condor33, Cotton, Eumolpo, Giampfrank, Giorces, Jaqen, Phantomas, 4 Modifiche anonime Disaster recovery Fonte: http://it.wikipedia.org/w/index.php?oldid=56556466 Autori:: Alleborgo, Arriano60, Ary29, Avesan, Condor33, Giampfrank, Guam, Hellis, Ignlig, Joana, Marius, Pracchia-78, Protarkus, Qbert88, Sassospicco, Satyr, Veneziano, 35 Modifiche anonime Gestione del rischio Fonte: http://it.wikipedia.org/w/index.php?oldid=58352188 Autori:: Alphamu57, Berto77, Bultro, Condor33, DMor, ErixonBlues1980, Ettore Scarlino, Giovannimacchia, Ilenia stel, Losògià, MattLanf, Mauro742, Pracchia-78, Senpai, Sentruper, Shivanarayana, Tiesse, TintoMeches, Veneziano, Wetto, Yosri, 14 Modifiche anonime
Fonti, licenze e autori delle immagini file:Risk
and
Control
Impact
Assessment.JPG
Fonte:
http://it.wikipedia.org/w/index.php?
title=File:Risk_and_Control_Impact_Assessment.JPG Licenza: Creative Commons Zero Autori:: User:QuiteUnusual
Le piccole guide di TAI Solutions –3 2013 - www.taisolutions.it