Leggere le vulnerabilità: linee guida per una corretta valutazione dei rischi

Saper “leggere” le vulnerabilità ed essere quindi in grado di prevenirne le conseguenze rappresenta una fase molto importante nella procedura di valutazione dei rischi.

La vulnerabilità è definita come la caratteristica d’uso di un oggetto che può essere sfruttata da una minaccia per creare effetti negativi. La vulnerabilità si differenzia dalla debolezza che, invece, è la caratteristica intrinseca di un oggetto che può condurre ad effetti negativi.

Una zattera in bambù è certamente un’imbarcazione debole: per il materiale con il quale è costruita, per lo scarso equilibrio dovuto ad un pescaggio praticamente nullo, per il peso ridotto che può sopportare, ecc. Tuttavia, non viene considerata vulnerabile dagli operatori turistici della contea di Yangshuo, in Cina, i quali offrono ai viaggiatori un tour in zattera lungo “il piccolo fiume Li” (lo Yulong); questo perché l’uso della zattera sullo Yulong, fiume dalle acque tranquille, non può essere bersaglio di alcuna minaccia.

Questa distinzione è fondamentale nel documento che l’ENISA (l’European Union Agency for Cybersecurity) ha pubblicato 14 gennaio scorso con il titolo State of Vulnerabilities 2018/2019 – Analysis of Events in the life of Vulnerabilities.

Il documento ha lo scopo di aiutare le organizzazioni pubbliche e private a:

• fare chiarezza nel vasto mondo dei riferimenti, diffusi soprattutto online, che rendono disponibili le vulnerabilità degli oggetti ICT (principalmente software);
• comprendere a fondo le caratteristiche delle vulnerabilità per scegliere con attenzione le strategie da adottare per far non subirne gli effetti negativi.

Leggere le vulnerabilità per prevenire i rischi

Perché è necessario capire a fondo le caratteristiche di una vulnerabilità? Perché questo è il primo passaggio per valutare i rischi di un effetto negativo.

Com’è noto il rischio è caratterizzato da uno scenario in cui una minaccia sfrutti una vulnerabilità per creare effetti negativi. Quindi, se nella descrizione di una vulnerabilità la considerazione della minaccia è aspecifica e questo consente di quantificare l’impatto in caso di sfruttamento a prescindere dalla singola minaccia, nella valutazione del rischio appaiono due aspetti:

• l’impatto (caratteristica derivante direttamente dalla vulnerabilità);
• la probabilità che una specifica minaccia intervenga a sfruttare la vulnerabilità.

Occorre, quindi, nella valutazione del rischio, procedere, come primo passo, alla esatta comprensione della vulnerabilità per quantificare l’impatto.

Per questo sono nate, nel tempo, diverse risorse in Rete che sono diventate uno standard de facto sui quali ENISA ha cercato di fare luce analizzandone le caratteristiche di affidabilità e approfondendo quali di queste risorse può essere davvero utile alle organizzazioni ed in che modo leggerne i contenuti.

Le risorse principali sui quali si fonda lo studio di ENISA sono:

• i dati messi a disposizione dall’organizzazione internazionale no‑profit FIRST che effettua una valutazione articolata di ogni vulnerabilità; la valutazione avviene secondo criteri denominati Common Vulnerability Scoring System di cui mette a disposizione una versione più recente (la CVSS 3.1) ed una più datata (la CVSS 2);
• i dati messi a disposizione dall’organizzazione internazionale no‑profit MITRE che descrive i possibili attacchi che la minaccia può porre in essere e, quindi, le possibili azioni per ridurne la probabilità.

Naturalmente, ENISA non ha trascurato, quale autorevole punto di raccordo, il National Vulnerability Database messo a disposizione dal National Istitute of Standards and Technology americano nonché altri database cui gli esperti di tutto il mondo fanno riferimento.

L’indagine dell’ENISA, quindi, ha raccolto tutte le vulnerabilità pubblicate, a livello mondiale, in tutto il 2018 e nei primi due quadrimestri del 2019, per un totale di 27.471 vulnerabilità caratterizzate dai seguenti elementi:

• hanno una numerazione Common Vulnerabilities and Exposures (CVE);
• hanno una valutazione CVSS 3.1 e CVSS 2;
• hanno una valutazione sulle debolezze effettuata utilizzando lo schema Common Weakness Scoring System (CWE).

ENISA basandosi anche su altre informazioni disponibili nei diversi database esaminati, ha reso possibile, con adeguate tecniche statistiche, l’estrazione di molti aspetti che sfuggono alla ordinaria lettura puntuale che molti addetti del settore svolgono quotidianamente. Si tratta, quindi, di uscire dalla routine di ogni giorno ed osservare con maggior distacco ed un certo grado di profondità il mondo dei rischi derivante dai sistemi ICT.

Leggere le vulnerabilità: sistemi di riferimento

Il sistema di misurazione delle vulnerabilità più diffuso è il Common Vulnerability Scoring System (CVSS), oggi ormai alla versione 3.1 ma che il NIST, nel suo catalogo, offre anche nella versione 2. Il CVSS si affida a tre gruppi di metriche:

• metriche di base: costituiscono il cuore della valutazione ed esprimono la severità intrinseca della vulnerabilità prescindendo dall’avanzare del tempo e del contesto operativo in cui la vulnerabilità è osservata;
• metriche temporali: sono elementi correttivi del valore calcolato con le metriche di base e che servono a tenere conto dell’avanzare del tempo e, quindi, dello stato delle tecniche di sfruttamento, della presenza di patch fornite dal produttore, ecc.;
• metriche di contesto: sono elementi correttivi del valore calcolato con le metriche di base e temporali e che, di norma, sono calcolati dall’analista del singolo ambiente in cui la vulnerabilità è presente.

L’obiettivo della misurazione è il calcolo della severità di una vulnerabilità. Nel modello CVSS la severità può assumere un valore compreso nel range da 0 a 10 e, spesso, è riportato ad una scala qualitativa ordinale secondo la seguente tabella.

Com’è possibile notare, esiste una rilevante differenza tra i valori qualitativi offerti dalla versione v3.1 rispetto alla v2: la v3.1 ha aggiunto il valore “Critica”. Tuttavia, la differenza più importante tra le due versioni è la granularità delle metriche di base che sono riportate in questa seconda tabella:

La misurazione fornita dalla v2 della CVSS viene, tuttavia, ancora utilizzata da alcuni analisti (e fornita dal NIST) per motivi di confrontabilità e compatibilità con il passato.

Inoltre, il rapporto ENISA la cita per mostrare alcune forti incongruenze tra v2 e v3.1 che possono essere fuorvianti per gli addetti ai lavori. Per esempio, esiste una forte differenza tra le medie della severità calcolate su tutte le 27.471 vulnerabilità con la versione v2 (5,75 circa) e con la versione v3.1 (7,34 circa). Inoltre, andando più a fondo sugli elementi principali della metrica di base, gli indici di correlazione tra i valori assunti nelle due modalità di calcolo per riservatezza (0.79), integrità (0.34) e disponibilità (0.38) adombrano una notevole differenza tra i due approcci.

In ogni caso, considerando le risultanze del rapporto rispetto alla CVSS v3, appaiono interessanti alcuni aspetti:

• i tre settori nei quali sono state riscontrate il maggior numero di vulnerabilità sono il settore energetico, il settore commerciale ed il settore idrico; questo deriva, probabilmente, dall’elevata complessità dei sistemi ICT che supportano questi settori ma anche dalla scarsa attenzione (rispetto ad altri settori) che, storicamente, caratterizza la messa in esercizio dei sistemi;
• i tre prodotti che hanno accusato vulnerabilità di livello “Alto” o “Critico” sono Android, Debian Linux e Acrobat DC;
• i tre produttori per i quali, tramite i loro prodotti, è stato rilevato il maggior numero di vulnerabilità di livello “Alto” o “Critico” sono Microsoft, Qualcomm (per i firmware di alcune schede per smartphone e tablet) e Google;
• le tre tipologie di software con vulnerabilità di livello “Critico” sono i web browser, i software di ausilio alla programmazione ed i sistemi operativi.

Un’attenzione specifica merita l’analisi delle debolezze relative alle vulnerabilità che sono state oggetto dello studio. L’analisi di ENISA, per motivi pratici, ha estratto le 10 debolezze più frequenti nelle vulnerabilità oggetto dello studio: restrizioni improprie dei buffer, validazione impropria degli input, scorretta gestione dei privilegi, gestione impropria dei parametri dei comandi, improprio controllo degli accessi, uso della memoria libera, scrittura fuori perimetro, gestione impropria dei parametri dei comandi di sistema operativo, errata gestione dell’autenticazione.

È emerso, quindi, che, rispetto alle categorie di software e coerentemente con quanto rilevato rispetto alle vulnerabilità, quelle che contemplano tutte le 10 debolezze più frequenti sono i web browser ed i software di ausilio alla programmazione.

I sistemi di riferimento per l’apprezzamento delle minacce

L’ENISA, nel corso del suo rapporto, offre una significativa chiave di lettura fornendo alcune informazioni riferite alle minacce e schematizzate secondo l’approccio ATT&CK realizzato da MITRE. Questo approccio prevede 12 macrocategorie di possibili tattiche; ENISA, rispetto a questo modello ha potuto rilevare che:

• le tre tattiche maggiormente utilizzate, rispetto alle 27.471 vulnerabilità analizzate, sono l’elusione delle difese (Defense evasion), la scalata dei privilegi (Privilege escalation) e la persistenza (Persistence); pur essendo tattiche molto diverse tra loro, si distinguono per una certa complessità di azione rispetto alle altre;
• la più alta sensibilità all’insieme di tattiche di attacco è stata rilevata, attraverso una specifica tecnica statistica detta heatmap, per Cisco e Canonical (società che offre supporto ai software open source tra i quali Ubuntu) mentre Microsoft appare tra i produttori meno esposti.

Conclusioni

Il rapporto ENISA, quindi, ci dice che il più accorto operatore di sicurezza ICT ha bisogno, in questo momento di particolare esposizione, di disporre delle informazioni più corrette e complete rispetto alle singole vulnerabilità ma anche rispetto alle possibili minacce in un quadro di affidabilità che gli consenta interventi tempestivi ed efficaci.

Possibilmente, senza aspettare le patch che potrebbero arrivare dopo che “il danno è fatto”.