{"id":17094,"date":"2019-03-28T19:10:51","date_gmt":"2019-03-28T17:10:51","guid":{"rendered":"https:\/\/www.kaspersky.it\/blog\/?p=17094"},"modified":"2022-07-07T17:30:30","modified_gmt":"2022-07-07T15:30:30","slug":"patching-strategy-rsa2019","status":"publish","type":"post","link":"https:\/\/www.kaspersky.it\/blog\/patching-strategy-rsa2019\/17094\/","title":{"rendered":"RSAC 2019: alla ricerca della strategia di patching perfetta"},"content":{"rendered":"

\u201cMi scusi, signore, avrebbe un momento per parlare degli aggiornamenti di sicurezza?\u201d<\/p>\n

\u201cNo, sono troppo occupato a installare patch\u201d.<\/p>\n

Scherzi a parte, vale la pena fermarsi un momento a pensare se state gestendo le patch in maniera efficace oppure no.<\/p>\n

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\u00f9 complicate, non c\u2019\u00e8 mai abbastanza tempo per installare tutte le patch e bisogna stabilire delle priorit\u00e0. Ma come gestire al meglio questo compito?<\/p>\n

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

La premessa di base \u00e8 che non tutte le vulnerabilit\u00e0 vengono sfruttate nella pratica. Dando per vera questa affermazione, molti aggiornamenti potrebbero essere messi da parte senza correre rischi, dando cos\u00ec priorit\u00e0 a quelle vulnerabilit\u00e0 che potrebbe essere sfruttate (o per le quali esiste una maggiore probabilit\u00e0 che ci\u00f2 avvenga). Come \u00e8 possibile fare una distinzione tra vulnerabilit\u00e0 \u201cpericolose\u201d e quelle \u201cprincipalmente dannose\u201d?<\/p>\n

Armati delle descrizioni del database CVE (Common Vulnerabilities and Exposures), dei database pubblici degli exploit, ma anche dei dati delle analisi di vulnerabilit\u00e0 e dei sistemi IPS\/IDS (per un totale di 7,3 miliardi di registri di attacco e 2,8 miliardi di vulnerabilit\u00e0 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\u2019argomento, \u00e8 necessario fare una breve analisi del panorama delle vulnerabilit\u00e0.<\/p>\n\n

Quanti CVE esistono in the wild?<\/h3>\n

Qualsiasi esperto in sicurezza informatica vi dir\u00e0 che il numero delle vulnerabilit\u00e0 conosciute \u00e8 piuttosto alto, ma in pochi (se non nessuno) conoscono la cifra esatta. Al momento sono stati pubblicati circa 108 mila CVE.<\/p>\n

Va detto anche che, nell\u2019ultimo paio d\u2019anni, il tasso di pubblicazioni mensili \u00e8 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 \u00e8 rimasti su questo livello. Parliamo quindi di decine di nuovi bug ogni giorno!<\/p>\n

\"Il<\/p>\n

In generale, l\u2019esistenza 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.<\/p>\n

\"Nella<\/p>\n

Inutile dire che i tassi di installazione degli aggiornamenti non seguono la stessa velocit\u00e0. Di media, un mese dopo l\u2019identificazione, solo un quarto delle vulnerabilit\u00e0 vengono risolte installando la patch. Ci vogliono quindi 100 giorni per eliminare la met\u00e0 delle vulnerabilit\u00e0 e, un anno dopo, un quarto delle vulnerabilit\u00e0 non riceve la relativa patch.<\/p>\n

\"Di<\/p>\n

Oltre un terzo delle vulnerabilit\u00e0 per le quali non \u00e8 stata installata la patch si trova in prodotti appartenenti a soli tre vendor. Non \u00e8 difficile indovinare di quali vendor e prodotti stiamo parlando:<\/p>\n

\"Oltre<\/p>\n

\"I<\/p>\n

Nel frattempo, per il 77% dei CVE non sono ancora stati pubblicati exploit. \u00c8 interessante notare anche che non tutte le vulnerabilit\u00e0 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 \u00e8 proprio su questi che ci si dovrebbe <\/em>concentrare, bisogna soltanto identificarli correttamente.<\/p>\n

\"Dei<\/p>\n

Strategie di patching esistenti<\/h3>\n

I ricercatori hanno valutato la rilevanza delle strategie di patching seguendo due metriche: la parte di vulnerabilit\u00e0 \u201cpericolose\u201d rispetto al numero totale di vulnerabilit\u00e0 con patch (efficienza) e, viceversa, la parte di vulnerabilit\u00e0 con patch rispetto al numero totale di quelle \u201cpericolose\u201d (copertura).<\/p>\n

\"I

Se questa immagine vi sembra famigliare, probabilmente perch\u00e9 non \u00e8 nulla di nuovo<\/a>.<\/p><\/div>\n

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

<\/p>\n

L\u2019atteggiamento pi\u00f9 comune, ovvero quello di installare tutte le patch per vulnerabilit\u00e0 con punteggio CVSS di 7 o superiore, d\u00e0 migliori risultati e non \u00e8 quindi una cattiva soluzione, ma richiede molto tempo, in quanto implica dare la priorit\u00e0 all\u2019installazione di un gran numero di patch.<\/p>\n

\"Confronto<\/p>\n

Una strategia alternative sarebbe stabilire le priorit\u00e0 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\u00e0 a quei prodotti che contengono vulnerabilit\u00e0 la cui probabilit\u00e0 di essere sfruttate risulti maggiore.<\/p>\n

\"\u00c8<\/p>\n

In ogni caso, basandosi sull\u2019efficienza e la copertura, questa strategia sembra rivelarsi peggiore <\/em>rispetto all\u2019installazione casuale di patch, parliamo di un dimezzamento dell\u2019efficacia.<\/p>\n

\"Le<\/p>\n

Insomma, a lungo termine questo metodo risulta essere di gran lunga meno efficace rispetto a quello che si basa sul CVSS.<\/p>\n

Modello computazionale di probabilit\u00e0 per lo sfruttamento di vulnerabilit\u00e0<\/h3>\n

Tutto ci\u00f2 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 \u00e8 stato in grado di identificare una serie di segnali che indicano la probabilit\u00e0 che una vulnerabilit\u00e0 venga effettivamente sfruttata.<\/p>\n

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\u00e0 di sfruttare la vulnerabilit\u00e0 in questione.<\/p>\n

\"I<\/p>\n

Alcuni segnali, invece, riducono la probabilit\u00e0 di sfruttare una vulnerabilit\u00e0, come una vulnerabilit\u00e0 del browser Safari, o un exploit pubblicato nel database ExploitDB (non molto comodo per scopi pratici), la presenza dei termini \u201cauthenticated\u201d o \u201cdouble free memory\u201d nelle descrizioni CVE e altro. Combinando questi fattori, i ricercatori hanno potuto calcolare la probabilit\u00e0 per una particolare vulnerabilit\u00e0 di essere sfruttata.<\/p>\n

\"Alcuni<\/p>\n

Per verificare l\u2019accuratezza del modello, i ricercatori hanno confrontato le loro previsione con i dati provenienti da attacchi reali. Ecco le conclusioni:<\/p>\n