[ad_1]
La gestione delle patch è come dipingere o fare giardinaggio: a prima vista può sembrare un lavoro semplice e di routine. Ma in pratica, può rivelarsi molto più impegnativo di quanto sembri. Proprio come la mancanza di lavoro di preparazione può significare un disastro per un lavoro di verniciatura, o dimenticare di innaffiare e diserbare regolarmente può trasformare il tuo giardino in un pugno nell’occhio, gli errori di patching del software possono ostacolare gravemente la tua capacità di svolgere quello che dovrebbe essere il semplice compito di mantenere attive le app. -ad oggi.
Continua a leggere per dare un’occhiata alle sviste di gestione delle patch più comuni che ho riscontrato nella mia carriera di direttore IT, insieme ai suggerimenti su come le organizzazioni possono evitarle.
-
Non avere una strategia di patching
Probabilmente l’errore più comune nell’applicazione delle patch al software è la mancanza di una strategia di applicazione coerente.
La mancanza di strategia non significa che le patch non avvengano affatto. Ciò significa che l’applicazione delle patch avviene in modo ad hoc, senza linee guida chiare su quando, come e quanto spesso un’organizzazione applicherà le patch.
Per evitare questo errore, sviluppa un insieme chiaro di controlli e policy sull’applicazione delle patch che definiscano il modo in cui il tuo team affronterà l’applicazione delle patch. La tua strategia dovrebbe riflettere le tue capacità e i tuoi limiti; ad esempio, i reparti IT più piccoli potrebbero non essere in grado di applicare ogni patch con la stessa rapidità con cui vengono visualizzate, quindi le loro strategie dovrebbero identificare a quali tipi di app o patch dare la priorità.
Anche se la strategia di applicazione delle patch non include tutte le pratiche che sarebbe prevista se si disponessero di risorse illimitate, è sufficiente sviluppare un piano che tutte le parti interessate (leader IT, professionisti e dirigenti aziendali) possano supportare e gettare le basi per un’applicazione efficace delle patch.
-
Non sfruttare l’automazione delle patch
Esistono molti modi per automatizzare l’applicazione delle patch al software. È possibile utilizzare un semplice software di monitoraggio e gestione remota (RMM) per distribuire patch ai sistemi remoti. Potresti fare affidamento sui servizi di patch integrati nel sistema operativo, come Windows Server Update Services, se sono disponibili e coprono il software che devi gestire. Oppure potresti adottare uno strumento creato appositamente per l’applicazione delle patch, che di solito è il modo migliore per ottenere la copertura più ampia e il massimo grado di automazione.
Ma qualunque sia il tipo di strumento di automazione delle patch che scegli, il tuo obiettivo dovrebbe essere quello di assicurarti di avere almeno alcune automazioni in atto. Il moderno software di automazione delle patch è così affidabile e così economico che semplicemente non ci sono scuse per una routine di patching prevalentemente manuale.
-
Avere troppa paura dei brutti momenti
Esiste sempre il rischio che una patch possa causare più problemi di quanti ne risolva. È importante bilanciare questo rischio testando le patch in anticipo, per quanto possibile, oltre ad adottare un approccio strategico riguardo al momento in cui applicare le patch. Ad esempio, potresti non voler applicare una patch a un sistema mission-critical nel bel mezzo di una giornata lavorativa.
Detto questo, è altrettanto fondamentale evitare una postura di applicazione delle patch in cui si è così preoccupati per i rischi di una patch difettosa da non riuscire ad applicare le patch entro un periodo di tempo ragionevole. Se lasci i problemi principali senza patch per troppo tempo, potresti riscontrare gravi problemi di sicurezza o prestazioni.
Su questo fronte è importante tenere conto del contesto valutando quanto sia importante una determinata patch. Potrebbe essere fattibile eseguire test più approfonditi su una patch che risolve un bug con priorità più bassa, mentre una patch per una grave vulnerabilità della sicurezza zero-day è in genere quella che vorresti installare il più rapidamente possibile, anche se ciò significa eseguire test minimi patch test in anticipo.
-
Affidarsi agli utenti per installare le patch
Un errore comune nell’applicazione delle patch che ho riscontrato tra le organizzazioni più piccole è quello di esternalizzare la responsabilità della gestione delle patch agli utenti finali. Ad esempio, i reparti IT che non dispongono del personale per gestire le patch in modo proattivo potrebbero dire ai dipendenti che è loro responsabilità assicurarsi di installare le patch ogni volta che un’app glielo richiede.
I rischi di questa pratica sono abbastanza evidenti: molti utenti in realtà non installano le patch di routine, perché non sanno come fare o perché temono che le patch possano interrompere i loro flussi di lavoro.
Oltre a ciò, c’è il problema che l’installazione delle patch spesso richiede che gli utenti dispongano dei diritti di amministratore, quindi se attribuisci la responsabilità dell’applicazione delle patch ai tuoi utenti, devi concedere loro l’accesso di amministratore alle loro macchine. Questo di per sé rappresenta un rischio importante perché fornire agli utenti autorizzazioni di amministratore aumenta il rischio che gli aggressori che compromettono i loro account assumano il pieno controllo dei loro sistemi.
Un approccio migliore consiste nell’automatizzare l’applicazione delle patch utilizzando strumenti in grado di distribuire le patch sui computer dei dipendenti per loro conto, senza richiedere che i dipendenti abbiano diritti di amministratore. In questo modo, puoi applicare patch su larga scala anche se disponi di risorse IT limitate e non devi accettare il rischio degli utenti con account amministratore.
-
Mancanza di monitoraggio e audit delle patch
Il successo dell’installazione di una patch non significa che il personale IT possa andare avanti e non pensare mai più alla patch. Al contrario, è fondamentale monitorare e controllare i sistemi dopo l’installazione delle patch in modo da poter rilevare eventuali problemi di prestazione o di sicurezza che potrebbero emergere a causa di una patch.
Anche se hai testato attentamente la patch in anticipo, c’è sempre il rischio che la patch possa avere conseguenze indesiderate. Il monitoraggio e il controllo delle patch consentono ai team di anticipare questi problemi prima che gli utenti si riversino all’help desk o interrompano le operazioni aziendali.
-
Ignorare le patch di alcuni fornitori
Alcuni fornitori di software dispongono di ampie risorse e rilasciano patch regolarmente. Altri sono molto più piccoli e possono produrre macchie solo in modo irregolare.
Per i dipartimenti IT può essere forte la tentazione di ignorare quest’ultimo tipo di patch. Dopo tutto, se il vostro fornitore non rilascia patch frequentemente, installarle potrebbe non sembrare molto importante.
La realtà, però, è che spesso è estremamente importante installare patch da fornitori con risorse limitate perché le loro patch tendono ad essere particolarmente critiche. Quando un’azienda più piccola con una storia discontinua di rilasci di patch introduce una nuova patch, è necessario prestare attenzione e dare priorità alla patch.
Potresti anche voler fare un passo indietro e valutare se continuare a lavorare con un fornitore che non rilascia patch spesso o regolarmente. Ma nel breve termine, assicurati di chiudere eventuali vulnerabilità quando compaiono nuove patch, indipendentemente da chi sia il fornitore.
Conclusione: l’applicazione delle patch come base per la sicurezza moderna
Le conseguenze di una mancata applicazione efficace delle patch possono essere gravi. Non solo una gestione inefficace delle patch lascia le app a rischio di bug di sicurezza e prestazioni, ma può anche significare che la tua azienda non sarà coperta da un’assicurazione di sicurezza informatica in caso di attacco.
Evita questo rischio sviluppando una strategia di patch che ti consenta di applicare le patch in modo efficiente e scalabile sfruttando l’automazione ove possibile per applicare tutte le patch disponibili a tutti gli endpoint rilevanti entro un intervallo di tempo che rifletta la criticità di ciascuna patch.
[ad_2]
Source link
