Quando un fornitore pubblica una patch, gli autori degli attacchi potrebbero ricavarne indizi sulla vulnerabilità che essa risolve. È proprio in quel lasso di tempo che intercorre tra il rilascio della patch e la sua installazione verificata sui vostri endpoint che si accumula il rischio.
La presente guida illustra il funzionamento tecnico delle patch, i diversi tipi di patch che potrete incontrare e il motivo per cui la verifica è importante tanto quanto l’implementazione.
Cosa fa effettivamente una patch software
Una patch software è un breve frammento di codice che modifica un programma o un sistema operativo esistente. Le patch risolvono i bug, correggono le vulnerabilità di sicurezza o migliorano le prestazioni. A differenza di un aggiornamento completo del software o del rilascio di una nuova versione, una patch risolve problemi specifici senza sostituire l'intera applicazione.
Quando un fornitore individua un difetto, che si tratti di un errore di programmazione che causa arresti anomali o di una delle numerose vulnerabilità note che gli hacker potrebbero sfruttare, sviluppa una patch per correggerlo. La patch sovrascrive o modifica file specifici, voci del Registro di sistema o impostazioni di configurazione sul sistema di destinazione. La consideri come se dovesse sostituire un singolo componente difettoso in una macchina, anziché sostituire l’intero motore.
Le patch vengono distribuite tramite i siti web dei fornitori, gli aggiornamenti automatici come Windows Update, App o gli strumenti aziendali di gestione delle patch. Una volta installata, la patch modifica il comportamento del software intervenendo sul codice sottostante che era all’origine del problema.
Ecco cosa distingue le patch dagli altri tipi di aggiornamento:
- Ambito di applicazione: Le patch risolvono problemi specifici e circoscritti, anziché introdurre modifiche di ampia portata alle funzionalità
- Dimensioni: In genere sono di piccole dimensioni, spesso di pochi megabyte
- Urgenza: Le patch di sicurezza, in particolare, sono soggette a vincoli temporali poiché risolvono vulnerabilità di cui gli autori degli attacchi potrebbero già essere a conoscenza
Non appena un fornitore pubblica una patch, ha inizio il periodo di vulnerabilità per le organizzazioni che non l’hanno ancora applicata. Gli hacker e altri malintenzionati, compresi i criminali informatici organizzati, monitorano spesso il rilascio delle patch poiché queste possono rivelare indizi importanti sulla posizione di una vulnerabilità. Ecco perché il lasso di tempo che intercorre tra la disponibilità della patch e la sua installazione verificata è così importante.
Una volta chiariti i concetti fondamentali, la domanda successiva è: quali tipi di patch esistono e in cosa differiscono?
Una tassonomia precisa delle tipologie di patch software
Non tutte le patch software presentano lo stesso grado di urgenza o lo stesso profilo di rischio. Conoscere le differenze vi aiuta a organizzare le implementazioni in base all’impatto effettivo piuttosto che all’ordine di arrivo.
| Patch tipo | Finalità | Urgenza tipica | Complessità del rollback |
|---|---|---|---|
| Patch di sicurezza | Risolve una specifica vulnerabilità | Da elevato a critico | Di solito è semplice |
| Hotfix | Risolve un bug urgente al di fuori dei normali cicli di rilascio | Alto | Varia a seconda dell'ambito |
| Correzione di un errore | Corregge gli errori funzionali che incidono sulle prestazioni | Medio | Di solito è semplice |
| Aggiornamento cumulativo | Raggruppa più patch in un unico pacchetto | Medio | Più complesso |
| Service Pack | Include patch, correzioni di bug e miglioramenti delle funzionalità | Inferiore | Complesso |
| Aggiornamento delle funzionalità | Aggiunge nuove caratteristiche e nuove funzionalità | Inferiore | Varia |
Le patch di sicurezza, talvolta denominate “aggiornamenti di sicurezza”, risolvono le vulnerabilità che potrebbero consentire accessi non autorizzati, furti di dati o compromissioni del sistema. Il Common Vulnerability Scoring System (CVSS) valuta la gravità su una scala compresa tra 0 e 10. Un punteggio CVSS pari o superiore a 9,0 indica generalmente una vulnerabilità critica che dovrebbe essere trattata con la massima priorità.
Gli hotfix sono patch di risposta rapida rilasciate al di fuori del normale calendario degli aggiornamenti. I fornitori rilasciano hotfix quando l'attesa della prossima versione programmata esporrebbe i sistemi a minacce attive o a bug critici.
Gli aggiornamenti cumulativi raggruppano più patch in un unico pacchetto. Microsoft'Le pubblicazioni mensili del martedì della rubrica “ Patch ” assumono spesso questa forma. Sebbene siano pratici, gli aggiornamenti cumulativi possono risultare più difficili da annullare poiché raggruppano numerose modifiche.
Le implicazioni pratiche: Le patch di sicurezza e gli hotfix richiedono una risposta immediata poiché chiudono le finestre di vulnerabilità attive. Gli aggiornamenti cumulativi e i service pack raggruppano diverse correzioni e miglioramenti, il che rende più difficile ripristinare la versione precedente in modo corretto. Li si verifichino in ambienti applicativi rappresentativi prima di procedere a una distribuzione su larga scala.
Gli aggiornamenti delle funzionalità che introducono nuove funzionalità presentano il livello di urgenza più basso, ma comportano i rischi di incompatibilità più imprevedibili.
Una volta chiariti i diversi tipi di patch, ripercorriamo il percorso che una patch compie dal rilascio da parte del fornitore all’installazione su endpoint .
Il ciclo di vita delle patch software, dal rilascio da parte del fornitore all’installazione su endpoint
Dal momento in cui un fornitore distribuisce una patch software a quello in cui essa viene verificata sui vostri endpoint, possono verificarsi numerosi problemi. Ogni fase del ciclo di vita rappresenta un potenziale ritardo, e ogni ritardo allunga il lasso di tempo a disposizione degli aggressori per agire.
1. Individuazione: Il fornitore individua una vulnerabilità di sicurezza tramite test interni, segnalazioni da parte di ricercatori di sicurezza o segnalazioni dei clienti. Per questioni di sicurezza, ciò comporta spesso il coordinamento con organizzazioni quali la CISA o l’ , NIST e prima della divulgazione al pubblico.
2. Sviluppo: Gli ingegneri sviluppano una correzione, la testano su diverse configurazioni e la preparano per la distribuzione. Questa fase può richiedere giorni o settimane, a seconda della complessità.
3. Comunicato: Il fornitore pubblica la patch attraverso i canali ufficiali. Nel caso di software di largo uso, il presente annuncio potrebbe mettere in guardia gli autori degli attacchi circa l’esistenza della vulnerabilità.
4. Rilevamento: La Sua organizzazione viene a sapere dell’esistenza di nuove patch, sia per il software di prima parte che per le applicazioni di terze parti . Ciò avviene tramite avvisi dei fornitori, notifiche automatiche provenienti dalle piattaforme di gestione delle patch, il catalogo CISA delle vulnerabilità note oggetto di sfruttamento (KEV), il National Vulnerability Database (NVD) o strumenti di scansione automatizzata.
5. Definizione delle priorità: Si valuta quali endpoint siano interessati e con quale urgenza sia necessario applicare la patch, tenendo conto della gravità della vulnerabilità , della criticità delle risorse e del contesto aziendale.
6. Test: Prima di procedere alla distribuzione su larga scala, è necessario testare le patch su un campione rappresentativo di endpoint per individuare eventuali problemi di compatibilità o comportamenti imprevisti.
7. Distribuzione: La patch viene distribuita agli endpoint interessati tramite la vostra infrastruttura di distribuzione. Ciò potrebbe avvenire in più fasi, iniziando dai sistemi meno critici prima di passare agli ambienti di produzione.
8. Verifica: Si accerta che la patch software sia stata installata correttamente sugli endpoint di destinazione, verificando che il codice o la libreria dell’applicazione vulnerabile siano stati sostituiti, e non solo che il comando di distribuzione sia stato eseguito.
È proprio nell’intervallo tra la fase 3 (rilascio) e la fase 8 (verifica) che si accumula il rischio. Ogni giorno che trascorre con endpoint non aggiornati può ampliare il margine di manovra a disposizione degli aggressori.
Suggerimento: Map Valutate il vostro attuale flusso di lavoro relativo al processo di applicazione delle patch alla luce di queste fasi. In quali casi si verificano solitamente i ritardi? È proprio su questo che occorre concentrare gli sforzi di miglioramento.
Il periodo di esposizione e il rischio che esso comporta
Il periodo di vulnerabilità è l'intervallo di tempo che intercorre tra il momento in cui un fornitore rilascia una patch e quello in cui avete verificato che sia stata installata su tutti gli endpoint interessati. Non si tratta di un concetto astratto. Si tratta di un rischio quantificabile.
Gli aggressori non aspettano. Quando viene rilasciata una patch, spesso questa include informazioni dettagliate sulla vulnerabilità che risolve. Sia i ricercatori nel campo della sicurezza che gli autori delle minacce possono effettuare il reverse engineering della patch per comprendere esattamente come sfruttare i sistemi non aggiornati. In molti casi, trasformano rapidamente tali informazioni in un’arma, diffondendo malware progettato per sfruttare la vulnerabilità appena rivelata prima che le organizzazioni abbiano avuto modo di reagire.
Ogni giorno che trascorre all’interno di tale finestra di vulnerabilità rappresenta un giorno in cui gli aggressori possono agire sulla base delle informazioni che il Vostro stesso fornitore ha messo a loro disposizione al momento della pubblicazione della patch. Si consideri cosa accade durante un tipico periodo di esposizione:
- Giorno 0: Il fornitore rilascia una patch e un avviso
- Giorno 1–3: Gli hacker iniziano a sviluppare exploit basati sui dettagli delle patch
- Giorno 7: Potrebbe essere in circolazione nei forum clandestini un codice di exploit relativo a “ ”
- Giorno 14: Sono disponibili strumenti di attacco automatizzati che incorporano l’exploit
- Giorno 30+: La vostra organizzazione completa finalmente l’implementazione
Durante tale periodo, gli endpoint non aggiornati potrebbero rimanere vulnerabili. Più a lungo la finestra rimane aperta, maggiore è la probabilità che il sistema venga compromesso. Le vulnerabilità delle applicazioni non corrette stanno diventando sempre più spesso punti di accesso attivi per gli autori degli attacchi, aumentando il rischio di violazioni dei dati che comportano conseguenze normative, finanziarie e reputazionali.
La finestra di esposizione, tuttavia, non riguarda solo la velocità. Si tratta anche di completezza. Se applicate rapidamente le patch al 95 % degli endpoint interessati, ma ne tralasciate il 5 %, i sistemi trascurati rimangono esposti a rischio a tempo indeterminato.
In una grande impresa, il 5 % potrebbe significare migliaia di endpoint vulnerabili.
Per eliminare la vulnerabilità sono necessari due passaggi: applicare rapidamente le patch software e verificare che siano state effettivamente installate su ogni endpoint interessato. La maggior parte delle organizzazioni se la cava abbastanza bene nella prima parte. Il secondo caso è quello in cui i programmi smettono di funzionare senza dare alcun segnale.
Perché l’implementazione delle patch software spesso fallisce su larga scala
L'applicazione di una patch software a migliaia di endpoint sembra un’operazione meccanica. In pratica, è proprio lì che si creano silenziosamente delle lacune nella copertura, che prendono forma le violazioni della sicurezza e che le vulnerabilità delle applicazioni non corrette permangono più a lungo.
Gli endpoint non sono sempre raggiungibili. I computer portatili si spostano. I lavoratori da remoto si connettono in modo intermittente. I server situati in segmenti di rete isolati potrebbero non ricevere i comandi di distribuzione. Se un endpoint non è online e connesso al momento dell'invio della patch, non riceverà l'aggiornamento.
Le dipendenze generano conflitti. Una patch software destinata a un’applicazione può causare il malfunzionamento di un’altra applicazione che dipende da una versione specifica o da una libreria condivisa. Senza una visione d’insieme di ciò che è installato e di come le applicazioni interagiscono tra loro, non vi accorgerete che c’è un problema finché qualcosa non smetterà di funzionare.
Gli ambienti eterogenei aumentano la complessità. Le aziende gestiscono contemporaneamente più versioni di applicazioni, stack di dipendenze e configurazioni del sistema operativo. Una patch software convalidata per una determinata versione di un’applicazione potrebbe comportarsi in modo diverso se applicata a un’altra versione. Senza una visione chiara di ciò che è effettivamente installato, state effettuando l'implementazione alla cieca.
Le dichiarazioni fornite dagli stessi interessati non sono attendibili. Molti strumenti di applicazione delle patch segnalano il successo in base al fatto che il comando di distribuzione sia stato eseguito, non al fatto che la patch sia stata effettivamente installata correttamente. Un rapporto " endpoint " potrebbe indicare che la vulnerabilità è stata "corretta", mentre in realtà la vulnerabilità sottostante persiste.
Le finestre di manutenzione sono limitate. Le applicazioni che non possono essere riavviate durante l’orario di lavoro a causa di potenziali tempi di inattività limitano i tempi disponibili per l’applicazione delle patch. Quando tali finestre si chiudono prima che l’implementazione sia completata, le patch software vengono messe in coda anziché essere applicate. Il cumulo di lavoro arretrato si aggrava nel tempo, ampliando il periodo di vulnerabilità per ogni patch che non è stata implementata e costringendo i team di supporto IT a dedicarsi a interventi correttivi reattivi anziché a un’implementazione proattiva.
Verifica che una patch sia stata effettivamente applicata
L'implementazione non rappresenta il traguardo. La verifica consiste in quanto segue.
Una patch software distribuita senza che ne sia stata verificata l'installazione costituisce una questione aperta, non una vulnerabilità risolta. È proprio nel divario tra «l’abbiamo distribuita» e «l’abbiamo verificata» che le organizzazioni tendono costantemente a sovrastimare la loro effettiva copertura delle patch.
La verifica risponde a tre domande:
- La patch è stata inserita nell’ endpoint? Problemi di rete, dispositivi non connessi o errori di implementazione possono impedire la consegna.
- L' endpoint e ha installato correttamente le patch? Spazio su disco insufficiente, errori di autorizzazione o conflitti possono causare il fallimento dell'installazione anche se la patch è stata consegnata.
- La vulnerabilità è stata effettivamente risolta? In alcuni casi, è possibile che una patch venga installata senza tuttavia risolvere completamente il problema a causa di requisiti di configurazione o di riavvii in sospeso.
Molte organizzazioni fanno affidamento sui rapporti di esito positivi dei propri strumenti di applicazione delle patch. Tuttavia, tali rapporti riflettono spesso tentativi di implementazione, non risultati verificati. Lo strumento indica di aver applicato la patch. Ciò non conferma che l’ endpoint a abbia effettivamente ricevuto e installato correttamente le patch, né che la vulnerabilità sottostante sia stata risolta.
Per garantire un'efficace verifica è necessario interrogare direttamente gli endpoint al fine di confermarne lo stato attuale. Qual è la versione dell'applicazione installata? La libreria o il file vulnerabile è ancora presente? L'applicazione è stata riavviata per attivare il codice aggiornato?
È proprio in questo contesto che la visibilità in tempo reale endpoint assume un’importanza fondamentale. Le scansioni puntuali non rilevano gli endpoint che erano offline durante la scansione.
Inoltre, non rilevano le modifiche apportate dopo il completamento della scansione. La visibilità continua offre un quadro aggiornato e accurato dello stato delle patch nell’intero ambiente.
Suggerimento: Dopo l’applicazione di qualsiasi patch critica, esegua una query direttamente sugli endpoint interessati per verificare che il componente vulnerabile non sia più presente. Non si affidi esclusivamente ai registri di distribuzione.
La verifica completa il ciclo relativo a una singola patch software. Tuttavia, nessuna patch viene distribuita isolatamente, ed è il programma responsabile del passaggio delle patch dalla versione del fornitore allo stato verificato “ endpoint ” a determinare se la copertura rimane valida su larga scala.
Il ruolo delle patch software nella gestione delle patch
È fondamentale comprendere che cos’è una patch software e come funziona. In un contesto aziendale, tuttavia, le singole patch non si installano da sole. Essi seguono un percorso prestabilito: individuazione, definizione delle priorità, test, implementazione e verifica.
Tale programma è la gestione delle patch, e il suo corretto funzionamento determina la rapidità con cui la vostra organizzazione chiude la finestra di vulnerabilità dopo il rilascio di una patch software. Per un’analisi più approfondita della struttura e dei criteri di valutazione dei programmi di gestione delle patch, consulti la nostra guida “ ” dedicata alla gestione delle patch all’indirizzo.
Una patch software costituisce l'artefatto. Patch La gestione è il sistema che garantisce il passaggio di tale artefatto dalla versione rilasciata dal fornitore all’installazione verificata su centinaia di migliaia di endpoint.
Questa distinzione è importante perché molti errori nell'applicazione delle patch non sono dovuti alla patch stessa. Riguardano il programma:
- Lacune nell'individuazione: Non si sa se una patch esista né quali endpoint ne abbiano bisogno
- Errori nella definizione delle priorità: Le patch critiche rimangono in coda dietro agli aggiornamenti di routine
- Colli di bottiglia nei test: L’implementazione subisce ritardi poiché i team devono verificare manualmente la compatibilità
- Limiti di distribuzione: Le patch non riescono a raggiungere tutti gli endpoint interessati
- Lacune nella verifica: Non siete sicuri che le patch siano state effettivamente installate
Ciascuna di queste rappresenta una sfida a livello di programma, non un problema a livello di patch.
La scelta del software di gestione delle patch più adeguato rappresenta spesso il primo passo per colmare sistematicamente tali lacune, fornendo ai team la visibilità, l’automazione e la reportistica di cui hanno bisogno per operare su larga scala.
Per le organizzazioni che gestiscono grandi infrastrutture distribuite di endpoint , le sfide a livello di programma spesso superano di gran lunga la complessità tecnica di qualsiasi singola patch.
La visibilità in tempo reale, l’implementazione verificata, politiche chiare in materia di patch e flussi di lavoro automatizzati per la gestione delle patch diventano necessità operative piuttosto che semplici elementi auspicabili, soprattutto quando l’alternativa consiste nel monitorare manualmente lo stato delle patch su migliaia di endpoint.
In che modo “ Tanium ” supporta la gestione delle patch software per le aziende
Le sfide sopra descritte, tra cui la visibilità non aggiornata, gli errori di distribuzione e le correzioni non verificate, sono problemi a livello di programma che le singole patch non sono in grado di risolvere.
Tanium 'La piattaforma IT autonoma affronta tali problemi alla radice: interroga direttamente gli endpoint per verificare lo stato delle patch in tempo reale, ordina le distribuzioni in base al rischio effettivo utilizzando i punteggi di affidabilità dell’ e i dati sulle vulnerabilità, e verifica l’effettivo completamento dell’installazione anziché affidarsi esclusivamente ai registri di distribuzione.
Per le organizzazioni che gestiscono ampi parchi software distribuiti ( endpoint ), tale combinazione è stata concepita per contribuire a colmare il divario tra il rilascio delle patch e la correzione verificata in tempi più rapidi rispetto a quanto consentito in genere dagli approcci basati sulla scansione, senza richiedere un’infrastruttura secondaria.
La visibilità in tempo reale come fondamento
Il motivo più comune per cui i programmi di correzione falliscono su larga scala non è la mancanza di impegno. Si tratta di una mancanza di dati precisi e aggiornati. Tanium'La piattaforma IT autonoma di [azienda] affronta direttamente questa problematica fornendo visibilità in tempo reale su endpoint lo stato delle patch su tutti i dispositivi Windows, Linux e macOS.
Anziché fare affidamento su dati di scansione che potrebbero risalire a ore o giorni prima, le organizzazioni che utilizzano l’ Tanium possono interrogare direttamente gli endpoint per comprenderne lo stato attuale. Quando viene rilasciata una patch critica, i team IT possono identificare rapidamente quali endpoint potrebbero essere interessati, quali sembrano già aggiornati e quali potrebbero richiedere un rinvio, senza dover attendere il completamento di un ciclo di scansione programmato.
Tanium'La piattaforma IT autonoma è progettata per garantire la visibilità su ambienti distribuiti, compresi gli endpoint presenti nelle filiali, nelle sedi remote e nei siti geograficamente dispersi, il tutto da un’unica istanza di Tanium , concepita per ridurre la dipendenza da server secondari di inoltro, database o distribuzione.
L'architettura della piattaforma è progettata per supportare ambienti su larga scala, comprese le implementazioni con centinaia di migliaia di endpoint. Questa scala è importante perché le lacune nelle patch sono raramente uniformi: i punti finali più difficili da raggiungere sono spesso quelli che con maggiore probabilità rimangono privi di patch.
Riskdefinizione delle priorità in base a [criteri] prima della distribuzione
Non tutte le patch software richiedono lo stesso grado di urgenza. Effettuare l’implementazione senza stabilire delle priorità significa che i Suoi team potrebbero dedicare lo stesso tempo sia agli aggiornamenti delle applicazioni a basso rischio sia alla risoluzione delle vulnerabilità attive.
Tanium'La piattaforma IT autonoma consente alle organizzazioni di combinare i dati relativi alle vulnerabilità con i punteggi di criticità e affidabilità forniti d endpoint , al fine di stabilire le priorità nell’applicazione delle patch e concentrarsi innanzitutto sulle lacune ad alto rischio.
I punteggi di affidabilità vengono generati tramite un’analisi in tempo reale delle tendenze effettuata dall’intelligenza artificiale nel cloud, che tiene conto, tra l’altro, dei tassi di successo delle installazioni, della frequenza dei crash e dell’impatto sulle prestazioni, fornendo ai team dati utilizzabili per prendere decisioni informate in merito alla sequenza di applicazione prima che una patch venga distribuita su larga scala.
La piattaforma consente inoltre ai team di avvalersi dei segnali di rischio e del contesto aziendale per dare priorità alle patch che riducono per prime l’esposizione maggiore. Questo approccio integra la gestione delle patch direttamente nel più ampio flusso di lavoro di gestione delle vulnerabilità , anziché considerarla come un’attività isolata delle operazioni IT.
I team possono individuare le vulnerabilità risolvibili tramite patch e le patch non programmate più importanti, il che contribuisce a ottimizzare la comunicazione tra i team addetti alla sicurezza e quelli operativi e garantisce che le patch vengano classificate in ordine di priorità e applicate in modo efficace.
Implementazione controllata tramite distribuzioni a anello
Una delle funzionalità di maggiore rilevanza operativa della piattaforma IT autonoma di Tanium'è il supporto all’implementazione progressiva, basata su anelli. Anziché distribuire una patch a tutti gli endpoint contemporaneamente, le organizzazioni possono iniziare con un piccolo gruppo di endpoint, verificare i risultati e avvalersi delle informazioni fornite dall’ Community e dei clienti di Tanium per estendere con sicurezza l’implementazione man mano che ciascuna fase soddisfa i criteri di successo.
Questo approccio è particolarmente rilevante nel caso delle vulnerabilità zero-day di tipo “ ”, in cui la rapidità è fondamentale, ma è anche elevato il rischio che una patch problematica provochi gravi disagi su larga scala.
Patch Le implementazioni possono essere sottoposte a flussi di lavoro di approvazione e inserite in finestre di manutenzione al fine di ridurre al minimo l’impatto sulle attività aziendali. I team possono configurare la pianificazione delle patch e i flussi di lavoro in modo da adattarli alle modalità operative già in uso nella propria organizzazione, stabilendo quali endpoint ricevano le patch e in quale ordine, nonché a quali condizioni una distribuzione passi alla fase successiva.
I playbook di automazione , realizzati con Tanium Automate, consentono di gestire in tempo reale i flussi di lavoro relativi alle patch software in grandi parchi endpoint , gestendo le fasi di rilevamento, sequenziamento della distribuzione e verifica come un unico processo ripetibile, anziché come una serie di passaggi manuali tra diversi strumenti.
Convalida e bonifica a circuito chiuso
L'implementazione non equivale alla correzione. Tanium'La piattaforma IT autonoma monitora in tempo reale l’esito delle patch, le eccezioni e gli indicatori di prestazione, fornendo report dettagliati a supporto di futuri miglioramenti dei processi in termini di selezione degli obiettivi, tempistiche e sequenze.
A seguito di una distribuzione, le organizzazioni possono verificare lo stato delle patch e individuare i sistemi che non sono stati aggiornati, distinguendo tra gli endpoint in cui la patch è stata consegnata ma non installata e quelli che erano semplicemente irraggiungibili durante la finestra di distribuzione.
Tanium Comply amplia tale approccio valutando se le vulnerabilità del software siano state effettivamente risolte dopo l’applicazione di una patch, e non solo se l’implementazione sia stata completata. I team possono passare direttamente dall’individuazione di una vulnerabilità software non corretta all’avvio e al monitoraggio delle misure correttive all’interno della stessa piattaforma, senza dover cambiare strumento né riconciliare i dati provenienti da sistemi distinti.
Questo ciclo che va dall’identificazione alla correzione fino alla convalida implica che la gestione delle patch non si esaurisca con la distribuzione, bensì si concluda solo quando la vulnerabilità viene convalidata come corretta.
Rendicontazione in materia di conformità e preparazione alle verifiche di audit
Dimostrare che le patch software siano state applicate, e applicate correttamente, sta assumendo un’importanza sempre maggiore nell’ambito dei programmi di audit normativi , compresi quelli legati a quadri normativi quali l’HIPAA e l’ PCI. Tanium è stato progettato per soddisfare tali esigenze di documentazione.
Tanium Patch riassume lo stato di distribuzione di qualsiasi patch software, fornendo un riscontro immediato sui casi di successo e di errore che richiedono un intervento correttivo. Quando i revisori chiedono quali patch software siano state applicate e in quale momento, “ Tanium ” fornisce ai team la cronologia delle implementazioni, lo stato dei riavvii e la conferma delle azioni correttive necessarie per rispondere a tale domanda sulla base di dati concreti anziché di stime.
Da una lacuna nella conformità a una copertura delle patch del 90%: Honeywell
, società del gruppo Honeywell, si è trovata ad affrontare bassi tassi di conformità alle patch, il che esponeva l’organizzazione al rischio di attacchi ransomware e altri attacchi informatici. Dopo aver implementato Tanium , Honeywell ha superato il 90 % di conformità alle patch per tre mesi consecutivi, un livello di servizio che l’azienda non era riuscita a raggiungere in precedenza.
Tanium ha inoltre consentito a Honeywell di consolidare e, in alcuni casi, eliminare altri strumenti di applicazione delle patch, fornendo al contempo un’unica interfaccia per la rendicontazione sulla conformità a livello dirigenziale e operativo.
[Legga il caso di studio su Honeywell]
«Prima di utilizzare Tanium, il nostro livello di conformità alle patch era basso. Ora, grazie a “ Tanium”, abbiamo superato la soglia del 90% di conformità alle patch per tre mesi consecutivi. Questo è un dato significativo.”Manish Chopra, direttore IT di Honeywell
Il funzionamento di una patch software è semplice. La realtà operativa legata alla sua implementazione su migliaia di endpoint è ben diversa. Di seguito sono riportate le risposte alle domande che ci vengono poste più spesso.
Domande frequenti sulle patch software
Qual è la differenza tra una patch e un aggiornamento?
Una patch è una correzione mirata a risolvere un problema specifico, in genere un bug o una vulnerabilità di sicurezza nel software. Il termine "aggiornamento" è un concetto più ampio che può comprendere correzioni, aggiunte di funzionalità, miglioramenti delle prestazioni e altre modifiche. Tutte le patch sono aggiornamenti, ma non tutti gli aggiornamenti sono patch.
Con quale rapidità agiscono gli autori degli attacchi dopo il rilascio di una patch software?
Più rapidamente di quanto la maggior parte delle organizzazioni riesca a implementare. Quando un fornitore rilascia una patch software, la patch stessa può rivelare dettagli sulla vulnerabilità sottostante, fornendo agli autori degli attacchi una guida per sfruttare i sistemi non aggiornati. Nel caso di vulnerabilità software di grande rilevanza, il codice di exploit può comparire nel giro di poche ore dal rilascio della patch.
La vulnerabilità 2021 Log4j , un difetto presente in una libreria di registrazione Java ampiamente utilizzata, ha registrato oltre 200.000 tentativi di attacco nelle 24 ore successive alla sua divulgazione, secondo quanto riportato da Check Point Research. Ecco perché il lasso di tempo che intercorre tra il rilascio di una patch software e la sua installazione verificata rappresenta un rischio quantificabile, e non solo un inconveniente operativo.
È possibile annullare l’applicazione di una patch software qualora si verifichino dei problemi?
Dipende da come è stata impacchettata la patch. La maggior parte delle patch software autonome può essere disinstallata tramite l'applicazione stessa o i vostri strumenti di gestione delle patch, ripristinando così la versione precedente. Gli aggiornamenti cumulativi sono più difficili da annullare in modo pulito, poiché annullare una modifica comporta l’annullamento di diverse altre.
Prima di distribuire su larga scala qualsiasi patch software, la si testino su un campione rappresentativo di endpoint e si verifichi di disporre di una procedura di rollback nel caso in cui la patch causi problemi di compatibilità o un comportamento imprevisto delle applicazioni.
Perché alcune patch software richiedono un riavvio?
Le patch software che modificano i file delle applicazioni o le librerie condivise attualmente in uso non possono completare l'installazione finché tali file sono attivi. Un riavvio del sistema, o in alcuni casi un riavvio dell'applicazione, libera tali blocchi e consente ai file aggiornati di diventare operativi. La necessità di un riavvio dipende da ciò che la patch software modifica e dalla possibilità di riavviare in sicurezza l'applicazione interessata senza dover effettuare un riavvio completo del sistema.
Cosa accade se un’ endpoint e non esegue l’installazione di una patch software?
L’ endpoint e rimane esposto alla vulnerabilità del software che la patch avrebbe dovuto risolvere. Un’implementazione mancata non rappresenta una lacuna di poco conto. Ciò significa che il difetto di codice sottostante è ancora presente e può essere sfruttato. Per individuare gli endpoint non raggiunti è necessario interrogare direttamente tali endpoint in merito alle versioni attuali del software e allo stato delle patch, senza fare affidamento sui registri di distribuzione che confermano solo che la patch è stata inviata, ma non che sia stata installata correttamente.
Molte soluzioni moderne di gestione delle patch sono progettate per monitorare le distribuzioni non andate a buon fine, riprovare automaticamente e individuare le lacune, in modo che un numero minore di endpoint rimanga senza patch per periodi prolungati.
Una gestione efficace delle patch software inizia con la comprensione di ciò che si sta implementando e del motivo per cui lo si fa, fino ad arrivare alle modifiche specifiche apportate dal codice da una patch e a ciò che accade qualora questa non venisse installata correttamente. A questo punto, si tratta di chiudere la finestra di esposizione il più rapidamente e completamente possibile, per poi verificare che l’operazione sia effettivamente andata a buon fine.
Tanium offre visibilità in tempo reale sullo stato delle patch software in tutti gli ambienti distribuiti endpoint , consentendo ai team di identificare le lacune, effettuare le distribuzioni in tutta sicurezza e confermare l’applicazione delle correzioni anziché darla per scontata. Prenoti una demo all'indirizzo per scoprire come funziona su scala aziendale.