Punti Chiave
- Quando una patch non va a buon fine, contatta il fornitore o il provider di terze parti. Consulta risorse della community come PatchManagement.org o forum pertinenti per individuare problemi noti.
- Testa ogni patch su un gruppo pilota rappresentativo di endpoint per rilevare conflitti specifici dell’ambiente prima della distribuzione completa.
- Mantieni procedure documentate e guide di riferimento, incluse risorse sulla gestione delle patch basata sul rischio e sul Patch Tuesday, per affrontare gli errori e prevenire interruzioni a valle.
È arrivato il momento: bisogna applicare le patch agli endpoint. Forse è un’attività che ti piace, ma probabilmente non è così. L’applicazione delle patch può essere un compito impegnativo e, poiché molte organizzazioni la gestiscono ancora manualmente, richiede più tempo e risorse di quanto chiunque vorrebbe davvero considerare.
Ora, dato che investirai tutto quel tempo e quelle risorse nell’applicazione delle patch, vuoi assicurarti che tutto proceda senza intoppi. Nessuno vuole dedicare così tante energie alla gestione delle patch per poi ritrovarsi in un groviglio di confusione ed errori.
Assicuriamoci quindi di non incorrere in questi due problemi più comuni nell’applicazione mensile delle patch:
- Le tue patch funzionano?
- Hai testato le patch nel tuo ambiente?
Problema di patch n. 1: le tue patch funzionano?
Non è raro che le patch e gli aggiornamenti di sicurezza semplicemente non vadano a buon fine. A volte dipende da un problema specifico dell’ambiente. Altre volte, è la patch stessa a non essere valida.
Meno male che hai deciso di controllare quella patch prima di distribuirla alla cieca, vero? Ma ora che non funziona, cosa puoi fare? Dipende.
Soluzione 1: contatta il tuo fornitore di gestione delle patch di terze parti
Se utilizzi un fornitore di patching di terze parti per gestire gli aggiornamenti delle patch, sarà il primo interlocutore da contattare.
Sebbene le aziende che gestiscono il patching di terze parti testino accuratamente i contenuti che distribuiscono ai clienti, non possono verificare ogni scenario d’uso. Potresti avere una configurazione particolare, oppure il tuo endpoint potrebbe gestire la patch in modo diverso da quanto previsto dal fornitore di patch di terze parti.
Qualunque sia il motivo, il tuo fornitore dovrebbe sempre essere il primo punto di riferimento. Segnalare l’errore è importante non solo per poterlo correggere, ma anche perché è utile al fornitore di patching di terze parti.
Potresti aver individuato un problema sistemico. A quel punto diventi la persona che ha avvisato l’azienda di un problema più ampio, consentendole di intervenire rapidamente per risolverlo.
Forse non è sistemico, ma è comunque un problema abbastanza comune da aiutare l’azienda a prepararsi meglio alle future chiamate di altri clienti. Inoltre, hai fornito un potenziale nuovo scenario d’uso da aggiungere ai protocolli di test predefiniti.
Soluzione 2: consulta la community online più ampia per individuare possibili problemi delle patch
Ma se non utilizzi un fornitore di patching di terze parti? Supponiamo che la tua organizzazione esamini manualmente queste patch.
Esistono ottime risorse online per verificare se anche altre organizzazioni stanno riscontrando gli stessi problemi, tra cui:
- PatchManagement.org, “la prima mailing list del settore dedicata alla discussione sulla gestione delle patch”.
- Diverse community su Reddit e Mastodon, come r/sysadmin, infosec.exchange o qualsiasi community specifica di un fornitore.
- Le risorse Patch Tuesday di Ivanti, pensate per discutere quali patch vengono rilasciate e cosa ci si può aspettare da esse.
Indipendentemente dal percorso che decidi di seguire, hai a disposizione molte opzioni per capire cosa sia andato storto con la patch non riuscita.
Problema di patch n. 2: hai testato le patch nel tuo ambiente?
Bene, hai deciso di testare ogni patch in arrivo: ottimo! Sei al sicuro, giusto?
Non proprio.
Non devi inoltre dimenticare di testare le patch che distribuirai su dispositivi pilota provenienti da tutta l’organizzazione.
Perché? In fondo è solo un semplice aggiornamento di Chrome. Ma è davvero così?
Introdurre una nuova patch nei sistemi non è diverso dall’accogliere un nuovo animale domestico in casa. Anche se ne hai già avuto uno e sei convinto di sapere come prendertene cura, ognuno avrà reazioni proprie a stanze o persone, diverse da quelle dell’animale precedente.
Allo stesso modo, ogni patch presenta sfumature specifiche in termini di modifiche e aggiornamenti. Queste possono spesso entrare in conflitto con ciò per cui i tuoi sistemi o programmi sono stati progettati, compromettendo l’ambiente o l’efficacia della patch, anche se la patch ha superato i test iniziali.
Dopotutto, le aziende software non applicano patch ai prodotti pensando ai tuoi sistemi. Si concentrano sull’aggiornamento e sull’applicazione di patch alle proprie applicazioni, e non possono considerare tutti gli scenari d’uso.
Risolvere l’effetto domino dei problemi delle patch
Disporre di un gruppo pilota dedicato di endpoint su cui testare questi aggiornamenti può aiutarti a evitare di compromettere sistemi, programmi o persino processi da cui dipende la tua azienda. L’effetto domino di un piccolo aggiornamento di patch può essere dannoso per le attività aziendali.
Ad esempio, all’inizio di aprile, Chrome ha distribuito una patch per risolvere alcuni bug. Ma ha anche introdotto nuovi bug, uno dei quali ha interessato la capacità di stampa da Chrome.
E se la tua organizzazione operasse in un ambiente in cui si stampa molto e la possibilità di stampare tramite Chrome fosse indispensabile per le tue attività?
In questo modo, testare tutte le patch, anche quelle piccole e apparentemente insignificanti, può aiutarti a evitare conseguenze gravi.
Ricorda: quando qualcosa va storto, gli errori si propagano oltre il reparto o l’utente inizialmente interessato. La maggior parte degli utenti e delle organizzazioni non considera gli impatti a valle che una piccola patch può generare se non viene testata a fondo. Dopotutto, spesso è l’IT a dover rimediare agli effetti di un errore o di un’interruzione.
Quindi, quando arriva il momento di applicare le patch, vogliamo creare le condizioni per il successo. Per farlo, individuiamo una varietà adeguata di endpoint su cui testare le patch, così da assicurarci di non generare un impatto a valle evitabile, e ci prepariamo anche con le risorse della community nel caso in cui le patch non vadano a buon fine.
Puoi anche consultare:
- La guida definitiva alla gestione delle patch basata sul rischio per maggiori informazioni sulla creazione di gruppi pilota, sulla gestione prioritaria delle patch e su altri principi fondamentali del patching.
- Il podcast Security Insights, che tratta l’importanza della visibilità degli asset prima di distribuire semplicemente una nuova patch.
- La serie Patch Tuesday, che raccoglie tutte le nostre precedenti raccomandazioni e avvertenze sul patching. Non perdere il prossimo appuntamento, che si tiene ogni mese il mercoledì immediatamente successivo al Patch Tuesday.
A volte, la migliore strategia di gestione delle patch è semplicemente una buona preparazione. Buona fortuna.