Questo sito web utilizza cookie tecnici e, previo Suo consenso, cookie di profilazione, nostri e di terze parti. Chiudendo questo banner, scorrendo questa pagina o cliccando qualunque suo elemento acconsente all'uso dei cookie. Leggi la nostra Cookie Policy per esteso.OK

strategie

Resilienza, contro gli attacchi informatici: linee guida per le aziende

Sono ancora poche le organizzazioni, le aziende e le pubbliche amministrazioni che hanno fra i loro obiettivi l’essere resilienti, cioè in grado di resistere a un attacco informatico. Linee guida e consigli per raggiungere una perfetta resilienza

08 Ott 2018
B

Giancarlo Butti

Auditor, Esperto privacy, Autore, Docente


La capacità di resistere a un attacco è una prerogativa che può garantire la sopravvivenza di un’organizzazione. Sono tuttavia ancora poche le organizzazioni che hanno fra i loro obiettivi la resilienza e l’essere resilienti.

Diffusa è infatti la convinzione che difficilmente la propria organizzazione possa costituire l’obiettivo di un attacco terroristico o di un cyber attacco.

In realtà le notevoli interdipendenza e interconnessioni oggi esistenti fra i vari attori della vita civile e produttiva rendono le organizzazioni sempre più vulnerabili anche a questi eventi. È quindi opportuno comprendere quali siano le strategie utili ad aumentare la resilienza di una organizzazione.

Il concetto di resilienza

Il concetto di resilienza di una organizzazione si può mutuare dalle definizioni che di tale termine danno i maggiori dizionari, come il Treccani:

  1. Nella tecnologia dei materiali, la resistenza a rottura per sollecitazione dinamica, determinata con apposita prova d’urto: prova di r.; valore di r., il cui inverso è l’indice di fragilità.
  2. Nella tecnologia dei filati e dei tessuti, l’attitudine di questi a riprendere, dopo una deformazione, l’aspetto originale.
  3. In psicologia, la capacità di reagire di fronte a traumi, difficoltà ecc.

o il Garzanti:

  1. (fis.) proprietà dei materiali di resistere agli urti senza spezzarsi, rappresentata dal rapporto tra il lavoro necessario per rompere una barretta di un materiale e la sezione della barretta stessa.
  2. Capacità di resistere e di reagire di fronte a difficoltà, avversità, eventi negativi ecc.: resilienza sociale.

Di entrambe le definizioni prendiamo in considerazione l’ultimo capoverso, che considera la resilienza come la capacità di reagire di fronte ad un evento avverso. useremo questo concetto per descrivere la capacità di un’organizzazione di sopravvivere a un attacco terroristico di tipo tradizionale o cyber e in tale contesto tale concetto appare quasi sinonimo di quello di continuità operativa.

In realtà un’organizzazione dovrebbe essere resiliente anche rispetto a molte altre tipologie di avversità, quali potrebbero essere la congiuntura economica, l’evoluzione del mercato, i cambiamenti tecnologici.

Essere resilienti per resistere a un attacco

Com’è noto il rischio è un prodotto fra la probabilità di accadimento di un evento avverso e il danno provocato a un’organizzazione nel caso in cui l’evento abbia effettivamente luogo.

La probabilità di accadimento è a sua volta funzione di altri fattori, quali ad esempio la presenza di vulnerabilità intrinseche, la presenza di minacce, la predisposizione di adeguate contromisure.

Oltre alla tradizionale formula del rischio:

RISCHIO = PROBABILITÀ x DANNO

si possono reperire in letteratura formule più complesse, nelle quali compaiono altri fattori, come quelli appena citati e il rischio viene rappresentato come una funzione di tali fattori:

RISCHIO = f(Probabilità, Danno, Vulnerabilità, Minacce)

In realtà le due formule sono sostanzialmente analoghe, ma nella seconda sono esplicitati fattori che nella prima sono impliciti, quali minacce e vulnerabilità.

La valutazione del proprio grado di esposizione è legata al tipo di minaccia.

Nel caso di minacce determinate da eventi naturali (un terremoto, un uragano…) queste sono intrinseche nella collocazione dell’organizzazione e determinabili come probabilità di accadimento dai dati storici (se esistenti) o mediante strumenti matematici.

Per quanto attiene le minacce determinate da azioni volontarie, come appunto un attacco terroristico, queste dipendono da un lato dall’appetibilità dell’organizzazione (quali vantaggi otterrebbe l’attaccante colpendo l’organizzazione) e dall’altro dalla facilità con cui l’attaccante può raggiungere il suo scopo.

Poiché è difficile rendere poco appetibile la propria organizzazione agli occhi di un potenziale attaccante se questa lo è intrinsecamente (ad esempio un’infrastruttura critica), si deve operare mediante l’adozione di opportune contromisure, al fine di rendere un attacco il più possibile difficile, costoso e inefficace.

Purtroppo le organizzazioni non hanno una chiara idea di quanto possano essere appetibili a un tale tipo di attacco e valutano che solo le grosse istituzioni o le infrastrutture critiche possano costituire un bersaglio da colpire (In questo articolo si tratta specificatamente di attacchi e non anche di azioni terroristiche di altra natura, quali ad esempio l’alterazione di prodotti di un’organizzazione –prodotti alimentari per la GDO – che hanno la finalità di ledere l’immagine di una organizzazione o finalità estorsive).

Resilienza: le valutazioni giuste per saper resistere ad un attacco

È tuttavia necessario considerare due diversi fattori in questa valutazione.

Il primo riguarda specificatamente i cyber attacchi (i quali non necessariamente sono attacchi con finalità terroristiche) che, come mostrano i dati reperibili in letteratura (Rapporto CLUSIT sulla sicurezza ICT in Italia, CLUSIT edizioni 2016 e 2017), non solo sono in costante aumento, ma sono anche largamente diffusi in tutti i settori oltre che diretti verso le organizzazioni di qualunque dimensione.

Il secondo aspetto riguarda dipendenze e interconnessioni che sempre di più legano fra loro le varie organizzazioni e che si ripercuotono anche sulla probabilità di un attacco.

Diverse sono le tipologie di attacco che un’organizzazione può subire, così come le relative conseguenze.

Si può andare dalla distruzione fisica di edifici, impianti, infrastrutture ottenute mediante un ordigno esplosivo o più semplicemente mediante un incendio provocato ad arte, alla temporanea indisponibilità e inagibilità di un sito produttivo ad esempio mediante l’uso di sostanze contaminanti.

Periodi limitati d’inagibilità di una struttura possono essere ottenuti da un attaccante anche con un impegno molto limitato, con una semplice telefonata e un falso allarme bomba. In questo particolare momento storico, infatti, anche la semplice ipotesi di essere sotto attacco può avere ripercussioni imprevedibili, come i recenti fatti di Torino hanno dimostrato.

Oltre agli attacchi diretti all’organizzazione è possibile per l’attaccante ottenere risultati più o meno significativi intervenendo sulle infrastrutture a servizio dell’organizzazione (distruggendo ad esempio le cabine di alimentazione elettrica o per le comunicazioni) o sulla catena di fornitura.

Non vanno poi dimenticati gli attacchi portati a un’organizzazione operando sulle sue figure chiave, che non necessariamente sono i vertici della stessa, ma possono essere i soggetti senza i quali l’organizzazione stessa non può operare. Anche in questo caso l’attaccante ha ampia e di solito facile scelta nel poter operare. Tali soggetti (e i loro familiari, nel caso in cui la tecnica di attacco non consista nel rendere indisponibile la figura chiave, ma nel suo uso pilotato) sono infatti raramente soggetti a una qualche forma di protezione.

Ulteriore tipologia di soggetti che possono essere utilizzati sotto costrizione come strumento di attacco sono quelle figure che, pur non essendo figure chiave nel senso prima espresso, svolgono una attività che consente loro di arrecare un grave danno all’organizzazione (ad esempio un amministratore di sistema).

Un caso a parte meritano gli attacchi cyber in quanto, come vedremo oltre, la loro gestione non può avvalersi esclusivamente delle comuni tecniche di resilienza dei sistemi informativi (traducibile in alta affidabilità/disponibilità).

Resistere ad un attacco contro obiettivi esterni connessi all’organizzazione

Fino a questo momento sono stati analizzati i soli casi nei quali sia l’organizzazione stessa a essere l’obiettivo mirato di un attacco.

Proprio in virtù dei principi di dipendenza e interconnessione sempre più spinti che contraddistinguono la nostra realtà, un’organizzazione può subire pesanti ripercussioni anche da un attacco terroristico che abbia come obiettivo soggetti direttamente (o anche indirettamente) a essa connessi.

Un attacco a un’infrastruttura critica potrebbe avere ripercussioni su una pluralità di organizzazioni (in particolare le linee di trasporto dell’energia, quali tralicci o oleodotti, sono da sempre un obiettivo facile da colpire e difficili da presidiare) per tempi più o meno prolungati.

Anche eventi apparentemente lontani dagli interessi di un’organizzazione possono in realtà inficiarne la capacità operativa. Si pensi ad esempio a un attacco portato a un centro commerciale nel quale siano coinvolte una o più figure chiave di un’organizzazione.

Le probabilità che una qualunque organizzazione possa subire delle ripercussioni in seguito ad un attacco terroristico sono quindi molto maggiori di quanto le stesse siano tradizionalmente portate a pensare.

Del resto, se già la cultura della sicurezza appare scarsa nella maggior parte delle organizzazioni, quella della resilienza appare per lo più assente e solo grazie a una normativa sempre più attenta a tale aspetto si iniziano a vedere alcuni risultati anche se limitati ad ambiti molto settoriali (Il sistema bancario italiano, ad esempio, dispone dal 2004 di una specifica normativa sulla continuità operativa, oggi parte integrante della Circolare 285 di Banca d’Italia. Il Codice per l’Amministrazione Digitale ha introdotto con l’articolo 50-bis l’obbligo della Continuità operativa per le PA: tale previsione non è presente nel CAD attualmente in vigore).

Esempi di attacchi diretti e indiretti che possono avere impatto su un’organizzazione.

Implementare la continuità operativa

La continuità operativa di un’organizzazione è sempre più spesso condizionata dal corretto funzionamento del suo sistema informativo.

Riveste quindi un ruolo particolarmente importante la continuità dei servizi IT.

Al riguardo, ad esempio, il settore bancario ha una specifica normativa dal 2004; in seguito altri settori, come la PA, hanno emesso specifiche normative sulla continuità operativa.

Va precisato che entrambe le normative, pur dando larga enfasi alla continuità del sistema informativo, hanno come punto di attenzione la continuità della organizzazione nel suo complesso, anche per le parti non strettamente IT.

È in tale contesto che fanno la loro comparsa termini come Alta affidabilità (alta disponibilità), Disaster Recovery (nel seguito DR) e Business Continuity (nel seguito BC) che pur esprimendo concetti molto diversi fra loro, sono tutti orientati a garantire la continuità di un servizio (vedi la tabella 2). È assolutamente fondamentale che questi termini siano condivisi nel loro significato fra tutti gli attori, siano essi interni o esterni, coinvolti nella progettazione, realizzazione e gestione di una soluzione atta a garantire la resilienza di un’organizzazione.

Tabella 1 – I termini della continuità operativa

keyboard_arrow_right
keyboard_arrow_left
Alta affidabilità (alta disponibilità), disaster recovery e business continuity, esprimono concetti molto diversi fra loro, anche se strettamente connessi, in quanto tutti orientati a garantire la continuità di un servizio.
Alta affidabilitàLa capacità di un sistema di resistere a situazioni locali di guasto, tali da consentire la continuità nell’erogazione del servizio. Questo risultato si ottiene con accorgimenti tesi a ridurre le conseguenze della perdita, ad esempio, di un singolo componente di un server (disco, alimentatore, scheda di rete….), di un server completo, di un apparato di rete, di un intero locale CED.
Disaster RecoveryIl DR ha la finalità di garantire la ripartenza dei servizi informatici di un’organizzazione in seguito all’accadere di un qualsiasi disastro.

La definizione di disastro è arbitraria, avendo come unico punto di confluenza le situazioni che portano alla distruzione (o inagibilità) del sito primario.

Business ContinuityCome il nome stesso porta a intuire la BC si occupa della continuità del business.

Si tratta di un tema più ampio e complesso della semplice capacità di ripristinare il sistema informativo di un’organizzazione e comprende altri elementi quali edifici e persone.

Alta affidabilità: garantire la continuità di erogazione di un servizio

Per Alta Affidabilità si intende la capacità di un sistema di resistere a situazioni locali, anche estese di guasto (perdita di un singolo componente di un server: disco, alimentatore, scheda di rete…, di un intero server, di un apparato di rete, di un intero locale CED), tali da consentire la continuità nell’erogazione del servizio.

Le soluzioni normalmente adottate si basano sulla duplicazione degli elementi e sulla predisposizione di infrastrutture in grado di contrastare i rischi più comuni (mancanza di alimentazione, incendio, allagamento…). Si va dalla semplice ridondanza dei componenti, fino alla replica di un intero gruppo di server o alla replica di interi locali CED, collocandoli in posizioni tra loro più o meno geograficamente distanti.

La ridondanza può comprendere gli impianti di alimentazione elettrica, il cablaggio di rete, i sistemi di condizionamento e tutti gli altri apparati che servono a garantire il corretto funzionamento degli apparati IT, gli apparati di rete e la rete geografica (instradata su percorsi diversi e spesso di differenti operatori). Il tutto commisurato ovviamente al risultato che si desidera ottenere e al rapporto fra i costi e i benefici attesi.

In una piccola/media organizzazione è già molto se vi è una ridondanza di server, mentre in una banca non è raro trovare duplicate intere stanze del CED, nello stesso edificio o in edifici vicini in un campus di dimensioni limitate (il confine fra Alta Affidabilità e DR in questi casi può essere molto labile e limitarsi alla semplice definizione). Questo consente ovviamente di mantenere con facilità un sincronismo dei dati, che sono duplicati o replicati nel continuo due o più volte sui vari dispositivi di storage.

La ridondanza dei vari apparati può essere molto costosa, ma è assolutamente indispensabile evitare che esistano componenti non ridondati il cui guasto possa compromettere tutta l’architettura.

Altro aspetto molto importante è la corretta progettazione e disposizione dei vari elementi (ad esempio è poco utile avere due router, di cui uno sia il backup dell’altro, posizionati nello stesso rack).

Altri errori da evitare sono ad esempio il posizionamento delle batterie tampone all’interno del CED, il posizionamento di apparecchiature elettriche sotto un condizionatore che potrebbe perdere liquidi, la mancanza di un accordo formalizzato con un fornitore per un rifornimento garantito di carburante anche nel week end, la mancata ridondanza dell’impianto di condizionamento e via dicendo.

Mentre una grossa organizzazione dispone probabilmente di una propria autonoma sede, molte realtà anche significative hanno la loro sede in edifici condivisi con altre organizzazioni, il cui livello di sicurezza non è noto a priori. In un contesto di promiscuità con altre organizzazioni vanno quindi valutati molti altri fattori; ad esempio il fatto che il proprio CED possa essere allagato da infiltrazioni d’acqua dei locali soprastanti, o che il proprio personale debba essere sgombrato a causa di un incendio al piano sottostante (Un attentato a un locale al piano terra dell’edificio in cui era collocato il mio ufficio, posizionato al terzo piano, ha reso impossibile l’accesso ai nostri locali per alcuni giorni, pur in assenza di alcun danno materiale. Il fumo particolarmente denso provocato dall’incendio era infatti penetrato nei locali depositando uno strato di polvere e rendendo l’aria irrespirabile).

Il CED dovrebbe essere raggiungibile e gestibile il più possibile da remoto, onde evitare un’interruzione del servizio derivante dalla irraggiungibilità o inagibilità fisica dello stesso.

Chi progetta l’Alta Affidabilità pensa solitamente che sia sufficiente garantire che gli apparati del CED possano restare operativi anche in situazioni critiche.

Raro è infatti il caso che vengano posti sotto gruppo di continuità le postazioni utente o l’illuminazione degli uffici, con la conseguenza che i servizi del CED sono attivi, senza che però nessuno li possa utilizzare.

In fase di progettazione di una soluzione in Alta Affidabilità del proprio sistema informativo sarà quindi necessario prendere in considerazione l’intera catena degli elementi che possano garantire un servizio per l’utente finale. Le tabelle 2 e 3 riepilogano alcuni degli aspetti che è necessario considerare per garantire l’Alta affidabilità.

Tabella 2 – Elementi per garantire l’alta affidabilità di un CED

keyboard_arrow_right
keyboard_arrow_left
Ridondanza componenti
  • Server
  • Componenti dei server
    • Dischi
    • Alimentatori
    • Schede
  • Apparecchiature di rete
  • Dati
Ridondanza impianti
  • Alimentazione elettrica
    • CED
    • Postazioni utenti essenziali per il business
    • Illuminazione delle postazioni e luoghi essenziali per il business
  • Condizionamento CED
  • Rete interna
  • Connettività esterna
Misure di protezione
  • Antincendio
  • Anti intrusione
Raggiungibilità
  • Controllo del CED da remoto

Tabella 3 – Elementi per garantire l’alta affidabilità di una postazione di lavoro informatizzata

keyboard_arrow_right
keyboard_arrow_left
Garantire i servizi elementari dell’edificio
  • Acqua
  • Riscaldamento
Garantire i servizi essenziali per il business
  • Alimentazione elettrica
  • Illuminazione
  • Rete
  • Comunicazioni
Garantire la possibilità di accesso remoto e telelavoro
  • VPN
  • Smart working

Le soluzioni per il disaster recovery

L’Alta Affidabilità non è un’alternativa al DR e non va con questo confusa. Un danneggiamento esteso, che comprometta il corretto funzionamento del sito primario (o la sua agibilità), richiederà necessariamente la disponibilità di un sito alternativo dove poter ripartire. Una copia di dati, sistemi, applicazioni, configurazioni e relativa documentazione dovrà quindi essere sempre disponibile e utilizzabile, in un luogo adeguatamente lontano dal sito principale.

Tra la situazione estrema e quella di regolare erogazione dei servizi ci sono molti stadi intermedi, che andrebbero definiti e valutati a priori, in modo da non lasciare incertezze nella corretta gestione dei casi di emergenza.

L’attivazione del piano di DR è infatti un’attività molto rischiosa e spesso senza ritorno, che quindi va effettuata con le dovute cautele: si attivano le azioni di DR proprio quando non è possibile farne a meno.

Nella pratica esistono inoltre diverse situazioni di malfunzionamento del sistema informativo per le quali né l’Alta Affidabilità, né il DR costituiscono un rimedio.

Oltre alle già citate problematiche che possono derivare da un attacco cyber, anche un semplice malfunzionamento di un applicativo può bloccare per ore l’erogazione di un servizio IT. Questo aspetto va adeguatamente valutato al fine di distinguere la vera emergenza dalla normale operatività. Nelle due situazioni, anche se apparentemente simili come risultato finale (una mancata erogazione del servizio) possono valere regole operative e ruoli gerarchici diversi.

Per quanto attiene alle possibili soluzioni per il DR, queste variano moltissimo, in funzione della architetture, dei tempi di ripristino richiesti, dei budget allocati (si veda al riguardo la tabella 4).

Per una piccola/media organizzazione il DR può essere costituito dalla copia di dati, applicazioni, configurazioni e da un adeguato contratto di assistenza che consenta di ripristinare nel più breve tempo possibile l’uso di server e apparecchiature, installandovi le copie dei dati e del software precedentemente salvati.

La cosa più importante in questo caso è disporre dell’opportuna documentazione di tutte le configurazioni presenti.

Per massimizzare la possibilità di ripristino della operatività è utile in questi casi concentrare in un unico repository tutti i file vitali per l’organizzazione, siano essi costituiti da data base o archivi destrutturati, ivi inclusi tutti quelli creati con i tool di produttività individuale. La policy dell’organizzazione deve vietare agli operatori di poter salvare file indispensabili per lo svolgimento del proprio lavoro sulle proprie postazioni individuali (condizione questa che si può effettivamente verificare solo in fase di test). Le organizzazioni, anche le più grandi, fanno un larghissimo uso di applicazioni realizzate direttamente dagli utenti mediante strumenti di produttività individuale, di norma non censite e della cui importanza si ha evidenza solo quando non sono più disponibili.

Per le organizzazioni di grosse dimensioni, o meglio per l’organizzazione che ha Data Center significativi il problema è molto più articolato; sono infatti sufficienti pochi elementi non replicati o non aggiornati (e quindi non allineati) per rischiare di vanificare tutto il lavoro svolto o quantomeno per richiedere significative attività di analisi e operativa per riattivare il corretto funzionamento del CED. È al riguardo indispensabile un consistente e aggiornato apparato documentale, che consenta di avere sotto controllo tutti i componenti che costituiscono il CED, le loro configurazioni, le loro interdipendenze. Tale documentazione deve essere sempre accessibile e quindi non deve essere conservata sugli stessi server che è necessario ripristinare.

È pertanto necessario predisporre un vero e proprio piano di DR nel quale occorre specificare dettagliatamente gli strumenti da adottare e le azioni da eseguire in via preventiva (in fase di progettazione e implementazione) e in caso di incidente, sia da parte degli operatori incaricati di gestire l’ordinaria amministrazione, sia da quelli responsabili della riattivazione del sito secondario (questi ultimi è buona norma che non siano quelli che gestiscono il sito primario, in quanto potrebbero risultare non disponibili proprio in conseguenza dell’incidente che ha coinvolto tale sito). Il piano deve essere costantemente aggiornato e verificato, cosa che può risultare particolarmente onerosa e complessa.

La realizzazione del sito secondario

Se un’organizzazione ha deciso di attrezzarsi con due siti alternativi, deve seguire dei criteri ben definiti per il loro allestimento. Ad esempio, i siti primario e secondario devono essere sufficientemente distanti per garantire il non coinvolgimento contemporaneo degli stessi da un evento distruttivo esteso, tipo un terremoto. La scelta del sito secondario dovrebbe inoltre tener conto anche della raggiungibilità del sito stesso da parte del personale che dovrà poi gestirlo.

I tempi di ripartenza dei sistemi in DR non sono infatti condizionati solo da aspetti tecnici, ma anche dalla disponibilità del personale incaricato della sua gestione. Di conseguenza, posizionare un sito di DR in una località difficilmente raggiungibile, o che richieda tempi di percorrenza molto elevati, può rivelarsi una pessima idea.

Una buona soluzione consiste nel prevedere la possibilità di gestione remota del sito dopo la sua attivazione, cosa che risulta molto favorita dalle scelte che puntano sull’outsourcing del servizio includendovi anche il supporto del personale tecnico. In questo caso, particolare attenzione va data agli aspetti contrattuali e al tipo di servizio offerto. Molto spesso, infatti, l’outsourcer “vende” spazi e potenza elaborativa da utilizzare in caso di emergenza a più clienti contemporaneamente. Diventa quindi importante valutare quale sia l’effettiva garanzia di continuità offerta dai fornitori, in particolare nei casi in cui molti clienti della stessa area geografica siano interessati da uno stesso evento dannoso e richiedano contemporaneamente l’attivazione del proprio servizio di DR (Nel caso in cui il fornitore abbia impegnato le stesse risorse per fornire analoghi servizi ad altre aziende, in particolare se situate nella stessa zona, sono stabilite cautele contrattuali per evitare il rischio che, in caso di esigenze concomitanti di altre organizzazioni, le prestazioni degenerino o il servizio si renda di fatto indisponibile. Circolare 285 di Banca d’Italia).

Le architetture sulle quali impostare il servizio sono numerose, per cui occorre valutare bene quelle che più si addicono alle proprie esigenze.

Si possono distinguere in funzione del fatto che presso il sito di DR siano disponibili solo spazi per accogliere i sistemi, che siano presenti sistemi spenti, che siano presenti sistemi attivi ma condivisi, che siano presenti sistemi attivi e continuamente allineati con il sistema di produzione.

Per quest’ultima soluzione sono disponibili diverse varianti: ad esempio i sistemi nel sito di DR possono essere utilizzati contestualmente a quelli di produzione per bilanciare il carico, oppure possono essere utilizzati per svolgere altri compiti (ad esempio sviluppo e test).

Tabella 4 – Possibili soluzioni per il DR Fonte: Linee Guida per il Disaster Recovery (DR) delle PA

keyboard_arrow_right
keyboard_arrow_left
I LIVELLI

DELLE

SOLUZIONI

(Tier LG)

PRINCIPALI INDICATORI ELEMENTI DI MASSIMA DELLA SOLUZIONE TECNICA

(SOLUZIONI ALMENO A 2 SITI)

RTO RPO

max

Modalità minime di copia/aggiornamento per il conseguimento dei valori max di RPO Aspetti minimali connessi al sito di DR
MinMax
Tier 1:7g>7 gg

solari

max 7gg

solari

Copia su supporti rimuovibiliSito esistente ma da attrezzare con risorse elaborative/ server solo reperibili.

Il sito di DR è predisposto ad accogliere personale e apparecchiature, ma rimane privo di risorse fino al momento di effettiva necessità.

Di solito consiste solo di un ambiente fisico dotato di corrente elettrica e di rete dati con idonee misure di sicurezza (es: sistema antincendio ed antifumo; sistema antiallagamento; sistema di alimentazione in grado di garantire l’erogazione di energia elettrica anche a fronte di prolungate interruzioni di alimentazione nella cabina di fornitura; sistema d’aria condizionata per garantire temperatura ed umidità costante; impianto per il ricambio d’aria; sistema di accesso controllato).

Tier 2: .3gmax 7 ggmax 7 gg solariCopia su supporti

rimuovibili

Il sito dispone di hw e connettività già funzionante ma su scala inferiore rispetto al sito principale o a un sito alternativo sempre disponibile e con replica costante dei dati.
Tier 3:1g3gMax 1 ggElectonic vaulting: soluzione che comporta il backup dei dati presso il sito alternativo in maniera

elettronica, con una riduzione del tempo necessario per il trasporto dei dati e la possibilità di un recovery time più veloce.

Il sito dispone di hardware e connettività già funzionante ma su scala inferiore rispetto al sito principale o ad un site alternativo sempre disponibile e con replica costante dei dati.

Il backup avviene in modalità elettronica e quindi sono necessari collegamenti fra i siti tenuto conto della tipologia, quantità e periodicità dei dati da backupare

Tier 4:4h3ggMax

4 h

Asincrono On line

(risorsa storage accesa)

Il sito alternative è solitamente “un duplicato” del sito originale con tutti i sistemi hardware e la quasi totalità dei backup di dati disponibile. Il sito alternativo può essere pronto ed operativo in alcune ore o meno. Nel caso in cui il personale deve essere spostato fisicamente presso il sito secondario, il sito risulterà operativo solo dal punto di vista del data processing. La piena operatività sarà raggiunta quando anche il personale avrà raggiunto il sito.
Tier 5:1hmax 4

h

max 5 minAggiornamento Sincrono (risorsa storage accesa)E’ la soluzione che prevede due siti attivi ciascuno con capacità sufficiente a prendere in carico il lavoro dell’altro e in cui l’aggiornamento del dato avviene solo quando entrambi i siti hanno completato l’update (con perdita dei soli i dati che in quel momento stanno per essere processati). E’ fondamentale, per questa tipologia di soluzione, valutare la distanza fra i siti.
Tier 6: 0m1hZero min.Aggiornamento Sincrono (risorsa storage accesa)E’ la soluzione che prevede due siti attivi, ognuno dei quali possiede capacità sufficienti a farsi carico del lavoro dell’altro; in questa soluzione il carico di lavoro da un sito all’altro si trasferisce immediatamente ed automaticamente. E’ fondamentale, per questa tipologia di soluzione, valutare la distanza fra i siti.

Avere sistemi già attivi nel sito di DR garantisce di solito tempi di ripartenza più contenuti, ma soprattutto garantisce l’organizzazione circa l’effettivo funzionamento dei sistemi.

Un sito di DR può non contenere tutti gli elementi del sito primario, per un’evidente ragione di costi e opportunità. Per lo stesso motivo un’organizzazione può decidere di non garantire lo stesso livello di servizio quando questo è offerto dal sito primario o da quello secondario. Rimane tuttavia fondamentale, nella individuazione dei componenti che costituiranno il sito secondario, includere non solo i componenti più critici per l’attività della organizzazione, ma anche quelli architetturali a loro supporto. È infatti poco utile ripristinare un mainframe con relative applicazioni e dati, se non si ripristina il sistema che consente agli utenti di raggiungerlo (ad esempio il sistema di autenticazione e di instradamento).

Nella pratica più un sistema è complesso e più è difficile che la ripartenza avvenga senza problemi (salvo il caso in cui i due siti siano contemporaneamente attivi e allineati). Essendo infatti impossibile gestire una ripartenza in blocco di tutti i sistemi e applicazioni di un CED di medie dimensioni si possono generare dei disallineamenti fra i dati in quanto un’applicazione ripristinata potrebbe inoltrare (o aspettare) flussi di dati da applicazioni non ancora ripristinate. Va inoltre considerato che difficilmente un sistema informativo di una certa complessità non scambi flussi con applicazioni di outsourcer e fornitori, che devono essere raggiungibili anche dal sito di DR.

La resilienza agli attacchi cyber

Gli strumenti utili a garantire l’Alta affidabilità solo parzialmente permettono di garantire una resilienza nei confronti di attacchi cyber. Analogamente vale per le soluzioni di DR. Ad esempio un attacco di tipo ransomware potrebbe comportare la indisponibilità dei dati sia sul sistema primario, sia sulle repliche (Al riguardo è necessario prevedere che i collegamenti verso gli outsourcer e i loro siti di DR possano avvenire parimenti sia dal proprio sito primario, sia dal proprio sito secondario) dei dati presenti nel sito secondario.

La resilienza rispetto a tale tipologie di attacco viene implementata mediante l’adozione sia di una serie di misure preventive, quali opportuni strumenti per la protezione perimetrale (firewall, IDS, IPS, antivirus…) sia da un’attività di monitoraggio continuo (quasi sempre assente in quanto molto onerosa dal punto di vista delle risorse richieste).

La costruzione e conduzione di un sistema di monitoraggio richiede la creazione di un System Information and Event Management (SIEM) nel quale far confluire informazioni provenienti ad esempio da:

  • apparati di sicurezza (firewall, IDS/IPS, sistemi antivirus di varie tipologie);
  • eventi di sicurezza provenienti dai sistemi server (Windows, Linux…);
  • log di audit provenienti da DMBS;
  • bilanciatori web e reverse proxy web;
  • sistemi dedicati alla navigazione web degli utenti;
  • sistemi di autenticazione;
  • audit e tracking dei sistemi di posta elettronica;

e richiede la presenza di personale specializzato, capace di analizzare la grande quantità di informazioni raccolte, che devono necessariamente essere precedentemente filtrare mediante criteri dettati dall’esperienza.

Contestualmente è necessario disporre di una procedura per la gestione degli incidenti di sicurezza informatica che, nei casi più gravi, si deve raccordare con quella per la gestione della continuità operativa.

Anche in questo caso le organizzazioni di dimensioni più contenute potrebbero essere maggiormente tutelate esternalizzando il proprio sistema informativo mediante l’utilizzo di soluzioni cloud, su piattaforme quindi opportunamente presidiate anche dal punto di vista della sicurezza.

La sicurezza delle infrastrutture e delle persone

Per garantire un’adeguata protezione a edifici e infrastrutture è necessario affidarsi a un insieme di misure di sicurezza attive e passive, fra loro coordinate e periodicamente verificate (si vedano al riguardo le tabelle 5 e 6).

Tabella 5 – Protezione di un edificio (Fonte: Sicurezza totale, G.Butti – ITER)

keyboard_arrow_right
keyboard_arrow_left
Elementi di rischio della sede in base alla collocazione
  • Zona sismica
  • Corsi d’acqua nelle vicinanze con rischio esondazione
  • Aziende con lavorazioni pericolose
  • Installazioni pericolose (aeroporti, depositi carburanti…)
  • Area degradata
Elementi di mitigazione in base alla vicinanza dei servizi
  • Carabinieri o altre forze di polizia e vigilanza
  • Ospedali o altri presidi
  • Vigili del fuoco
Misure di sicurezza generali della sedeAnti intrusione

  • Antifurto
  • Vigilanza
  • Videosorveglianza
  • Controllo accessi
  • Recinzioni
  • Cancelli
  • Grate alle finestre
  • Porta blindata
  • Serratura di sicurezza

Antincendio

  • Estintori
  • Idranti
  • Rilevatori
  • Allarmi
  • Porte taglia fuoco

Altre misure

  • Antisismica
  • Anti allagamento
  • Eventi atmosferici (fulmini)
AltroRegolarità degli impianti

  • Elettrico
  • Climatizzazione

Continuità elettrica

  • UPS
  • Generatori

Altro

  • Aree separate per ricevimento clienti/fornitori
Procedure
  • Procedura di gestione degli accessi (comprese autorizzazioni, revoche, smarrimento badge…)
  • Procedura di gestione dei visitatori/manutentori

Tabella 6 – Protezione di un CED (Fonte: Sicurezza totale, G.Butti – ITER)

keyboard_arrow_right
keyboard_arrow_left
Misure di sicurezza CEDAnti intrusione

  • Adeguato posizionamento all’interno dell’edificio
  • Pareti soffitto/pavimento
  • Pareti di adeguato spessore e robustezza
  • Misure anti effrazione
  • Controllo accessi
  • Videosorveglianza

Antincendio

  • Rilevatori di fumo, calore, allagamento
  • Misure antincendio compatibili con le apparecchiature presenti
  • Porte antincendio di adeguata dimensione
  • Interruttore generale della alimentazione elettrica
  • Impianto di climatizzazione

Continuità elettrica

  • Gruppo di continuità (per lo spegnimento corretto)
  • Gruppo elettrogeno (per la continuità del servizio)
  • Coerenza fra i dispositivi di continuità e le normative VVFF

Apparecchiature e impianti

  • Pavimento galleggiante per l’adeguato posizionamento dei cavi
  • Corretto e ordinato posizionamento dei cavi elettrici
  • Corretto e ordinato posizionamento dei cavi di rete
  • Posizionamento ordinato delle apparecchiature nei rack
  • Spazio intorno ai rack adeguato per la movimentazione e manutenzione delle apparecchiature
  • Gestione remota delle apparecchiature

Le misure di sicurezza devono proteggere da possibili infrazioni sia mediante l’uso di barriere fisiche, sia mediante l’utilizzo di sensori, sistemi di videosorveglianza, servizi di vigilanza e via dicendo.

L’impostazione di questa tipologia di misure sicurezza è solitamente tesa a proteggere gli asset in quanto tali, per il loro valore intrinseco piuttosto che in una prospettiva di resilienza. È quindi opportuno, se si desiderano proteggere le proprie infrastrutture dalle conseguenze di un attacco (o nel caso in specie di prevenirlo), riesaminare le proprie misure di sicurezza specificatamente per tale finalità (si consideri ad esempio l’importanza che rivestono le infrastrutture per l’energia o per le comunicazioni).

Altra cosa sono le misure messe in atto per resistere alle possibili conseguenze di un attacco, in particolare le misure antincendio. Anche in questo caso l’analisi dei rischi per definire dove intervenire dovrebbe considerare in prima battuta la protezione non degli asset che abbiano il maggior valore intrinseco, ma di quelli che sono indispensabili a garantire la continuità. È evidente che molto spesso non si tratta della stessa tipologia di asset e che quindi la scelta di un’organizzazione nell’individuare quali beni meritino un maggior livello di protezione è spesso legata alla cultura della resilienza da essa posseduta.

Queste misure possono risultare del tutto inefficaci se a portare l’attacco è una persona che ha libero accesso all’organizzazione e in particolare a locali vitali per l’organizzazione stessa. Le organizzazioni hanno di solito una scarsa sensibilità in questo senso e permettono ad esempio la presenza anche di un solo operatore all’interno di un CED altrimenti blindato. Tali pratiche vanno riconsiderate; indipendentemente dalla affidabilità del singolo operatore, si deve infatti valutate la possibilità che lo stesso possa operare sotto costrizione.

Alcune delle misure fino a qui esposte premettono anche di tutelare il personale che opera presso l’organizzazione. Tuttavia le figure chiave di un’organizzazione non possono di norma usufruire di una protezione che si estenda al di fuori dell’ambiente di lavoro. Sono quindi necessarie misure di prevenzione attuabili sia mediante un’opportuna sensibilizzazione e formazione dei soggetti potenzialmente esposti, sia rendendo l’organizzazione il più possibile indipendente rispetto a tali soggetti, che devono risultare “rimpiazzabili” senza grossi traumi per l’organizzazione stessa.

Fra le misure da attuare in tal senso vi è sicuramente la formalizzazione del know how detenuto da tali soggetti, affinché diventi effettivo patrimonio dell’organizzazione (tale attività non sempre è di facile attuazione, anche a causa delle resistenza di tali soggetti che sono consapevoli del loro ruolo). La formalizzazione del capitale intellettuale di una organizzazione in file e documenti, oltre a tutelarla rispetto alla perdita di figure chiave, consente alla stessa di proteggere tali asset.

Le soluzioni di business continuity

La business continuity, come il nome stesso porta a intuire, si occupa della continuità del business.

Si tratta di un tema più ampio e complesso della semplice capacità di ripristinare il sistema informativo di un’organizzazione.

Banca d’Italia, ad esempio ha previsto, nella Circolare 285, che le banche debbano predisporre un piano di BC che prende in considerazione diversi scenari di crisi basati almeno sui seguenti fattori di rischio, conseguenti a eventi naturali o attività umana, inclusi danneggiamenti gravi da parte di dipendenti:

  • distruzione o inaccessibilità di strutture nelle quali sono allocate unità operative o indisponibilità di personale essenziale per il funzionamento dei processi aziendali;
  • interruzione del funzionamento delle infrastrutture (tra cui energia elettrica, reti di telecomunicazione, reti interbancarie, mercati finanziari);
  • alterazione o perdita di dati e documenti critici;
  • apparecchiature critiche;
  • indisponibilità di sistemi informativi critici.

Tali scenari interessano in realtà anche tutte le altre organizzazioni che erogano servizi o per le quali la gestione delle informazioni costituisce una componente essenziale per garantire la produzione. Per le aziende manifatturiere tali scenari andrebbero integrati aggiungendo, ad esempio, l’indisponibilità di una linea di produzione o la mancanza di semilavorati o materie prime.

In generale la capacità di continuare la propria attività è condizionata almeno dai seguenti fattori:

  • disponibilità di strumenti;
  • disponibilità di informazioni;
  • disponibilità dei collaboratori (in particolare delle figure chiave);

ai quali si aggiungono per le aziende di produzione:

  • disponibilità di materie prime, semilavorati, infrastrutture, impianti…

Deve essere inoltre disponibile un edificio con le opportune infrastrutture in cui collocare quanto sopra.

Molte delle informazioni di cui è necessario disporre per predisporre soluzioni di continuità operativa dovrebbero già essere disponibili presso le organizzazioni in quanto necessarie per il rispetto di altre normative (l’attuale normativa privacy prevedeva per la compilazione del DPS una discreta mappatura delle informazioni presenti nell’organizzazione, dei documenti, del sistema informativo; il nuovo Regolamento europeo sulla privacy, GDPR – Regolamento (UE) 2016/679, richiederà una analoga mappatura, ma molto più dettagliata.

È infatti necessario mappare:

  • sistema informativo;
  • archivi elettronici;
  • documenti;
  • processi e attività;
  • struttura organizzativa;
  • controparti.

Le verifiche effettuate nel corso della mia attività di consulenza presso numerosissime organizzazioni dei più disparati settori e dimensioni hanno di fatto evidenziano le seguenti carenze:

  • mancanza di documentazione;
  • assenza di una mappatura e formalizzazione dei processi;
  • parti di processi chiave non documentate;
  • eccessivo ricorso a figure chiave, in particolare nelle organizzazioni medio piccole;
  • ampio uso di applicazioni di operatività individuale in aggiunta al sistema informativo dell’organizzazione;
  • dispersione nella archiviazione dei file, molto spesso collocati anche sui singoli pc in uso ai collaboratori;
  • assenza di un censimento della documentazione presente al di fuori del sistema informativo;
  • mancanza di qualunque classificazione delle informazioni.

Inoltre, molte delle informazioni che servono a una organizzazione sono ancora presenti unicamente al di fuori del sistema informativo; vi è ancora un largo uso di documenti, spesso per esigenze legali e contrattuali.

Tali documenti rivestono particolare rilevanza per un’organizzazione, ma nessuno si preoccupa di custodirne una copia in un luogo diverso dal sito principale (analogamente a quanto dovrebbe avvenire per le copie di backup), o di procedere a una loro digitalizzazione o meglio ancora alla loro eliminazione sostituendoli con documenti informatici di analoga valenza legale.

Anche nel caso di una adeguata documentazione, quello che si riesce a mappare è comunque solo la componente esplicita del patrimonio informativo dell’organizzazione, la parte cioè formalizzata. La componente implicita, patrimonio molto spesso di singoli collaboratori come precedentemente espresso, è esclusa da questo censimento, salvo poi costituire l’elemento chiave per consentire o no la ripresa dell’attività.

Anche il legislatore se ne è accorto e uno degli scenari previsti da Banca d’Italia è proprio l’indisponibilità di personale essenziale per il funzionamento dell’organizzazione.

Nell’accezione bancaria si tratta del personale che presiede i processi critici o vitali (molto spesso legati all’area finanza), che in un corretto piano di business continuity è sostituibile con altro personale che abbia le stesse competenze, che possibilmente utilizzi gli stessi strumenti e che possibilmente operi in un’altra località (in questo modo viene coperto anche lo scenario della indisponibilità di un sito, in quanto spesso i due eventi sono fra loro collegati).

Nel caso di una piccola organizzazione può essere difficile trovare un idoneo sostituto di una figura chiave ed è per questo motivo che, come precedentemente illustrato, i processi critici o vitali dell’organizzazione dovrebbero essere il più possibile documentati (il tutto da conciliare con le indispensabili esigenze di riservatezza).

Alcune tipologie di servizi conservano rilevanti quantità di documenti, quasi sempre in originale, che in caso di distruzione (incendio, alluvione…) comportano da una lato danni gravissimi per i clienti e dall’altro un costo enorme per la ricostruzione degli stessi (dove possibile) e per la ripresa dell’attività.

Nel caso specifico, un semplice accorgimento come la conservazione delle sole copie (lasciando ai clienti la responsabilità della conservazione degli originali) ridurrebbe drasticamente i rischi e consentirebbe una più agevole ripresa del lavoro.

Altro punto di difficile attuazione per una piccola e media organizzazione è la predisposizione di soluzioni relative a una scenario come la distruzione o l’inaccessibilità di strutture nelle quali siano allocate unità operative o apparecchiature critiche. Per una società di servizi parte del problema può essere risolto de localizzando i sistemi presso un outsourcer o facendo ricorso a soluzioni cloud e predisponendo come possibili fonti di accesso postazioni mobili o telelavoro.

Le soluzioni cloud costituiscono probabilmente oggi una delle soluzioni più precorribili per le piccole e medie organizzazioni, per aumentare considerevolmente la propria resilienza esternalizzando i propri sistemi informativi, con la possibilità di includere nel servizio anche la loro continuità operativa.

Non mancano anche esempi concreti di società manifatturiere che hanno saputo esternalizzare molte attività (dalla progettazione alla produzione) concentrando in spazi molto limitati le sole attività di coordinamento e marketing.

Esternalizzazione, diversificazione anche geografica delle unità produttive, così come diversificazione dei fornitori, costituiscono alcune delle possibili strategie di continuità (si veda la tabella 8) anche per le aziende di produzione.

Tabella 7 – Strategie per la gestione della continuità produttiva

keyboard_arrow_right
keyboard_arrow_left
Siti alternativi di produzioneLa disponibilità di un sito alternativo di produzione rispetto a quello principale si può configurare con varie modalità, analogamente a quanto avviene per le soluzioni di DR dei sistemi informativi.

È possibile disporre di un sito in cui si svolga effettivamente la produzione nel continuo (non necessariamente dello stesso prodotto), o che sia semplicemente pronta a farlo o che possa ospitare l’attività produttiva.

AppaltoIdentificazione di soggetti presso i quali continuare la produzione.
Acquisizione post incidenteAcquisizione delle infrastrutture, strumenti, prodotti atti a continuare la produzione dopo l’incidente. È opportuno che i potenziali fornitori siano stati già individuati e periodicamente verificata la capacità di fornire quanto necessario in tempi compatibili con le esigenze dell’organizzazione.
Indipendentemente dalla strategia adottata devono essere pianificate le azioni da intraprendere e allocati i relativi budget.

Tabella 8 – Strategie per la gestione della continuità della catena di fornitura

keyboard_arrow_right
keyboard_arrow_left
Strategie di selezione e salvaguardiaCriteri di selezione del fornitore che consentano di valutare la sua resilienza

Clausole contrattuali

Verifica della priorità di fornitura nei confronti degli altri clienti

Documentazione attestante la capacità di garantire la continuità operativa

Documentazione dei test e partecipazione ai test

Documentazione in merito a precedenti incidenti e loro gestione

Valutazione delle conseguenze di una interruzione di fornitura (in funzione della durata della interruzione)

Tipologia di fornitori coinvoltiUtilities: acqua, gas, energia elettrica, comunicazioni

Materie prime e componenti

Attrezzature, impianti

Sistemi informativi e applicazioni

Servizi vari, quali trasporti…

Gestione della produzione per conto dell’organizzazione

Strategie risolutiveFornitori alternativi

Stoccaggio di materie prime e componenti

Utilizzo di materiali/processi alternativi

Autoproduzione (ad esempio energia elettrica)

Le attività di test

Le attività di test dovrebbero avere la finalità di confermare il corretto funzionamento delle soluzioni implementate e di individuare le criticità al fine di risolverle. Per tale motivo dovrebbero essere svolte (gradualmente) anche in condizioni che rispecchino situazioni critiche reali, come i periodi di ferie o importanti attività di manutenzioni dei sistemi.

Le possibili attività di test sono molteplici e devono partire dalle verifiche dei singoli componenti di un sistema, sia quelli del sito primario, sia quelli del sito secondario (nel caso in cui sia attivo un sito di DR) fino al test complessivo dell’intero sito.

Vanno testati tutti gli impianti e gli elementi ridondati. Tali attività vanno però eseguite con “intelligenza”. Emblematico è il caso dei test dei gruppi elettrogeni, che si risolve nella maggior parte dei casi con una prova annuale del loro corretto funzionamento per un tempo molto limitato. La conseguenza di questa modalità di svolgimento del test è che il carburante permane nei serbatoi anche per anni, con effetti deleteri sulle valvole e sul galleggiante che misura il livello di carburante. Il risultato è che in un vera emergenza l’erogazione del carburante può bloccarsi per un malfunzionamento di uno di questi componenti del valore di pochi euro, vanificando così tutto il lavoro svolto.

L’esempio non è un caso isolato. Basta visitare un qualunque CED per trovare accatastati scatoloni di ogni genere in conseguenza delle costanti attività di manutenzione, spesso posizionati nelle vie di fuga o davanti agli ugelli del sistema antincendio.

È piuttosto raro che le organizzazioni, anche molto grandi, dispongano in autonomia di un sito di DR; molto più spesso ricorrono a servizi in outsourcing, nel qual caso la possibilità di effettuare dei test è condizionata dalla disponibilità dei tecnici del fornitore e dagli spazi dove allocare le proprie risorse presso l’outsourcer.

Il periodo per compiere i test è pertanto limitato a pochi giorni in un anno. Per ovviare a questo inconveniente è opportuno prevedere lo svolgimento di test anche presso la propria struttura. Ad esempio, la verifica puntuale della leggibilità e capacità di ripristino dei singoli componenti dei sistemi può essere fatta anche in locale, isolando opportunamente porzioni adeguate del sistema.

L’attività di test della continuità operativa per la parte non IT deve prevedere ad esempio l’indisponibilità di un edificio o di personale critico. In teoria in mancanza di un edificio sarebbe possibile utilizzare le stesse risorse spostandole in un’area appositamente attrezzata a tale scopo.

Questo tipo di soluzione, peraltro molto diffusa, ha il limite di non prendere in considerazione l’indisponibilità proprio delle risorse. Peraltro tale soluzione potrebbe risultare più costosa della effettiva dislocazione di risorse in luoghi diversi, essendo necessario mantenere costantemente allineate alle postazioni principali le postazioni di riserva di solito inutilizzate, pagando comunque le relative licenze software e le relative attività di manutenzione. Pur non simulando un malfunzionamento del sistema informativo, l’esperienza ha evidenziato che un test di questo tipo comporta il coinvolgimento di diversi aspetti ICT. Come in precedenza accennato, solo durante i test è possibile scoprire se gli utenti utilizzano per la loro operatività strumenti di produttività individuale con cui hanno realizzato file salvati sulle proprie postazioni (spesso con macro e path assoluti), documenti, apparecchiature particolari (ad esempio telefoni con registrazione della chiamata).

Va inoltre considerato il fatto che un evento che comporta il ricorso, ad esempio, allo sgombero di un edificio e alla invocazione del piano di BC può accadere in qualunque momento e quindi il personale che dal sito alternativo prende in carico le varie attività troverà delle applicazioni aperte e dei file bloccati. L’IT dovrà quindi intervenire per sbloccare da remoto tali situazioni e per attribuire le corrette credenziali al personale subentrante.

Le modalità di svolgimento dei test di continuità operativa possono comprendere anche esercizi prettamente teorici, dedicati in particolare a verificare la preparazione del personale coinvolto e delle procedure di invocazione e gestione della crisi.

Tabella 9 – Esempi di tipologia di test

keyboard_arrow_right
keyboard_arrow_left
Test degli impianti sia sul sito primario, sia sul sito di DR

  • impianto elettrico
  • LAN e relativi componenti
  • connettività esterna
  • continuità elettrica (avviamento, autonomia, apparati serviti…)
  • condizionamento
  • controllo accessi e videosorveglianza
  • antincendio
  • antiallagamento
  • collegamenti ridondati fra sito primario e sito secondario
Test dei componenti
  • indisponibilità di un apparato di elaborazione
  • indisponibilità di un apparato di archiviazione dati
  • verifica delle configurazioni per la ripartenza
Test del sistema informativo
  • test di ripristino di singoli componenti
  • test di ripristino del sito di DR
Test di indisponibilità delle unita critiche/edifici
  • indisponibilità/inagibilità di un edificio
  • indisponibilità di risorse chiave
Test di terzi
  • collegamento al sito di DR dei fornitori di servizi dal proprio sito primario
  • collegamento al sito di DR dei fornitori di servizi dal proprio sito di DR

Resilienti per legge: come essere GDPR compliant

Sia in modo diretto, sia in modo indiretto (tutelando ad esempio i dati personali oggetto di trattamento) le normative hanno da diversi anni introdotto vincoli che obbligano le organizzazioni a dotarsi di strumenti che aumentano la loro resilienza, quantomeno per quanto riguarda gli aspetti IT.

In particolare tutte le organizzazioni sono soggette a vincoli normativi che regolamentano la capacità di ripristino e di accesso ai dati e ai sistemi predisponendo soluzioni che consentano una protezione delle informazioni in caso di disastro.

Anche se quanto viene richiesto dalla normativa non è un vero e proprio disaster recovery, il D.Lgs. 196/03 (normativa privacy) introduce una serie di prescrizioni (si veda la tabella 10).

Tali prescrizioni sono notevolmente aumentate dal Regolamento (UE) 2016/679 (nuovo regolamento UE sulla privacy – GDPR) che introduce espressamente il concetto di resilienza e suggerisce, come adeguata misura di sicurezza, il ripristino immediato nell’accesso ai dati.

Come più volte ricordato, dal 2004 il sistema bancario italiano è soggetto a una specifica normativa che prevede la predisposizione di piani di BC, mentre il CAD prevedeva tale adempimento anche per le PA.

Oltre alla normativa italiana la richiesta di piani di business continuity trova riscontro anche in altri ambiti, quali ad esempio la Sarbanes-Oxley.

Tabella 10 (a) – Esempi di normativa in ambito continuità operativa

keyboard_arrow_right
keyboard_arrow_left
D.Lgs 196/03

Tutti i titolari di trattamento

Art. 31. Obblighi di sicurezza
1. I dati personali oggetto di trattamento sono custoditi e controllati, anche in relazione alle conoscenze acquisite in base al progresso tecnico, alla natura dei dati e alle specifiche caratteristiche del trattamento, in modo da ridurre al minimo, mediante l’adozione di idonee e preventive misure di sicurezza, i rischi di distruzione o perdita, anche accidentale, dei dati stessi, di accesso non autorizzato o di trattamento non consentito o non conforme alle finalità della raccolta.
Art. 34. Trattamenti con strumenti elettronici
1. Il trattamento di dati personali effettuato con strumenti elettronici è consentito solo se sono adottate, nei modi previsti dal disciplinare tecnico contenuto nell’allegato B), le seguenti misure minime:
f) adozione di procedure per la custodia di copie di sicurezza, il ripristino della disponibilità dei dati e dei sistemi;
Allegato B

Tutti i titolari di trattamento

Inoltre nell’Allegato B, in particolare per quanto attiene ai trattamenti di dati sensibili e giudiziari viene prescritto:

19.5. la descrizione dei criteri e delle modalità per il ripristino della disponibilità dei dati in seguito a distruzione o danneggiamento di cui al successivo punto 23;

….
23. Sono adottate idonee misure per garantire il ripristino dell’accesso ai dati in caso di danneggiamento degli stessi o degli strumenti elettronici, in tempi certi compatibili con i diritti degli interessati e non superiori a sette giorni.

Regolamento (UE) 2016/679

GDPR

Tutti i titolari di trattamento

Articolo 32 Sicurezza del trattamento

1.Tenendo conto dello stato dell’arte e dei costi di attuazione, nonché della natura, dell’oggetto, del contesto e delle finalità del trattamento, come anche del rischio di varia probabilità e gravità per i diritti e le libertà delle persone fisiche, il titolare del trattamento e il responsabile del trattamento mettono in atto misure tecniche e organizzative adeguate per garantire un livello di sicurezza adeguato al rischio, che comprendono, tra le altre, se del caso:

b) la capacità di assicurare su base permanente la riservatezza, l’integrità, la disponibilità e la resilienza dei sistemi e dei servizi di trattamento;

c) la capacità di ripristinare tempestivamente la disponibilità e l’accesso dei dati personali in caso di incidente fisico o tecnico;

Tabella 10 (b) – Esempi di normativa in ambito continuità operativa

keyboard_arrow_right
keyboard_arrow_left
Circolare 285

Banca d’Italia

Titolo IV – Governo societario, controlli interni e gestione dei rischi

Capitolo 4 – Il sistema informativo

Sezione IV – La gestione della sicurezza informatica

7. La disponibilità delle informazioni e delle risorse ICT

— in relazione alle esigenze di disponibilità delle singole applicazioni, sono definite procedure di backup (di dati, software e configurazione) e di ripristino su sistemi alternativi, in precedenza individuati;

— le architetture sono disegnate in considerazione dei profili di sicurezza informatica delle applicazioni ospitate, tenendo conto di tutte le risorse ICT e di supporto interessate (alimentazione elettrica, impianti di condizionamento, ecc.); a tale riguardo, l’intermediario valuta la necessità di predisporre piattaforme particolarmente robuste e ridondate (ad es., applicando il principio del no single point of failure) volte a garantire l’alta disponibilità delle applicazioni maggiormente critiche, in sinergia con le procedure e il sistema di disaster recovery;

— in funzione dei profili di rischio delle comunicazioni, delle applicazioni e dei servizi acceduti, i collegamenti telematici interni alla banca o al gruppo sono opportunamente ridondati; in relazione al rischio di incidenti di sicurezza informatica che possono determinare l’interruzione dei servizi (ad es., mediante attacchi di tipo denial of service o distributed denial of service), oltre a soluzioni specifiche per l’individuazione e il blocco del traffico malevolo, la banca valuta l’opportunità di sfruttare procedure e strumenti per l’allocazione dinamica di capacità trasmissiva ed elaborativa;

Circolare 285

Banca d’Italia

Titolo IV – Governo societario, controlli interni e gestione dei rischi

Capitolo 5 – La continuità operativa

Allegato A – Requisiti per la continuità operativa

Sezione II – Requisiti per tutti gli operatori

1. Ambito del piano di continuità operativa

2. Analisi di impatto

3. Definizione del piano di continuità operativa e gestione delle crisi

3.1 1Ruolo degli organi aziendali

3.2 I processi critici

3.3 La responsabilità del piano di continuità operativa

3.4 Il contenuto del piano di continuità operativa

3.5 Le verifiche

3.6 Le risorse umane

3.7 Esternalizzazione, infrastrutture e controparti rilevanti

3.8 Controlli

3.9 Comunicazioni alla Banca d’Italia e alla Banca centrale europea

Tabella 10 (c) – Esempi di normativa in ambito continuità operativa

keyboard_arrow_right
keyboard_arrow_left
Decreto Legislativo 7 marzo 2005, n. 82 e s.m.i.

Codice dell’amministrazione digitale

Articolo abrogato dal D.LGS. 26 Agosto 2016, n. 179

Art. 50-bis. Continuità operativa.

1. In relazione ai nuovi scenari di rischio, alla crescente complessità dell’attività istituzionale caratterizzata da un intenso utilizzo della tecnologia dell’informazione, le pubbliche amministrazioni predispongono i piani di emergenza in grado di assicurare la continuità delle operazioni indispensabili per il servizio e il ritorno alla normale operatività.

2. Il Ministro per la pubblica amministrazione e l’innovazione assicura l’omogeneità delle soluzioni di continuità operativa definite dalle diverse Amministrazioni e ne informa con cadenza almeno annuale il Parlamento.

3. A tali fini, le pubbliche amministrazioni definiscono:

a) il piano di continuità operativa, che fissa gli obiettivi e i principi da perseguire, descrive le procedure per la gestione della continuità operativa, anche affidate a soggetti esterni. Il piano tiene conto delle potenziali criticità relative a risorse umane, strutturali, tecnologiche e contiene idonee misure preventive. Le amministrazioni pubbliche verificano la funzionalità del piano di continuità operativa con cadenza biennale;

b) il piano di disaster recovery, che costituisce parte integrante di quello di continuità operativa di cui alla lettera a) e stabilisce le misure tecniche e organizzative per garantire il funzionamento dei centri di elaborazione dati e delle procedure informatiche rilevanti in siti alternativi a quelli di produzione. DigitPA, sentito il Garante per la protezione dei dati personali, definisce le linee guida

per le soluzioni tecniche idonee a garantire la salvaguardia dei dati e delle applicazioni informatiche, verifica annualmente il costante aggiornamento dei piani di disaster recovery delle amministrazioni interessate e ne informa annualmente il Ministro per la pubblica amministrazione e l’innovazione.

4. I piani di cui al comma 3 sono adottati da ciascuna amministrazione sulla base di appositi e dettagliati studi di fattibilità tecnica; su tali studi è obbligatoriamente acquisito il parere di DigitPA.

1. In relazione ai nuovi scenari di rischio, alla crescente complessità dell’attività istituzionale caratterizzata da un intenso utilizzo della tecnologia dell’informazione, le pubbliche amministrazioni predispongono i piani di emergenza in grado di assicurare la continuità delle operazioni indispensabili per il servizio e il ritorno alla normale operatività.

2. Il Ministro per la pubblica amministrazione e l’innovazione assicura l’omogeneità delle soluzioni di continuità operativa definite dalle diverse Amministrazioni e ne informa con cadenza almeno annuale il Parlamento.

3. A tali fini, le pubbliche amministrazioni definiscono:

a) il piano di continuità operativa, che fissa gli obiettivi e i principi da perseguire, descrive le procedure per la gestione della continuità operativa, anche affidate a soggetti esterni. Il piano tiene conto delle potenziali criticità relative a risorse umane, strutturali, tecnologiche e contiene idonee misure preventive. Le amministrazioni pubbliche verificano la funzionalità del piano di continuità operativa con cadenza biennale;

b) il piano di disaster recovery, che costituisce parte integrante di quello di continuità operativa di cui alla lettera a) e stabilisce le misure tecniche e organizzative per garantire il funzionamento dei centri di elaborazione dati e delle procedure informatiche rilevanti in siti alternativi a quelli di produzione. DigitPA, sentito il Garante per la protezione dei dati personali, definisce le linee guida

per le soluzioni tecniche idonee a garantire la salvaguardia dei dati e delle applicazioni informatiche, verifica annualmente il costante aggiornamento dei piani di disaster recovery delle amministrazioni interessate e ne informa annualmente il Ministro per la pubblica amministrazione e l’innovazione.

4. I piani di cui al comma 3 sono adottati da ciascuna amministrazione sulla base di appositi e dettagliati studi di fattibilità tecnica; su tali studi è obbligatoriamente acquisito il parere di DigitPA.

DIRETTIVA (UE) 2016/1148 DEL PARLAMENTO EUROPEO E DEL CONSIGLIO del 6 luglio 2016 recante misure per un livello comune elevato di sicurezza delle reti e dei sistemi informativi nell’UnioneArticolo 14 Obblighi in materia di sicurezza e notifica degli incidenti

2.Gli Stati membri provvedono affinché gli operatori di servizi essenziali adottino misure adeguate per prevenire e minimizzare l’impatto di incidenti a carico della sicurezza della rete e dei sistemi informativi utilizzati per la fornitura di tali servizi essenziali, al fine di assicurare la continuità di tali servizi.

Modelli, standard e loro limiti

Sia la Circolare 285 di Banca d’Italia, sia il CAD danno alcune indicazioni di massima che trovano poi declinazione in una serie di linee guida emesse da ABI LAB e quindi a circolazione limitata al mondo bancario (si vedano al riguardo: Metodologia per la realizzazione del Piano di continuità operativa, ABI LAB, 2004; Linee guida per la manutenzione del Piano di Continuità, ABI LAB, 2007; Linee guida per la gestione della Business Continuity, ABI LAB, 2011) e nelle Linee guida per il disaster recovery delle pubbliche amministrazioni di pubblico dominio. Tali documenti, pur essendo dedicati a banche e PA sono applicabili, per quanto attiene alla metodologia riportata, a qualunque organizzazione.

In particolare, le Linee guida per il disaster recovery delle pubbliche amministrazioni costituiscono un valido e completo strumento per quanti desiderano implementare soluzioni di continuità operativa in particolare per una organizzazione che eroga servizi.

Relativamente a tematiche legate a resilienza, continuità operativa e disaster recovery esistono numerosi standard (si veda tabella 11) ma anche metodologie proprietarie, come quelle proposte dal Business continuity Institute (www.thebci.org).

Comuni alle varie metodologie sono alcuni parametri quali RTO (Recovery Time Objective) e RPO (Recovery Point Objective) che hanno una importanza fondamentale in quanto indicano il primo, il tempo atteso di ripristino dopo un evento dannoso e il secondo, la perdita dati tollerata (nel caso in cui l’evento dannoso comporti una perdita di dati).

Analogamente a quanto richiesto in merito ai termini di Alta affidabilità, DR e BC, anche il significato di RTO e RPO deve essere largamente condiviso fra tutti gli attori coinvolti nel processo di implementazione della continuità operativa.

La valutazione di quelli che siano gli RTO e gli RPO richiesti da un’organizzazione per garantire la propria continuità operativa (a un livello di servizio accettabile) sono definiti mediante una puntuale attività di analisi (BIABusiness Impact Analysis) presso i vari owner di processo. In questo contesto gli RTO e RPO espressi come necessari dai vari owner, sono quelli di un servizio/sistema funzionante e perfettamente operativo. Relativamente ad un sistema informativo questo comporta (in funzione del tipo di soluzione di continuità implementata) ripristinare l’infrastruttura, le applicazioni, i dati e validare il tutto. Se queste attività, come accade nella maggior parte dei casi, sono svolte da fornitori diversi, devono essere concordati contrattualmente con questi soggetti, per le specifiche attività di loro competenza, tempi di RTO molto più bassi di quelli attesi dall’owner.

Questi parametri inoltre, per quanto possano essere significativi e universalmente riconosciuti, hanno un limite intrinseco estremamente rilevante che è necessario considerare nella predisposizione delle soluzioni di recovery. Per molte attività il tempo di RTO desiderato non è fisso, ma è legato al momento della giornata o al giorno dell’anno in cui un evento distruttivo avviene. Se ad esempio il sistema informativo di una banca va in fault un’ora prima della chiusura del mercato finanziario anche tempi ristrettissimi di RTO (oggi le banche a rilevanza sistemica devono avere un tempo di ripristino di 4 ore) si rivelano assolutamente inadeguati in quanto in ogni caso non sufficienti a ritornare operativi in tempo utile. Analogamente, un fault del sistema che comporti una interruzione di una elaborazione batch notturna di diverse ore, potrebbe comportare, dopo l’attività di ripristino, la riesecuzione della elaborazione, aumentando considerevolmente il tempo di indisponibilità complessiva del sistema.

È quindi utile inserire un nuovo parametro ad integrazione di quelli prima illustrati, che permetta di definire (nel caso esista) il momento nel quale un’azione di ripristino secondo i tempi predefiniti di RTO non è comunque sufficiente a salvare l’operatività giornaliera.

Modelli e standard sono quindi utili, ma vanno quindi contestualizzati alla realtà considerata.

Tabella 11 – Alcuni degli standard ISO relativi alla continuità operativa

keyboard_arrow_right
keyboard_arrow_left
ISO 22313 e ISO 22301 – sistema di gestione della Continuità Operativa generale

Standard ISO/IEC relativi alla Continuità Operativa e al DR ICT

ISO/IEC 27031 relativo alla Continuità Operativa ICT

ISO/IEC 24762 relativo ai servizi di DR ICT

Standard ISO/IEC relativi a tematiche ICT correlate alla Continuità Operativa e al DR

ISO/IEC 27001 e 27002 relative alla sicurezza ICT che prevedono tra gli oggetti di controllo la gestione della continuità operativa

ISO/IEC 20000-1 e 20000-2 relative al sistema di gestione dei servizi ICT che include tra i servizi la gestione della continuità dei servizi

Tabella 12 – I parametri della continuità operativa (ISO 22301)

keyboard_arrow_right
keyboard_arrow_left
RTO (Recovery Time Objective)period of time following an incident within which

  • product or service must be resumed, or
  • activity must be resumed, or
  • resources must be recovered
RPO (Recovery Point Objective)point to which information used by an activity must be restored to enable the activity to operate on resumption
MAO (maximum acceptable outage)time it would take for adverse impacts, which might arise as a result of not providing a product/service or performing an activity, to become unacceptable
MTPD (maximum tolerable period of disruption)time it would take for adverse impacts, which might arise as a result of not providing a product/service or performing an activity, to become unacceptable

Le giuste valutazioni per resistere ad un attacco

Un’organizzazione che vuole essere resiliente rispetto a un evento disastroso può oggi contare su strumenti, metodologie e tecnologie consolidate. L’esperienza di settori specifici, come quello finanziario o della PA, dove la continuità operativa è diventato un obbligo normativo, può essere agevolmente trasferita anche in altri ambiti.

Il limite attuale è principalmente di natura culturale e deriva da una scarsa consapevolezza delle organizzazioni circa la loro esposizione, anche indiretta, verso specifiche categorie di minacce, come ad esempio un attacco terroristico o cyber.

Anche in questo ambito quindi, saranno probabilmente gli obblighi normativi coinvolgenti un sempre crescente numero di organizzazioni a rendere più resilienti le singole organizzazioni e di conseguenza l’intero sistema Paese.

@RIPRODUZIONE RISERVATA

Articolo 1 di 5