Cybersecurity nella PA, il ruolo dei controlli di secondo livello

La Pubblica amministrazione non può permettersi interruzioni di servizi. Un cyberattacco può bloccare l’intera attività creando, a cascata, disfunzioni e disagi anche gravissimi per i cittadini. Un sistema in grado di garantire cybersecurity adeguata deve prevedere piani operativi, procedure e linee guida che consentano la prosecuzione delle funzioni di core business anche a fronte di vere e proprie calamità. Approfondiamo i processi alla base dei  “controlli di secondo livello”.

Se, infatti, nei precedenti step il focus era principalmente rivolto alla progettazione ed all’implementazione di contromisure logiche, fisiche, amministrative e procedurali in grado di prevenire, mitigare o rimediare ai danni causati da possibili minacce esterne o interne, in questa fase è necessario concentrarsi, al contrario, sulle modalità con le quali sia possibile reagire a eventuali “fallimenti”, più o meno rilevanti e profondi, dell’architettura di protezione, che possono, a vario titolo, intaccare il perimetro di sicurezza, aumentare le vulnerabilità, rendere più fragile l’intera infrastruttura di difesa.

E’ necessario, pertanto, prevedere, con la maggior dovizia di particolari possibile, gli scenari negativi che in linea teorica possono concretizzarsi nel corso delle normali attività, con lo scopo di disegnare ulteriori meccanismi di risposta finalizzati prioritariamente a spegnere sul nascere piccoli focolai di infezione e, in seconda battuta, ad affrontare nella maniera più razionale possibile eventi di natura eccezionale che possono sfociare in vere e proprie calamità.

PA e sicurezza, l’attacco Ransomware

Proviamo ad esempio a pensare a cosa potrebbe succedere nel caso in cui, nonostante la presenza di meccanismi più o meno sofisticati di difesa come gli antivirus, i sistemi di individuazione e/o blocco delle intrusioni (conosciuti dagli addetti ai lavori rispettivamente come Intrusion Detection System – IDS e Intrusion Prevention System – IPS), uno o più computer client di un’amministrazione fossero vittime di un attacco “Ransomware” (ossia avessero contratto un virus in grado di cifrare, rendendoli inutilizzabili, tutti i file, chiedendo un “riscatto” per la loro “restituzione”). O ancora, se alcune password di sistemi anche molto importanti fossero state sottratte, diffuse ed utilizzate per effettuare accessi abusivi e non autorizzati ad informazioni sensibili.

Ci troveremmo sicuramente di fronte ad una situazione di grave pericolo, potenzialmente in grado di avere un impatto elevato sull’intera organizzazione soprattutto a causa del fatto che la prima cintura di protezione, costituita dai controlli “di primo livello”, è stata violata e che, pertanto, gli “attaccanti” si trovano in una situazione di vantaggio, essendo riusciti, in qualche modo, a penetrare tra le maglie della nostra architettura e ad avvicinarsi in maniera insidiosa al proprio obiettivo.

In termini tecnici, ci troveremmo di fronte a quello che viene universalmente conosciuto come un “incidente di sicurezza”, che, se confermato e validato nella sua gravità, deve innescare una serie di azioni, attività, procedure e verifiche in grado di tamponare nel più breve tempo possibile la falla appena generata, applicare una soluzione immediata, seppur temporanea, per riportare la situazione alla normalità ed avviare, in un secondo momento, un processo di analisi, verifica e studio finalizzato a comprendere le reali cause che hanno fatto insorgere il problema, individuare le soluzioni migliori in relazione alle informazioni ottenute e, in un’ottica di miglioramento continuo dell’intero sistema di sicurezza, apportare i correttivi ritenuti più idonei ad evitare che una simile emergenza possa ripetersi in futuro.

Incident Management: ecco gli step

Provando a delineare un quadro d’insieme, dunque, anche sulla scorta di quanto appena descritto, il processo di “Incident Management” che rappresenta, come anticipato, una prima forma di “autodifesa” del sistema ed il cui ruolo può essere in qualche modo assimilato a quello degli “anticorpi” o delle “piastrine” deputate a tamponare piccole ferite del tessuto epiteliale del corpo umano, può essere scorporato nelle seguenti macro-fasi:

• Individuazione degli eventi anomali: è del tutto evidente come il primo imprescindibile passo per una corretta gestione degli incidenti sia costituito dall’individuazione, quanto più possibile repentina, delle situazioni che esulano dalle condizioni di funzionamento standard. E’ fondamentale, a tal riguardo, implementare un efficiente sistema di monitoraggio, pervasivo ad ogni livello dell’organizzazione, che possa rilevare, idealmente in maniera automatizzata, eventi anomali e potenzialmente pericolosi, così da attivare le successive attività in tempo utile. A tal proposito, però, è importante sottolineare come il primo e più efficiente strumento di monitoraggio sia costituito dalle persone che operano quotidianamente all’interno dell’organizzazione e che devono essere adeguatamente formate, istruite e sensibilizzate non solo verso il corretto utilizzo della strumentazione ed il rispetto delle procedure di sicurezza ma anche e soprattutto verso l’individuazione di eventi inattesi e la successiva ed immediata condivisione dei dati in proprio possesso attraverso tutti i mezzi a disposizione. Pensiamo, ad esempio, ad un utente che riceva nell’arco di poche ore diverse email sospette finalizzate a carpire informazioni sensibili quali password, carte di credito aziendali, etc. E’ molto semplice, nel caso in questione, individuare la differenza intercorrente tra un’azione, pur positiva ma dall’impatto limitato, quale la cancellazione dei messaggi o la loro classificazione come tentativi di phishing all’interno del client di posta elettronica ed una, ben più efficace, rappresentata dalla notifica dell’evento al Responsabile della Sicurezza delle informazioni che potrebbe neutralizzare sul nascere, magari attraverso la previsione di regole più stringenti per le email in ingresso, un attacco potenzialmente molto pericoloso se condotto su larga scala su tutta l’organizzazione. Non deve, pertanto, stupire se tra gli indicatori finalizzati a misurare l’impatto e l’efficacia dei corsi di formazione sulla sicurezza delle informazioni sia sempre presente quello riferito all’aumento delle notifiche di incidenti da parte del personale dipendente.
• Classificazione degli incidenti: dopo aver individuato un evento ipoteticamente dannoso, è necessario associarlo, nella maniera più accurata possibile, ad una macro-classe in grado di rappresentarne la gravità, la tipologia, la natura e, al contempo, indirizzare le successive attività di “primo intervento” e risoluzione definitiva. In linea generale, è possibile prevedere le seguenti categorie di incidenti:

1. Vulnerabilità o evento di sicurezza – non si è verificato un vero e proprio incidente, ma un evento anomalo connesso ad un sistema, processo o funzione che può provocare l’avvenimento di un incidente nei prossimi o futuri avvenimenti;
2. Incidente minore – una situazione che non può avere un impatto significativo sulla riservatezza o sull’integrità delle informazioni e non può causare una mancata disponibilità a lungo termine;
3. Incidente rilevante – un vero e proprio incidente, che può comportare danni significativi a causa della perdita di riservatezza o integrità delle informazioni o può causare interruzioni nella disponibilità di dati e/o processi per un periodo inaccettabile.

• Applicazione di un rimedio immediato: il primo obiettivo, nella gestione di un incidente, deve essere quello di tamponare il problema attraverso i cosiddetti “work-around”, ossia delle tecniche di immediata implementazione che, pur non garantendo una risoluzione a lungo termine, permettono di arginare sul nascere l’evento anomale e recuperare tempo prezioso per l’individuazione delle cause scatenanti e, conseguentemente, dell’individuazione delle migliori opzioni risolutive per il caso in questione. Si faccia, ad esempio, riferimento al caso già citato in precedenza di un computer vittima di un attacco “Ransomware” potenzialmente in grado di propagarsi per tutta l’organizzazione. In una tale circostanza, un primo intervento volto a circoscrivere l’incidente potrebbe essere quello di disconnettere il dispositivo dalla rete così da preservare il resto dell’architettura da possibili infezioni. Dovrebbe, invece, essere attentamente valutata l’opzione di effettuare lo shutdown del computer, in quanto tale operazione potrebbe avere l’effetto di cancellare informazioni preziose contenute nella memoria volatile e, soprattutto, rendere più complesse, se non addirittura vanificare, le eventuali indagini di tipo forense volte a raccogliere elementi opponibili a terzi in caso di giudizio.
• Ricerca delle cosiddette “root causes”: dopo aver arginato con successo l’incidente ed essere riusciti a riportare la situazione, almeno temporaneamente, alla normalità, è necessario procedere con la ricerca delle cause scatenanti che hanno determinato l’insorgere del problema e che, se non opportunamente gestite, potrebbero generare nuovamente in futuro situazioni analoghe se non ancora più difficili da affrontare. Riprendendo ancora una volta l’esempio che ci ha guidato finora, ossia quello di un computer affetto da Ramsonware, l’idea di fondo è quella di comprendere se l’antivirus non abbia funzionato in maniera corretta, se l’utente sia stato ingannato da una email malevola o abbia utilizzato una periferica non sicura.
• Individuazione della soluzione “definitiva”: la naturale prosecuzione della fase precedente è quella della risoluzione alla radice della problematica attraverso l’implementazione di processi, procedure ed attività in grado di affrontare direttamente i fattori scatenanti alla base dell’incidente e che possono consistere, ad esempio, in ulteriori sessioni di formazione per i dipendenti, nuove implementazioni o rivisitazioni/reingegnerizzazioni di controlli tecnici, etc.
• Raccolta ed analisi delle “lessons learned”: un ultimo fondamentale step è, infine, quello rivolto all’esplicitazione ed alla condivisione dei principali aspetti positivi e negativi emersi dalla gestione dell’incidente appena chiuso. In tale contesto sarà possibile comprendere quali passaggi possano essere affinati, quali criticità sarà necessario eliminare e, dall’altro lato, individuare alcune buone prassi da riproporre perché particolarmente utili nel ciclo vita dell’intero processo di “Incident Management”.

Business continuity e Disaster recovery

E’ necessario, a questo punto, riflettere sulle possibili implicazioni della risposta ad un evento potenzialmente dannoso per l’amministrazione che, almeno in linea di principio, ossia escludendo i cosiddetti “falsi allarmi” (individuati e classificati nelle prime fasi dell’”Incident Management”), è stato generato anche a causa del fallimento della prima linea di difesa, costituita, come abbiamo avuto modo di approfondire nelle precedenti “puntate” della road-map, dai controlli di primo livello progettati, implementati e messi in esercizio in base agli esiti delle attività di risk assessment e mappatura dei processi.

In particolare, cosa succederebbe se non risultasse possibile risolvere in breve tempo un incidente e quello che inizialmente si presentava, in forma figurata, come un “principio d’incendio” si propagasse fino a bloccare totalmente una parte o la totalità delle funzionalità dei sistemi informativi, dei processi amministrativi, delle attività istituzionali?

In altri termini, quale sarebbe, ad esempio, l’impatto di un intero armadio rack non più funzionante, della perdita totale della connettività verso internet, dell’impossibilità di accedere fisicamente ad un singolo ufficio o, addirittura, a tutto lo stabile in cui sono allocati i servizi di un’amministrazione?

Ci troveremmo, in estrema sintesi, di fronte ad un secondo, e naturalmente ben più grave, fallimento: riprendendo l’esempio della città fortificata già citato nello scorso “appuntamento”, anche la seconda linea di difesa, deputata a sopperire ai possibili malfunzionamenti della cinta muraria, non è riuscita a fermare o a rallentare l’attacco esterno; archibugieri, fanti, cavalleria e soldati semplici sono stati spazzati dalla furia nemica ed ora l’intero villaggio è saccheggiato se non proprio raso al suolo.

Ci troveremmo, in sostanza, di fronte ad un disastro, potenzialmente in grado di bloccare l’intera attività, creando, a cascata, disfunzioni e disagi anche gravissimi per l’utenza e, pertanto, nel caso della pubblica amministrazione, per una porzione più o meno estesa di cittadini e popolazione.

Sarebbe, ad esempio, accettabile che un ospedale interrompesse, anche solo temporaneamente, le proprie attività a causa di un malfunzionamento esteso dei propri sistemi informativi? E’ possibile sospendere trattamenti medicali di vitale importanza perché non esistono meccanismi in grado di mitigare un danno strutturale, architetturale o anche “semplicemente” connesso ad un software o ad un apparato hardware?

Quello appena descritto è il fine ultimo di due processi tra loro profondamente interconnessi che sono universalmente conosciuti come “Disaster Recovery” e “Business Continuity” e rappresentano la chiusura ideale del cerchio perfetto in cui deve essere racchiusa l’intera architettura di sicurezza per poter garantire, in maniera completa, armonica ed uniforme, la tutela dell’integrità, della disponibilità e della riservatezza delle informazioni a vario titolo trattate all’interno dell’organizzazione.

Mutuando le definizioni fornite da ISACA, che rappresenta uno dei punti di riferimento più autorevoli a livello internazionale nel settore della sicurezza delle informazioni, è possibile affermare che la “Business Continuity Management” sia un processo strategico e tattico in grado di permettere ad un’organizzazione di rispondere a qualunque avvenimento e interruzione del business che può avere impatto sui processi aziendali di “core business”, garantendo un livello di servizio minimo accettabile predefinito.

Come avremo modo di vedere in maniera più approfondita nel resto della trattazione, per “Disaster Recovery” si intende, invece, l’insieme delle tecnologie e dei processi atti a ripristinare sistemi, dati e infrastrutture necessarie all’erogazione di servizi “core business” a fronte di gravi emergenze (disastri).

PA digitale: la continuità operativa

Alla luce di quanto affermato finora, è del tutto evidente che la predisposizione dei cosiddetti controlli di secondo livello richiede alle pubbliche amministrazioni un vero e proprio mutamento culturale perché non può prescindere dall’integrazione delle tematiche amministrative ed informatiche, che hanno rappresentato, purtroppo, finora due mondi nettamente separati fra loro.

Per comprendere al meglio la portata rivoluzionaria del concetto di “Continuità Operativa”, intesa nell’accezione più ampia che integra in sé Business Continuity, Disaster Recovery ed Incident Management, è sufficiente analizzare un ulteriore scenario di “Disastro” e valutare le conseguenze di potenziali soluzioni parziali, orientate al solo ambito informativo oppure esclusivamente a quello organizzativo.

Scenario: Cosa succederebbe se, a causa di un incendio o di un evento climatico avverso, la sede principale di una Pubblica Amministrazione non fosse più accessibile?

Soluzione parziale 1 – (Orientata all’informatica): Sarebbe sufficiente avere a disposizione un secondo sito, magari anche ben attrezzato con le più recenti tecnologie, già configurate e pronte a ripartire con i dati più aggiornati (provenienti dal backup) se i funzionari non conoscono le modalità di accesso alla nuova struttura, non esistono regolamenti che disciplinino le modalità di lavoro in caso di crisi o semplicemente non siano previsti mezzi di trasporto (ed eventualmente autisti) per permettere la migrazione del personale?

Soluzione parziale 2 – (Orientata all’organizzazione): Allo stesso modo, quale giovamento porterebbe un Piano in cui le risorse umane sono perfettamente formate ed informate, i regolamenti sono adeguatamente predisposti ma mancano le attrezzature hardware e software necessarie ad accedere ai dati?

Dagli esempi sopra riportati emerge chiaramente la complessità, ma anche la multidisciplinarietà, delle problematiche connesse alla Continuità Operativa la cui implementazione è stata variamente descritta nella vasta letteratura stratificatasi nel tempo.

Gli obiettivi della continuità operativa

Alla luce di quanto finora illustrato, è possibile affermare che la Continuità Operativa debba avere, nella PA, quale obiettivo di fondo quello di consentire al cittadino di usufruire del servizio richiesto allorquando ne abbia effettivamente necessità, abbandonando il concetto di servizio pubblico erogato secondo tempi e procedure definite unilateralmente dall’amministrazione competente.

E’ necessario, a tal fine, definire in termini oggettivi e facilmente misurabili il concetto di continuità operativa all’interno del quale, in particolare, è fondamentale, in estrema sintesi, garantire che:

• Le attività ritenute più importanti e critiche da una pubblica amministrazione siano preservate anche in caso di eventi avversi, che possono manifestarsi sotto le più svariate forme e fenomenologie (Business Continuity);
• Sia possibile ripristinare le attività più importanti in un intervallo di tempo ed a un livello qualitativo accettabili in seguito ad una “interruzione critica” che non è stato possibile evitare (Disaster Recovery);
• Siano messe a punto delle politiche e delle procedure che permettano di gestire in maniera adeguata, pianificata, razionale e tempestiva gli incidenti di sicurezza, prima che si trasformino in un disastro e che quindi inneschino le procedure di “Business Continuity” (Incident Management).

Due sono, pertanto, le variabili da considerare e monitorare in base alle diverse esigenze e mission istituzionali di ogni Pubblica Amministrazione:

• Il tempo che una PA può permettersi di attendere e che il cittadino può tollerare prima che le proprie funzioni vitali riprendano in seguito ad un disastro (la domanda da porsi è: quante ore/giorni possono trascorrere dal momento dell’interruzione forzata delle attività al momento in cui è nuovamente possibile erogare e ricevere i servizi della PA?). Tale grandezza è generalmente chiamata “Recovery Time Objective” (RTO).
• Il grado di aggiornamento delle informazioni da cui ripartire in caso di disastro (a quante ore/giorni anteriori all’evento dannoso devono risalire le informazioni in possesso dell’amministrazione?). Questa variabile condiziona naturalmente la periodicità delle operazioni di backup e viene universalmente chiamata “Recovery Point Objective” (RPO).

Nasce così un nuovo modo di rapportarsi con il pubblico servizio e con le sue deviazioni patologiche che conducono ad una interruzione la cui durata nel tempo può risultare più o meno contenuta.

I Piani di Continuità Operativa e Disaster Recovery, infatti, se da un lato permettono ad una Pubblica Amministrazione di garantire una razionale ed organizzata risposta alle emergenze, dall’altro può condurre ad una condizione virtuosa in cui la maggior parte dei servizi non subisce interruzioni (“Disaster Avoidance”).

Il nuovo Piano Triennale per l’Informatica nella Pubblica Amministrazione rappresenta, in tal senso, una preziosa opportunità per le amministrazioni italiane che possono affrontare una tematica di tale importanza con il supporto della normativa – impositiva di stringenti misure obbligatorie in grado di sensibilizzare il top management – ma anche e soprattutto delle professionalità dell’Agenzia per l’Italia Digitale, che, ormai da anni, ha avviato un processo di accompagnamento e supporto per tutti gli enti, fornendo anche strumenti di lavoro, linee guida, raccolte di buone prassi.

PA e cybersecurity: uno studio internazionale

E’ opportuno, a questo punto, sottolineare come, a livello internazionale, siano state definite e concretamente attuate, nel corso del tempo, diverse modalità operative di “Business Continuity”, sia in realtà pubbliche che private, dimensionalmente differenti fra di loro.

Un caso significativo in merito è rappresentato da uno studio effettuato dalla “Queensland University of Technology” – Brisbane, Australia (si veda a tal proposito https://research.qut.edu.au/aotf/), che ha preso in esame un sistema complesso come è quello di un aeroporto (erogatore di un servizio essenziale quale è il trasporto pubblico aereo) ed ha proposto una soluzione strategica ed operativa, fondata sull’analisi dei principali casi di successo implementati nel mondo, i cui tratti salienti possono essere, così, sintetizzati:

• Un’incisiva fase di pianificazione e di progettazione, finalizzata a prevedere le azioni che dovranno essere intraprese in concreto, il cui elemento fondante è il Piano di Continuità Operativa;
• La previsione di una forte integrazione fra i vari settori di un’organizzazione, i quali sono chiamati a partecipare attivamente alla realizzazione del Piano;
• L’individuazione di soluzioni tecnologiche adatte al contesto di riferimento, quali ad esempio la ridondanza delle infrastrutture e la presenza di un sito alternativo di “Disaster Recovery”;
• L’essenziale presenza di test periodici in grado di verificare l’efficacia e l’efficienza del Piano nel suo complesso;
• La necessità di diffondere il Piano fra tutti gli appartenenti all’organizzazione, attraverso continue campagne di sensibilizzazione finalizzate alla creazione di un elevato grado di consapevolezza dell’importanza della “Continuità Operativa” e del proprio ruolo nel caso in cui si verifichi un evento avverso.

Controlli di secondo livello: le criticità

Quanto sin qui esposto, se può apparire di più facile o comunque più lineare attuazione in una struttura tradizionalmente flessibile ed aperta al “cambiamento” come può essere quella di una società privata, risulta purtroppo, nelle pubbliche amministrazioni, da un lato estremamente innovativo e dall’altro decisamente più complesso, critico e delicato, anche in virtù dei variegati compiti istituzionali affidati agli enti centrali e periferici e, soprattutto, per la necessità assoluta di dover erogare servizi, a volte vitali (nel senso letterale del termine), senza soluzione di continuità.

Evitando di addentrarsi in questioni di carattere prettamente giuridico-amministrativo come quella concernente la natura del servizio pubblico inteso in senso lato e sulle conseguenze legali (civili, penali ed amministrative) di una sua immotivata interruzione, è immediatamente comprensibile come il mancato funzionamento di sistemi informativi sottesi al corretto e puntuale svolgimento di talune specifiche funzioni (si pensi ancora una volta all’ambito sanitario ma anche al monitoraggio dei fiumi o delle piogge, alle allerte anti-sismiche, a settori quali la protezione civile, le forze dell’ordine, etc) possa condurre a conseguenze devastanti e probabilmente incalcolabili sotto il profilo economico, sociale ed umanitario.

E’ possibile anche solo concettualmente pensare che un’architettura informatica o comunque un processo “aziendale” dal quale dipendono, in maniera diretta e senza possibilità di rimedio, interessi e beni di assoluto valore possa essere posto in produzione senza adeguate garanzie di resilienza, capacità di rispondere ad eventi imprevisti e possibilità di continuare a funzionare, seppur a ranghi ridotti, a fronte di calamità disastrose ma pur sempre possibili?

Se la risposta al precedente quesito, che potrebbe apparire retorico se non proprio mal posto, non può che essere univoca, altrettanto, purtroppo, non si può dire della concreta attuazione nei contesti reali e contingenti non solo delle nostre pubbliche amministrazioni ma anche delle loro società “controllate” o “in house”.

Anche in questo caso, è facile intuire come il concetto di continuità operativa non sia connesso esclusivamente ad aspetti digitali o tecnologici ma debba, al contrario, essere traslato a tutti gli ambiti operativi in cui gli enti quotidianamente lavorano e per i quali devono, necessariamente, fornire risposte o prestazioni concrete, affidabili, integre e quanto più possibili immuni o “impermeabili” a circostanze eccezionali, sfavorevoli o semplicemente sfortunate.

A rendere ancora più complesso, articolato e fortemente difficile da gestire l’universo della pubblica amministrazione, inoltre, contribuisce anche la natura stessa dell’apparato statale che, a causa della presenza di stringenti obblighi normativi e di regole sempre più settoriali, possiede una struttura rigida (per utilizzare un eufemismo) oltre ad una governance polverizzata e ramificata, nella quale il fisiologico equilibrio di pesi e contrappesi necessario per la salvaguardia dei principi democratici rende inevitabilmente più lento il processo di adeguamento alle innovazioni ed alle grande mutazioni.

PA digitale, le resistenze al cambiamento

Basti pensare al complesso, farraginoso ed in gran parte inattuato processo di avvio della Rete Unica della Pubblica Amministrazione che, ideata a metà degli anni ‘90 con la Direttiva del PCM “Principi e modalità per la realizzazione della Rupa” (G.U. 21 novembre 1995, n. 272), non ha mai raggiunto un adeguato grado di operatività e sta, ora, faticosamente migrando nel Sistema Pubblico di Connettività (SPC).

Inoltre – e questo è un punto essenziale ed estremamente attuale– le organizzazioni pubbliche, in virtù dell’assenza di un turnover efficace, annoverano nelle proprie file (tralasciando punte di eccellenza che è possibile rinvenire, purtroppo a macchia di leopardo, in tutta Italia ed in tutte le categorie di pubbliche amministrazioni) funzionari ancora poco inclini all’utilizzo dei moderni strumenti informatizzati e che, tutt’al più, si limitano ad apprendere solo le principali caratteristiche di alcuni programmi di video scrittura.

Infine, non può essere sottovalutato l’aspetto tecnico-economico della questione: la necessità di realizzare sempre maggiori risparmi di spesa pubblica si riflette inevitabilmente sul sistema di ricambio delle infrastrutture hardware e software che, molto spesso, risultano del tutto inadeguate rispetto alle concrete esigenze da soddisfare.

Cybersecurity PA, un processo senza fine

Il processo di progettazione, definizione ed implementazione dei controlli di secondo livello ed, in generale, la concretizzazione di un Piano di Continuità Operativa, in grado di rispondere sia ad incidenti di lieve entità che a veri e propri eventi disastrosi, rappresenta, di fatto, il momento di “chiusura” dell’’intero processo di costruzione di un’architettura posta a presidio del patrimonio informativo di un’organizzazione e, nel caso particolare della presente road-map, di una pubblica amministrazione.

Com’è facilmente intuibile, però, tale attività, pur rivestendo un ruolo di primaria importanza nell’intera infrastruttura e pur apponendo l’”ultimo” tassello di un complicato e multiforme mosaico che, come abbiamo avuto modo di vedere, travalica nettamente gli ambiti tecnici, informatici o procedurali per abbracciare le sfere amministrative, gestionali, strategiche e politiche dell’intera amministrazione, non può rappresentare il momento realmente conclusivo di un processo per sua natura iterativo, sempre aperto, dinamico e chiamato a mutare, per restare efficace ed efficiente, insieme alla realtà da difendere ed al contesto esterno in cui l’organizzazione è inserita.

Allo stesso tempo, inoltre, come vedremo nel prossimo conclusivo “capitolo”, resta da affrontare un ultimo fondamentale ambito, apparentemente “parallelo” e indipendente ma in realtà così fortemente connesso al sistema di protezione da diventarne una sua parte essenziale, integrante ed inscindibile. Ossia quello che in gergo tecnico è chiamato come “Internal Audit” e che, di fatto, rappresenta lo strumento strategico ed operativo attraverso il quale è possibile assicurare che il sistema costruito e posto concretamente in esercizio sia effettivamente funzionante e, soprattutto, rispondente alle reali esigenze della collettività, del top management, della normativa ed, in generale, di tutti gli stakeholder di riferimento.