Da CVSS a RBVM: assegnazione delle priorità alle vulnerabilità eseguita correttamente

Cause delle discrepanze nelle classificazioni del CVSS (Common Vulnerability Scoring System), errori comuni durante l’utilizzo del CVSS per l’assegnazione delle priorità alle vulnerabilità e come eseguire questa operazione correttamente.

Cause delle discrepanze nelle classificazioni del CVSS (Common Vulnerability Scoring System), errori comuni durante l'utilizzo del CVSS per l'assegnazione delle priorità alle vulnerabilità e come eseguire questa operazione correttamente.

Quando si incontra per la prima volta il CVSS (Common Vulnerability Scoring System), è facile pensare che si tratti dello strumento perfetto per il triage e l’assegnazione delle priorità alle vulnerabilità. Un punteggio più alto indica una vulnerabilità più critica, giusto? In realtà, questo approccio non funziona. Ogni anno assistiamo a un numero crescente di vulnerabilità con punteggi CVSS elevati. I team di sicurezza non riescono a correggerle tutte in tempo, ma la stragrande maggioranza di questi difetti non viene mai effettivamente sfruttata negli attacchi nel mondo reale. Nel frattempo, gli autori degli attacchi sfruttano costantemente vulnerabilità meno appariscenti con punteggi più bassi. Ci sono anche altre insidie nascoste, che vanno da problemi puramente tecnici, come punteggi CVSS contrastanti, a problemi concettuali, come la mancanza di contesto aziendale.

Non si tratta necessariamente di carenze del CVSS stesso. Si evidenzia invece la necessità di utilizzare lo strumento correttamente, nell’ambito di un processo di gestione delle vulnerabilità più sofisticato e completo.

Discrepanze CVSS

Hai mai notato come la stessa vulnerabilità possa avere punteggi di gravità diversi a seconda dell’origine disponibile? Un punteggio del ricercatore sulla cybersecurity che l’ha trovato, un altro del fornitore del software vulnerabile e ancora un altro di un database nazionale delle vulnerabilità? Non è sempre e solo un semplice errore. A volte diversi esperti possono non essere d’accordo sul contesto dello sfruttamento. Potrebbero avere idee diverse sui privilegi con cui viene eseguita un’applicazione vulnerabile o sulla connessione a Internet. Un fornitore potrebbe ad esempio basare la propria valutazione sulle best practice consigliate, mentre un ricercatore della sicurezza potrebbe considerare il modo in cui le applicazioni sono configurate tipicamente nelle organizzazioni reali. Un ricercatore potrebbe valutare la complessità dell’exploit come alta, mentre un altro ritenerla bassa. Non è un evento raro. Uno studio di Vulncheck del 2023 ha rilevato che il 20% delle vulnerabilità nel National Vulnerability Database (NVD) aveva due punteggi CVSS3 da fonti diverse e il 56% di questi punteggi accoppiati era in conflitto.

Errori comuni durante l’utilizzo di CVSS

Da oltre un decennio FIRST sostiene l’applicazione metodologicamente corretta del CVSS. Tuttavia, le organizzazioni che utilizzano le classificazioni CVSS nei processi di gestione delle vulnerabilità continuano a commettere errori tipici:

  1. Utilizzare il punteggio di base CVSS come indicatore di rischio primario. CVSS misura la gravità di una vulnerabilità, non quando verrà sfruttata o il potenziale impatto del relativo sfruttamento sull’organizzazione sotto attacco. Talvolta una vulnerabilità critica è innocua nell’ambiente di un’azienda specifica perché risiede in sistemi insignificanti e isolati. Al contrario, un attacco ransomware su larga scala potrebbe iniziare con una vulnerabilità relativa alla fuga di informazioni apparentemente innocua con un punteggio CVSS di 6.
  2. Utilizzare il punteggio di base CVSS senza adattamenti di Minaccia/Temporali e Ambientali. La disponibilità di patch, exploit pubblici e misure compensative influenza in modo significativo il modo e l’urgenza di affrontare una vulnerabilità.
  3. Concentrarsi solo sulle vulnerabilità al di sopra di un determinato punteggio. Questo approccio è talvolta imposto dal governo o dalle autorità di regolamentazione del settore (“correggere le vulnerabilità con un punteggio CVSS superiore a 8 entro un mese”). Di conseguenza, i team di cybersecurity devono far fronte a un carico di lavoro in continua crescita che, in realtà, non rende la loro infrastruttura più sicura. Il numero di vulnerabilità con punteggi CVSS elevati identificate ogni anno è in rapido aumento negli ultimi 10 anni.
  4. Utilizzo di CVSS per valutare la probabilità di sfruttamento. Queste metriche sono scarsamente correlate: solo il 17% delle vulnerabilità critiche viene sfruttato negli attacchi.
  5. Utilizzo solo della valutazione CVSS. La stringa vettoriale standardizzata è stata introdotta in CVSS in modo che chi difende potesse comprendere i dettagli di una vulnerabilità e calcolarne in modo indipendente l’importanza all’interno della propria organizzazione. CVSS 4.0 è stato specificamente rivisto per tenere conto in modo più facile del contesto aziendale utilizzando metriche aggiuntive. Qualsiasi sforzo di gestione della vulnerabilità basato esclusivamente su una classificazione numerica sarà in gran parte inefficace.
  6. Ignorare ulteriori fonti di informazione. Fare affidamento su un singolo database delle vulnerabilità e analizzare solo CVSS non è sufficiente. L’assenza di dati su patch, proof of concept funzionanti e casi di sfruttamento nel mondo reale rende difficile decidere come affrontare le vulnerabilità.

Cosa non dice CVSS in merito a una vulnerabilità

CVSS è lo standard del settore per descrivere la gravità di una vulnerabilità, le condizioni in cui può essere sfruttata e il potenziale impatto su un sistema vulnerabile. Tuttavia, al di là di questa descrizione (e del punteggio di base CVSS), c’è molto che non copre:

  • Chi ha trovato la vulnerabilità? È stato il fornitore, un ricercatore etico a segnalare il difetto in attesa di una patch o è stato un utente malintenzionato?
  • Esiste un exploit disponibile pubblicamente? In altre parole, c’è un codice prontamente disponibile per sfruttare la vulnerabilità?
  • Quanto è pratico da sfruttare in scenari del mondo reale?
  • C’è una patch? Copre tutte le versioni del software vulnerabili e quali sono i potenziali effetti collaterali della sua applicazione?
  • L’organizzazione deve affrontare la vulnerabilità? Oppure interessa un servizio cloud (SaaS) in cui il provider correggerà automaticamente i difetti?
  • Ci sono segni di sfruttamento in natura?
  • Se non ve ne sono, qual è la probabilità che un utente malintenzionato sfrutterà questa vulnerabilità in futuro?
  • Quali sono i sistemi specifici vulnerabili all’interno dell’organizzazione?
  • Lo sfruttamento è praticamente accessibile a un utente malintenzionato? Un sistema potrebbe ad esempio essere un server Web aziendale accessibile a chiunque online oppure una stampante vulnerabile connessa fisicamente a un singolo computer che non ha accesso alla rete. Un esempio più complesso potrebbe essere una vulnerabilità nel metodo di un componente software, in cui la specifica applicazione aziendale che utilizza tale componente non chiama mai effettivamente il metodo.
  • Cosa accadrebbe se i sistemi vulnerabili venissero compromessi?
  • Qual è il costo finanziario di un evento del genere per l’azienda?

Tutti questi fattori influenzano in modo significativo la decisione su quando e come porre rimedio a una vulnerabilità, o anche se è necessario rimediare.

Come modificare il CVSS? RBVM ha la risposta!

Molti fattori spesso difficili da spiegare all’interno dei confini di CVSS sono centrali per un approccio popolare noto come gestione delle vulnerabilità basata sul rischio (RBVM).

RBVM è un processo olistico e ciclico, con diverse fasi chiave che si ripetono regolarmente:

  • Inventario di tutte le risorse IT dell’azienda. È incluso di tutto: da computer, server e software, a servizi cloud e dispositivi IoT.
  • Assegnare la priorità alle risorse in base all’importanza.
  • Scansione delle risorse alla ricerca di vulnerabilità note.
  • Arricchimento dei dati sulla vulnerabilità. Sono inclusi il perfezionamento delle classificazioni CVSS-B e CVSS-BT, l’integrazione delle informazioni sulle minacce e la valutazione della probabilità di sfruttamento. Due strumenti popolari per misurare lo sfruttamento sono EPSS (un’altra valutazione FIRST che fornisce una probabilità percentuale di sfruttamento nel mondo reale per la maggior parte delle vulnerabilità) e database di consultazione come CISA KEV, che contiene informazioni sulle vulnerabilità attivamente sfruttate dagli utenti malintenzionati.
  • Definizione del contesto aziendale: comprensione del potenziale impatto di un exploit sui sistemi vulnerabili, considerando le relative configurazioni e il modo in cui vengono utilizzate all’interno dell’organizzazione.
  • Definizione del modo in cui la vulnerabilità può essere neutralizzata tramite patch o misure compensative.
  • La parte più interessante: valutare il rischio aziendale e definire le priorità in base a tutti i dati raccolti. Viene assegnata la priorità alle vulnerabilità con la più alta probabilità di sfruttamento e con il possibile impatto significativo sulle risorse IT chiave. Per classificare le vulnerabilità è possibile calcolare CVSS-BTE, incorporando tutti i dati raccolti nel componente Ambientale, oppure utilizzare metodologie di classificazione alternative. Anche gli aspetti normativi influenzano l’assegnazione delle priorità.
  • Impostazione delle scadenze per la risoluzione di ogni vulnerabilità in base al relativo livello di rischio e a considerazioni operative, ad esempio il momento più opportuno per gli aggiornamenti. Se gli aggiornamenti o le patch non sono disponibili o se la loro implementazione introduce nuovi rischi e complessità, vengono adottate misure compensative al posto della correzione diretta. Talvolta, il costo della correzione di una vulnerabilità supera il rischio che essa comporta e si potrebbe decidere di non porvi rimedio. In questi casi, l’azienda accetta consapevolmente i rischi di sfruttamento della vulnerabilità.

In aggiunta a quanto illustrato, è fondamentale analizzare periodicamente il panorama delle vulnerabilità e l’infrastruttura IT dell’azienda. In seguito a questa analisi è necessario introdurre misure di cybersecurity che impediscano lo sfruttamento di intere classi di vulnerabilità o aumentino in modo significativo la sicurezza generale di specifici sistemi IT. Tali misure possono includere la microsegmentazione della rete, l’implementazione dei privilegi minimi e l’adozione di criteri di gestione degli account più rigorosi.

Un processo RBVM correttamente implementato riduce drasticamente l’onere per i team IT e di sicurezza. Trascorrono il tempo in modo più efficace poiché i loro sforzi sono diretti principalmente ai difetti che rappresentano una vera minaccia per l’azienda. Per cogliere l’entità di questi incrementi di efficienza e risparmi di risorse, è opportuno prendere in considerazione questo studio FIRST. L’assegnazione della priorità alle vulnerabilità utilizzando il solo EPSS consente di concentrarsi solo sul 3% delle vulnerabilità, ottenendo al contempo un’efficienza del 65%. In netto contrasto, l’assegnazione delle priorità da parte di CVSS-B richiede di affrontare ben il 57% delle vulnerabilità con un’efficacia deludente del 4%. In questo caso, “efficienza” si riferisce alla correzione delle vulnerabilità che sono state effettivamente sfruttate in natura.

Consigli