Il nuovo CAD e la continuità operativa: un nuovo DPS? giovedì 21 febbraio 2013
Posted by andy in Business Continuity, Pubblica Amministrazione.add a comment
Il 22 Dicembre 2010 è stato definitivamente approvato il nuovo CAD (Codice per l’Amministrazione Digitale).
Oltre ai tanti obiettivi di qualità, efficienza e riduzione dei costi, all’art. 50 bis il testo prevede l’obbligo per tutti gli enti e le strutture della PA di dotarsi. entro 15 mesi, di un piano di continuità operativa e di uno per il disaster recovery.
I 15 mesi stanno per scadere, e ci si viene a trovare in una situazione analoga a quella in cui scattò l’obbligo della redazione del DPS (Documento Programmatico sulla Sicurezza), previsto dal D.Lgs. 196/2003, e obbligatorio a decorrere dal 31 Marzo 2006.
Seppur con meno fibrillazione della precedente scadenza per il DPS, qualcosa inizia a muoversi; proverò a fare il punto su quali siano realmente le implicazioni dell’art. 50 bis ed a scattare una fotografia sui diversi approcci emergenti, così da consentire a chi non avesse provato ad analizzare la situazione da vari punti di vista possa collocare l’approccio adottato e valutare le alternative.
Focalizziamoci in primo luogo su quali siano realmente gli obblighi: le pubbliche amministrazioni devono definire:
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.
Venendo ora ai principali approcci che riscontro, i più rilevanti appaiono essere i seguenti:
- l’ufficio non fa nulla, per la mancanza di risorse;
- l’ufficio prova ad analizzare realmente quali siano i punti su cui può intervenire.
- l’ufficio si affida ai fornitori, che garantiscono la compliance normativa attraverso la semplice adozione di soluzioni commerciali hardware e/o software.
L’approccio 1. può essere comprensibile: in effetti con i continui tagli alle risorse degli ultimi anni, e con quelli che prevedibilmente continueranno ad arrivare, gli uffici si trovano spesso talmente oberati di lavoro che non risulta fattibile distogliere risorse dai propri incarichi per affrontare, gestire e portare a compimento un progetto di questo tipo. In effetti, qualsiasi progetto non può ragionevolmente essere avviato senza la preventiva assegnazione di adeguate risorse.
Approccio 2: è l’ideale; si affronta oggettivamente il problema, si effettua una spassionata analisi dei rischi, e sulla base delle priorità e delle disponibilità si definisce un piano per gli interventi possibili;
L’approccio 3 è il più pericoloso: l’obiettivo passa dall’interesse della PA all’interesse del fornitore, che tende a massimizzare il proprio ritorno riducendo i costi e massimizzare i margini; a seconda dei casi, al cliente verranno proposte soluzioni che saranno un mix di consulenze, hardware e software.
Ovviamente niente è mai così semplice e definito, e le situazioni reali fanno spesso un mix dei vari approcci, fondendo i vari approcci, in base alle capacità e disponibilità dei referenti degli uffici, e dalla capacità ed insistenza dei fornitori.
Dopo tutto questo preambolo, doveroso per scattare una foto di quella che appare essere la realtà, desidero dedicare qualche parola anche alla sostanza.
Per farlo, focalizziamoci sugli obiettivi imposti dal CAD: un piano di continuità operativa, ed un piano di disaster recovery.
L’IT al giorno d’oggi è di fatto il fondamento di ogni processo operativo, e viene quindi naturale pensare che i termini ‘continuità’ e ‘disaster recovery’ vengano immediatamente associate ai sistemi informativi.
Questo è un grave errore, perché ci porta a dimenticare che l’IT non è il fine, ma il mezzo.
I sistemi, il software, la connettività non sono ciò che dobbiamo proteggere, ma strumenti a supporto dei processi che dobbiamo proteggere.
Prendendo ad esempio un qualunque edificio pubblico, come il palazzo del Comune, o quello di Giustizia, cosa accadrebbe se un terremoto che occorresse la Domenica notte ne compromettesse gravemente la struttura?
Ci si troverebbe alle 8 del Lunedì mattina con tutti gli utenti che si assiepano fuori dal palazzo, con le proprie esigenze, i propri certificati da richiedere, i propri atti da registrare, e nessun ufficio aperto, nessun sistema accessibile.
Certamente i sistemi informativi saranno stati realizzati a regola d’arte; i computer continueranno a funzionare, nel palazzo o in un’altra sede predisposta per il disaster recovery.
Ma i dipendenti dell’ufficio non sapranno cosa fare, dove sedersi, su quale tastiera mettere le mani.
È inverno, e fà piuttosto freddo; la folla all’esterno inizia a rumoreggiare; gli anziani sono già in coda dalla primissima mattina.
Inizia ad arrivare qualche vigile urbano, che non sa cosa fare, o cosa dire, se non che non è possibile accedere ai locali dell’edificio per motivi di sicurezza.
Qualcuno si è preso una giornata di permesso dal lavoro per richiedere un certificato, e senza una tempestiva ordinanza qualche condannato verrà rimesso in libertà per decorrenza dei termini di custodia cautelare.
Passa mezza giornata, e nulla è cambiato; qualche dirigente cerca di organizzarsi come può, ma non sà dove e come allestire le decine o centinaia di postazioni di lavoro per i propri dipendenti, per poter continuare a fornire il servizio dovuto ai cittadini.
Eppure i server e le applicazioni funzionano e i dati ci sono: una perfetta configurazione di disaster recovery, costata tanto hardware, software, consulenze, tempo uomo per l’installazione, le prove ed i collaudi …
E la morale qual’è? Che la continuità operativa, così come la sicurezza, non è uno ‘stato’, ma un processo, ed un processo, per essere tale, deve esistere nel tempo.
Probabilmente per l’emissione di molti certificati sarebbe stato sufficiente predisporre un piano per trasferire temporaneamente il personale presso gli uffici periferici, attivando una connessione ad hoc verso i server, ed informare i vigili urbani sulle informazioni da dare ai cittadini che si fosser presentati agli ingressi del palazzo; anche un comunicato stampa via Internet ed alle televisioni locali e regionali avrebbero potuto essere d’aiuto.
Il numero degli scenari che si possono verificare è naturalmente limitato soltanto dalla fantasia.
Tuttavia, per quanto si possa spendere in tecnologia, il giorno che accade qualcosa di anomalo, è estremamente improbabile che questa consenta di affrontare i problemi, se non è parte di un piano coordinato in cui tutte le persone coinvolte sanno come comportarsi.
Dedico anche qualche riga a tutti quei software progettati per aiutare le organizzazioni ad effettuare le proprie analisi dei rischi e a definire i propri piani di continuità e di recovery.
Si tratta di software veramente notevoli, che più sono completi ed evoluti e più costano.
Tali software hanno tuttavia alcuni difetti:
- per essere utilizzati correttamente necessitano di specialisti ben preparati;
- per fornire risultati realistici ed attendibili devono essere compilati in modo puntuale ed esaustivo;
- devono essere tenuti continuamente aggiornati a fronte di qualsiasi variazione;
Purtroppo gli specialisti sono in generale molto bravi ad utilizzare il software, ma non hanno la minima idea di quali siano i reali rischi che l’organizzazione corre, ed i risultati che emergono sono spesso in conflitto con ciò che il buon senso e l’esperienza indica come prioritario.
In pratica, il miglior compromesso per le PMI e per le organizzazioni anche grandi ma poco mature nella gestione dei propri rischi è quello di avere il supporto di uno specialista che faciliti il percorso di maturazione del processo della gestione della continuità operativa, da cui poi, con il tempo, può derivare naturalmente l’acquisto di software di supporto e di tecnologia per ridurre i costi di ripristino in caso di eventi anomali.
Self-Assessment per la migrazione verso i servizi ‘in the cloud’ sabato 9 febbraio 2013
Posted by andy in tecnologia.Tags: cloud, IaaS, Microsoft, PaaS, SaaS
add a comment
Attraverso il CSA – Italy Chapter, sono venuto a conoscenza di uno strumento messo on-line da Microsoft per valutare il proprio stato di preparazione ad accedere al cloud
Descrizione dello strumento
Metodo di valutazione
Per quanto riguarrda il metodo di valutazione, ho valutato due casi ragionevolmente ai limiti in Europa (un’organizzazione governativa con parecchie migliaia di PC, e una di produzione con pochissimi PC), e per entrambe ho compiilato il form fornendo la configurazione e quella migliore.
Pro
- semplicità d’uso: le informazioni generali richieste per la categorizzazione dell’utilizzatore sono veramente poche e chiare; anche i quesiti per l’assessment sono molto semplici e chiari, e le risposte possibili (quattro) consentono di inquadrare molto facilmente il contesto effettivamente in essere presso la propria realtà;
- semplicità di registrazione e non invasività della propria privacy;
- il report è ben schematizzato, sintetico e chiaro;
- può essere un interessante strumento per iniziare ad approcciare in poco tempo il tema del cloud e della possibilità di valutare la possibilità di appoggiarvi alcuni servizi;
- lo strumento consente di salvare più analisi, con la possibilità di modificarle e riesaminarle in momenti successivi;
- lo strumento non è di parte, nel senso che non evidenzia vantaggi e specificità dell’offerta del realizzatore.
Contro
- Lingua: al momento il sito è soltanto in lingua inglese, così come il report generato; questo potrebbe costituire un fattore limitante soprattutto per le piccole imprese;
- Tipologia di servizi cloud: al momento, lo strumento offre come unica scelta l’opzione SaaS; le opzioni IaaS e PaaS sono indicate ma non selezionabili;
- Il report è forse un po’ troppo astratto ed orientato ad un dettaglio di controlli troppo formale (NIST SP800-53), e quimdi fruibile più da uno specialista della sicurezza, piuttosto che da un’organizzazione che vuole capire quanto il cloud possa essere o meno una soluzione per elevare i propri livelli di sicurezza;
- dato che la norma di riferimento in Europa è la ISO27001, sarebbe apprezzabile avere riferimenti per il mapping dei controlli (anche) rispetto a questa norma;
- manca una presentazione intuitiva dei risultati dell’assessment e del gap esistente rispetto ad una possibile migrazione verso i servizi nel cloud;
- vengono presentati soltanto i vantaggi derivanti da una migrazione verso il cloud, omettendone invece i problemi ed i rischi.
Conclusioni
Lo strumento è ‘asimmetrico’, nel senso che, qualunque sia il risultato dell’assessment, evidenzia soltanto gli aspetti positivi di una migrazione verso il cloud, e quindi non può essere considerato completamente obiettivo in sede di valutazione; non vengono presentati in nessun modo i problemi derivanti dalla necessità di riqualificare o riconvertire le competenze del proprio personale, dei possibili rischi e dei costi nascosti.