Valutazione della criticità di una vulnerabilità: la dipendenza dal sistema

Un problema che i proprietari e gli amministratori di un sistema devono spesso affrontare è quello di decidere come intervenire sulle vulnerabilità di un sistema. In particolare, è importante stabilire un ordine tra le varie attività che devono eliminare o ridurre le vulnerabilità esistenti.

Il metodo ideale per ordinare le attività da eseguire sulle vulnerabilità che affliggono i vari componenti di un sistema è quello che considera il rischio associato alla singola vulnerabilità. Condizione preliminare per applicare questo metodo è scegliere la definizione di rischio associato ad una vulnerabilità. Comunque, tutte le definizioni attualmente in uso concordano sul fatto che il rischio aumenti in funzione di due valori: la probabilità che la una minaccia sfrutti la vulnerabilità ed il danno che la minaccia può così generare.

Valutare il rischio associato alla singola vulnerabilità, permette di produrre un ordinamento o ranking tra le vulnerabilità in base al rischio e quindi di intervenire sulle vulnerabilità nell’ordine definito. In questo modo, le contromisure per mitigare o eliminare il rischio vengono applicate a partire dalle vulnerabilità più pericolose. In un sistema ICT di media complessità, il numero di vulnerabilità su cui intervenire è generalmente elevato e definizione di un ranking è un problema estremamente complesso. Occorre quindi adottare soluzioni non esatte, che approssimano il valore del rischio a partire da due aspetti: le caratteristiche intrinseche della vulnerabilità, ad esempio la facilità di eseguire l’attacco che la sfrutta, la criticità ed il ruolo nel sistema complessivo. del componente che è affetto dalla vulnerabilità.

Un punto da tenere ben presente è che sistemi diversi possono utilizzare gli stessi componenti in modo diverso. Questo fatto incide, e deve incidere, quindi, sulla valutazione del rischio di ogni sistema e quindi anche sul ranking. Consideriamo, ad esempio, una vulnerabilità che affligge un web server e supponiamo che nel sistema in esame esistano due istanze di questo web server. In questo esempio, la prima istanza è collegata direttamente ad un database, mentre, la seconda istanza è collegata ad un altro database attraverso una connessione filtrata da un firewall. È evidente come il ranking debba valutare la stessa vulnerabilità, replicata nelle due istanze, in modo diverso in base all’istanza del componente che si considera.

Per approfondire i problemi posti dalla definizione di un ranking tra le vulnerabilità a partire da una valutazione approssimata del rischio, consideriamo uno delle più noti metodi approssimati attualmente in uso: il Common Vulnerability Scoring System (CVSS). Questo standard aperto è stato in origine definito dallo National Infrastructure Advisory Council (NIAC) che ha analizzato il problema negli anni 2003/2004. Questa analisi ha portato alla definizione della versione 1 del CVSS nel Febbraio 2005. Attività successive sullo standard sono state delegate al Forum of Incident Response and Security Teams (FIRST) fino alla definizione della versione 3 nel 2015.

Nel caso del CVSS è più corretto parlare di metrica e non di strategia di ranking, infatti esso calcola, per ogni vulnerabilità, un valore numerico da 0 a 10, proporzionale al rischio che la vulnerabilità genera. In questo caso, l’ordinamento tra le vulnerabilità avviene unicamente in base al valore calcolato per ognuna. In generale, un valore maggiore di 9 indica una vulnerabilità critica che deve essere eliminata non appena possibile. Invece, valori minori di 4 sono associati a vulnerabilità che possono essere eliminate in tempi più lunghi.

La metrica CVSS assume, innanzitutto, che la minaccia conosca già tutte le vulnerabilità del sistema target. Il valore che CVSS associa ad una vulnerabilità è prodotto componendo i valori generati da tre metriche più semplici:

di base,
temporale
ambientale.

Ognuna delle tre metriche è definita componendo metriche più semplici. Al di là dell’apparente complessità, tutto il procedimento è estremamente semplice una volta definite le singole proprietà di ogni vulnerabilità che le singole metriche considerano. I valori generati dalle singole metriche sono trasformati in un unico valore mediante somme pesate che assegnano al valore generato da ogni metrica un peso predefinito ed indipendente dal sistema target.

La metrica di base del CVSS considera le caratteristiche intrinseche di una vulnerabilità. Queste sono le caratteristiche che non cambiano con il tempo e che non dipendono dal sistema considerato. Esse vengono valutate a partire da tre sotto-metriche: Exploitability, Authorization Scope ed Impact. E(V), l’exploitability di una vulnerabilità V, valuta la facilità di implementare un attacco che sfrutti V e gli strumenti disponibili per eseguire questo attacco. E(V) dipende non solo da V, ma anche dal componente che è affetto da V. Infatti, questo componente contribuisce a definire gli attacchi possibili ed i meccanismi che la minaccia può sfruttare per realizzare il singolo Possibili meccanismi sono la manipolazione di parametri di procedure e funzioni o di protocolli di rete, la trasmissione di valori maligni in form web o di query malevoli su un database. Di conseguenza, la metrica E(V) considera non tanto le proprietà di V ma quelle dell’attacco che V abilita. In particolare, le proprietà di interesse di un attacco sono:

il tipo di accesso richiesto per l’esecuzione dell’attacco;
la complessità dell’esecuzione;
i privilegi che l’esecuzione richiede;
la necessità di un’interazione con l’utente legittimo.

Per ogni proprietà, la metrica considera alcuni possibili casi ed associa ad ogni caso un valore numerico che poi verrà utilizzato come valore in ingresso della formula che calcola il rischio associato. I valori sono tanto più vicini ad 1 quanto più è semplice eseguire l’attacco ed il valore della metrica risultante è il prodotto dei valori stabiliti per ogni proprietà.

La metrica considera i quattro tipi di accesso che la minaccia deve avere per poter eseguire l’attacco. Il rischio è minimo se l’attacco richiede un accesso fisico alla macchina, cresce se l’accesso è solo logico e diventa massimo quando la minaccia può eseguire l’attacco inviando da remoto un pacchetto malevolo alla macchina.

La complessità dell’esecuzione dipende dalla capacità della minaccia di creare autonomamente le condizioni necessarie per lanciare l’attacco. In particolare, il rischio diminuisce se l’attacco richiede delle condizioni particolari che l’attaccante non può produrre autonomamente. Il rischio aumenta e si avvicina al massimo se l’attacco non richiede condizioni particolari, o se, comunque, l’attaccante è in grado di produrre facilmente tali condizioni.

I privilegi richiesti possono andare dall’insieme vuoto a quello dei privilegi utenti o di amministrazione. Maggiore è il numero di privilegi, minore è il rischio. Infine, il rischio si riduce se l’attacco può essere eseguito solo quando un utente legittimo del sistema esegue delle specifiche azioni, e.g. apre o chiude un certo file. È evidente che la focalizzazione sulle azioni necessarie per eseguire l’attacco permetta di trascurare le correlazioni con il sistema in esame.

La metrica Authorization Scope, introdotta nella versione 3, valuta la capacità di V di coinvolgere autorità diverse nell’attacco. Un esempio possibile è quello di vulnerabilità che permettano di violare una macchina virtuale o una sandbox. In questo caso, l’attacco coinvolge, ad esempio, sia l’amministratore della macchina virtuale che quello della macchina fisica che esegue quella virtuale. Si compie quindi un primo passo per la contestualizzazione del singolo componente affetto da V nel sistema in cui tale componente è immerso.

I(V), la metrica Impact della vulnerabilità V, valuta l’impatto degli attacchi abilitati da V, cioè i danni per chi controlla il sistema ICT, dovuti al successo di uno di tali attacchi. In generale, il componente affetto da V può essere un modulo o una libreria software. Notabili eccezioni sono state di recente le vulnerabilità Spectre e Meltdown che coinvolgono il processore utilizzato. I componenti che generano l’impatto I(V) possono essere non solo hardware e software ma anche collezioni di dati. La metrica I(V) è basata sulla classica triade di disponibilità, confidenzialità ed integrità e distingue tra perdita bassa, media ed alta di ognuna delle tre proprietà. Anche questa metrica associa agli impatti possibili valori numerici nell’intervallo 0..1, ed il suo valore è uguale al prodotto dei valori. È opportuno sottolineare che la metrica non aiuta in nessun modo la scelta del valore da utilizzare per la specifica vulnerabilità. Inoltre, la metrica fa riferimento agli impatti sul componente, mentre spesso quello che interessa è valutare l’impatto complessivo sul sistema e non sul componente. In molti casi, è quasi ovvio decidere se un attacco che sfrutti V risulti in una perdita in uno o più delle tre proprietà, mentre in molti altri la definizione dell’impatto globale è molto più complessa. Consideriamo, ad esempio, una vulnerabilità come Meltdown o Spectre che può provocare una perdita di confidenzialità. Gli effetti di tale perdita sono quasi totalmente dipendenti dal ruolo nel sistema target del componente affetto dalla vulnerabilità. Se, ad esempio, questo componente ha un ruolo di autenticazione degli utenti, la perdita di confidenzialità può permettere ad una minaccia di sfruttare un account legittimo per eseguire altri attacchi che sfruttano vulnerabilità assumendo il ruolo di un utente o di un amministratore Questo è un esempio in cui una vulnerabilità V, che provoca la perdita di confidenzialità di informazioni in un componente, semplifica l’esecuzione di altri attacchi, ovvero l’attacco che sfrutta V modifica il valore di E(V’) per una vulnerabilità V’ diversa da V. In altri casi la perdita di confidenzialità può provocare problemi di privacy o la perdita di proprietà intellettuale.

La necessità di distinguere quali componenti siano affetti da una stessa vulnerabilità, evidenzia come ogni metodologia che voglia definire un ranking delle vulnerabilità non possa trascurare le catene di attacco. Infatti, raramente ad una minaccia è sufficiente eseguire un solo attacco per raggiungere i privilegi sul sistema target. Piuttosto, è molto più frequente il caso in cui l’attaccante debba comporre sequenzialmente i suoi attacchi, costruendo in questo modo una catena di attacchi. Una catena permette all’attaccante di sfruttare i privilegi ed i diritti ottenuti grazie agli attacchi precedenti per eseguire quelli successivi, fino ad ottenere tutti i privilegi di interesse. Quali catene siano possibili e quali l’attaccante scelga è un problema di sistema e non del singolo componente o della singola vulnerabilità. Infatti, ogni catena comprende attacchi contro componenti diversi del sistema e che utilizzano vulnerabilità diverse. Metriche focalizzate sulle singole vulnerabilità trascurano le catene di attacco ed i corrispondenti impatti.

Tramite l’introduzione di altre due metriche, il CVSS raffina il punteggio generato per V dalle tre metriche precedenti. Come detto precedentemente, infatti, il CVSS definisce una metrica temporale ed una ambientale. Come suggerito dal nome, la metrica temporale assegna a V un valore che tiene conto degli aspetti che possono cambiare con il trascorrere del tempo. In particolare, la metrica temporale considera:

la disponibilità di un exploit affidabile;
la disponibilità di una contromisura per gli attacchi abilitati da V;
il livello di credibilità delle informazioni su V e sulle sue caratteristiche.

Anche questa metrica definisce i valori possibili per ogni attributo ed associa un parametro numerico ad ogni valore. Ad esempio, la metrica distingue tre diversi livelli di credibilità delle informazioni che vanno da “presenza confermata con report affidabili” a “report di fonte sconosciuta e senza dettagli”. Inoltre, la metrica stima il rischio dovuto all’esistenza di un exploit pubblico con uno di quattro valori che vanno da “codice funzionante e disponibile” a “codice inesistente”. Un ranking può non applicare le metriche a cui non sia interessato oppure se non dispone di notizie affidabili su alcuni degli aspetti valutati dalla metrica.

L’ultima metrica, quella ambientale, è composta da due sotto-metriche. La prima valuta quanto una perdita di confidenzialità, integrità e disponibilità del sistema target va ad impattare sui processi aziendali. In altri termini, valuta quanto i parametri di sicurezza del sistema influenzino la sicurezza complessiva degli utilizzatori finali del sistema. La seconda sotto-metrica tiene conto del livello di personalizzazione dei moduli, ovvero degli interventi che hanno differenziato i vari moduli del sistema rispetto a quelli standard. Questa metrica vuole valutare come modifiche apportate a componenti standard oppure specifiche configurazioni possano ostacolare l’attaccante.

Al di là delle specifiche valutazioni della metrica CVSS complessiva, è evidente che l’oggettività e la ripetibilità delle valutazioni dei singoli attributi diminuiscono per le metriche diverse da quelle di base. Proprio per questo, forse, non esiste nessuno strumento automatico che supporti la valutazione.

È necessario ricordare che, attualmente, esistono metodologie alternative che ambiscono a definire un ranking più accurato e che tengono di conto del contesto del componente affetto dalla singola vulnerabilità V. Queste metodologie definiscono la posizione nel ranking della vulnerabilità V considerando le catene di attacco che si possono costruire componendo gli attacchi abilitati da V con quelli abilitati da vulnerabilità diverse da V che affliggono il sistema target. Ciò permette di superare la valutazione isolata e non contestuale degli attacchi abilitati da V. È possibile, ad esempio, che V permetta di eseguire degli attacchi estremamente pericolosi, quindi con un valore molto elevato nella metrica di base CVSS, ma che comunque non ponga nessun rischio per il sistema.

Questo accade, ad esempio, quando l’attaccante non può ottenere i privilegi necessari per eseguire tali attacchi. In altre parole, l’attaccante non può costruire una catena di attacchi che gli permetta di acquisire i privilegi necessari per eseguire un attacco abilitato da V. In maniera simile, V può abilitare un attacco non particolarmente critico ma che, all’interno del sistema target, rappresenta l’anello mancante di una catena di attacco. Ovvero, due sequenze di attacchi, che in precedenza erano singolarmente ininfluenti, possono essere unite, grazie alla vulnerabilità V in un’unica catena che permette all’attaccante di raggiungere un obiettivo con un impatto elevato. Un caso come questo può essere scoperto solo ragionando sulle catene e non sugli attacchi isolati. Tali considerazioni sono utili anche per scegliere quali contromisure è necessario applicare. Se una minaccia è in grado di eseguire alcune catene, possiamo bloccarle bloccando almeno un attacco in ogni catena. In questo caso, privilegeremo, ovviamente, le vulnerabilità che permettono attacchi condivisi, che appaiono cioè in più. Rimuovendo una vulnerabilità condivisa, infatti, si bloccano tutte le catene che utilizzano gli attacchi che essa abilita. Inoltre, per ovvie ragioni di convenienza, verranno considerate prioritariamente le vulnerabilità che garantiscono all’attaccante una probabilità di successo più elevata o che possono provocare un danno più elevato.

Per scoprire le catene di attacco contro il sistema target, si possono applicare metodologie e strumenti diversi, ma che hanno un forte elemento di similitudine. Infatti, tutte queste metodologie utilizzano strutture di tipo grafo, che sono rappresentazioni alternative di una stessa struttura logica, l’attack graph. Ogni cammino su questo grafo rappresenta una diversa catena di attacco, mentre i vari attacchi sono rappresentati, ad esempio, dagli archi di un cammino. Una cosa da evidenziare è che non tutti i cammini sono interessanti. La valutazione del rischio deve focalizzarsi su sottoinsiemi di cammini; quelli che partono dai privilegi e dai diritti che ogni attaccante può legalmente acquisire e che terminano con il controllo dei “gioielli della corona”, cioè tutte quelle risorse di interesse di un attaccante nel sistema target. Il numero di questi cammini è percentualmente trascurabile rispetto a quello di tutti i cammini del grafo. Mentre, in precedenza, sono state definite metodologie che eliminavano i cammini non interessanti solo dopo aver generato tutti i cammini, attualmente si cerca di minimizzare il numero di cammini da eliminare. Di conseguenza, le varie metodologie di analisi del rischio esistenti differiscono proprio per il numero di cammini che ognuna deve generare per scoprire le catene di attacco. Questo numero è così diverso, che la bontà di ogni metodologia può essere misurata in base al numero di cammini inutili che la metodologia è costretta a generare per poter scoprire tutti quelli utili.

Un altro parametro fondamentale per valutare una metodologia, è la capacità dia associare ad ogni catena, o cammino, la probabilità che essa abbia successo e quella che l’attaccante la scelga. Ad esempio, è estremamente difficile generare valutazioni accurate di queste probabilità a posteriori, cioè dopo aver generato tutto il grafo. Quindi, si preferiscono metodologie in cui la probabilità di generare un cammino sia correlata alla probabilità che l’attaccante lo scelga.

I problemi sopra descritti sono complessi e di non banale soluzione, ma le informazioni associate alla soluzione sono fondamentali per definire un ranking, anche approssimato, ma consistente e che non alteri in maniera significativa il rischio associato ad ogni vulnerabilità nello specifico sistema target. Un ranking non accurato può essere pericoloso anche perché può produrre un senso di sicurezza assolutamente non giustificato. Tanto maggiore è l’accuratezza della stima del rischio, tanto più accurato può essere il piano per l’adozione delle contromisure e più elevato sarà il ritorno dell’investimento in sicurezza.

Per approfondire

https://www.first.org/cvss/
Baiardi and F.Tonelli, Evaluating risk without data in Computer Fraud & Security, 2014, n. 9, pp 5 – 9, http://www.sciencedirect.com/science/article/pii/S1361372314705305
Baiardi, F.Tonelli and al., Selecting Countermeasures for ICT Systems Before They are Attacked, Journal of Wireless and Mobile Networks, Vol. 6, N.2, June 2015.
Muñoz-González, D. Sgandurra, A. Paudice, E. C. Lupu, Efficient Attack Graph Analysis through Approximate Inference, in Journ of ACM Trans. Priv. Secur., 2017, n. 3 pp. 2471-2566
Keramati, A. Akbari, CVSS-based Security Metrics for Quantitative Analysis Of Attack Graphs, 3rd International Conference on Computer and Knowledge Engineering, pp. 178-183, 2013.

A cura di: F.Baiardi, F.Tonelli

Profilo Autore

Fabrizio Baiardi

Full Professor, Università di Pisa
E' attualmente è professore ordinario di Informatica presso l'Università di Pisa dove coordina il gruppo di ricerca su ICT risk assessment and management. La sua attività di ricerca è focalizzata su strumenti e metodi formali l'automazione dell'analisi e la gestione del rischio.

Profilo Autore

Federico Tonelli

F.Tonelli ha ricevuto il dottorato in Informatica nell’Aprile del 2017 dall'Università di Pisa.
In precedenza, ha ottenuto una laurea in Informatica ed una magistrale con lode in Sicurezza Informatica dalla stessa università. Successivamente, ha vinto una borsa di studio finanziata da Enel Ingegneria e Servizi sulla ricerca di vulnerabilità in sistemi SCADA.