La resistenza al cambiamento è sempre presente, soprattutto se si ritiene che i processi già in uso siano efficienti ed efficaci. Molte organizzazioni la pensano così riguardo alle proprie procedure di gestione del software, finché non subiscono una violazione o un incidente di sicurezza e si chiedono dove abbiano sbagliato.

La realtà è che la maggior parte dei programmi di gestione delle patch si basa su ipotesi e raccomandazioni, anziché su dati concreti relativi alle vulnerabilità sfruttate attivamente. La gestione delle patch basata sul rischio è la risposta a questo problema.

In questo articolo troverai:

I problemi della prioritizzazione tradizionale delle patch

Gli aggiornamenti delle funzionalità software, le correzioni di sicurezza, le correzioni di bug, i miglioramenti delle prestazioni e molti altri tipi di release software esistono sin dagli inizi dell’industria del software. I vendor spesso assegnano a ciascuno di questi elementi un livello di gravità o un altro punteggio per indicare ai clienti ciò che ritengono più importante.

Purtroppo non esiste uno standard di settore associato a queste valutazioni, quindi ci troviamo a dover confrontare e prioritizzare le release da distribuire sui nostri sistemi sulla base di raccomandazioni. Inoltre, tali valutazioni vengono aggiornate raramente per tenere conto del contesto delle minacce attive, anche quando le vulnerabilità cambiano.

Trascurare una vulnerabilità sfruttata attivamente

Pur essendo meglio di niente, le valutazioni di gravità dei vendor spesso non sono sufficienti. Prendiamo in considerazione la vulnerabilità Follina (CVE-2022-30190) pubblicata a maggio 2022. Questa vulnerabilità nello strumento di diagnostica del supporto Microsoft Windows (MSDT) consente l’esecuzione di codice da remoto.

Follina è stata oggetto di attacchi per diversi mesi prima che Microsoft rispondesse infine con vari aggiornamenti. In modo preoccupante, Microsoft ha assegnato a questa vulnerabilità solo una valutazione Common Vulnerability Scoring System (CVSS) v3 pari a 7,8 e una gravità di livello Importante. Se si applicano le patch solo in base alla gravità Critica, questa vulnerabilità sarebbe passata inosservata, lasciando una lacuna significativa nella superficie di attacco.

Ancora peggio, il punteggio CVSS di Follina è rimasto a 7,8 anche dopo che è emerso che la vulnerabilità veniva sfruttata attivamente per distribuire il ransomware Bisamware, esponendo a un rischio ancora maggiore le organizzazioni che avevano trascurato la vulnerabilità. 

Ivanti Neurons for Vuln KB
Informazioni di intelligence sulla minaccia ransomware associata a CVE-2022-30190 visualizzate in Ivanti Neurons for VULN KB

Limiti del CVSS

Le valutazioni di gravità vengono “arricchite” con i punteggi CVSS di FIRST. A ogni CVE viene assegnato un numero CVSS, come il 7,8 attribuito a CVE-2022-30190 nell’esempio precedente.

Uno degli obiettivi principali del calcolo del numero CVSS effettivo è garantire la standardizzazione, in modo che tutti i CVE siano valutati in modo coerente e possano essere confrontati con precisione. Quanto più alto è il punteggio CVSS di una vulnerabilità e della patch associata, tanto più critica è la sua distribuzione nella maggior parte degli ambienti.

Per gli aggiornamenti software che risolvono più CVE, di solito viene preso in considerazione il valore CVSS più alto ai fini della prioritizzazione. Ma questo valore è davvero accurato?

I risultati di un’analisi dei punteggi CVSS in un articolo recente hanno mostrato una discrepanza in quasi il 20% dei punteggi CVSS (25.000). Questa analisi si basava su un confronto tra i punteggi riportati nel National Vulnerability Database (NVD) del NIST e quelli comunicati direttamente dai vendor stessi.

Incoerenze nelle valutazioni di gravità dei vendor

Un punto importante da tenere presente è che storicamente i vendor hanno assegnato una propria terminologia alla gravità (ad esempio, critica, importante). Usare il punteggio di gravità del vendor come meccanismo di prioritizzazione può funzionare bene quando si confrontano tutte le patch di un determinato vendor, ma non sempre offre un confronto accurato delle patch tra vendor diversi. Di fatto, molti utilizzano terminologie completamente differenti.

Analogamente, la gravità indicata dal vendor non è sempre un indicatore positivo. Molte vulnerabilità zero-day sono classificate da Microsoft solo come Importanti, pur avendo punteggi CVSS elevati. È evidente come l’applicazione delle patch utilizzando gravità e CVSS per la prioritizzazione si basi su ipotesi e raccomandazioni e possa tradursi in un ambiente vulnerabile.

Perché dare priorità agli exploit attivi rispetto a qualsiasi altro metodo di prioritizzazione?

Secondo la Cybersecurity and Infrastructure Security Agency (CISA) degli Stati Uniti, una vulnerabilità sfruttata attivamente è “una vulnerabilità per la quale esistono prove affidabili che l’esecuzione di codice dannoso sia stata effettuata da un attore su un sistema senza l’autorizzazione del proprietario del sistema”. In termini semplici, una vulnerabilità in fase di sfruttamento attivo è una vulnerabilità che è stata utilizzata da un attore della minaccia per lanciare un attacco informatico.

Pertanto, per ridurre al minimo il rischio di un attacco alla tua organizzazione, devi dare priorità alle vulnerabilità sfruttate attivamente rispetto a tutte le altre. La buona notizia è che la maggior parte delle vulnerabilità non viene sfruttata attivamente e quindi rappresenta un rischio minimo o nullo per la tua organizzazione. È possibile identificare quelle che sono state sfruttate tramite la gestione delle patch basata sul rischio.

Che cos’è la gestione delle patch basata sul rischio?

La gestione delle patch basata sul rischio è un’estensione della gestione delle vulnerabilità basata sul rischio, che va oltre la gravità indicata dai vendor e i punteggi CVSS di base per identificare e qualificare le vulnerabilità specifiche che pongono il rischio più significativo per un’organizzazione. Questo integra il contesto del rischio reale nel processo di gestione delle patch, affinché i team IT possano concentrare i propri sforzi sugli aggiornamenti con vulnerabilità note sfruttate che contano maggiormente per la postura di sicurezza dell’organizzazione.

In che modo la mia organizzazione può adottare la gestione delle patch basata sul rischio?

Per le organizzazioni pronte ad adottare un approccio alla gestione delle patch basato sul rischio, un buon punto di partenza è il catalogo CISA Known Exploited Vulnerabilities (KEV). CISA ha compiuto un importante passo avanti per aiutare a prioritizzare le vulnerabilità quando ha introdotto la Binding Operational Directive 22–01 insieme al suo catalogo KEV. Al momento della pubblicazione iniziale, il catalogo conteneva circa 200 vulnerabilità sfruttate attivamente. Da allora è cresciuto fino a quasi 900. 

CISA costruisce l’elenco sapendo che le vulnerabilità incluse vengono sfruttate in contesti reali da minacce attive. Tuttavia, l’elenco presenta alcuni limiti, poiché attualmente esclude 131 vulnerabilità associate al ransomware.

Il catalogo CISA KEV è l’unica risorsa disponibile per la gestione delle patch basata sul rischio?

Le organizzazioni con pratiche di gestione delle patch basata sul rischio più mature sfruttano metodologie avanzate di scoring del rischio in sostituzione o in aggiunta al CVSS. Queste metodologie assegnano punteggi a ogni vulnerabilità identificata nell’ambiente di un’organizzazione, consentendo a tali organizzazioni di estendere il proprio approccio basato sul rischio oltre il CISA KEV.

Molti vendor nell’ambito della gestione delle vulnerabilità basata sul rischio hanno sviluppato metodologie di scoring proprietarie che rappresentano il rischio reale posto da una vulnerabilità. Lo fanno fornendo valutazioni dinamiche del rischio che attribuiscono un peso maggiore alle vulnerabilità sfruttate attivamente.

Ad esempio, il Vulnerability Risk Rating (VRR) di Ivanti ha assegnato a Follina un punteggio di 10, un punteggio che rappresenta il rischio posto da quella vulnerabilità in modo più accurato rispetto al suo punteggio CVSS di 7,8.

Ivanti's VRR rating of Follina.
La differenza tra i punteggi VRR e CVSS v3 e i livelli di gravità per CVE-2022-30190, come mostrato in Ivanti Neurons for VULN KB 

Perché è il momento ideale per adottare la gestione delle patch basata sul rischio 

Se ritieni di essere rimasto indietro con gli aggiornamenti di sistema o di essere sopraffatto da nuovi sistemi e applicazioni nella tua azienda, questo è il momento ideale per adottare la gestione delle patch basata sul rischio. 

Anche se ritieni di avere già un programma solido basato su valutazioni di gravità e punteggi CVSS, è il momento di superare la resistenza al cambiamento e avviare un nuovo processo prima che la tua azienda subisca gravi danni a causa di una violazione dei dati derivante da una vulnerabilità sfruttata. 

Inizia utilizzando il CISA KEV per prioritizzare gli aggiornamenti e destina un budget a una soluzione di gestione delle vulnerabilità e delle patch basata sul rischio. Con gli strumenti adeguati a disposizione, puoi identificare rapidamente i sistemi a più alto rischio da aggiornare per primi e procedere lungo l’elenco per garantire la sicurezza dei tuoi sistemi.

Vuoi compiere il primo passo? Consulta questo eBook: una guida completa per implementare un moderno programma di gestione delle patch basata sul rischio