RSAC 2019: alla ricerca della strategia di patching perfetta

Durante la conferenza RSA 2019, alcuni ricercatori hanno descritto il panorama attuale delle vulnerabilità e hanno creato un modello per una strategia di patching efficace.

“Mi scusi, signore, avrebbe un momento per parlare degli aggiornamenti di sicurezza?”

“No, sono troppo occupato a installare patch”.

Scherzi a parte, vale la pena fermarsi un momento a pensare se state gestendo le patch in maniera efficace oppure no.

In un mondo perfetto, installereste le patch per tutti i software in uso nella vostra azienda non appena disponibili. Nella vita reale, invece, le cose sono leggermente più complicate, non c’è mai abbastanza tempo per installare tutte le patch e bisogna stabilire delle priorità. Ma come gestire al meglio questo compito?

Durante la conferenza RSA 2019, Jay Jacobs del Cyenta Institute e Michael Roytman di Kenna Security hanno presentato uno studio dal titolo The Etiology of Vulnerability Exploitation (Eziologia dello sfruttamento delle vulnerabilità). Il report, ben argomentato, descrive quali sono le vulnerabilità a cui prestare maggiore attenzione e in che modo migliorare considerevolmente l’installazione delle patch e degli aggiornamenti di sicurezza.

La premessa di base è che non tutte le vulnerabilità vengono sfruttate nella pratica. Dando per vera questa affermazione, molti aggiornamenti potrebbero essere messi da parte senza correre rischi, dando così priorità a quelle vulnerabilità che potrebbe essere sfruttate (o per le quali esiste una maggiore probabilità che ciò avvenga). Come è possibile fare una distinzione tra vulnerabilità “pericolose” e quelle “principalmente dannose”?

Armati delle descrizioni del database CVE (Common Vulnerabilities and Exposures), dei database pubblici degli exploit, ma anche dei dati delle analisi di vulnerabilità e dei sistemi IPS/IDS (per un totale di 7,3 miliardi di registri di attacco e 2,8 miliardi di vulnerabilità su 13 milioni di sistemi), i ricercatori hanno creato un modello che aiuta piuttosto bene a gestire questo compito. Per avere la giusta prospettiva sull’argomento, è necessario fare una breve analisi del panorama delle vulnerabilità.

Quanti CVE esistono in the wild?

Qualsiasi esperto in sicurezza informatica vi dirà che il numero delle vulnerabilità conosciute è piuttosto alto, ma in pochi (se non nessuno) conoscono la cifra esatta. Al momento sono stati pubblicati circa 108 mila CVE.

Va detto anche che, nell’ultimo paio d’anni, il tasso di pubblicazioni mensili è cresciuto considerevolmente: se negli anni 2005-2017 sono stati pubblicati ogni mese tra i 300-500 CVE, a fine 2017 la media mensile di pubblicazioni ha superato le 1.000 voci e da allora si è rimasti su questo livello. Parliamo quindi di decine di nuovi bug ogni giorno!

Il tasso di pubblicazione CVE è cresciuto considerevolmente nel 2017, superando le 1.000 voci al mese.

In generale, l’esistenza di un exploit si palesa subito prima o subito dopo la pubblicazione della voce CVE. Esistono delle eccezioni, ma nella maggior parte dei casi, parliamo di un intervallo di un paio di settimane in anticipo o in ritardo dalla pubblicazione CVE, che richiede quindi una risposta rapida.

Nella maggior parte dei casi, un exploit appare circa due settimane prima o dopo la data di pubblicazione CVE

Inutile dire che i tassi di installazione degli aggiornamenti non seguono la stessa velocità. Di media, un mese dopo l’identificazione, solo un quarto delle vulnerabilità vengono risolte installando la patch. Ci vogliono quindi 100 giorni per eliminare la metà delle vulnerabilità e, un anno dopo, un quarto delle vulnerabilità non riceve la relativa patch.

Di media, un quarto delle vulnerabilità rimane irrisolta un anno dopo la pubblicazione della relativa soluzione.

Oltre un terzo delle vulnerabilità per le quali non è stata installata la patch si trova in prodotti appartenenti a soli tre vendor. Non è difficile indovinare di quali vendor e prodotti stiamo parlando:

Oltre due terzi delle falle senza patch appartengono a prodotti Oracle, Microsoft e Adobe.

I prodotti che spesso rimangono senza patch: in prima fila ci sono Java e Acrobat

Nel frattempo, per il 77% dei CVE non sono ancora stati pubblicati exploit. È interessante notare anche che non tutte le vulnerabilità sono stati individuate in ambienti del mondo reale (solo 37 mila dei 108 mila CVE). E solo 5 mila CVE esistono in the wild e possono essere sfruttati. Ed è proprio su questi che ci si dovrebbe concentrare, bisogna soltanto identificarli correttamente.

Dei 108 mila CVE che si sa che esistono, solo 5 mila sono stati individuati in ambienti reali e sfruttati in attacchi.

Strategie di patching esistenti

I ricercatori hanno valutato la rilevanza delle strategie di patching seguendo due metriche: la parte di vulnerabilità “pericolose” rispetto al numero totale di vulnerabilità con patch (efficienza) e, viceversa, la parte di vulnerabilità con patch rispetto al numero totale di quelle “pericolose” (copertura).

I ricercatori hanno misurato la rilevanza delle strategie di patching seguendo due metriche: efficienza e copertura

Se questa immagine vi sembra famigliare, probabilmente perché non è nulla di nuovo.

Una delle strategie di patching generalmente accettate si basa sul Common Vulnerability Scoring System (CVSS), e la priorità viene assegnata a partire da un determinato punteggio CVSS. Se prendiamo le vulnerabilità con un punteggio CVSS equivalente a 10, l’efficienza e la copertura corrispondono rispettivamente al 23 e al 7%. L’aspetto interessante è che lo stesso identico risultato (almeno secondo queste metriche) viene raggiunto installando patch in modo casuale.

L’atteggiamento più comune, ovvero quello di installare tutte le patch per vulnerabilità con punteggio CVSS di 7 o superiore, dà migliori risultati e non è quindi una cattiva soluzione, ma richiede molto tempo, in quanto implica dare la priorità all’installazione di un gran numero di patch.

Confronto tra le strategie di patch in base al CVSS

Una strategia alternative sarebbe stabilire le priorità in base al vendor. Dopotutto, gli sviluppatori hanno indici diversi di exploit reali in rapporto al numero totale di CVE e sembra quindi logico dare la priorità a quei prodotti che contengono vulnerabilità la cui probabilità di essere sfruttate risulti maggiore.

È maggiormente probabile che siano sfruttate vulnerabilità presenti in prodotti di alcuni vendor piuttosto che altri

In ogni caso, basandosi sull’efficienza e la copertura, questa strategia sembra rivelarsi peggiore rispetto all’installazione casuale di patch, parliamo di un dimezzamento dell’efficacia.

Le strategie che si basano sui vendor sono molto meno efficaci rispetto all'installazione casuale delle patch

Insomma, a lungo termine questo metodo risulta essere di gran lunga meno efficace rispetto a quello che si basa sul CVSS.

Modello computazionale di probabilità per lo sfruttamento di vulnerabilità

Tutto ciò ci riporta al modello creato dai nostri ricercatori. Dopo aver comparato i dati delle descrizioni CVE (database di exploit disponibili per tutti) e i sistemi IPS/IDS, il team è stato in grado di identificare una serie di segnali che indicano la probabilità che una vulnerabilità venga effettivamente sfruttata.

Ad esempio, da un lato ci sono segnali come il riferimento CVE di Microsoft o la presenza di un exploit in Metasploit, che aumentano drasticamente la probabilità di sfruttare la vulnerabilità in questione.

I ricercatori hanno identificato quei segnali che aumentano la probabilità di sfruttare una vulnerabilità

Alcuni segnali, invece, riducono la probabilità di sfruttare una vulnerabilità, come una vulnerabilità del browser Safari, o un exploit pubblicato nel database ExploitDB (non molto comodo per scopi pratici), la presenza dei termini “authenticated” o “double free memory” nelle descrizioni CVE e altro. Combinando questi fattori, i ricercatori hanno potuto calcolare la probabilità per una particolare vulnerabilità di essere sfruttata.

Alcuni segnali aumentano la probabilità dello sfruttamento di una vulnerabilità, altri la diminuiscono

Per verificare l’accuratezza del modello, i ricercatori hanno confrontato le loro previsione con i dati provenienti da attacchi reali. Ecco le conclusioni:

  • Per le vulnerabilità con una probabilità minima, il modello funziona bene;
  • Il modello sembra sopravvalutare la possibilità di sfruttare vulnerabilità con una probabilità media di previsione;
  • In caso di alta probabilità, il modello sembra sottovalutare il rischio.

Il modello non è perfetto ma funziona.

In base a quanto detto, il modello non è perfetto nei dettagli ma funziona nel complesso. Basandosi su questo modello, i ricercatori hanno creato tre strategie di installazione delle patch: di alta efficienza, bilanciata e di massima copertura. La strategia “bilanciata”, ad esempio, offre un’efficienza duplicata rispetto alla strategia di installazione in base al CVSS 7 o superiore (63% di efficienza vs 52%), con la metà di sforzi profusi (ovvero il numero di patch installate si riduce della metà). Interessante, vero?

Infine, qualche consiglio da parte dei ricercatori:

  • Riflettete sull’idea di utilizzare solamente il CVSS per la vostra strategia di installazione delle patch;
  • Verificate quante vulnerabilità aperte/chiuse siano presenti nella vostra infrastruttura;
  • Iniziate a raccogliere dati dai vostri sensori in merito agli exploit utilizzati negli attacchi rivolti alle vostre risorse;
  • Dopo aver raccolto una quantità importante di dati, utilizzateli per calcolare i punteggi di efficienza, copertura e sforzo che riguardano la vostra infrastruttura;
  • Confrontate i valori con altre strategie di definizione di priorità.

Siamo d’accordo con i ricercatori sul fatto che, installare manualmente tutte le patch senza una strategia, implica un gran dispendio di risorse. Tuttavia, il nostro approccio è diverso: Kaspersky Systems Management (parte della soluzione Kaspersky Security for Business) utilizza il monitoraggio delle vulnerabilità e i sottosistemi di installazione delle patch.

In questo modo è possibile identificare rapidamente le vulnerabilità, stabilire priorità per poi risolverle. Oltre ai punteggi CVSS, utilizziamo le informazioni offerte da Kaspersky Security Network. Ad esempio, se i nostri sistemi si rendono conto che si sta sfruttando una vulnerabilità, diventa più prioritario risolverla. Qui potete avere maggiori informazioni sulla nostra tecnologia.

Consigli