Ivanti Blog: Post di

In che modo la gestione delle patch basata sul rischio dà priorità alle vulnerabilità sfruttate attivamente

Fri, 03 Jan 2025 18:10:36 Z

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:

Cosa non funziona nel mantenere le priorità tradizionali.
Che cos’è la gestione delle patch basata sul rischio.
Perché è il momento ideale per adottare la gestione delle patch basata sul rischio.

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à.

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.

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.

Processi moderni efficaci di patch management e best practice per le operazioni di patch

Thu, 01 Aug 2024 06:01:00 Z

Adottare un programma di gestione delle vulnerabilità basato sul rischio è essenziale per mantenere sicuro l’ambiente informatico aziendale. In un blog precedente, “In che modo l’implementazione del patch management basato sul rischio dà priorità agli exploit attivi”, ho offerto una prospettiva su come assegnare le priorità alle vulnerabilità. Per questo processo è essenziale perfezionare l’aspetto operativo della protezione dei sistemi.

Gestire le operazioni di patch all’interno dell’organizzazione può essere un processo complesso. Anche avendo una certa visibilità sulle priorità delle vulnerabilità, è comunque necessario considerare:

La cadenza di rilascio delle patch.
Policy di supporto per rendere efficace questo processo.
Campagne per distribuire gli aggiornamenti.
Accordi sul livello di servizio (SLA) e misurazione della conformità.

Potrebbe sembrare un equilibrio difficile da mantenere, ma un sistema flessibile, in grado di gestire gli eventi pianificati e tenere conto degli imprevisti, permette di avere il pieno controllo.

Ha davvero il controllo?

Alcuni aspetti dei rilasci delle patch possono essere pianificati, altri no.

Prendiamo ad esempio la cadenza dei rilasci delle patch di sicurezza. Il Patch Tuesday, il secondo martedì di ogni mese, Microsoft cerca di rilasciare tutti gli aggiornamenti più recenti. Questi includono aggiornamenti per sistemi operativi, Office e altre applicazioni utente, strumenti di sviluppo come Visual Studio e componenti cloud in Azure, solo per citarne alcuni.

Il Patch Tuesday, che ha celebrato il suo 20° anniversario nell’ottobre 2023, è alla base di molti programmi di patch: offre un momento preciso in cui distribuire tutti gli ultimi aggiornamenti Microsoft e quelli di terze parti disponibili. Nessun altro vendor ha avuto un impatto così profondo nel guidare i programmi di patch delle organizzazioni e, ancora oggi, il ciclo mensile delle patch, incentrato sul Patch Tuesday, rimane uno standard del settore.

Altri vendor hanno cercato di seguire lo stesso modello e rilasciare i propri aggiornamenti secondo una pianificazione:

Oracle rilascia il proprio Critical Patch Update una volta a trimestre.
Adobe di solito rilascia i propri aggiornamenti una volta al mese, spesso in sincronia con il Patch Tuesday.
Google ha recentemente iniziato a rilasciare un singolo aggiornamento ogni settimana.

Tuttavia, la maggior parte dei vendor rilascia aggiornamenti di sicurezza non appena e con la frequenza possibile, per assicurarsi di risolvere le vulnerabilità il più rapidamente possibile. Ne deriva un flusso casuale e continuo di aggiornamenti che devono essere costantemente prioritizzati e distribuiti in tutta l’organizzazione.

Processo di patch management per policy e campagne

Per tenere sotto controllo il caos dei rilasci delle patch servono un insieme di regole chiaramente definito e un’infrastruttura in grado di applicarle. Nell’ambito delle patch, questo si traduce in policy e campagne.

Una policy di patch richiede un’ampia gamma di considerazioni oltre alla prioritizzazione delle vulnerabilità, tra cui l’impatto degli aggiornamenti sulle attività aziendali, l’applicabilità a diversi tipi di sistemi, il grado di controllo sugli aggiornamenti e altri fattori.

Le policy di patch mettono in evidenza forti differenze, a seconda dell’azienda. Per un server che ospita applicazioni aziendali critiche, la policy prevede un insieme di aggiornamenti chiaramente definito e sottoposto a rigoroso controllo della configurazione, viene applicata solo durante una finestra di manutenzione definita e impone sempre un riavvio al termine, per garantire che il sistema sia completamente aggiornato. La policy di patch per il laptop di un utente del marketing identifica una serie di applicazioni con aggiornamenti approvati che possono essere presenti o meno e consente all’utente di rimandare aggiornamenti e riavvio al momento più opportuno.

Le campagne tengono conto di queste policy, ma permettono anche di controllare la moltitudine di patch rilasciate continuamente.

Le best practice moderne di patch management richiedono interventi di patching più frequenti rispetto alla semplice cadenza mensile. Le patch di Google Chrome vengono rilasciate ogni settimana e le patch zero-day possono essere rilasciate in qualsiasi momento. Una campagna mensile lascerà molti sistemi vulnerabili per periodi prolungati.

Definire tre tipi di campagne

Una best practice consiste nel definire tre tipi di campagne: manutenzione regolare, aggiornamenti prioritari e distribuzioni critiche.

Campagna di manutenzione regolare

Le campagne di manutenzione regolare applicano il rollout standard mensile delle patch ad anelli, oggi utilizzato dalla maggior parte delle organizzazioni. Questa campagna include:

Test iniziali in un ambiente controllato per garantire che le patch si installino come previsto.
Rollout a un gruppo pilota più ampio di early adopter, pronti a segnalare eventuali problemi.
Rollout ai gruppi predefiniti di sistemi di produzione per completare la distribuzione complessiva.

Le patch in una campagna di manutenzione includono aggiornamenti di sicurezza rilasciati con minore frequenza, come i rilasci del Patch Tuesday di Microsoft, oltre ad aggiornamenti delle prestazioni o delle applicazioni. I sistemi interessati da questa campagna possono anche essere quelli con finestre di manutenzione limitate e che non possono essere interrotti senza un impatto aziendale significativo. È molto probabile che la maggior parte delle patch rientri nella campagna di aggiornamenti prioritari.

Campagna di aggiornamenti prioritari

La campagna di aggiornamenti prioritari è progettata per intervenire rapidamente sui sistemi che sono esposti in modo continuo a nuove vulnerabilità, ma che possono essere aggiornati con maggiore frequenza. I sistemi utente che eseguono applicazioni di produttività e browser rientrano in questa campagna e spesso sono tra quelli a rischio più elevato, a causa dell’esposizione a phishing, malware e ransomware.

Le patch associate a questa campagna hanno spesso la massima priorità a causa di vulnerabilità con sfruttamento noto, ma possono anche avere un impatto aziendale relativamente ridotto, richiedendo il riavvio di un browser o di un’applicazione. Di conseguenza, le policy possono prevedere un ciclo di test più breve prima del rilascio e possono essere distribuite più rapidamente a gruppi più ampi di sistemi non critici per il business; ad esempio, i server potrebbero non avere un browser installato, mentre i laptop del team vendite sì.

Campagna di risposta zero-day

La campagna di risposta zero-day è riservata alla distribuzione di patch di emergenza imposta dall’azienda o dal settore, quando la situazione è critica e la correzione deve essere implementata in tempi brevi. Questa campagna ha la precedenza su tutte le altre.

La policy per questa campagna potrebbe ridurre i tempi o abbassare gli standard tra le fasi di rollout controllato, oppure potrebbe ignorarli del tutto, a seconda dello SLA da rispettare. L’aspetto più importante delle campagne di risposta zero-day è questo: si tratta comunque di una distribuzione controllata delle patch e tutte le attività vengono comunque registrate per monitorare con precisione gli eventi della campagna fino al completamento.

Il tempo di esposizione determina la conformità

Se la conformità viene misurata in termini di macchine completamente aggiornate, secondo questa metrica la maggior parte dei sistemi risulta conforme solo per un numero limitato di ore al mese. Pur essendo tecnicamente accurato, questo è un indicatore poco efficace per mostrare la sicurezza del sistema nel tempo nell’ambito di un programma basato sul rischio. Mostrare il “tempo di esposizione” a una determinata vulnerabilità o a un gruppo di vulnerabilità offre un indicatore di rischio migliore.

Ecco un esempio: CVE-2024-4761 è stata indicata come corretta in un aggiornamento di Google Chrome rilasciato il 14 maggio, che coincideva con il Patch Tuesday di maggio. Il giorno successivo, questa patch di Chrome è stata aggiunta a una campagna di aggiornamenti prioritari che prevedeva un periodo di distribuzione di due settimane su 500 sistemi nel Gruppo 1 e 1.000 sistemi nel Gruppo 2. Supponendo che la maggior parte dei sistemi sia stata aggiornata correttamente entro quella finestra di due settimane, un report mostrerebbe quando ogni sistema è stato aggiornato, ma soprattutto per quanto tempo ciascuno di questi 1.500 sistemi è rimasto senza patch, esposto alla vulnerabilità e quindi a rischio.

Questo è un esempio semplice, con una vulnerabilità e una patch. Ma se nella campagna fossero presenti più patch con diverse vulnerabilità, le informazioni potrebbero essere aggregate per offrire una vista più completa della campagna. Se nello stesso periodo fossero eseguite più campagne, il risultato potrebbe essere sovrapposto o combinato per fornire una valutazione del rischio ancora più accurata.

Con questi dati a disposizione, è possibile mostrare a un auditor il reale stato di sicurezza dei sistemi. E, forse ancora più importante, è possibile iniziare a valutare i risultati e migliorare l’efficacia delle moderne operazioni di patch management. A quel punto, sarà l’organizzazione a gestire l’operazione, non il contrario.