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, in caso di interruzione. Il primo passo fondamentale di ogni processo di pianificazione di emergenza è l’analisi d’impatto aziendale (la c.d. BIA: Business Impact Analisys). Vediamo cos’è e come va sviluppata una BIA.

Le procedure per l’esecuzione di tale capacità devono essere documentate in un piano di emergenza formale che può assumere le caratteristiche di:

1. 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);
2. 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;
3. 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 (BIA: Business Impact Analisys).

Si tratta di un processo volto a correlare specifici componenti IT con i processi critici e, conseguentemente, a determinare i requisiti e le priorità per garantire la continuità operativa.

Per la definizione e lo sviluppo della BIA, ENISA (Agenzia Europea per la Cybersicurezza) fa rimerimento 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 un’Analisi di Impatto (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:

1. i componenti del sistema;
2. i processi aziendali/la missione supportati;
3. 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 possono utilizzare i risultati della BIA per determinare i requisiti e le priorità della pianificazione di emergenza.

In genere, il processo di analisi di impatto aziendale si sviluppa in 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.

Eccoli di seguito.

Determinazione dei processi aziendali e delle criticità del ripristino

In questo primo momento, vengono identificati i processi aziendali 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.

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.

Obbiettivo del tempo di recupero

Il 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.

Obbiettivo del tempo 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 del 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.

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

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.

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.

Alcune misure comuni sono elencate di seguito:

1. 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);
2. generatori a benzina o diesel per fornire energia di riserva a lungo termine;
3. impianti di condizionamento dell’aria con un’adeguata capacità in eccesso per prevenire il guasto di alcuni componenti, come un compressore;
4. sistemi antincendio;
5. rilevatori di fuoco e fumo;
6. sensori d’acqua nel soffitto e nel pavimento della sala computer;
7. contenitori resistenti al calore e impermeabili per supporti di backup e documenti vitali non elettronici;
8. interruttore di arresto del sistema principale di emergenza;
9. archiviazione fuori sede di supporti di backup, record non elettronici e documentazione di sistema;
10. controlli tecnici di sicurezza, come la gestione delle chiavi crittografiche;
11. backup pianificati frequenti, inclusa la posizione in cui sono archiviati i backup (in loco o fuori sede).