Installare le patch: meglio un batch?

19 Giugno 2006

“Suggerite di testare e installare tutte le patch così come sono rilasciate, oppure sarebbe meglio dare delle priorità e salvare le patch funzionali per un batch o un processo successivo?” L’obiettivo del patch testing è di assicurare un’implementazion …

“Suggerite di testare e installare tutte le patch così come sono rilasciate, oppure sarebbe meglio dare delle priorità e salvare le patch funzionali per un batch o un processo successivo?”

L’obiettivo del patch testing è di assicurare un’implementazione efficace a livello aziendale quando una patch (o più di una) viene adottata all’interno della vostra organizzazione. Tuttavia, questo processo può richiedere parecchio tempo e quindi effettuare il test globale di un ampio numero di pach, come per esempio quelle rilasciate da Microsoft, può comportare costi proibitivi.

Poiché non tutte le patch hanno il medesimo grado di criticità, dovete attribuire delle priorità e programmare gli aggiornamenti, favorendo quelli più urgenti. Suggerisco di dare la priorità alle patch suddividendole in due categorie: da una parte quelle inerenti la sicurezza dall’altra tutte le altre. Per esempio, la dofesa dai worm di Internet è molto più importante che non un aggiornamento funzionale di Microsoft. Outlook. Prima che sia rilasciato un exploit, potreste avere soltanto alcuni giorni per esaminare una patch relativa alla sicurezza al fine di decidere se utilizzarla o meno. Quindi finché avete tempo disponibile, aspettate a provare e installare altre patch.

Prima di installare qualsiasi patch, è importante che identifichiate i problemi di sicurezza e gli aggiornamenti del software cruciali per il vostro ambiente e stabiliate se il rischio legato alla mancata installazione della patch riesca a compensare l’onere del costo dell’installazione stessa. Quali amministratori della rete, dovreste avere un resoconto dettagliato del sistema che pone tutte le macchine su livelli differenti in termini di priorità. Questo vi permette di stabilire una strategia che privilegia l’aggiornamento dei computer con il maggior livello di criticità.

Lo sviluppo di un profilo per ogni applicazione business in uso presso la vostra organizzazione vi aiuterà a valutare l’importanza del sistema, i downtime che possono essere sfruttati utilmente e il livelli di rischio di vulnerabilità. Per esempio, un’azienda può sopravvivere se alcuni pc si bloccano, ma non si può dire altrettanto di uno stop del server principale: in altre parole, gli aggiornamenti del server sono più critici delle pacth di un desktop. Il livello di criticità attribuito dal vendor è un altro elemento chiave su cui basarsi per calcolare l’importanza di una patch, lo stesso si può dire per un exploit conosciuto che può utilizzare una vulnerabilità che è stata modificata tramite patch come vettore per un attacco.

Prima di impiegare qualsiasi patch, è bene testarla in un ambiente non produttivo. Questo permette di scoprire tutti i problemi potenziali o i conflitti che potrebbero sorgere con le configurazioni attuali, specifiche dei sistemi in cui le patch saranno installate. Il raggio d’azione del vostro test sarà direttamente proporzionale alla criticità dei vostri sistemi e dei vostri dati. Tuttavia, è importante provare la patch su quanti più sistemi possibile. Mi esprimerei contro il batch testing perché, se il test fornisce un risultato insoddisfacente, dovete identificare le cause del problema prima di continuare, il che è piuttosto difficile se avete installato diverse pach in una sola volta. I rollout di produzione possono essere considerati una parte aggiuntiva del processo di valutazione se effettuati per gradi. Il rollout iniziale deve essere attuato sui sistemi meno critici e, se le performance sono come avete previsto, potete continuare con il rollout fino a che tutti i sistemi non siano aggiornati. Tuttavia, poteste dover modificare questa modalità operativa quando il rischio di attacco è più rilevante del rischio di downtime del sistema.

Una nota finale: la policy di sicurezza che adottate dovrebbe definire la posizione della vostra organizzazione nei confronti dei livelli di priorità delle patch, dei test e delle implementazioni nelle predette circostanze.