Fino a qualche tempo fa se ne parlava poco, ma adesso quasi ogni discorso che sento sul rischio inizia più o meno così: “Probabilità per impatto, prima di tutto valutiamo gli impatti. Per quanto riguarda le probabilità, dati reali utilizzabili nel contesto della sicurezza ICT ce ne sono pochi, perché…” (segue una serie di motivi). “Quindi, possiamo fare una valutazione qualitativa, o semi-quantitativa, usando…” (segue una serie di trucchi per dare credibilità alle valutazioni di probabilità). Al tempo. La gestione moderna della sicurezza ICT parte dalla gestione del rischio, cioè dal prodotto di due fattori, uno dei quali è in buona parte tarato. Se vogliamo, è una situazione che ho visto più volte: tutti dicono che un certo strumento non funziona, ma continuano ad usarlo perché non c’è di meglio, senza però cercare realmente un’alternativa. Formalmente è tutto corretto, ma nella pratica i dati di appoggio non ci sono, e sembra che ci sia una sorta di attesa che prima o poi da qualche parte questi dati, miracolosamente, saltino fuori.
Le riflessioni che seguono derivano dall’attività di ricerca che sto svolgendo in collaborazione con il Dipartimento di Informatica dell’Università di Pisa, attività che cerca anche di dare una risposta ad una richiesta che ci ha fatto un partner dell’industria.
Quello che cerchiamo di definire è una metodologia di prioritizzazione delle vulnerabilità, per capire quali sono le più urgenti da eliminare. Perché poi, alla fine, nella sicurezza ICT il problema si riduce a questo: individuare, implementare e gestire delle contromisure adeguate alle nostre vulnerabilità, reali o potenziali, in modo da ridurre il rischio ad un livello accettabile. E questo in un’ottica di priorità, dato che essendo la disponibilità di fondi limitata, è generalmente necessario scegliere di elimnare per prime le vulnerabilità più critiche.
Rivediamo allora il nostro problema iniziale. Il nostro scopo è, e rimane, proteggere i processi di business aziendali. Per fare questo, proviamo a partire dalle informazioni che abbiamo, invece di partire da una valutazione della probabilità. Conosciamo l’architettura del nostro sistema informativo, le risorse critiche del nostro sistema, gli impatti che la loro perdita o danneggiamento avrebbe sul business aziendale (il secondo fattore che compone il rischio). Conosciamo anche le minacce, o meglio gli agenti di minaccia: un semplice elenco di questi, con le risorse che hanno a disposizione per l’attacco, è un’informazione più facile da ottenere rispetto a una probabilità. In effetti, in mancanza di dati statistici, una valutazione degli agenti di minaccia è uno dei fattori sui quali spesso viene “costruita” la probabilità. Infine, conosciamo le vulnerabilità del nostro sistema, reali o potenziali.
Cosa si può fare con i dati che abbiamo, prima di metterne di “valutati”? La base del lavoro che stiamo facendo cerca di dare uno strumento rigoroso ma di ragionevole usabilità che permetta di stabilire se e come i diritti sul sistema che una minaccia acquisisce mediante attacchi che sfruttano le diverse vulnerabilità, le permettono alla fine di acquisire diritti sulle risorse critiche del sistema. Lo scopo è capire quali vulnerabilità sono più critiche sotto questo aspetto, in modo da dare una priorità alle vulnerabilità che possono portare a impatti maggiori, e da scegliere delle contromisure adeguate. Se interessa approfondire la cosa, ho fatto una presentazione a SMAU l’anno scorso.
Il punto che qui vorrei discutere è un altro. Supponiamo di essere riusciti a stabilire, con il nostro strumento o un altro, che una certa minaccia è in grado di sfruttare una o più vulnerabilità per acquisire i diritti necessari per operare (leggere, cancellare o altro) su una risorsa che le interessa e che per noi è critica. Ad esempio, studiando il nostro sistema informativo, vediamo che un nostro concorrente sarebbe certamente in grado, sfruttando un certo insieme di vulnerabilità del nostro sistema e con le risorse che puo mettere in campo, di attaccare da Internet il nostro sistema e arrivare a leggere le informazioni segrete su qualche nostro prodotto o brevetto. Si tratta di un’informazione che riusciamo ad avere senza bisogno di tirare in ballo le probabilità. Dove entrano allora in gioco le probabilità, che certamente fanno parte del concetto di rischio? Un primo punto riguarda le vulnerabilità: se noi non trattiamo solo le vulnerabilità effettive e note del nostro sistema, ma anche quelle ipotetiche, possiamo allora associare una probabilità che queste vulnerabilità ci siano effettivamente.
Il punto in cui la probabilità entra realmente è però un altro. Sappiamo che il nostro concorrente può, e già ieri poteva, attaccare i nostri sistemi per arrivare alla formula segreta, che certamente gli interessa. Perché non lo ha ancora fatto? Ovvero, perché la probabilità che lo faccia, in un certo intervallo di tempo, non è del 100%? Ci sono una serie di fattori che possono mitigare il rischio: non conosce i nostri sistemi (e non sa quanto gli sarebbe facile arrivare alla formula segreta 😉 ), ci vuole del tempo per preparare l’attacco, ritiene che il rischio di essere scoperto sia troppo alto, è onesto… se noi conoscessimo con certezza qualcuno di questi fattori, potremmo trattarlo direttamente ed eliminarlo. Ad esempio, se il concorrente è onesto, la probabilità (per quell’agente di minaccia) scende a 0, mentre se l’onestà per lui non è un vincolo, smette di essere un fattore di mitigazione. La probabilità si riduce quindi ai fattori sui quali non abbiamo informazioni certe, il che è coerente sia con l’uso che ne viene normalmente fatto nella gestione del rischio, sia con la difficoltà che abbiamo a trovare dati utilizzabili nel settore ICT. Questa logica dei fattori di mitigazione, anziché quella inversa della “probabilità che un attacco venga praticato”, secondo me permette di disaggregare meglio i fattori che compongono la probabilità, e quindi di valutare esplicitamente tutto il valutabile: non ci serve una statistica di attacchi alle banche USA per decidere se il nostro concorrente è abbastanza disonesto da attaccare i nostri sistemi, e non ci servono le statistiche degli attacchi su Internet per decidere se un nostro dipendente ha motivazioni e competenza per praticare un attacco. Possiamo usare invece le statistiche più semplici, ad esempio sui tempi fra la scoperta di una vulnerabilità, la pubblicazione di un exploit e il suo utilizzo massiccio, per decidere qual’è l’urgenza nell’applicare una patch.
Cosa cambia quindi nel nostro approccio? Che prima di tutto cerchiamo di lavorare tutta l’informazione che abbiamo, l’attenzione è focalizzata sul sistema e non sull’alea. Una volta stabilito che un insieme di vulnerabilità permette a un concorrente di arrivare alla formula segreta, i fattori di mitigazione, quando riusciamo a valutarli, ci diranno semplicemente quanto possiamo aspettare prima di risolvere il problema. Se non riusciamo a trovare un buon motivo per cui il concorrente non debba agire già domani, consideriamo la probabilità del 100% e ci muoviamo di conseguenza, basandoci solo su quello che abbiamo realmente in mano: una prioritizzazione delle vulnerabilità data dagli impatti che gli agenti di minaccia possono causare grazie a quelle vulnerabilità.
Gli articoli più formali relativi a questa (e altre) attività sono disponibili qui.
