BCP e DRP: pianificare l'interruzione e il ripristino

La Business Continuity Planning (BCP) e la Disaster Recovery Planning (DRP) sono discipline correlate ma distinte. La BCP si concentra sul mantenimento delle operazioni aziendali durante un'interruzione, attraverso processi manuali, sedi alternative o modalità di servizio degradate. La DRP si concentra specificamente sul ripristino dei sistemi e dell'infrastruttura IT dopo un disastro. La BCP è l'ambito più ampio: la DRP è una componente della BCP che gestisce l'aspetto del ripristino tecnologico. Entrambi i piani devono essere documentati, testati e mantenuti aggiornati.

BCP e DRP vengono attivate da eventi dirompenti che superano la normale risposta agli incidenti operativi. Tra i fattori di attivazione rientrano: attacchi ransomware che crittografano i sistemi critici, disastri naturali (alluvioni, terremoti o tornado che danneggiano il data center principale), guasti dell'infrastruttura (interruzioni prolungate dell'alimentazione o del servizio ISP), pandemie o emergenze di sanità pubblica (il COVID-19 ha dimostrato l'importanza dei piani di continuità del lavoro da remoto) e interruzioni della catena di approvvigionamento che impediscono di ottenere hardware sostitutivo.

Una Business Impact Analysis (BIA) è il documento fondamentale sia per il BCP sia per il DRP. Identifica: quali processi aziendali sono critici e devono continuare a qualsiasi costo, quali processi sono importanti ma possono tollerare ritardi, l'impatto finanziario e operativo dell'inattività per ciascun processo (perdita di ricavi oraria, sanzioni normative, danni alla reputazione) e il massimo tempo di inattività tollerabile per ciascun processo. I risultati della BIA determinano direttamente gli obiettivi RTO e RPO che definiscono i requisiti di ripristino tecnologico.

Quando viene dichiarata una situazione di emergenza, si attiva un Crisis Management Team (CMT), che assume l'autorità sulla risposta dell'organizzazione. Il CMT comprende i vertici aziendali e rappresentanti dei reparti IT, legale, comunicazione, risorse umane e gestione delle strutture. Il CMT segue una Incident Command Structure (ICS) predefinita, che assegna ruoli chiari: chi prende le decisioni sul ripristino, chi comunica con clienti e media, chi si coordina con fornitori e autorità di regolamentazione e chi si occupa del benessere del personale. Strutture di comando chiare prevengono il caos e gli errori di comunicazione che amplificano l'impatto di una situazione di emergenza.

Il BCP si basa generalmente su siti alternativi per riprendere le operazioni quando il sito primario non è disponibile. Un hot site è una struttura duplicata completamente attrezzata, sincronizzata continuamente e in grado di subentrare nel giro di pochi minuti. Un warm site dispone di apparecchiature e alimentazione elettrica, ma richiede da alcune ore a diversi giorni per caricare i dati e configurare i sistemi. Un cold site è una struttura vuota con alimentazione elettrica e connettività: le apparecchiature devono essere spedite e installate, con tempi da alcuni giorni a diverse settimane. Gli hot site hanno costi significativamente maggiori, ma riducono al minimo i tempi di inattività dei processi critici.

Gli accordi di mutua assistenza sono contratti tra organizzazioni per fornirsi assistenza durante le situazioni di emergenza. Le forme più comuni includono: gli accordi reciproci (due organizzazioni accettano di ospitare le operazioni dell'altra se una delle due viene colpita da una situazione di emergenza), i fornitori di servizi DR di terze parti (aziende come Sungard o IBM offrono strutture di disaster recovery come servizio) e le organizzazioni di mutua assistenza del settore (aziende di servizi pubblici, banche e sistemi sanitari dispongono di reti formali per condividere risorse durante emergenze regionali). Gli accordi di mutua assistenza devono essere riesaminati annualmente e attivati durante le esercitazioni.

I piani di comunicazione sono una componente essenziale del BCP. Durante una situazione di emergenza, i normali canali di comunicazione potrebbero non essere disponibili (server e-mail fuori servizio, telefoni dell'ufficio non disponibili). I piani devono includere: elenchi dei contatti di emergenza con i numeri di cellulare personali, canali di comunicazione out-of-band (Slack, istanza di backup di Teams, e-mail personale), procedure di notifica ai clienti (pagine di stato, social media, e-mail dirette), obblighi di notifica alle autorità di regolamentazione (leggi sulla notifica delle violazioni dei dati, autorità di vigilanza finanziaria) e rapporti con i media per gestire le comunicazioni pubbliche.

Una documentazione BCP efficace comprende diversi componenti fondamentali: la BIA (identifica i processi critici e il massimo tempo di inattività tollerabile), il BCP stesso (procedure dettagliate per mantenere le operazioni), il DRP (procedure di ripristino IT), le directory dei contatti di emergenza, gli elenchi dei contatti dei fornitori (provider cloud, ISP, fornitori chiave), la documentazione assicurativa e le procedure di notifica alle autorità di regolamentazione. Tutti i documenti devono essere archiviati in luoghi accessibili quando i sistemi primari non sono disponibili: copie stampate, archiviazione cloud sicura con accesso offline oppure unità USB in possesso del personale chiave.

Il COVID-19 ha rivelato che la maggior parte dei piani BCP non affrontava adeguatamente gli scenari pandemici, nei quali la situazione di emergenza non è localizzata, ma interessa contemporaneamente tutte le sedi. Le principali lezioni apprese sono: assicurarsi che l'infrastruttura VPN sia dimensionata per supportare da remoto il 100% della forza lavoro (non solo il 20-30% ipotizzato dai progetti precedenti alla pandemia), implementare strumenti di collaborazione basati sul cloud che funzionino senza infrastruttura on-premises, verificare che i processi critici possano essere completati interamente da remoto e garantire la continuità della supply chain per l'hardware quando è necessario allestire rapidamente gli uffici nelle abitazioni dei dipendenti.

Un BCP che non è mai stato testato è destinato a fallire durante una vera situazione di emergenza. Gli approcci di test regolari includono: esercitazioni tabletop (analisi guidate basate sulla discussione con il personale chiave, senza attivare i sistemi), esercitazioni funzionali (attivazione effettiva delle catene di comunicazione e di procedure di ripristino parziali), test su scala reale (trasferimento delle operazioni al sito alternativo e gestione dell'attività da lì per un determinato periodo) e revisioni post-incidente per aggiornare il piano sulla base dell'esperienza reale. I piani devono essere riesaminati annualmente e aggiornati dopo ogni modifica significativa dell'infrastruttura.

Molti settori regolamentati impongono l'adozione di BCP e DRP. HIPAA richiede alle entità soggette alla normativa di disporre di piani di emergenza che includano procedure per il backup dei dati, il DR e il funzionamento in modalità di emergenza. PCI-DSS richiede piani di risposta agli incidenti e procedure di continuità operativa per i sistemi nell'ambito di applicazione. FINRA e le autorità di vigilanza bancaria richiedono un BCP dettagliato, con test annuali e presentazione agli organi di regolamentazione. Le compagnie di assicurazione contro i rischi informatici richiedono sempre più spesso un BCP documentato e testato come condizione per la copertura e possono rifiutare i risarcimenti se, al verificarsi di un evento coperto, i piani sono assenti o non sono stati testati.

Verifichi la Sua comprensione dei concetti di CompTIA Security+ (SY0-701) trattati in questa lezione.

In questa lezione ha appreso che: il BCP mantiene operative le attività aziendali durante le interruzioni, mentre il DRP ripristina i sistemi IT; la Business Impact Analysis identifica i processi critici e il massimo tempo di inattività tollerabile, determinando i requisiti di ripristino; e i siti alternativi (hot, warm e cold) offrono diversi livelli di velocità e costi di ripristino per riprendere le operazioni quando il sito primario non è disponibile. Nella prossima sezione esamineremo RTO, RPO e MTTR, le metriche specifiche che quantificano gli obiettivi di ripristino.