I continui attacchi informatici ai quali sono soggette imprese e Pubbliche Amministrazioni rendono evidente la necessità che tutte le organizzazioni sviluppino piani di emergenza per ciascun sistema informativo, al fine di soddisfare le esigenze delle operazioni critiche (i.e. quelle funzionali al business) in caso di interruzione. Il primo passo fondamentale di ogni processo di pianificazione di emergenza è l’analisi d’impatto ziendale (la c.d. BIA: Business Impact Analisys). Vediamo cos’è e come va sviluppata una BIA.
BIA e analisi dei rischi: quali sinergie per predisporre soluzioni di resilienza e recovery
Indice degli argomenti
La pianificazione di emergenza
Le procedure per l’esecuzione di tale capacità devono essere documentate in un piano di emergenza formale che può assumere le caratteristiche di:
- piano di continuità aziendale (c.d. BCP: Business Continuity Plan) che si concentra sul sostegno dei processi aziendali funzionali al raggiungimento degli obiettivi di business (i cc.dd. processi critici);
- piano di continuità operativa (c.d. COOP: Continuity Of Operations Plan) che, in genere, è sviluppato dalle Pubbliche Amministrazioni per recuperare, in tempi brevi, la capacità di offrire servizi ai cittadini. In questo caso l’urgenza potrebbe non essere alta come per le imprese poiché gli Enti pubblici non sono gravati dal rischio di fallimenti;
- piano di ripristino di emergenza (c.d. DRP: Disaster Recovery Plan) che si applica a gravi interruzioni del servizio, solitamente fisiche, che negano l’accesso alla infrastruttura principale e che richiedono il trasferimento dell’operatività in un sito alternativo.
Qualunque sia il piano di emergenza che si va a predisporre, il primo necessario e fondamentale adempimento da porre in essere è l’analisi di impatto aziendale (la c.d. BIA: Business Impact Analisys).
Si tratta di un processo volto a correlare specifici componenti IT con i processi critici (i.e. quelli funzionali al raggiungimento degli obiettivi di business) che gli stessi componenti IT supportano e, conseguentemente, a determinare i requisiti e le priorità per garantire la continuità operativa.
Per la definizione e lo sviluppo della BIA, ENISA fa riferimento alle linee guida NIST Special Publication 800-34 Rev. 1, uno specifico documento rivolto alle organizzazioni federali USA.
Ne riportiamo, di seguito, alcune indicazioni di tali Linee Guida utili a comprendere come poter sviluppare una BIA.
Come condurre l’analisi d’impatto aziendale (BIA)
L’analisi d’impatto aziendale, che è un passo fondamentale nel processo di pianificazione di emergenza in generale, consente all’impresa o alla Pubblica Amministrazione di caratterizzare:
- i componenti del sistema;
- i processi aziendali/la missione supportati;
- le interdipendenze.
Scopo della BIA è quello di correlare il sistema con i processi e i servizi di business critici forniti e, sulla base di tali informazioni, caratterizzare le conseguenze di un’interruzione.
L’impresa o la Pubblica Amministrazione può utilizzare i risultati della BIA per determinare i requisiti e le priorità della pianificazione di emergenza, incorporandoli, poi, opportunamente nell’analisi e negli sforzi di sviluppo della strategia per BCP, COOP e DRP dell’Organizzazione.
In genere il processo di analisi di impatto aziendale si sviluppa nei sottonotati tre passaggi:
- determinazione dei processi aziendali/di missione e della criticità del ripristino;
- identificazione dei requisiti delle risorse;
- identificazione delle priorità di ripristino per le risorse di sistema.
Vediamoli di seguito.
Determinazione dei processi aziendali e della criticità del ripristino
In questo primo momento, vengono identificati i processi aziendali/di missione supportati dal sistema e viene determinato l’impatto di un’interruzione del sistema su tali processi, insieme ai tempi di inattività stimati.
Il tempo di inattività dovrebbe riflettere il tempo massimo che un’organizzazione può tollerare considerando la missione da realizzare.
Un sistema informativo può essere molto complesso e spesso supporta più processi di business o più missioni, con conseguenti diverse prospettive sull’importanza dei servizi o delle capacità del sistema.
Per realizzare l’analisi d’impatto aziendale e comprendere meglio gli impatti che un’interruzione del sistema può avere sull’organizzazione, il soggetto o il team incaricato di sviluppare la BIA dovrebbe collaborare con la direzione e i punti di contatto interni ed esterni per identificare e convalidare i processi aziendali/di missione che dipendono o sono supportati dal sistema informativo.
Gli impatti dei processi identificati vengono quindi ulteriormente analizzati in termini di disponibilità, integrità, riservatezza e livello di impatto stabilito per il sistema informativo.
In particolare, il soggetto o il team incaricato di sviluppare la BIA dovrebbe analizzare i processi aziendali/di missione supportati e, insieme ai responsabili di detti processi e al C-Level, determinare il tempo di inattività accettabile per un determinato processo che sia stato interrotto.
I tempi di inattività possono essere identificati nei sottonotati diversi modi.
Tempo di inattività massimo tollerabile
Il MTDT (Maximum Tolerable DownTime) rappresenta la quantità di tempo totale che l’impresa o la Pubblica Amministrazione proprietaria del sistema è disposta ad accettare per l’interruzione di un processo aziendale o di una missione e include tutte le considerazioni sull’impatto. Determinare il MTDT è importante perché fornisce al soggetto o al team incaricato di sviluppare la BIA, utili indicazioni circa:
- la selezione di un metodo di ripristino appropriato;
- la profondità dei dettagli che saranno richiesti durante lo sviluppo delle procedure di ripristino, inclusi il loro ambito e contenuto.
Obiettivo del tempo di recupero
Il RTO (RTO: Recovery Time Objective) definisce la quantità massima di tempo entro il quale una risorsa di sistema può rimanere non disponibile prima che si verifichi un impatto inaccettabile su altre risorse di sistema oppure sui processi aziendali/di missione supportati e sull’MTDT.
Determinare il RTO è importante per selezionare le tecnologie appropriate che sono più adatte a soddisfare il MTDT. Attenzione: il RTO, poiché deve garantire che il MTDT non venga superato, deve normalmente essere sempre più breve dello stesso MTDT.
Obiettivo del punto di ripristino
Il RPO (RPO: Recovery Point Objective) rappresenta il momento, prima di un’interruzione del sistema, i.e. il momento in cui i dati processo aziendale/ di missione possono essere ripristinati (data la copia di backup più recente dei dati) dopo un’interruzione.
A differenza del RTO, il RPO non è considerato parte di MTDT. Piuttosto, è un fattore utile a comprendere quanta perdita di dati può tollerare la missione/il processo aziendale durante il processo di ripristino (i.e. il c.d. MTDL: Maximum Tollerance Data Loss).
Il bilanciamento dei costi
Il soggetto o il team incaricato di sviluppare la BIA, in collaborazione con la direzione, dovrebbe determinare il punto ottimale per ripristinare il sistema informativo affrontando i fattori sopra menzionati, bilanciando il costo dell’inoperabilità del sistema con il costo delle risorse necessarie per ripristinare il sistema stesso e il suo supporto complessivo a missioni/attività critiche/processi.
Si consideri che più breve è il RTO, più costose sono le soluzioni di recupero da implementare. Ad esempio, se il sistema deve essere ripristinato immediatamente, le soluzioni senza tempo di inattività e i costi del sito di elaborazione alternativo saranno molto più elevati, mentre un basso impatto sul sistema con un RTO più lungo comporterebbe l’implementazione di un semplice sistema di backup su nastro, meno costoso.
Identificazione dei requisiti delle risorse
In questo secondo momento, gli sforzi di recupero realistici richiedono una valutazione approfondita delle risorse che sono necessarie per riprendere, il più rapidamente possibile, i processi aziendali/di missione e le relative interdipendenze.
Esempi di risorse che dovrebbero essere identificate includono:
- strutture,
- personale,
- attrezzature,
- software,
- file di dati,
- componenti di sistema,
- record vitali.
Lavorando con la direzione e con i punti di contatto interni ed esterni associati al sistema, Il soggetto o il team incaricato di sviluppare la BIA dovrebbe garantire che le risorse dell’intero sistema informativo siano identificate.
Identificazione delle priorità di ripristino per le risorse di sistema
Sulla base dei risultati delle attività precedenti, le risorse di sistema possono essere collegate in modo più chiaro a processi e funzioni aziendali/missione critiche. È possibile così stabilire livelli di priorità per la sequenza delle attività e delle risorse di recupero.
Lo sviluppo delle priorità di ripristino è l’ultimo passaggio del processo di sviluppo di una BIA. Le priorità di ripristino possono essere stabilite in modo efficace prendendo in considerazione:
- la criticità dei processi aziendali/di missione;
- gli impatti delle interruzioni;
- i tempi di inattività tollerabili;
- le risorse di sistema.
Il risultato sarà una gerarchia di priorità di ripristino del sistema informativo che il soggetto o il team incaricato di sviluppare la BIA dovrebbero prendere in considerazione per portare a termine il processo di analisi.
Misure di mitigazione. I controlli preventivi
In alcuni casi, gli impatti di un’interruzione dell’operatività identificati nella BIA possono essere mitigati o eliminati attraverso misure preventive che scoraggiano, rilevano e/o riducono gli impatti sul sistema.
Laddove sia possibile ed economicamente vantaggioso, i metodi preventivi sono preferibili alle azioni che potrebbero essere necessarie per ripristinare il sistema dopo un’interruzione. Questa fase include l’identificazione di efficaci controlli preventivi di pianificazione di emergenza e il mantenimento di tali controlli su base continuativa.
Alcune misure comuni sono elencate di seguito:
- gruppi di continuità opportunamente dimensionati per fornire alimentazione di backup a breve termine a tutti i componenti del sistema (compresi i controlli ambientali e di sicurezza);
- generatori a benzina o diesel per fornire energia di riserva a lungo termine;
- impianti di condizionamento dell’aria con un’adeguata capacità in eccesso per prevenire il guasto di alcuni componenti, come un compressore;
- sistemi antincendio;
- rilevatori di fuoco e fumo;
- sensori d’acqua nel soffitto e nel pavimento della sala computer;
- contenitori resistenti al calore e impermeabili per supporti di backup e documenti vitali non elettronici;
- interruttore di arresto del sistema principale di emergenza;
- archiviazione fuori sede di supporti di backup, record non elettronici e documentazione di sistema;
- controlli tecnici di sicurezza, come la gestione delle chiavi crittografiche;
- backup pianificati frequenti, inclusa la posizione in cui sono archiviati i backup (in loco o fuori sede).
