La sicurezza dell'informazione nelle organizzazioni interconnesse

Transcript

1 La sicurezza dell'informazione nelle organizzazioni interconnesse Francesco Virili 1 Introduzione La gestione della sicurezza non è un fatto nuovo per chi si occupa di sistemi informativi, ma in tempi recenti essa ha cominciato ad assumere complessità e rilevanza crescenti. Uno dei fattori che ha certamente contribuito ad accrescere la complessità e i costi della sicurezza dell'informazione è l'enorme diffusione dei sistemi connessi alle cosiddette "unbounded networks" (Internet). Il fatto di essere permanentemente collegati a un sistema di reti geografiche di portata globale rende le probabilità di essere oggetto di attacco dall'esterno molto concrete, tanto da giustificare affermazioni come quella che segue: Nonostante gli sforzi degli esperti di sicurezza, nessuna misura può garantire che un sistema connesso ad una 'unbounded network' sarà invulnerabile agli attacchi. La disciplina della 'Survivability' può aiutare a garantire che questi sistemi possano continuare a fornire i servizi essenziali e mantenere proprietà primarie come integrità, confidenzialità e performance, nonostante la presenza di intrusioni (Tradotto da ELLISON, FISHER, LINGER, LIPSON, LONGSTAFF, MEAD, 1999, pag. 1). L'affermazione qui riportata conclude una breve analisi sulla vulnerabilità delle istituzioni finanziarie on line riportata in (VIRILI, 2001), a cui rinviamo il lettore interessato ad ulteriori approfondimenti su questo tema. Appare comunque evidente come la connessione ad Internet accresca gli aspetti di rischio e possa presentare anche particolari implicazioni dal punto di vista dell'organizzazione della funzione sicurezza, come vedremo nelle prossime sezioni. Un altro aspetto molto importante che tende ad accrescere la complessità attuale della gestione della sicurezza rispetto al passato è rappresentato dallo scenario economico e politico internazionale che la guerra globale al terrorismo innescata dagli attentati dell'11 settembre 2001 sta correntemente delineando. Per molte organizzazioni, specie in Europa, non esiste un rischio diretto e concreto di attentati terroristici che ne metta direttamente a repentaglio le risorse e la capacità di business. Esiste però un'importante componente sistemica nel rischio di attentati terroristici che può produrre conseguenze simili a quelle del temuto e ormai dimenticato "millennium bug". L'esistenza di forti interdipendenze a livello globale tra le organizzazioni di tutto il mondo fa sì che la paralisi di alcune di esse possa danneggiare indirettamente anche coloro che si trovano in relazione di business con i soggetti colpiti, con un effetto domino che si può propagare molto rapidamente fino a generare ripercussioni negative a livello di sistema. Tali effetti sono spesso destinati ad essere ulteriormente aggravati e amplificati dal gioco delle aspettative nei mercati finanziari. La difesa rispetto a questo tipo di rischi sistemici aggiunge dunque un ulteriore elemento di complessità alla gestione della sicurezza dell'informazione. Non possiamo dunque attribuire esclusivamente a fattori emotivi e passeggeri la generale crescita dell'attenzione per tutti gli aspetti della sicurezza, anche in realtà in cui il rischio di attentati terroristici rimane estremamente basso. Oggi è dunque più difficile e più importante di ieri garantire con mezzi adeguati la sopravvivenza dell'organizzazione. Accanto ai consueti rischi per eventi colposi, imprevisti o catastrofici come incendi o allagamenti e alle minacce di intrusioni "fisiche" come quelle per furto e sabotaggio, è necessario oggi fronteggiare le intrusioni "virtuali" provenienti dalla rete Internet e le incertezze 1

2 derivanti da "effetti domino" collegate al sistema in cui l'organizzazione opera. Entrambi questi fattori di rischio sono intimamente collegati alla forte e crescente interconnessione e interdipendenza delle organizzazioni. Essa, come vedremo, pur determinando delle nuove vulnerabilità, può anche essere sfruttata per mitigarle. Nelle sezioni che seguono, affronteremo dapprima il tema della gestione della sicurezza nelle organizzazioni, con particolare riguardo alla sicurezza dell'informazione; quindi ne passeremo in esame alcuni aspetti organizzativi. 2 La funzione sicurezza dell'informazione: dalla gestione in seno al CED al Business Continuity Management La gestione della sicurezza delle informazioni è nata in un contesto che era tipicamente molto diverso da quello attuale. Quando i primi sistemi corporate per la gestione amministrativa hanno cominciato a diffondersi, a partire dalla seconda metà degli anni '60, la tecnologia allora disponibile era quella dei mainframe di tipo multiterminale, ad architettura fortemente accentrata e gestiti da personale specializzato: la famiglia di mainframe IBM System 3/60, introdotta nel 1964, ha rappresentato il paradigma e il fondamento di questa concezione architetturale che si è rapidamente diffusa in tutto il mondo e costituisce ancora oggi, nelle sue successive evoluzioni, l'ossatura dei sistemi informativi di molte grandi organizzazioni. La funzione sistemi informativi era allora molto ben delimitata sia per le competenze che per le attribuzioni esclusive dei tecnici del CED; l'accesso ai terminali era molto disciplinato, riservato ad utenti autorizzati per compiti molto specifici e delimitati, con margini di libertà operativa praticamente nulli e una chiara definizione sia fisica che logica dello spettro di attività ammesse per ciascun soggetto. In un contesto di questo genere è ovvio che l'attenzione alla sicurezza dell'informazione fosse fortemente integrata con quella della gestione stessa del sistema informativo: le policy di accesso al sistema, le procedure per la duplicazione degli archivi e per la gestione dei malfunzionamenti e delle emergenze erano di appannaggio dei responsabili del CED e venivano considerate come una delle normali attività di manutenzione e gestione del sistema informativo aziendale. Date le caratteristiche di forte accentramento gerarchico, di isolamento e di ridotti contatti con l'esterno dei centri elaborazione dati, la funzione sicurezza era considerata un aspetto a bassa criticità che tipicamente veniva affrontato in ambito CED senza richiedere alcun coinvolgimento del top management. Con la successiva diffusione di tecnologie come i database management systems, i PC e le reti locali, le nuove tecnologie si sono spesso stratificate sulle vecchie senza sostituirle completamente, facendo nascere sistemi eterogenei nei quali convivono mainframe multiterminali, sistemi dipartimentali in ambiente misto (tipicamente Unix) e reti di PC con applicazioni client-server. Per di più, sempre più spesso i database aziendali alimentano server Web per la gestione delle attività di e-business dell'organizzazione. Un contesto di questo genere presenta ovviamente caratteristiche molto diverse da quello delineato in precedenza: il sistema informativo non è più isolato a facilmente controllabile, gli utenti hanno maggiore libertà e spazi di autonomia e le occasioni di contatto con l'esterno sono enormemente accresciute dalla connessione a Internet. Con la diffusione del modello client-server, le applicazioni e le basi dati distribuite richiedono procedure di gestione della sicurezza localizzate e non più fortemente accentrate; inoltre la diffusione delle applicazioni di produttività personale (come i fogli elettronici) e il loro utilizzo per elaborazioni locali è sovente sottovalutato nella pianificazione delle procedure di salvataggio dei dati e di gestione delle emergenze. Oltre ai cambiamenti imposti dall'evoluzione tecnologica e dalle nuove architetture IT che tendono ad accrescere il grado di autonomia e le capacità di comunicazione degli utenti e a determinare una distribuzione sempre più sparsa e decentrata del patrimonio informativo aziendale, i cambiamenti delle logiche di business verso modelli sempre più collaborativi e globali rendono la tradizionale 2

3 impostazione della funzione sicurezza sempre più inadeguata. Riportiamo di seguito un'osservazione che ci pare significativa in proposito: Business: anywhere, anytime, anyway sembra essere la mission implicita di molte organizzazioni. Ciò che è più importante sottolineare nel considerare i nuovi rischi collegati alle attività di business su scala globale e la relativa infrastruttura di rete globale dei sistemi informativi è il fatto che un'organizzazione è davvero forte come il più debole dei suoi collegamenti sia esso un archivio lasciato incustodito in un ufficio al Cairo, o una workstation senza password del sistema di Monaco, o piuttosto un laptop dimenticato in un aeroporto. (KRAUSE, TIPTON, 1999, pp ). Se dunque un'organizzazione è forte come il più debole dei suoi collegamenti, la gestione delle vulnerabilità non potrà limitarsi, come tradizionalmente avveniva in passato, alla protezione di un sistema interno isolato e facilmente controllabile, ma dovrà estendersi alla tutela di un flusso di informazioni condivise che coinvolge anche i propri business partner: Le grandi organizzazioni dovranno richiedere ai propri partner di e-business di adottare un insieme di regole operative che assicuri il mantenimento di livelli minimi di sicurezza. VISA ha già cominciato con i suoi partner. (PALLER, NORTHCUTT, 2000, pag. 3). Continuare a considerare la sicurezza dell'informazione come una delle normali attribuzioni della funzione sistemi informativi, di tipo routinario e di scarso rilievo strategico, non è dunque più giustificabile in molte organizzazioni moderne, per l'effetto combinato dell'evoluzione tecnologica e dell'affermazione di modelli organizzativi e processi di business globali. La tendenza attuale è piuttosto quella di dare autonomia e rilevanza strategica alla sicurezza dell'informazione, i cui molteplici aspetti vengono presi in considerazione da una disciplina che prende il nome di Business Continuity Management (o Survivability). Qui di seguito introdurremo alcuni dei concetti fondamentali del Business Continuity Management (BCM) senza ovviamente trattare l'argomento in modo esaustivo. Ci sono molte pubblicazioni di buon livello a cui il lettore interessato può fare riferimento, tra le quali indichiamo ad esempio (DEVLIN, DEVLIN, EMERSON, WROBEL, WROBEL, DESMAN, 1997; ROWAN, ROWAN; 1999, DAUGHTY, 2001a; BARNES, 2001). 2.1 Le attività di Business Continuity Management Condizione necessaria, (ma non sufficiente, come vedremo), per il Business Continuity Management è l'esistenza di un Business Continuity Plan, cioè di un piano formalizzato che preveda nel dettaglio le azioni da intraprendere nell'organizzazione in quei casi che ne possano compromettere la sopravvivenza o la continuità del business. La redazione e la gestione di un Business Continuity Plan è dunque il primo e il più importante aspetto da considerare, anche se è bene ricordare che esso è lo strumento e non il fine delle attività di BCM. La semplice redazione di un piano di continuità del business non assicura la sopravvivenza dell'organizzazione così come la redazione di un budget non garantisce di per sé il raggiungimento degli obiettivi. Le principali attività di BCM vengono da BARNES (2001, p. 19) raggruppate in cinque fasi: Project Foundation; Business Assessment; 3

4 Strategy Selection; Plan Development; Testing and Maintenance. Nella fase di Project Foundation si pongono le basi per l'intera iniziativa, a cui dovrà direttamente o indirettamente partecipare gran parte dell'organizzazione. Essa richiede dunque un'attenta preparazione iniziale, in cui è essenziale un'attenta verifica del coinvolgimento attivo del top management. In questa fase si affrontano argomenti come l'allocazione di risorse, l'analisi degli obiettivi strategici, la valutazione delle aspettative e dei tempi di realizzazione del progetto. Nella fase di Business Assessment vengono analiticamente considerate le minacce sia interne che esterne per la continuità del business dell'organizzazione. Nella fase di Strategy Selection per ciascuna delle minacce sopra evidenziate viene selezionata una delle possibili strategie di prevenzione/reazione, tenendo in considerazione sia gli aspetti di rischio che i costi associati a ciascuna di esse. Nella fase di Plan Development viene redatto e reso operativo il piano vero e proprio, che definisce la sequenza di azioni di prevenzione/reazione che l'organizzazione deve mettere in atto, ridefinendo a tal fine ruoli, mansioni e responsabilità all'interno dell'organizzazione. Nella fase di Testing and Maintenance si valuta (anche attraverso una serie di simulazioni) l'efficacia delle procedure previste dal piano e si garantisce che esso sia stato ben assimilato e messo in atto dall'intera organizzazione. Sono inoltre effettuati una serie di controlli e aggiornamenti periodici per adeguare progressivamente le strategie di BCP ai cambiamenti intervenuti nell'organizzazione. I maggiori elementi di innovazione rispetto alla gestione tradizionale della sicurezza dell'informazione sono evidenti nelle prime tre fasi: nella fase di Project Foundation il coinvolgimento del top management, l'elevata rilevanza strategica e la diffusione dei principi di BCP nell'intera organizzazione si contrappongono alla precedente tendenza a considerare questi aspetti come tipiche attribuzioni di manutenzione ordinaria da relegare nell'ambito della funzione sistemi informativi. Nelle fasi di Business Assessment e di Strategy Selection l'approccio alla individuazione delle minacce e delle contromisure da adottare è molto più evoluto rispetto agli orientamenti "classici" che erano adatti a sistemi chiusi e facilmente controllabili e si concentravano prevalentemente sulla definizione delle policy di accesso/autorizzazione degli utenti, delle procedure di backup/recovery degli archivi centrali e di ripristino della funzionalità dell'hardware in caso di malfunzionamenti. Nel BCM, invece, la metodologia di individuazione delle minacce e delle contromisure e quella di selezione delle strategie segue principi di analisi del rischio e può essere estesa all'intero sistema di business dell'organizzazione. Nella sezione che segue osserviamo più da vicino come. 2.2 Dal Business Assessment alla Strategy Selection La fase di Business Assessment prevede due importanti componenti: l'individuazione dei rischi e la valutazione dell'impatto sul business. L'individuazione dei rischi ha l'obiettivo di identificare nel modo più completo possibile tutti i possibili eventi che possano compromettere la continuità del business insieme alle misure di prevenzione che sono già in atto nell'organizzazione. Barnes (2001, pp ) fornisce una tabella esemplificativa, con tre colonne: "Minaccia"; "Conseguenze"; "Misure Preventive", dove per ogni categoria di minacce sono estensivamente 4

5 elencati i presumibili effetti negativi attesi e le misure che l'organizzazione ha già messo in atto per mitigarli. La tabella è troppo ampia per riportarla qui, per cui ci limitiamo a nominare le minacce prese in considerazione, che rappresentano un elenco parziale e non esaustivo: Tempeste/uragani; Incendi/esplosioni; Energia elettrica; Alluvioni; Guasti agli impianti di termoventilazione; Guasti alle tubazioni; Terremoti; Acqua (interruzione di fornitura/allagamenti); Guasti agli impianti di telecomunicazione; Mezzi di trasporto/mobilità del personale; Rischi relativi alla sicurezza fisica/produttività del personale; Personale esterno (intrusioni, furti, spionaggio e simili); Rischi relativi agli impianti di produzione; Rischi di vicinato; Rischi di data processing; Rischi connessi al personale. Ovviamente l'ampiezza e il contenuto di tale elenco possono variare molto a seconda delle dimensioni e del tipo di organizzazione, e devono tenere conto del grado di interazione esistente con l'esterno al fine di non tralasciare i rischi di sistema che possono essere presi in considerazione. Ad esempio, le misure preventive associate alla categoria "Guasti agli impianti di telecomunicazione" potrebbero risultare molto importanti. Alcune lezioni utili in questo senso possono essere apprese anche dal disastro del World Trade Center, secondo il resoconto che ne fece il Financial Times qualche mese dopo: Il Business Continuity Planning è salito in cima alla lista delle priorità per molte organizzazioni dopo gli attentati di settembre, ma non è un problema di semplice soluzione e richiede importanti ristrutturazioni tecnologiche e organizzative. Tra queste, è necessario un attento riesame dei sistemi di salvataggio dei dati, della infrastruttura di telecomunicazione dell'organizzazione e, molto importante, il fattore umano, cioè la garanzia che le persone chiave possano velocemente entrare in azione in caso di emergenza. [ ] Le società finanziarie devono per legge essere dotate di buoni sistemi di back-up, per cui (tra quelle che si trovavano nel World Trade Center, NdT) si sono verificate soltanto trascurabili perdite di dati. Ma ci sono stati seri problemi in un'altra area: le telecomunicazioni. Questo è avvenuto perché una grande centrale telefonica della Verizon è stata severamente danneggiata dal collasso delle torri del World Trade Center e degli edifici vicini. E l'alluvione di telefonate di parenti e amici preoccupati ha messo fuori uso il resto dell'infrastruttura. <<Se la Verizon avesse usato commutatori telefonici software, i problemi di comunicazione non si sarebbero verificati>> sostiene Michael Jaschke, manager della Siemens Carrier Networks. (FOREMSKI, 2001). Dunque in caso di applicazioni mission critical (come quelle delle grandi società finanziarie) le valutazioni di rischio si possono estendere fino a considerare l'effettiva capacità di garantire la continuità del servizio da parte dei fornitori, prendendo eventualmente contromisure appropriate attraverso accordi con terze parti, infrastrutture ridondanti/proprietarie e simili. L'obiettivo dell'individuazione dei rischi è di stabilire se le misure preventive effettivamente messe in atto siano adeguate a mitigare i rischi più rilevanti. La messa in atto di tutte le misure preventive più appropriate non basta comunque a scongiurare definitivamente il verificarsi di eventi dannosi con le relative conseguenze, per cui si rende necessaria una valutazione dei danni da essi potenzialmente prodotti e delle azioni di ripristino necessarie. A tal fine si ricorre alla Business Impact Analysis, nella quale vengono identificati i principali processi di business dell'organizzazione per valutarne la criticità, gli obiettivi di tempo di ripristino e le risorse necessarie. La Business Impact Analysis viene effettuata per ciascuna delle unità di business dell'organizzazione, intervistando i responsabili con l'obiettivo di identificare il rischio di interruzione del processo di business, le funzioni critiche ad esso associate e le risorse da cui questo dipende; è necessario inoltre stimare l'impatto finanziario e operativo di un'interruzione di servizio, la presenza di eventuali vincoli normativi, la verifica di aspetti qualitativi come l'impatto sull'immagine dell'azienda o sulla fiducia della clientela. Sulla base di questi fattori può essere 5

6 determinato il cosiddetto Recovery Time Objective (RTO), cioè il tempo entro il quale il processo deve essere ripristinato in caso di incidente per evitare che ne derivi un danno troppo elevato per l'organizzazione. Barnes (2001, pp ) fornisce un modello per i questionari da utilizzare nelle interviste e per il rapporto finale di business impact, che dovrebbe includere la lista dei processi di business critici, la valutazione delle misure esistenti di riduzione del rischio, delle raccomandazioni per migliorarle, una stima dell'impatto potenziale - finanziario e operativo - di un'interruzione dei processi di business critici, la stima del tempo massimo di ripristino (RTO) per ciascuno di essi, l'ammontare minimo di risorse necessarie per le operazioni di ripristino di ciascuno dei processi. Per il ripristino dei processi di business esistono naturalmente diverse opzioni alternative, con efficacia e costi diversi: a puro titolo di esempio in figura 1 vengono evidenziate alcune strategie alternative di ripristino delle funzionalità operative di un computer center a fronte dei costi relativi. C O S T O D E L L A Centro duplicato con mirror degli archivi STRATEGIE DI RIPRISTINO di un Centro Elaborazione Dati S T R A T E G I A Centro duplicato con copia batch degli archivi Hot site Cold site Relocate Restore Rebuild Nessuna strategia Minuti Ore Giorni Settimane Mesi TEMPO DI RIPRISTINO Figura 1: Comparazione in base al costo e al tempo necessario di diverse strategie di ripristino per un centro elaborazione dati. Da (BARNES, 2001, pag. 93). In caso di distruzione del CED, la soluzione più efficace è quella in alto a sinistra, che prevede il mantenimento di un CED identico all'originale in altro luogo, i cui archivi e programmi vengono aggiornati in tempo reale attraverso connessioni a larga banda. Questa strategia permette, anche dopo eventi distruttivi come incendi o terremoti, di ripristinare l'operatività delle infrastrutture hardware e software del CED senza perdite di dati nel giro di pochi minuti dall'incidente (ovviamente non viene qui considerato il fattore umano, nell'ipotesi che non ci siano state perdite gravi in organico). All'estremo opposto troviamo invece le strategie di rilocazione, ripristino e ricostruzione del centro che hanno costi molto inferiori ma tempi di ripristino nell'ordine di mesi, a seconda dei danni subiti. Le soluzioni intermedie sono quelle dei cosiddetti "hot sites" (uffici messi a disposizione da un fornitore che possono essere allestiti su misura e dotati dell'hardware necessario e del ripristino di programmi e archivi originali nel giro di qualche giorno) o dei "cold 6

7 sites" (spazi liberi attrezzabili messi a disposizione dal fornitore su richiesta, che possono essere allestiti nel giro di qualche settimana). SCELTA DELLA STRATEGIA DI RIPRISTINO Ammontare, $ (mancati introiti o costi di ripristino) BUSINESS IMPACT COSTI DI RIPRISTINO Strategia A Strategia B Strategia C Strategia D TEMPO DI RIPRISTINO Figura 2: La scelta tra diverse strategie di ripristino viene effettuata minimizzando la somma dei costi di ripristino e del business impact. Rielaborazione sulla base di (BARNES, 2001, pag. 92). Simili opzioni tra strategie alternative si presentano per tutti i processi di business critici presi in esame nella Business Impact Analysis: la scelta della strategia più corretta non deve dunque tenere conto soltanto degli obiettivi di tempo massimo di ripristino evidenziati nella business impact analisys, ma deve anche tentare di gestire il trade-off tra la necessità di ridurre al massimo i tempi di ripristino per attenuare il business impact evidenziato nella BIA e l'esigenza di mantenere contenuti i costi e le risorse associati alle strategie di ripristino prescelte. In figura 2 le due componenti di costo associate alla scelta della strategia vengono riportate assieme: con il crescere dei tempi di ripristino si riduce il costo della strategia di ripristino ma aumentano le perdite associate alla interruzione del processo di business (business impact). Queste coppie di curve avranno ovviamente caratteristiche diverse a seconda dei processi di business e delle strategie di recovery prese in esame di volta in volta. In questo esempio si tratta di scegliere tra quattro strategie, con tempi di ripristino crescenti e costi decrescenti man mano che si passa dalla strategia A alla strategia D. Ciò che conta è la somma dei costi di ripristino e dei mancati introiti registrati nel periodo di ripristino: passando dalla strategia A alla strategia B aumentano i tempi di ripristino, ma l'aumento del business impact è inferiore rispetto alla forte riduzione dei costi di ripristino: dunque la strategia B è preferibile alla A. A prima vista potrebbe sembrare che le migliore strategia sia C, in cui si eguagliano costi di ripristino e business impact, ma invece, come noterà il lettore più attento, la scelta corretta è quella della strategia B 1. 1 Ciò avviene per due motivi: la somma delle due componenti di costo è inferiore in B rispetto a C (passando da B a C l'aumento del business impact è superiore alla riduzione del costo di ripristino); inoltre, anche se le differenze di costo fossero trascurabili, una strategia che a parità di altre condizioni ha tempi di ripristino più bassi risulterebbe comunque 7

8 Un altro aspetto interessante è quello della stima delle probabilità associate a ciascuno degli eventi target. L'associazione di appropriati valori di probabilità agli eventi da cui l'organizzazione deve difendersi potrebbe teoricamente permettere di effettuare analisi di rischio in senso proprio, utilizzando metodologie quantitative come quella del Value at Risk (DOWD, 1998); tuttavia la difficoltà di stima oggettiva della distribuzione di probabilità degli eventi target e persino della loro volatilità, suggerisce di ricorrere a metodologie basate su valutazioni approssimative e soggettive delle frequenze, del tipo "evento quasi certo", "probabile", "difficile", "raro", che, associate ad una determinazione altrettanto approssimata delle conseguenze dell'evento, del tipo "catastrofico, "importante", "moderato", "minore" generano una griglia di analisi di rischio che può essere utile per qualificare ulteriormente la scelta delle strategie di ripristino, proporzionando le allocazioni di risorse nelle strategie di ripristino anche al grado di rischio associato all'evento temuto. Questo tipo di valutazione viene preso in considerazione, ad esempio, in (DAUGHTY, 2001b, pag. 132), che illustra come utilizzare la metodologia standard "AS4360 Risk Management". Secondo alcuni, però, in situazioni in cui la stima delle probabilità degli eventi non può essere molto attendibile, l'enfasi con cui si sostiene la rilevanza dei metodi di analisi del rischio è piuttosto eccessiva: cfr. ad esempio su questo punto le osservazioni di Bozart e Menkus: La valutazione del rischio, indipendentemente dalla metodologia utilizzata, è ancora prevalentemente questione di (1) valori stimati superficialmente da manager spesso molto impegnati in altre attività; (2) valori storici relativi a danni subiti in precedenza da altre organizzazioni che potrebbero non essere applicabili alla realtà in esame. L'applicazione di una formula matematica a questi pesi o valori nel processo di valutazione del rischio non lo rende più attendibile, non importa quanto solidi e robusti i numeri impiegati appaiano essere. (BOZART, MENKUS, 2001, pag. 350). 2.3 Il Business Continuity Plan Ultimata la scelta delle strategie di ripristino più appropriate, si passa alla vera e propria redazione del piano di business continuity che servirà per metterle in atto. Rinviando il lettore interessato al capitolo 5 di (BARNES, 2001) per una descrizione dettagliata e supportata da esempi pratici, ci limitiamo in questa sede a individuare i contenuti essenziali di un business continuity plan, che è costituito da «un set integrato di procedure e di informazioni sulle risorse che viene utilizzato per ripristinare l'operatività in caso di eventi che hanno interrotto o ostacolato le normali attività di business» (BARNES, 2001, pag. 121). Il piano ha dunque l'obiettivo di riportare l'organizzazione alla normale operatività nel più breve tempo possibile. Tipicamente esso è così strutturato: Primo intervento; Verifica dei danni subiti; Chiamata in causa e mobilizzazione dei dipendenti; assegnazione dei ruoli dei team di ripristino, attribuzione di responsabilità, definizione delle procedure; Informazioni sulle risorse necessarie in fase di ripristino: dipendenti, fornitori, clienti; Procedure di test e di manutenzione. preferibile, considerando ad esempio le possibili sinergie con gli altri processi di business e i benefici indiretti che in ogni caso sono associati ad un più rapido ripristino dell'operatività. 8

9 Come accennato in precedenza, però, perché l'organizzazione sia in grado di eseguire correttamente il piano di business continuity in caso di necessità è necessario non solo aver redatto il piano correttamente, ma anche e soprattutto aver creato adeguate condizioni organizzative, che non sono necessariamente le stesse in tutte le organizzazioni e le situazioni. Quali sono le scelte organizzative da porre in atto e in base a quali criteri? La prossima sezione prenderà in esame questo aspetto. 3 Aspetti organizzativi Nella sezione precedente abbiamo ricordato come la gestione della sicurezza dell'informazione sia nata come una delle attribuzioni tipiche della funzione sistemi informativi, per poi più recentemente tendere a coinvolgere trasversalmente tutta l'organizzazione. Dal punto di vista organizzativo questo fenomeno potrebbe essere interpretato come una migrazione delle attività di information security management dalla funzione sistemi verso una specifica unità organizzativa autonoma (tipicamente - ma non necessariamente - di staff) oppure verso una distribuzione trasversale delle stesse a più unità organizzative, oppure ancora verso una soluzione ibrida, intermedia tra le due precedenti. Nei fatti nessuna delle situazioni prospettate può essere considerata come la migliore in assoluto: a seconda dei contesti e delle esigenze può prevalerne una o anche emergerne una diversa. Un altro aspetto importante, se si costituisce una unità organizzativa autonoma, è quello della assegnazione delle responsabilità: a chi dovrebbe far capo l'unità di sicurezza dell'informazione? Un esempio particolarmente indicativo della varietà delle soluzioni possibili in proposito è quello fornito da Richard Power, il direttore del Computer Security Institute di San Francisco (CSI) in un saggio dal tono provocatorio e dal contenuto preoccupante sulle vulnerabilità dei sistemi on line (POWER, 2000). Per dare una risposta a questa domanda, Power ha organizzato una tavola rotonda con un panel di esperti del CSI Advisory Council. La domanda posta era esattamente questa: «Where should the information security unit report?». Il dibattito che ne è scaturito è estremamente interessante e occupa circa 10 pagine del libro (POWER, 2000, pp ): le soluzioni possibili menzionate sono: al Chief Information Officer (CIO); al Chief Financial Officer (CFO); al Chief Operating Officer (COO), al Quality Management; alla Direzione Generale (ma in via sussidiaria); altre due soluzioni, cioè il riporto al Software Development; o all'unità di Audit sono state considerate non condivisibili, ma spesso riscontrate nella realtà specie nelle piccole organizzazioni. In generale la risposta finale è stata che, escludendo il riporto alla funzione Sistemi Informativi e a quella di Audit, e privilegiando il riporto al CIO (quando presente), tutte le altre soluzioni possono essere plausibili, e la scelta dovrebbe essere fatta rispondendo ad una serie di domande come: quale area della tua organizzazione ha maggiore visibilità? esiste un CIO? quanto è matura la struttura organizzativa? quanto è sviluppata in senso verticale? qual è il settore industriale di appartenenza? è ad alta o bassa intensità di informazione? in che modo l'informazione rappresenta un asset per la tua organizzazione? a quali rischi si esporrebbe l'organizzazione in caso di accesso non autorizzato al proprio patrimonio informativo? e così via. Varietà e complessità ancora maggiore si può riscontrare nelle altre caratteristiche strutturali: ad esempio lo stesso Power fornisce alcune indicazioni di massima (riferite comunque ad un contesto specifico e non valide universalmente) sul fatto che il dipartimento di sicurezza dell'informazione opera di frequente in tre macroaree che andrebbero tendenzialmente separate: Strategia e pianificazione; Monitoring ; Comunicazione e disseminazione. Un aspetto particolarmente importante è quello della certificazione e del monitoring della sicurezza del software sviluppato internamente o acquisito all'esterno, specie se ad interfaccia Web. Il grado di accentramento decisionale della struttura è un altro aspetto che dovrebbe essere accuratamente studiato: in genere strutture più accentrate sono indicate in presenza di più elevati fattori di rischio; è comunque buona 9

10 norma accentrare almeno il monitoring degli ambienti di rete locale e mainframe. Un esempio di macrostruttura riportato da Power è quello di figura 3: Direttore Security Team Strategie Security Componente Team: Componente Team: Componente Team: Componente Team: Supervisore Sicurezza Fisica Norme per la Security Supervisore Security Monitoring e Amministrazione (tutte le piattaforme) Supervisore Security E- Commerce - Firewall Vigilanza Sicurezza Fisica Amministrazione Security Unix, NT Specialista Firewall Intrusion Detection Amministrazione Security IBM, DEC Security Monitoring (tutte le piattaforme) Figura 3: Una possibile configurazione della funzione information security: adattato da (POWER 2000, pag. 234). D'altro canto, soluzioni diverse in cui prevale il decentramento decisionale e la disseminazione trasversale di ruoli e responsabilità per la gestione della sicurezza sono possibili, specie nelle organizzazioni più vicine al modello della cosiddetta "learning organization", caratterizzato da sviluppo prevalentemente orizzontale, prevalenza dei ruoli sulle mansioni, forte attitudine a lavorare in team, basso grado di formalizzazione e di gerarchia, processi prevalentemente di tipo organico piuttosto che meccanico (Daft, 2001, pag. 33). In questo tipo di organizzazioni il decentramento della funzione information security avviene prevalentemente con l'attribuzione di responsabilità e ruoli relativi alla gestione della sicurezza a posizioni chiave in ciascuno dei processi di business interessati. Inoltre, la formazione, la gestione e l'eventuale messa in atto dei piani di business continuity viene garantita dalla formazione di "virtual protection team" (VPT) (KRAUSE, TIPTON, 1999, pp ). Un VPT è tipicamente formato da un responsabile della sicurezza, da consulenti legali, consulenti esterni di IT, da personale dell'aerea sistemi informativi e dell'area di EDP audit e ha il grande vantaggio di permettere un'allocazione dinamica delle risorse (che vengono destinate anche ad altre funzioni) e di poter contare su consistenti apporti anche di personale specialistico esterno all'organizzazione. All'estremo opposto possiamo invece collocare le impostazioni più tradizionali della funzione information security, che la vedono collocata in seno alla funzione sistemi informativi e ad un livello piuttosto basso della gerarchia: l'impostazione offerta ad esempio nel recente testo di Fugini, Maio e Plebani (2001, pag. 236) è di questo tenore e si pone nel solco della tradizione della disciplina della Computer Science, che attribuisce ai responsabili dei sistemi informatici la 10

11 creazione e la gestione delle policy di sicurezza: un approccio che è ancora appropriato per la gestione di sistemi chiusi in ambienti stabili e facilmente controllabili. Anche gli appunti tratti dall'esperienza professionale di Innamorati (2002, pp ) nella gestione della sicurezza aziendale 2, confermano il quadro estremamente variabile delle soluzioni organizzative adottate: anche qui viene riscontrata una molteplicità di posizionamenti possibili per l'unità di security, che può essere posta alle dipendenze dirette della Direzione Generale, del Personale, dell'ufficio Legale, dei Servizi Generali, della Programmazione e Controllo: A parere nostro, comunque, tra tutte le collocazioni possibili sono da preferire quelle che non sviliscono la vocazione interfunzionale del ruolo e che ne esaltano i contenuti, le finalità e gli aspetti interdisciplinari (INNAMORATI, 2002, pp ). Una delle soluzioni che più rispondono a questa esigenza, prosegue Innamorati, è quella della dipendenza diretta dalla Direzione Generale, che qualifica l'unità di gestione della sicurezza come Unità di staff puro. Altre collocazioni menzionate sono quella di Staff puro con sostegno funzionale, Linea pura, presente in tutte le funzioni aziendali, e quella Mista, che è presente solo nelle Unità di linea più importanti e supporta le altre come Unità di staff. Un'interessante interpretazione delle varie configurazioni strutturali riscontrabili nella pratica viene effettuata sulla base di due dimensioni di analisi: il «grado di integrazione» 3 che tiene conto di quanto le attività di security management siano accentrate un stessa unità organizzativa piuttosto che distribuite; e il «ruolo» -operativo piuttosto che di supporto professionale - rivestito. Utilizzando questo schema potremmo notare come la funzione "tradizionale" di Information Security Management in seno al CED sia tipicamente fortemente accentrata e di tipo operativo, mentre all'estremo opposto possiamo trovare i virtual protection team, con funzioni distribuite e a più elevato contenuto professionale. Un cenno doveroso va fatto alla possibilità di demandare all'esterno la gestione della sicurezza dell'informazione, ricorrendo a contratti di outsourcing. In molti casi il ricorso a partner esterni è praticamente obbligato: sarebbe impensabile ad esempio immaginare di poter usufruire di servizi di "hot sites", con un completo ripristino di un CED funzionante e operativo entro pochi giorni dalla chiamata, senza ricorrere all'assistenza di partner altamente specializzati e attrezzati; lo stesso dicasi per servizi avanzati di duplicazione on line degli archivi, come mirroring, remote hosting e simili, che mettono al riparo l'organizzazione dai rischi di perdita dei dati senza le incombenze della gestione di un'infrastruttura remota, ridondante e ad affidabilità garantita. La stipula di contratti con più fornitori alternativi per servizi chiave come quelli di telecomunicazione, può aiutare a mitigare alcuni rischi di tipo sistemico come quelli menzionati in precedenza. In generale, il fatto di essere parte di una rete di relazioni può essere considerato non solo un fattore di maggiore vulnerabilità ma anche un punto di forza per difendersi dalle minacce sfruttando partnership e sinergie. La definizione dei confini efficienti dell'organizzazione e delle conseguenti scelte di esternalizzazione di funzioni e processi apre naturalmente una serie già molto dibattuta di prospettive di analisi e discussione proprio nel punto in cui si chiude la nostra breve trattazione. Rinviamo dunque il lettore ai lavori di (VIRTUANI, 1997; CANTONI, 2001) e ai riferimenti ivi ospitati 2 Si fa qui riferimento a tutti gli aspetti della gestione della sicurezza, non soltanto alla sicurezza dell'informazione. 3 Queste due dimensioni di analisi vengono riportate testualmente con le parole dell'autore. I concetti di "integrazione" e "ruolo" vengono normalmente usati con significato affatto diverso nella letteratura organizzativa (cfr. ad esempio (GRANDORI, 1995, pag. 454 e pag. 576). 11

12 4 Bibliografia BARNES J.C., 2001, A Guide to Business Continuity Planning, Wiley. BOZART J., MENKUS B., 2001, Using Audit Resources in IT Business Continity Planning, in K. DAUGHTY (a cura di), Business Continuity Planning: Protecting Your Organization's Life, Auerbach Publications, pp CANTONI F., 2001, L'outsourcing del sistema informativo nella banca multicanale, in A. CARIGNANI, M. SORRENTINO (a cura di), On-line banking, Mc Graw Hill, pp DAFT R.L., 2001, Organizations Theory and Design, South-Western College Publishing (trad. it. NACAMULLI R.C.D, BOLDIZZONI D. (a cura di), 2001, Organizzazione Aziendale, Apogeo.). DAUGHTY K. (a cura di), 2001a, Business Continuity Planning: Protecting Your Organization's Life, Auerbach Publications. DAUGHTY K., 2001b, Selecting the Right Business Continuity Planning Strategies, in K. DAUGHTY (a cura di), Business Continuity Planning: Protecting Your Organization's Life, Auerbach Publications, pp DEVLIN E.D., DEVLIN E.S., EMERSON C.H, WROBEL L.A., WROBEL L.JR., DESMAN M., 1997, Business Resumption Planning, Auerbach Publications. DOWD K., 1998, Beyond Value at Risk: The New Science of Risk Management, Wiley, ELLISON R.J., FISHER D.A., LINGER R.C, LIPSON H.F., LONGSTAFF T.A. E MEAD N.R., 1998, Survivability: Protecting Your Critical Systems, in Proceedings of the International Conference On Requirements Engineering, 6/4/98, Colorado Springs, Colorado, FOREMSKI T., 2001, Key lessons learned in attack on New York, «Financial Times», FT-IT Review, 5 dicembre 2001, pag. III, FUGINI M., MAIO F., PLEBANI P., 2001, Sicurezza dei sistemi informatici, Apogeo. GRANDORI A., 1995, Organizzazione e Comportamento Economico, Il Mulino. INNAMORATI F., 2002, La Security d'impresa: Lineamenti generali e fondamenti tecnicoorganizzativi, Edizioni Simone. KRAUSE M., TIPTON H.F. (a cura di), 1999, Information Security Management Handbook, Auerbach Publications. (versione on line: PALLER A., NORTHCUTT S., 2000, Expert predictions for security trends in 2001, SANS Security Alert Report, 12/2000. ( ROWAN J., ROWAN S., 1999, Call Center Continuity Planning, Auerbach Publications. VIRILI F., 2001, Sicurezza e nuovi canali di distribuzione nel mondo finanziario, in A. CARIGNANI, M. SORRENTINO (a cura di), On-line banking, Mc Graw Hill, pp VIRTUANI R., 1997, L'Outsourcing nei Sistemi Informativi Aziendali, Franco Angeli. 12