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.