Patching management — Migliorare la Velocity

Ci sono molte cose che ruotano attorno al tema della Security (o per chi ama il marketing Cyber Security), una di queste è il Patching Management.

Stavo leggendo questo documento redatto da Kenna Security e Cyentia “PRIORITIZATION TO PREDICTION”, vi consiglio la sua lettura per un “azzeramento” su alcuni temi in cui sono personalmente carente, di seguito alcune naturali considerazioni, qualche riflessione e una breve checklist di consigli

Velocity: (def.) the speed of something in a given direction

Ho sempre considerato “efficace” un processo di patching valutando quando questo fosse in grado di coprire, nel minor tempo possibile, le vulnerabilità evidenziate e sollevate da un qualunque tool di continous VA.

Questa mia personale e semplicistica percezione si porta dietro un tema essenziale da identificare: la “Velocity” con cui il patching viene effettuato.

Quant’è il “minor tempo possibile”?

Per chi si occupa di security e abbia la pretesa che chiunque sia intorno a lui abbia lo stesso livello di awareness sui temi SEC, “minor tempo” vuol dire ieri.

Tuttavia questa è una pretesa irrealizzabile soprattutto per chi ha come obiettivo quello di gestire i sistemi che devono essere patchiati (IT Operation), e che deve tener conto, in questo processo, di vari fattori quali:

• Gestione del Software legacy: cosa succede se patcho il sistema?
• Conoscenza tacita di quello che c’è sui sistemi: avrò preso in considerazione tutte le componenti sul sistema?
• Testing e verifica operativa (IT): come effettuo i test e chi coinvolgo per un UAT?
• Testing e verifica di sicurezza: che altro si inventerà quello della security per capire se ho “fatto bene” il mio lavoro?

In poche parole l’availability dei sistemi, al solito, cozza con i requisiti di sicurezza se questa non è prevista “by design” al momento della progettazione di un sistema (ma se parliamo di legacy è quasi sempre “mancante”).

Tuttavia l’availability è uno dei pilastri della sicurezza e spesso prediligere lei al resto la compromette irreparabilmente.

Come parlare con i nostri colleghi dell’IT senza sollevare richieste pretenziose?

Il tema secondo me è dibattuto; a mio modo di vedere ci sono due fattori da tenere in considerazione:

• cosa s’intende per vulnerabilità e
• il monitoraggio del processo.

Quali Vulnerabilità?

Ritengo che sia IT Operation, da un lato, che IT Security, dall’altro, possano convergere sulle “CVE”.

Sapendo di commettere un errore, vedremo poi poco rilevante, personalmente ritengo che le CVE siano il corretto elemento di collegamento tra i due mondi, per i seguenti motivi:

• Permettono una copertura di almeno il 90/95% di quelle che sono le vulnerabilità (non è sufficiente lato SEC ma è un ottimo inizio)
• Producono un elenco di evidenze qualificate, le classificazioni CVSS, che permettono una prioritizzazione degli interventi basata su elementi tangibili
• Sono oramai una standard de facto (forse anche de iure)
• Sono squisitamente misurabili e quantificabili (l’ho già detto per caso?)

Sopra potete notare la distribuzione delle CVE nel tempo. Oltre all’inevitabile aumento fisiologico delle vulnerabilità anche l’adozione massiva del CVE Numbering Authorities, dal 2017, ha fatto si che si sia stato un aumento delle stesse.

Potrà sembrare una banalità ma esistono sistemi di Endpoint Management che non mappano le patch tramite CVE (se non con voli carpiati di CVS ed Excel) e che hanno, per giunta, la pretesa di rimappare quanto il vendor e la community produce come classificazioni. Attenti quindi a verificare cosa c’è sotto il cofano cari colleghi delle IT Operations; chi reiventa la ruota non fa mai un buon lavoro.

Tutte le CVE sono uguali?

No, assolutamente no. Per fare un po’ di discrimine oltre alla “severity” (spesso dichiarata nella patch dal vendor) ci sono altri elementi che conviene tenere in considerazione, mi riferisco ai parametri che compongono la classificazione CVSS, quali:

• Score: quanto pesa quella vulnerabilità;
• Access: dove si deve essere per sfruttarla
• Complexity: quanto è difficile metterla in pratica

Questo potrebbe permettervi di “affettare” il problema evitando di rovesciare un carico di lavoro importante sui vostri colleghi.

Si potrebbero scegliere, come base di partenza, tutte le vulnerabilità sopra la media (score 6,6) che hanno sfruttabilità remota in maniera semplice, per iniziare il patching

Questo riduce lo scope di quello che “osservate” ma attenzione ad avere sempre un quadro d’insieme che tenga conto anche dell’exploitabilità delle vulnerabilità rilevate, altrimenti sono guai.

Rapporto tra vulnerabilità observed/not observed e exploited/not exploited

Ci possiamo concentrare solo sulle “medium/high”?

Di nuovo, assolutamente no!
Spesso in un sistema complesso ci sono molte variabili che creano “combinati disposti” di legale memoria utili a sfruttare una vulnerabilità. Mi ricordo che esisto una serie di seminari “From Low To Pwned” che potrebbero farvi cambiare idea se aveste la presunzione di dire “le low non le patcho”.

Tutto quanto sopra ci permette di scomporre il problema in elementi più piccoli velocizzando il processo di selezione senza tralasciare il suo insieme migliorando, nel complesso, la Velocity.

Altre cose che potremmo prendere in considerazione potrebbero essere:

• il numero di macchine affette,
• il numero di riavvi richiesti,
• quanto il vendor aggrega queste CVE nei suoi processi di patching release periodici ecc.,

vi lascio alla vostra fantasia, al buonsenso e al vostro strumento di patching (che ribadisco spero abbiate scelto accuratamente).

Bonus: Tutti i produttori di software sono uguali?

Anche qui la risposta è no.

Differenze nella “Remediation velocity” dei vari produttori di software

Ci sono molti fattori che influenzano la Velocity in un processo di patching. Oltre a quelli che inevitabilmente sono interni al processo, quindi all’azienda, ce ne sono altri riconducibili al vendor e quindi non trascurabili per definizione.

In un ciclo di patching per raggiungere il 25% del parco macchine si passa dai 14gg quando si ha a che fare con Microsoft ai 225gg quando il prodotto è di IBM (o HP o Oracle o Cisco) 15/16 volte tanto rispetto al migliore.
Dato per me impressionante.

Questo è riconducibile ad una serie di fattori che vanno dalla bontà del ciclo di sviluppo dei software in questione, al suo impiego nell’architettura IT spesso diverso e più infrastrutturale.

Java, ad esempio, è notoriamente molto difficile da patchare senza rompere qualcosa (il susseguirsi dei vari vendor e la mancata retro-compatibilità del framework sono oramai problemi cronici). Apple ha storicamente meno vulnerabilità di Microsoft, e (forse) forte di una “auto-attribuita” superiorità nello sviluppo, lascia latitare il supporto enterprise. Google aggiorna molto di frequente i propri prodotti ma gli utenti si scordano di riavviare il browser.

Quello che emerge forte e chiaro tuttavia è che, i software che si auto-aggiornano o che hanno una chiara e definita periodicità nei rilasci delle patch, anche di sicurezza, hanno dei cicli di applicazione delle patch più semplici quindi più corti.

Morale: scegliete con cura i vostri software e soprattutto i vendor.

Differenze nella “Remediation velocity” dei vari produttori di software — Timeline in mesi

Dati gli assunti che abbiamo fatto sopra sulle CVE e i loro “parametri” CVSS si potrebbe immaginare che le aziende, stando al documento, potrebbero patchare prima le vulnerabilità con rischio più alto. Purtroppo il seguente grafico lascia intravedere una realtà diversa.
Evitate di scegliere la “semplicità di patching” come unico parametro altrimenti potreste avere delle brutte sorprese in caso di attacco.

Come e cosa monitorare?

Ok, ora che ci siamo dati delle regole sul cosa tenere sotto controllo e sul come aggredire lo scope di patch da applicare, clusterizzandole, torniamo al tema iniziale, “in quanto tempo”?

Il momento t0 è quello della scoperta della vulnerabilità (chiaramente scoperta esterna)

Il grafico sopra riporta quanto osservato nel report sulla totalità delle aziende prese in considerazione (divise equamente tra: small, medium e large enterprise) sulla totalità dei brand/vendor di software soggetti a patching.

Da questo grafico deduco tre informazioni fondamentali:

1. per coprire i 2/3 delle vulnerabilità nel cluster selezionato 3 mesi è un tempo medio spesso non accettabile dal punto di vista della security
2. la copertura del 100% è irrealizzabile
3. I cicli di verifica dovrebbero essere almeno trimestrali

Immaginiamo uno scenario di una vulnerabilità wormable, 0day, ad alto rischio e immaginiamo un nome a caso: EternalBlue (alla base di WannaCry)

Qui la breve cronistoria degli eventi

• Estate 2016: l’NSA perde il controllo di alcuni toolkit utilizzati dal TAO (Tailored Access Operation), tra cui EternalBlue; il furto viene perpetrato ad opera di Shadow Brokers
• Il 14 Marzo 2017: Microsoft rilascia la patch per molti sistemi operativi con il bulletin MS017–010; Severity: Critical
• Il 12 Maggio 2017 fa la sua comparsa nel mondo WannaCry

Analizziamo questi eventi alla luce del grafico sopra, assumendo che la statistica sia retroattivamente valida.

I più efficaci nel processo di aggiornamento delle macchine, cioè quelli partiti con l’applicazione della patch critica lo stesso giorno (o il giorno dopo) della pubblicazione del bulletin Microsoft, durante il rilascio di WannaCry avevano aggiornato il 45% delle macchine, magari, spero io, quelle critiche per il business (oppure no perché avete deciso di lasciate indietro proprio quelle perché “non si possono fermare i sistemi”; se siete nella seconda categoria e non avete avuto seri problemi siete stati solo fortunati fino ad oggi).

Le dimensioni contano, ma non come credete

La dimensione di una compagnia può determinare in maniera significativa il tempo che si impiega per completare “un giro” di patching.

La remediation velocity cambia a seconda della grandezza dell’azienda

Cosa sarà rimasto di quei sistemi non patchati di una large company dopo il 64° giorno se nel mentre hanno “incontrato” WannaCry? Penso ben poco.

La cosa preoccupante a mio avviso è che: tanto è grande l’azienda, quindi nominalmente con più risorse, tanto il processo è lento, forse e spero per una maggiore complessità nella gestione del processo o forse (ma non lo spero) per uno sbilanciamento nella distribuzione delle risorse tra i vari dipartimenti o per mala gestione.

Chiaramente l’awareness è l’elemento chiave che contraddistingue gli andamenti nelle varie industry di appartenenza:

La remediation coveage distinta per industry/market

Nell’impostare la vostra strategia di patching, e in virtù delle esperienze sopra citate risulta chiaro che ci siano aziende più attente a certi temi (le banche) e altre molto più inclini a “lasciar correre”, spesso però un 5% più lenti o più veloci può segnare la differenza tra catastrofe e salvezza.

In conclusione

• Scegliete un linguaggio comune con i colleghi delle IT Operation es. le CVE
• Clusterizzate la scelta delle CVE da patchare sui parametri CVSS delle stesse prediligendo exploitabilità, accessibilità della vulnerabilità e score
• Programmate di patchare anche ciò che è Low per diminuire drasticamente la superfice d’attacco
• Ogni mese coprite il maggior numero di macchine core per il business aziendale a partire dai cluster selezionati (magari prediligendo le exploitable su cadenza quindicinale e le altre mensilmente)
• 1 Mese per chiudere il 65% delle macchine è una sfida fattibile (i Top Performer del report sono 2.5 volte più veloci degli altri)

• Lasciate che i sistemi si aggiornino (o non vi frapponete tra loro e gli aggiornamenti se non sapete fare di meglio), soprattutto per gli applicativi consumer in mano all’utente
• Effettuate test trimestrali sul buon andamento del processo
• Effettuate verifiche trimestrali su cosa non è stato ancora preso in considerazione dal processo di patching (vulnerabilità escluse dal)
• Commettere l’errore di pensare che a “noi non capiterà” (un attacco infrastrutturale). Potrebbe esservi fatale.