L’IT risk assessment è una disciplina consolidata e normata da precise convenzioni che rappresenta un pilastro fondamentale per le buone pratiche di gestione del rischio. Basti pensare alle linee guida del sistema qualità ISO 9001, o alle prescrizioni del National Institute of Standards and Technology (NIST). È sufficiente ricorrere all’ampia letteratura disponibile per progettare, eseguire e controllare procedure di risk assessment in modo corretto. Ma cosa serve per creare un processo “ideale”, in grado di aderire perfettamente alle esigenze e agli obiettivi della propria organizzazione?
La raccolta sistematica degli input che descrivono le caratteristiche di ciascuna linea di business costituisce una fase determinante per identificare gli asset da proteggere e rilevare tutte le minacce che li riguardano direttamente e indirettamente. Condurre interviste focalizzate assumendo anche punti di vista inusuali per mappare gli scenari di rischio è inoltre fondamentale per svolgere un censimento capace di infrangere la lente deformante della quotidianità. Non basta infatti valutare i problemi noti o plausibili. Per comprendere quali sono i veri punti deboli del network bisogna esaminare le aree tradizionalmente (e spesso sconsideratamente) ritenute sicure, evitando a tutti i costi il cosiddetto “pregiudizio di sopravvivenza”, che ben si esplica in un esempio ricorrente nel mondo del risk management.
Durante la Seconda guerra mondiale, i team di ingegneri degli Alleati cominciarono a mappare i fori di proiettile negli aerei che, dopo essere sopravvissuti alla contraerea dell’Asse, erano riusciti a tornare a casa. Sulla base delle osservazioni fatte, i tecnici suggerirono di rinforzare le aree maggiormente colpite, così da blindare i velivoli nei punti più presi di mira. Ma, secondo la vulgata, il matematico Abraham Wald suggerì un altro approccio: visto che i danni erano quelli subiti dagli aerei rientrati alla base, forse conveniva analizzare le parti della fusoliera rimaste intonse, che con ogni probabilità, dopo essere state colpite, avevano causato l’avaria degli aerei mai tornati.
A prescindere dal fatto che la storia sia del tutto vera o che sia stata amplificata dalla cultura pop, la morale non cambia: si tratta di un’intuizione felice, ed è la stessa che dovrebbero avere tutti i responsabili del risk assessment aziendale nel momento in cui si avvia un’analisi sul potenziale impatto delle minacce informatiche.
Adottando questa logica, il censimento deve dunque essere svolto a 360 gradi e riguardare asset tecnologici e umani, oltre a componenti di processo gestite da fornitori esterni, che sono sempre più soggetti e oggetti di rischio. Solo l’analisi integrata e periodicamente revisionata di tutti questi elementi e delle minacce correlate a ogni specifica entità consente di sviluppare la più ampia prospettiva possibile.
Tornando all’esempio degli aerei della Seconda guerra mondiale, non è infatti sufficiente intervenire sulla corazza della fusoliera per massimizzare la probabilità di rientro incolume. Ci sono anche altre variabili, più o meno critiche, da inserire nell’equazione, e vanno dalla quantità di carburante caricato nel serbatoio alle condizioni meteo, passando per le condizioni fisiche del pilota e la dislocazione dell’antiaerea. Per l’IT risk assessment è lo stesso. Le variabili evidenziate possono poi essere prese in considerazione o meno nella programmazione di un piano di gestione del rischio, l’importante è percepirle e valutarle.
Riuscire a minimizzare l’errore di valutazione significa d’altra parte introdurre nel processo di risk assessment una metodologia di calcolo ponderata. Secondo la letteratura accademica, la più efficace è quella che prevede una quantificazione oggettiva del rischio, in modo da poterlo tradurre in costi. Le stesse fonti, però, sottolineano come a volte questo approccio sia impraticabile, e quindi suggeriscono di ricorrere a una valutazione soggettiva, che per definizione non può essere altrettanto accurata e universalmente comprensibile.
Anche in assenza di una formula aritmetica, è tuttavia possibile almeno applicare una logica matematica efficace per tradurre una serie di pareri in una visione omogenea che abbia senso per la propria realtà organizzativa. È dunque consigliabile creare modelli ad hoc ricorrendo a specialisti del risk management, oppure adottare schemi sviluppati in altre realtà, purché siano omologhe. Del resto, una logica funzionale tende a prendere in considerazione variabili che dipendono da scenari condivisi, i quali, a loro volta, si innestano in modo coerente sul core business di riferimento.
A partire da una metodologia di calcolo ponderata in linea con la propria postura di rischio, si possono poi naturalmente operare modifiche dei parametri per specializzare e affinare ulteriormente lo schema.
Quanto detto finora, però, potrebbe risultare del tutto vano se le attività di risk assessment non sono supportate da un’ottima procedura di revisione e test di ripristino dei processi. Sulla carta, infatti, il backup può rispondere a tutti gli use case analizzati, ma la verità è che all’atto pratico non si sa mai se funzionerà come previsto fino a quando non lo si mette davvero alla prova.
Un dubbio che è meglio togliersi quanto prima, considerato il fatto che in ambito tecnologico le procedure di backup & restore rappresentano l’ultima ratio in caso di incidenti gravi o attacchi informatici andati a buon fine.
Il problema è che, come gli addetti ai lavori ben sanno, le risorse IT sono costantemente impegnate a gestire l’ordinaria amministrazione, e il tempo per pianificare e avviare sessioni di simulazione di disastri e test di ripristino è sempre più difficile da trovare. Una soluzione potrebbe essere quella di fare leva sul monkey testing, una tecnica attraverso la quale si mettono alla prova applicazioni, utenti e sistemi fornendo input casuali e verificandone il comportamento senza avvisare la popolazione aziendale. È un approccio un po’ brutale, senz’altro, ma è uno dei pochi metodi che permettono di verificare l’effettiva tenuta dei processi con una crisi controllata.
Ai tre requisiti analizzati bisogna aggiungerne un quarto, essenziale per le imprese che lavorano nel settore del Manufacturing. Se la consapevolezza dell’importanza del risk assessment sul piano dell’IT è infatti ormai universalmente diffusa, la stessa cosa non si può dire per il comparto OT (Operations Technology), al quale, di fatto, fino a pochi anni fa non era collegato nemmeno il concetto di security. Oggi invece la tutela di questi sistemi è parte integrante del lavoro di chi ha la responsabilità di stilare e gestire piani di mitigazione del rischio, e i principi che valgono per le componenti informatiche devono essere estesi anche agli asset industriali.
È d’altra parte comprensibile che ancora oggi siano solo in pochissimi ad aver accettato questa idea: della sicurezza OT balzano all’occhio i costi, mentre i vantaggi sono molto meno evidenti: quando non succede nulla, vuol dire che tutto sta funzionando come dovrebbe, e che quindi gli investimenti hanno dato i loro frutti. È un salto culturale non da poco, ma necessario, se si punta a creare un business davvero resiliente.