Patch Il “” del martedì, il giorno in cui Microsoft pubblica i propri aggiornamenti software, ricorre una volta al mese con la precisione di un orologio. Quasi tutti (almeno nel mondo della sicurezza informatica) lo sanno, quindi verrebbe da pensare che i team IT aggiornino i propri sistemi non appena ricevono l’avviso.
Solo che non è così. Da un recente studio intitolato “ ” ( ), condotto da Synopsys, è emerso che il 28% dei professionisti IT impiega almeno tre settimane per applicare le patch alle vulnerabilità critiche, mentre un altro 20% ammette di impiegare fino a un mese.
In un momento in cui gli autori delle minacce stanno mettendo a punto nuovi attacchi mirati alle vulnerabilità, questo approccio lento alla gestione delle patch di sta esponendo innumerevoli reti e dati a un rischio ancora maggiore. È come guidare un’auto con la spia di manutenzione accesa: si sa che c’è un problema, ma poiché l’auto funziona ancora, è facile rimandare la riparazione.
Possono trascorrere settimane o mesi prima che un’auto si guasti dopo l’accensione della spia di manutenzione. Nel campo della sicurezza, quando viene pubblicato un avviso relativo a una patch, si hanno solo pochi secondi per risolvere il problema – se non è già troppo tardi – poiché i malintenzionati effettuano continuamente scansioni alla ricerca di vulnerabilità note.
«Anche se ci si trova all’interno di una rete aziendale e tutto è protetto da un firewall, è solo questione di tempo prima che qualcuno riesca a penetrare nel perimetro e individui quella vulnerabilità», ha affermato David Brumley, consulente dell’agenzia di intelligence sulla sicurezza del software, professore di sicurezza informatica presso la Carnegie Mellon University e “ CEO ” presso ForAllSecure. «Dal punto di vista della sicurezza, è opportuno applicare le patch il più rapidamente possibile.»
Le ragioni alla base della lentezza nell’applicazione delle patch
Nel corso dell’ultimo anno, i team IT e di sicurezza si sono trovati ad affrontare vulnerabilità quali: MOVEit, una vulnerabilità zero-day relativa al trasferimento di file che potrebbe consentire agli aggressori di assumere il controllo di un sistema; curl, un attacco zero-day contro uno strumento open source che utilizza la sintassi URL per il trasferimento dei dati; e l’exploit Apache Superset , una vulnerabilità zero-day che espone configurazioni e database. Sebbene ogni anno vengano registrati meno di 100 nuovi attacchi zero-day, questi tendono a causare danni di entità sproporzionata, poiché non prendono di mira una singola organizzazione, ma tutti coloro che utilizzano il software. La capacità di colpire un numero così elevato di obiettivi con il minimo sforzo ne fa un vettore di attacco molto diffuso tra gli Stati-nazione e le organizzazioni criminali informatiche.
«Anche se vi trovate all’interno di una rete aziendale e tutto è protetto da un firewall, è solo questione di tempo prima che qualcuno riesca a penetrare nel perimetro e individui quella vulnerabilità.»David Brumley, consulente in materia di sicurezza informatica e professore presso la Carnegie Mellon University
Allora, perché i team IT e di sicurezza impiegano così tanto tempo ad applicare le patch una volta che vengono rilasciate?
La prima sfida riguarda la visibilità dell’ : i team di sicurezza devono conoscere il numero e le tipologie di risorse e di endpoint effettivamente in uso su una rete, sia le apparecchiature ufficialmente autorizzate dall’azienda sia i numerosi altri dispositivi e applicazioni che i dipendenti introducono di propria iniziativa. La vulnerabilità potrebbe risiedere, ad esempio, in un sistema “shadow IT” utilizzato dai dipendenti e non segnalato al personale IT. Oppure il team DevOps potrebbe utilizzare ambienti che si basano su strumenti non supportati.
Un secondo fattore che ritarda l’applicazione delle patch riguarda la visibilità del software – in particolare, i componenti all’interno del software in cui si trova la vulnerabilità. Troppo spesso, quando viene resa nota una vulnerabilità zero-day, i team di sicurezza si rendono conto di non disporre di informazioni sufficienti sulla propria catena di fornitura del software “ ” e devono affrettarsi a verificare se un componente infetto sia integrato in una delle applicazioni in uso sulla propria rete.
[Leggi anche: 7 modi per proteggere la propria catena di fornitura del software]
Ecco cosa è accaduto su dicembre 2021 quando è stata individuata una vulnerabilità zero-day in Apache Log4j, la popolare libreria di logging open source Java utilizzata in decine di migliaia di applicazioni. Le patch sono state rilasciate poco dopo eppure, a distanza di oltre due anni, un numero impressionante di aziende non ha ancora risolto la vulnerabilità. (Da un recente sondaggio condotto da è emerso che il 38% delle app che utilizzano la versione Log4j si basa su una versione non sicura.)
Per individuare tali componenti problematici, le aziende ricorrono sempre più spesso a una “ ” (SBOM, Software Bill of Materials), che elenca in modo dettagliato i componenti o gli elementi costitutivi di tutte le applicazioni e i programmi software utilizzati da un’organizzazione. «Pensi ai vari prodotti presenti nella Sua dispensa», ha spiegato Melissa Bischoping, direttrice della ricerca sulla sicurezza informatica presso endpoint (società proprietaria di questa rivista) all’indirizzo Tanium . Ogni ingrediente contenuto in ogni prodotto viene accuratamente monitorato dai produttori alimentari, il che consente loro – nel caso, ad esempio, di un focolaio di listeriosi o di E. coli – di individuare con esattezza quando e dove un ingrediente contaminato sia stato aggiunto al proprio prodotto. Allo stesso modo, un SBOM semplifica il monitoraggio dei componenti che costituiscono il software e rende tali informazioni più facilmente accessibili quando viene rilevata una vulnerabilità.
Una terza possibile ragione alla base della lentezza nell’applicazione delle patch è di natura commerciale.
«L’attività deve proseguire, e molti sistemi richiedono interruzioni, tempi di inattività o riavvii», ha affermato Bischoping. «Ciò può provocare resistenze da parte dei titolari delle aziende o dei team operativi, i quali sostengono che l’applicazione della patch debba essere rimandata.»
Ci sono poi casi in cui una vulnerabilità è nota e i dirigenti aziendali ne sono informati e si sono impegnati ad applicare la patch, ma non è possibile intervenire finché il fornitore non la rilascia. Ciò rappresenta un problema soprattutto nel caso del software open source o dei sistemi che utilizzano componenti open source.
«Bisogna attendere che i fornitori aggiornino il proprio software», aggiunge Bischoping. «Ciò significa attendere che l’intero ecosistema renda disponibili tali aggiornamenti e, successivamente, disporre dei processi, delle tecnologie e delle politiche necessarie per agevolarne l’implementazione nel nostro ambiente.»
Perché a volte è così allettante rallentare un po’ il ritmo
Alcuni di coloro che rimandano l’installazione delle patch sostengono di avere una giustificazione: temono che applicare immediatamente la patch possa finire per causare più danni.
“Interruzioni di servizio, tempi di inattività o riavvii… possono provocare resistenze da parte dei titolari delle aziende o dei team operativi, i quali sostengono che l’applicazione della patch debba essere rimandata.”Melissa Bischoping, responsabile della ricerca sulla sicurezza presso l’ endpoint , Tanium
«L’applicazione delle patch comporta delle incognite», ha affermato Brumley. In qualità di utente, non sa quanto tempo richiederà l’aggiornamento, se l’applicazione della correzione causerà malfunzionamenti nei sistemi, né quale problema si sta risolvendo o prevenendo.
Dal punto di vista di uno sviluppatore, può risultare difficile garantire la stabilità del codice esistente. «Quando ha scritto il codice, funzionava perfettamente. «Ma ora, quando vi viene richiesto di effettuare un aggiornamento, lo sviluppatore non sa in quale punto la dipendenza presenti una nuova instabilità», ha osservato.
Agli sviluppatori vengono forniti messaggi contraddittori quando viene loro richiesto di applicare una patch. Da un lato occorre aggiornare il prima possibile tutti i componenti vulnerabili, dall’altro occorre assicurarsi che nulla smetta di funzionare. Quest’ultimo aspetto, ha aggiunto Brumley, è il modo in cui gli sviluppatori valutano il proprio lavoro: desiderano creare un codice solido piuttosto che doverlo correggere.
Per alleggerire in parte il carico di lavoro degli sviluppatori e ridurre la tentazione di attendere la verifica delle incognite relative alle patch, i team IT e di sicurezza potrebbero (e dovrebbero) adottare un approccio “ ” (sicurezza integrata fin dalla progettazione) . Tale approccio mira a eliminare il più possibile le vulnerabilità attraverso test continui e l’integrazione di misure di protezione per l’autenticazione nel processo di sviluppo. La Strategia nazionale per la sicurezza informatica “ ” (), pubblicata dalla Casa Bianca nel 2023, raccomanda vivamente alle organizzazioni di adottare protocolli di “security-by-design”. Secondo la Cybersecurity and Infrastructure Security Agency (CISA), l’adozione di un approccio “secure by design” consentirà di colmare più efficacemente le lacune nella sicurezza informatica, compreso il lasso di tempo che intercorre tra il rilascio di una patch e la sua applicazione.
Finché non avremo raggiunto un punto in cui la “sicurezza fin dalla progettazione” sarà la norma in tutte le organizzazioni, avremo bisogno di una procedura adeguata che coinvolga i team IT, di sicurezza e di sviluppo, al fine di garantire che l’applicazione delle patch proceda a un ritmo più sostenuto.
L'applicazione delle patch inizia con le politiche
A differenza di un privato che, seduto davanti al proprio computer di casa, installa gli aggiornamenti su Chrome e Windows, la gestione delle patch in un contesto aziendale inizia con la definizione di politiche, secondo quanto afferma Kyle Miller, socio del gruppo globale per la protezione dei dati e la sicurezza informatica di Dentons.
“Se uno strumento monitora il 80% delle vostre applicazioni, allora il 20% delle vostre applicazioni presenterà un rischio sproporzionato di vulnerabilità, poiché non è incluso nel vostro strumento di gestione delle patch.”Kyle Miller, socio dello studio legale Dentons
«Il punto di partenza consiste nel documentare le politiche e le procedure relative alla gestione delle patch», ha affermato Miller. Ciò garantisce un controllo organizzativo volto ad assicurare che chiunque si occupi dell’implementazione della patch sia a conoscenza delle aspettative dell’azienda.
«La maggior parte delle aziende con cui collaboro dedica una finestra temporale al di fuori dell’orario di lavoro per applicare le patch di routine», ha affermato Miller. «Ma hanno anche bisogno di una procedura per approvare, all’occorrenza, l’applicazione di patch alle vulnerabilità critiche, e talvolta ciò deve avvenire il più rapidamente possibile.» Ciò richiede di effettuare un inventario dei sistemi, in modo da poter identificare i potenziali rischi e l'origine della patch.
Uno dei motivi per cui l’applicazione delle patch viene effettuata al di fuori dell’orario di lavoro è che in tal modo si riducono i tempi di inattività che ne derivano. E se l’applicazione delle patch viene effettuata manualmente – un processo che richiede molto tempo – spesso questo è l’unico momento in cui i team di sicurezza riescono a occuparsene.
Ciò avvalora l’importanza sia dell’automazione dell’ e che dell’intelligenza artificiale. L’automazione del processo di applicazione delle patch non solo ridurrà la necessità di interventi manuali in un’attività altrimenti ripetitiva, ma consentirà anche di prestare maggiore attenzione agli aggiornamenti, il che, a sua volta, ridurrà il periodo di vulnerabilità. L’automazione del processo di applicazione delle patch può inoltre migliorare la posizione dell’azienda rispetto agli obiettivi di conformità, riducendo il rischio che un attacco informatico provochi una violazione dei dati. Le organizzazioni possono inoltre avvalersi di soluzioni di gestione delle vulnerabilità basate sull’intelligenza artificiale (), in grado di classificare le vulnerabilità in base ai rischi critici e di applicare le patch in funzione di tale priorità.
Esiste un’ampia gamma di strumenti per la gestione delle patch, ma Miller avverte che, affinché uno strumento sia efficace, deve essere adattato alle vostre esigenze specifiche.
«Se uno strumento monitora il 80% delle vostre applicazioni, allora il 20% delle vostre applicazioni presenterà un rischio sproporzionato di vulnerabilità, poiché non è incluso nel vostro strumento di gestione delle patch», ha affermato Miller. Allo stesso modo, gli strumenti di gestione delle patch in grado di individuare le versioni obsolete dei vostri sistemi interni sono utili solo se un addetto alla sicurezza esamina tali notifiche e provvede ad aggiornare tali sistemi.
Detto questo, occorre anche prestare attenzione alla proliferazione degli strumenti di " ". Un numero eccessivo di strumenti può infatti ostacolare l’efficacia delle operazioni di applicazione delle patch e la sicurezza informatica in generale. Per garantire un processo di applicazione delle patch il più efficace possibile, i team IT e di sicurezza dovranno valutare gli strumenti già a loro disposizione, individuare eventuali ridondanze e le aree non coperte, determinare l’efficacia di ciascuno (gli strumenti risolvono effettivamente i problemi di sicurezza attuali o sono compatibili con i sistemi attualmente in uso?) e stabilire in che modo tali strumenti possano ridurre al meglio le attività manuali grazie a processi di applicazione delle patch automatizzati .
«È necessario combinare l’acquisto dello strumento con la verifica che esso sia adattato al proprio sistema e implementato in modo appropriato, per poi essere monitorato dal proprio team IT interno», ha affermato Miller.
Migliorare la vostra cultura delle correzioni
Indipendentemente dagli strumenti utilizzati, dalle politiche adottate o dalla solidità del codice in fase di sviluppo, le vulnerabilità continueranno sempre a presentarsi. Consapevoli di questa realtà, le aziende devono cambiare la propria cultura in materia di aggiornamenti. Un modo per farlo consiste nel creare un programma di gestione delle vulnerabilità .
«La creazione di un vero e proprio programma di gestione delle vulnerabilità rientra nella realizzazione di un programma efficace di gestione delle patch», ha affermato Bischoping dell’ Tanium.
Potrebbero sembrare la stessa cosa, ma non lo sono. La gestione delle vulnerabilità valuta le minacce e l’impatto che ciascuna di esse può avere sul Suo ambiente. Alcune potrebbero rappresentare un grave rischio per la sicurezza della vostra organizzazione, mentre altre vulnerabilità ad alto livello di gravità potrebbero non essere sfruttabili nel vostro sistema.
Oltre a creare programmi di gestione delle vulnerabilità, le organizzazioni devono migliorare la sicurezza complessiva e la formazione sulla sensibilizzazione. Mostrare agli utenti le conseguenze di sistemi non protetti, sottolineare i pericoli derivanti da vulnerabilità non corrette e definire politiche e procedure volte a ottimizzare il funzionamento del sistema aiuterà i team IT e di sicurezza ad affrontare con maggiore efficacia le difficoltà che impediscono l’applicazione tempestiva delle patch.
