Un problema che i gestori di un sistema devono spesso affrontare è quello di determinare il rischio associato ad una vulnerabilità di un componente, ovvero la probabilità che tale vulnerabilità sia sfruttata da una minaccia ed il danno conseguente. Nel caso di più vulnerabilità presenti simultaneamente, valutare in modo consistente il rischio di ognuna può essere troppo complesso. In questo caso, si utilizza spesso un ordinamento, o ranking, delle vulnerabilità che valuta in modo relativo il rischio che ognuna di esse genera. Se consideriamo il numero di vulnerabilità a cui rimediare in un sistema ICT anche di media complessità, il ranking di queste vulnerabilità è un input fondamentale di ogni strategia, poiché chi applica le contromisure deve intervenire in modo prioritario partendo dalle vulnerabilità più rischiose per il sistema che deve essere protetto.

Una qualunque strategia di ranking deve, quindi, valutare il rischio integrando contemporaneamente due aspetti: le caratteristiche intrinseche della vulnerabilità e come essa va ad impattare sul sistema che utilizza i componenti affetti dalle vulnerabilità.

Una valutazione integrata è fondamentale perché, ovviamente, non si possono trascurare né le caratteristiche intrinseche della vulnerabilità, ad esempio quanto è facile eseguire l’attacco che la sfrutta, né il ruolo dei componenti attaccati nel sistema complessivo.

Per illustrare i problemi che una valutazione integrata pone, consideriamo una delle più note strategie di ranking: il Common Vulnerability Scoring System (CVSS). Nel caso del CVSS è più corretto parlare di metrica e non di strategia di ranking, visto che esso associa ad ogni vulnerabilità un valore numerico e proporzionale al rischio che la vulnerabilità genera. L’ordinamento tra vulnerabilità considera unicamente il valore associato che va da 0 a 10. La metrica CVSS assume, innanzitutto, che l’attaccante conosca già tutte le vulnerabilità da ordinare ed è definita componendo tre metriche più semplici: la metrica di base, quella temporale e quella ambientale. In maniera ricorsiva, ognuna di tali metriche è definita in base a metriche più semplici. Al di là della apparente complessità, tutto il procedimento è estremamente semplice una volta definite le proprietà di interesse di una vulnerabilità. La metrica di base del CVSS considera le caratteristiche intrinseche di una vulnerabilità, quelle che non cambiano con il tempo e che non dipendono dal sistema considerato. Queste caratteristiche 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, perché questo componente contribuisce a definire quali sono gli attacchi possibili ed i meccanismi per realizzarlo. Questi meccanismi appartengono ad un range che comprende parametri di procedure e funzione, protocolli di rete, form web o query su un database. La metrica considera non tanto le proprietà della vulnerabilità ma dell’attacco che essa abilita. In particolare, E(V) considera queste proprietà dell’attacco che V abilita:

1. il tipo di accesso richiesto per l’esecuzione;
2. la complessità dell’esecuzione;
3. i privilegi necessari per eseguire l’attacco;
4. la necessità di un’interazione con l’utente legittimo.

Per ogni proprietà vengono introdotti alcuni possibili casi; ad ogni caso corrisponde un valore numerico che poi verrà utilizzato come input della formula per il calcolo del 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.

Il tipo di accesso considera quattro casi possibili che vanno dalla necessità di disporre di un accesso fisico alla macchina, rischio minimo, a quello di poter trasmettere un pacchetto TCP alla macchina, rischio massimo.

La complessità dell’esecuzione dipende dalla capacità dell’attaccante di creare 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 mentre aumenta e si avvicina ad 1 se l’attacco non richiede condizioni particolari, o se comunque l’attaccante è in grado di riprodurle facilmente.

I privilegi richiesti possono andare dall’insieme vuoto a quello dei privilegi utenti o di amministrazione. Più grande è l’insieme di privilegi, minore è il rischio. Infine, il rischio si riduce se l’attacco richiede che l’utente legittimo del sistema esegua delle specifiche azioni. È evidente che la focalizzazione sulle azioni che l’attacco richiede permetta di trascurare le correlazioni con il sistema target.

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 la virtuale. Si compie 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. I componenti che generano l’impatto I(V) possono essere sia hardware che software ed anche collezioni di dati. La metrica di I(V) fa riferimento alla classica triade di disponibilità, confidenzialità ed integrità distinguendo tra perdita bassa, media ed alta di ognuna delle tre proprietà. Anche questa metrica introduce valori numerici, nell’intervallo 0..1, per la stima delle perdite possibili ed il suo valore è uguale al prodotto dei valori numerici, ma la metrica non aiuta in nessun modo la scelta del valore da utilizzare. Se in molti casi è quasi ovvio decidere se un attacco che sfrutti V risulti in una perdita in uno o più delle tre proprietà, in 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 del componente affetto da V. Se, ad esempio, nel sistema questo componente ha compiti di autenticazione, è ovvio che la perdita di confidenzialità permetta all’attaccante di accedere al sistema e di eseguire altri attacchi che magari richiedono l’account di un utente o di un amministratore. In altri termini, la perdita di confidenzialità, dovuta ad un componente, semplifica l’esecuzione di altri attacchi, ovvero cambia il valore di E(V’) per una vulnerabilità V’ diversa da V. Questa relazione tra due vulnerabilità in componenti diversi evidenzia come ogni metodologia che voglia definire un ranking delle vulnerabilità non possa trascurare le catene di attacco. Infatti, un attaccante sfrutta raramente un solo attacco per raggiungere il suo obiettivo. Molto più frequente è il caso in cui l’attaccante compone sequenzialmente i suoi attacchi, cioè costruisca una catena di attacchi, sfruttando i diritti ottenuti dagli attacchi precedenti per poter eseguire quelli successivi. Quale catene siano possibili e quali l’attaccante scelga è un problema di sistema, poiché ogni catena può comprendere attacchi contro componenti diversi del sistema.

CVSS raffina il punteggio che le tre metriche precedenti assegnano a V mediante altre due metriche opzionali, quella temporale e quella ambientale. Come suggerito dal suo nome, il valore che la metrica temporale assegna a V cambia nel tempo, poiché questa metrica ingloba tutti quegli aspetti che possono cambiare con il trascorrere del tempo. In particolare, la metrica temporale considera:

1. la disponibilità di un exploit affidabile;
2. la disponibilità di una contromisura per gli attacchi che V abilita;
3. il livello di credibilità delle informazioni su V e sulle sue caratteristiche.

Anche questa metrica definisce i valori possibili per ogni attributo ed il corrispondente parametro numerico. Ad esempio, la metrica introduce tre diversi livelli di credibilità che vanno da “presenza confermata con report affidabili” a “report di fonte sconosciuta e senza dettagli”. Inoltre, la metrica utilizza quattro valori per stimare il rischio dovuto all’esistenza di un exploit pubblico che vanno da “codice funzionante e disponibile” a “codice inesistente”. Un ranking può non applicare una o più di queste metriche nel caso non sia interessato alla metrica o non disponga di notizie affidabili sui valori di interesse.

L’ultima metrica, quella ambientale, compone due metriche. La prima valuta quanto una perdita di confidenzialità, integrità e disponibilità del sistema considerato va ad impattare sui processi aziendali. In altri termini, valuta quanto i parametri di sicurezza del sistema target in esame influenzino la sicurezza complessiva degli utilizzatori finali del sistema. La seconda metrica tiene conto del livello di personalizzazione del sistema, ovvero degli interventi sul sistema target che hanno differenziato i vari moduli rispetto a quelli standard. Questa metrica vuole valutare come le modifiche apportate a componenti standard 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. Inoltre, non esiste nessuno strumento di supporto alla valutazione.

È necessario dire che, attualmente, esistono metodologie alternative che vogliono produrre un ranking più accurato e che meglio tenga conto del contesto del componente affetto dalla singola vulnerabilità V. Queste metodologie definiscono la posizione del ranking della vulnerabilità V e considerano le catene di attacco in cui gli attacchi abilitati da V appaiono piuttosto che gli attacchi che V abilita in maniera isolata. È possibile, ad esempio, che V abiliti degli attacchi estremamente pericolosi, e che quindi abbiano un valore elevato delle metriche di base CVSS, ma che V non ponga nessun rischio per il sistema. Questo accade, ad esempio, quando l’attaccante non può ottenere i diritti necessari per eseguire tale attacco. In altre parole, non esiste una catena di attacchi che permetta di acquisire i diritti necessari per eseguire l’attacco abilitato da V. In maniera simile, un attacco non particolarmente critico può divenire tale se rappresenta l’anello mancante di una catena di attacco. Ovvero, due sequenze di attacchi, che erano singolarmente ininfluenti, possono essere fuse, grazie alla vulnerabilità considerata in un’unica catena che permette all’attaccante di raggiungere un obiettivo con un impatto elevato. Questi casi possono essere scoperti solo ragionando sulle catene. Ragionare sulle catene è utile anche per scegliere le contromisure da applicare. Se un attacco appare in alcune catene, possiamo renderlo ininfluente bloccando almeno un attacco in ogni catena. In questo caso, privilegeremo, ovviamente, gli attacchi condivisi, che appaiono cioè in più catene. Per ovvie ragioni di convenienza privilegeremo le contromisure che garantisco all’attaccante una probabilità di successo più elevata o che possono provocare un danno più elevato.

Per scoprire le possibili catene, 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, ad esempio, gli archi di un cammino. Ovviamente, siamo interessati ad un sottoinsieme dei cammini; quelli che partono dai diritti che ogni attaccante può legalmente acquisire e quelli che terminano con il controllo dei “gioielli della corona”, cioè le risorse di valore del sistema ICT bersaglio. Il numero di questi cammini è percentualmente trascurabile rispetto a quello di tutti i cammini. Quello in cui le varie metodologie esistenti differiscono fortemente è il numero di cammini che ognuna deve generare per scoprire le catene di interesse. Questo numero è cosi diverso che la bontà di ogni metodologia può essere misurata in base al numero di cammini inutili, che essa genera, per poter scoprire tutti i cammini utili. Un altro parametro fondamentale, per valutare la bontà di una metodologia, è la capacità di valutare la probabilità che ogni catena abbia successo e che l’attaccante la scelga. Questi problemi sono complessi e di non banale soluzione, ma che è una condizione fondamentale per definire un ranking, anche approssimato, ma consistente e che non alteri in maniera significativa il rischio associato ad ogni vulnerabilità. Tanto maggiore è l’accuratezza della stima del rischio e tanto più accurato può essere il piano per l’adozione delle contromisure e più elevato il ritorno dell’investimento in sicurezza.

A cura di: F.Baiardi, F.Tonelli

Laureato in Scienze dell’Informazione all’Università di Pisa.

E’ attualmente è professore ordinario di Informatica presso l’Università di Pisa dove coordina il gruppo di ricerca sy 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.

Ha partecipato a numerosi assessment di sistemi ICT con particolare interesse per quelli con componenti SCADA.

Attualmente è responsabile scientifico del progetto Haruspex che ha prodotto una suite integrata di strumenti per analisi e gestione del rischio.

Una lista aggiornata delle pubblicazioni scientifiche sul progetto Haruspex e dei premi ricevuti si può trovare alla pagina http://www.di.unipi.it/~tonelli/securityteam/publications.php

F. Baiardi è stato presidente della laurea in Informatica Applicata e della laurea magistrale in Sicurezza Informatica dell’Università di Pisa.

E’ stato coinvolto in vari progetti nazionali ed europei sulla valutazione della qualità dei corsi di studio e di formazione superiore. Inoltre è valutatore di progetti di innovazione tecnologica per enti pubblici e fondazioni private nazionali ed europei.

https://www.ictsecuritymagazine.com/articoli/valutazione-contestuale-della-criticita-di-una-vulnerabilita/