Quantificare i rischi informatici

421

La gestione delle vulnerabilità dei sistemi è una complessità difficile da gestire. Il modello CVSS permette di quantificare e calibrare l’impatto teorico di una vulnerabilità, adattandolo alla specificità di un’organizzazione

I bollettini di sicurezza sono accompagnati da un livello di criticità. Tale classificazione, sebbene valida in generale, non può essere considerata esaustiva al punto di guidare le scelte aziendali o dei dipartimenti IT. Due esempi chiariscono il concetto: una vulnerabilità del sistema operativo MacOS definita critica non rappresenta un problema per l’ente che non adotta alcuna macchina Apple; e, a parità di MacOS, il livello di rischio legato a un sistema di monitoraggio cardiaco è diverso da quello di un sistema usato per fini ludici. Questi semplici esempi evidenziano un importante elemento, spesso trascurato. Infatti la criticità proposta dai bollettini di sicurezza rappresenta un valore intrinseco dell’evento in sè, e non ha nessuna relazione diretta con il livello di rischio dell’ente/utente finale. Per questo, applicare ciecamente le patch di sicurezza orientandosi solo sulla priorità definita da questi bollettini è non solo sbagliato, ma fonte di rischi e di un uso inefficace di risorse umane e finanziarie.

I modelli di calibrazione
Di questo problema sono ben consci gli addetti che producono questi avvisi, nonostante le indicazioni su come effettivamente regolarsi non accompagnino i bollettini stessi, facendo implicitamente pensare che il livello di criticità sia da adottare sic-et-simpliciter. Ci sono stati diversi studi tesi a “istanziare” questo tipo di criticità intrinseca alla situazione specifica di ciascuno, ovvero di “calibrarla” in modo da stabilire un legame quantitativo con l’entità delle azioni e degli investimenti da considerare. Il metodo attualmente più promettente, e anche quello più affermato si chiama CVSS (Common Vulnerability Scoring System).
Il CVSS nasce sotto l’egida del FIRST (Forum of Incident Response and Security Teams), organizzazione transnazionale che si pone come centro nevralgico di coordinamento tra i vari enti che si occupano di sicurezza IT (i cosiddetti CERT – Computer Emergency Response Team). La prima versione risale al 2005, poi nel giugno 2007 è stata varata la versione 2 del metodo, che è quella tuttora in uso e che, grazie alla sua maturità, ne ha permesso un’importante diffusione. La lista degli enti che lo hanno adottato cresce stabilmente e vale la pena citarne alcuni: Amazon, Cisco, HP, IBM, McAfee, NIST, Oracle, Skype, Symantec, US Department of Homeland Security.

Come funziona il CVSS
Il CVSS stabilisce il principio che per calcolare l’effettivo livello di rischio applicabile al nostro contesto si devono applicare tre gruppi di metriche. Di fatto prende un valore di rischio “di base” e lo modifica in funzione di due fattori specifici del nostro ambiente: il momento temporale in cui l’analisi è compiuta, e la specifica configurazione del nostro ambiente. Il risultato è un nuovo valore di rischio (da 0 a 10) e un vettore delle scelte che ne hanno determinato il risultato. Questa seconda informazione è fondamentale per caratterizzare nel tempo e nello spazio il risultato ottenuto, in modo che sia possibile verificarne la validità / applicabilità in altri momenti e/o contesti. Per ciascuna metrica, il CVSS offre un numero limitato di scelte e a ciascuna di esse associa un valore. Dall’aggregazione di tutti questi valori, secondo una particolare formula, si ottiene l’indice di rischio reale da considerare nella nostra organizzazione. La formula prevede inizialmente il calcolo di un indice unico che aggreghi tutte le metriche del gruppo Base, e poi pesa questo valore con il risultato prima delle metriche Temporali e poi di quelle Ambientali.
Il sistema può essere implementato con due livelli di complessità: fermarsi alle metriche di Base o estenderlo a tutte e tre le componenti. La raccomandazione è di utilizzare l’intero insieme: in tal modo si ottiene un’ottimizzazione degli investimenti e una minimizzazione del rischio residuale.

 

 Figura 1 – L’insieme di metriche CVSS, divise nei tre insiemi.

Le metriche di Base
Questo insieme permette di catturare le caratteristiche intrinseche del problema, indipendenti dall’ambiente e dal momento in cui si calcolano. La definizione potrebbe essere fuorviante, sembrando un duplicato del livello di rischio annunciato dai bollettini. In realtà ha un significato preciso, che emergerà analizzando gli altri gruppi di metriche. Abbiamo sei metriche:

 

Access Vector: che tipo di prossimità al sistema è necessaria per utilizzare la vulnerabilità? Bisogna essere fisicamente vicini, o basta avere una connessione di rete?
Access complexity: quanto è complesso effettuare l’attacco, una volta avuto accesso al sistema?
Authentication: quante volte bisogna autenticarsi prima di arrivare a poter portare l’attacco al sistema obiettivo?
Confidentiality Impact: una volta che l’attacco è riuscito, che livello di accesso alle informazioni si è ottenuto? Si possono vedere tutti i file, o solo alcuni?
Integrity Impact: una volta che l’attacco è riuscito, che livello di confidenza si ha sull’affidabilità delle informazioni contenute nel sistema?
Availability Impact: una volta che l’attacco è riuscito, qual’è l’impatto sulla utilizzabilità delle risorse del sistema compromesso?

 

Raccogliendo le scelte in una lista si ottiene il Vettore di Base. Aggregando i valori associati a ciascuna scelta si ottiene il livello di rischio di base (Base Score). Il punteggio va da 0 a 10, con 10 a indicare il livello massimo di rischio.
 

Le metriche Temporali
Questo gruppo di metriche quantifica il fatto che il livello di rischio cambia nel tempo. Ad esempio perché le tecniche di uso (exploit) della vulnerabilità si affinano, oppure perché divengono disponibili rimedi alla vulnerabilità stessa. Abbiamo tre metriche:

 

Exploitability: quanto è reale la possibilità di tradurre una vulnerabilità in un attacco concreto? Ad esempio: esiste uno script pubblico che realizza l’attacco o c’è solo una dimostrazione teorica della vulnerabilità?
Remediation Level: che tipo di soluzione esiste, se ne esiste una? Una soluzione tampone o una patch ufficiale? Questa metrica è molto importante per definire le priorità di azione.
Report Confidence: quanto è credibile la fonte di informazione sulla vulnerabilità? C’è una conferma dal produttore del sistema vulnerabile o è un insieme di informazioni conflittuali?

 

Come le metriche di Base si procede col creare il Vettore Temporale delle scelte. Fatto ciò si può calcolare il nuovo valore di rischio, correggendo il valore ottenuto in precedenza (Base Score) con i parametri delle metriche temporali. Si ottiene un nuovo valore aggregato (Temporal Score) che rappresenta il livello di rischio attualizzato. Il sistema è disegnato in modo che il Temporal Score sia minore o uguale al Base Score. Questo ci illumina sul significato reale delle Metriche di Base: esse rappresentano di fatto il livello di rischio massimo collegato ad una data vulnerabilità nella sua evoluzione temporale.
 

Le metriche d’Ambiente
Questo gruppo di metriche quantifica la specificità di una organizzazione e del suo ambiente IT. Abbiamo cinque metriche:

 

Collateral Damage Potential: Che probabilità c’è di una perdita fisica di risorse (infrastrutturali, economiche o vite umane) a seguito di furto o danneggiamento causato dall’esecuzione dell’attacco? Nel considerare perdite economiche bisogna includere anche perdite di incassi o di produttività. Anche questa è un’ottima metrica per valutare il bilancio investimenti/riduzione di rischio.
Target Distribution: Qual è la proporzione di sistemi vulnerabili rispetto all’insieme di quelli posseduti/gestiti?
Security Requirements: Confidentiality, Integrity, Reliability: queste tre metriche pesano l’impatto delle corrispondenti metriche di base, quando le applichiamo al nostro specifico contesto. Queste sono le uniche metriche che permettono di aumentare il peso delle rispettive metriche di Base, qualora l’impatto sia “alto”.

 

Anche in questo caso si procede col creare il Vettore Ambientale delle scelte. Fatto ciò si calcola il nuovo valore di rischio, correggendo il valore ottenuto dalle metriche Temporali (Temporal Score) con i parametri di queste metriche.
Il valore ottenuto con questa ultima aggregazione (Environment Score) rappresenta il livello di rischio finale corretto, ovvero quello su cui è importante basarsi per definire le proprie strategie di Risk Management e relative priorità di azione e investimento di risorse e mezzi finanziari. La documentazione referenziata fornisce tutto quanto (con tanto di tabelle, formule e valori permessi) per implementare i calcoli di CVSS nella propria organizzazione. Sebbene sia un aiuto fondamentale per un’ottimizzazione del rapporto costi/rischi, questa è solo la parte meccanica del processo. È infatti necessario che sia disegnato intorno al meccanismo di quantificazione del rischio anche un processo di management che permetta di associare a ciascun valore di Environment Score un percorso decisionale efficace. Il suggerimento è di realizzare un sistema a fasce di rischio, magari con tolleranze sul modello Prince2, con per ciascuna un insieme di azioni correttive definite preventivamente.

 

Figura 2 – Metodo di calcolo dell’indice di rischio CVSS

Per evitare valutazioni errate
Sebbene il CVSS sia disegnato per la massima semplicità ed efficacia, e la possibilità di sole scelte predefinite per ciascuna metrica rappresenti un grande aiuto, la selezione del livello di impatto per ciascuna metrica rimane un processo con una componente di interpretazione soggettiva che potrebbe condurre a valutazioni sistematicamente errate in un senso o nell’altro. Ci sono però alcune indicazioni utili ad evitare gli errori più comuni:

 

1) Considerare ogni vulnerabilità come a sè stante
2) In caso di diverse tecniche di attacco legate ad una stessa vulnerabilità, considerare quella con l’impatto maggiore
3) Se ci sono diversi metodi di accesso, considerare quello che permette la maggior distanza
4) Quando l’attacco richiede un azione locale, se questa è eseguita da terzi ignari dell’attacco, esso va considerato come remoto. Un esempio: qualcuno dentro l’organizzazione apre un file compresso ricevuto per e-mail che contiene un malware.

 

Inter-connettività globale e pervasività dell’IT sono un dato di fatto, da cui non si torna indietro. La gestione del rischio collegato alle vulnerabilità di tutti questi sistemi si presenta come una complessità oggettivamente difficile da gestire. Le organizzazioni si trovano di fronte al dilemma di incrementare significativamente i propri costi, o di accettare crescenti livelli di rischio. Il CVSS offre un modo efficace per affrontare questa sfida. Esso permette infatti di quantificare e calibrare in modo semplice l’impatto teorico di una vulnerabilità, adattandolo alla specificità dell’organizzazione stessa e del momento temporale in cui la decisione deve essere presa. Ovviamente richiede che sia costruito intorno ad esso anche un processo decisionale efficace e che il modello sia adottato nella sua interezza, rifuggendo la tentazione di fermarsi alle metriche di Base. Ma ciò è ben piccola cosa rispetto ai vantaggi che se ne traggono.