Tutela della sicurezzaHo appena ricevuto un bollettino sulla sicurezza. Che cosa devo fare?

Christopher Budd

Il processo di rilascio mensile dei bollettini Microsoft sulla sicurezza, avviato nell'ottobre del 2003, è stato adottato in risposta alle esigenze dei clienti. Fra le esigenze più importanti vi era la prevedibilità delle date di rilascio dei bollettini sulla sicurezza. Microsoft ha saputo utilizzare prevedibilità e sistematicità per ottimizzare e migliorare i processi interni.

Nel sito Microsoft Security Bulletin Search (in inglese) è possibile trovare l'ultimo bollettino sulla sicurezza pubblicato e cercare bollettini precedenti, come mostrato nella figura 1. Un bollettino di esempio, in questo caso quello di agosto 2006, è illustrato nella figura 2.

Figura 1.** Microsoft Security Bulletin Search **(Fare clic sull'immagine per ingrandirla)

I bollettini mensili sulla sicurezza Microsoft hanno consentito a molti clienti di adottare processi più razionali per la distribuzione degli aggiornamenti per la protezione Microsoft. Poiché i bollettini sulla sicurezza vengono pubblicati in una data fissa, i clienti hanno approfittato di questa certezza per definire processi regolari con cui gestirli. Hanno saputo creare tempi e passaggi nei processi di valutazione e distribuzione degli aggiornamenti per la protezione che tengono conto della regolarità del rilascio mensile dei bollettini Microsoft sulla sicurezza. I clienti utilizzano questi processi per analizzare, testare e distribuire gli aggiornamenti con una sistematicità che aumenta le condizioni generali di sicurezza e riduce i tempi di inattività.

Figura 2.** Bollettino sulla sicurezza dell'agosto 2006 **(Fare clic sull'immagine per ingrandirla)

Alcuni clienti, tuttavia, eseguono la valutazione e la distribuzione degli aggiornamenti per la protezione senza attenersi a una procedura ben definita. Pur essendo possibile implementare senza problemi gli aggiornamenti in modo asistematico, questo approccio contrasta con le procedure consigliate per la gestione degli aggiornamenti per la protezione.

Microsoft ha fornito informazioni utili sui metodi e le date di pubblicazione dei bollettini, ma non ha dato molte indicazioni su come è possibile utilizzarli e integrarli nei processi aziendali. Alcuni clienti potrebbero non essere a conoscenza dei processi di cui potrebbero beneficiare né del modo migliore per metterli in pratica.

Per questo motivo, in questo articolo verranno descritti i processi e le operazioni utili per la valutazione e la distribuzione degli aggiornamenti per la protezione. Qualsiasi organizzazione, indipendentemente dalle dimensioni, potrà adottare questi processi. Le organizzazioni più grandi farebbero meglio, però, a suddividere le operazioni tra gruppi diversi, in base alla loro struttura interna. Nelle organizzazioni più piccole queste operazioni possono essere eseguite da un solo gruppo o addirittura da una sola persona. A prescindere da chi se ne occupa, tutte queste operazioni devono essere chiaramente incluse nei processi di valutazione e distribuzione degli aggiornamenti. Nella figura 3 è fornita una visione d'insieme di questo processo.

Figura 3.** Processo di valutazione e distribuzione dei bollettini sulla sicurezza **

1. Ricezione di notifiche avanzate

Quando si utilizzano i bollettini mensili sulla sicurezza, la prima cosa da fare è assicurarsi di ricevere una notifica degli aggiornamenti per la protezione imminenti. Microsoft pubblica queste informazioni sul suo sito Web alle 10.00 circa (fuso orario del Pacifico, ossia alle 19.00 ora italiana) tre giorni feriali prima del rilascio mensile, previsto per il secondo martedì del mese. Le informazioni di notifica avanzata vengono pubblicate quindi il giovedì precedente.

Lo scopo della notifica avanzata è fornire informazioni che consentano di pianificare la distribuzione degli aggiornamenti prima del rilascio dei bollettini. La scelta del livello di dettaglio risponde a un'esigenza di equilibrio tra informazione e tutela dei clienti fino al giorno del rilascio degli aggiornamenti: non si divulgano quindi informazioni che potrebbero agevolare eventuali attacchi. La notifica avanzata raccoglie le informazioni sugli aggiornamenti per la protezione imminenti in base al nome del prodotto, senza fornire informazioni sulle versioni specifiche (ad esempio, Microsoft® Windows® o Microsoft Office). Ciascuna voce indica quanti bollettini verranno pubblicati per quel prodotto e il relativo livello di gravità massimo, quali richiederanno il riavvio del sistema e quali saranno gli strumenti di rilevamento Microsoft utilizzabili.

Per eliminare o ridurre al minimo il rischio di eventuali sorprese ed equivoci, la notifica avanzata fornisce anche informazioni su altri aggiornamenti non associati ai bollettini sulla sicurezza che verranno pubblicati lo stesso giorno. Nello specifico, indica quanti aggiornamenti non relativi alla protezione con priorità alta saranno scaricabili da Microsoft Update (MU) e Windows Update (WU) e se verrà rilasciato un aggiornamento dello Strumento di rimozione malware per Microsoft Windows.

Fornisce anche informazioni su eventuali problemi che potrebbero provocare ritardi nella distribuzione, come è avvenuto per la modifica delle autorizzazioni "Invia come" in MS06-019.

Ogni mese viene pubblicata una nuova notifica avanzata, che viene inviata anche tramite SNSCE (Security Notification Service Comprehensive Edition). È possibile iscriversi al servizio SNSCE.

2. Valutazione dell'impatto potenziale

Dopo aver ricevuto la notifica avanzata, la prima cosa da fare è valutare la rilevanza dei futuri bollettini nel proprio ambiente. Anche se la notifica avanzata contiene informazioni limitate sui prodotti interessati, queste dovrebbero essere sufficienti per capire se i bollettini interessano il proprio ambiente.

Si supponga, ad esempio, che la notifica avanzata segnali due bollettini sulla sicurezza riguardanti Microsoft Exchange, con un livello di gravità massimo (critico) e che richiedono il riavvio del sistema. Se non si esegue questo programma, è ovvio che i bollettini non interesseranno il proprio ambiente. Se si esegue invece Exchange Server 2003, si saprà che il martedì successivo si riceveranno due bollettini di importanza critica che richiederanno il riavvio del sistema.

Ai fini della pianificazione, si pensi alla notifica avanzata come a uno strumento per determinare il massimo impatto possibile sull'organizzazione (in termini di numero di bollettini e gravità) e l'impatto in fase di distribuzione (tenendo conto dei riavvii necessari). Dopo aver valutato la rilevanza e il massimo impatto possibile degli aggiornamenti, si può realizzare un programma che includa quanto segue:

• Personale addetto a valutazione dei rischi, testing e distribuzione
• Piani di testing e tempo impiegato nel laboratorio di prova
• Piani di distribuzione e riavvii programmati (se necessari)

Il programma realizzato in questa fase deve essere provvisorio perché le informazioni contenute nella notifica avanzata sono soggette a modifiche. Inoltre, data la natura limitata di queste informazioni, è possibile apportare cambiamenti una volta ricevuti tutti i dettagli.

Infine, nel caso in cui si ricevano informazioni aggiuntive, riguardanti ad esempio modifiche di funzionalità, è necessario impiegare il tempo che intercorre tra la notifica avanzata e il rilascio dei bollettini per condurre ricerche sul problema e valutarne il possibile impatto sull'ambiente. In questi casi, potrebbe essere necessario rivedere il programma provvisorio in base ai risultati delle ricerche.

3. Ricezione dei nuovi bollettini Microsoft sulla sicurezza

Microsoft pubblica i bollettini sulla sicurezza il secondo martedì del mese. Pur essendo previsto alle 10.00 (fuso orario del Pacifico), il rilascio si inserisce in un processo complesso e interdipendente, quindi potrebbe essere rimandato per diversi motivi. In fase di rilascio, si pubblicano sui siti Microsoft i bollettini sulla sicurezza, gli aggiornamenti per la protezione, gli aggiornamenti degli strumenti di rilevamento e distribuzione, quali Microsoft Baseline Security Analyzer (MBSA) e Windows Server® Update Services (WSUS), e i nuovi strumenti di rilevamento, quali la nuova versione di Enterprise Scan Tool (EST).

La pagina dei bollettini sulla sicurezza Microsoft è abilitata al supporto dei feed RSS. Quando i bollettini contengono degli aggiornamenti, viene aggiornato anche il feed RSS, che aggiorna a sua volta i visualizzatori e gli aggregatori RSS. Inoltre, viene inviata una notifica tramite i servizi SNS (Security Notification Service) e SNSCE. Le notifiche vengono inviate per posta elettronica e con gli avvisi MSN®.

Per ricevere informazioni sulla disponibilità dei nuovi bollettini sulla sicurezza, è consigliabile iscriversi a tutti i meccanismi di notifica offerti. I clienti possono iscriversi al feed RSS e a entrambi i servizi SNS e SNSCE.

4. Valutazione della rilevanza dei bollettini sulla sicurezza

È importante che si assegni a una o più persone specifiche la responsabilità di esaminare i nuovi bollettini sulla sicurezza per valutarne la rilevanza nel proprio ambiente. Nell'ambito di questa valutazione, è opportuno analizzare tutte le informazioni contenute nei bollettini per rivedere e modificare di conseguenza il programma provvisorio. Tornando al nostro esempio, se si è avvisato il team responsabile dell'amministrazione di Exchange del possibile rilascio di un aggiornamento critico, ma poi si scopre che Exchange Server non è esposto ad alcuna vulnerabilità, si può ripianificare l'uso di queste risorse.

Dopo aver stabilito la rilevanza dei bollettini sulla sicurezza nella propria organizzazione, è possibile stabilire per quali processi sono rilevanti.

5. Valutazione dei rischi e dei livelli di gravità dei bollettini

In questa fase si deve eseguire una valutazione dei rischi descritti nei bollettini rilevanti. Nelle organizzazioni con responsabilità suddivise, questa operazione è spesso effettuata dal team responsabile della protezione. Anche se ogni bollettino Microsoft sulla sicurezza ha un livello di gravità massimo, questo indica il livello più alto per tutte le vulnerabilità in tutti i prodotti interessati. Il livello di gravità Microsoft applicabile alla propria organizzazione potrebbe essere diverso dal livello massimo indicato, a seconda della serietà del problema che colpisce le versioni utilizzate nel proprio ambiente. Per ottenere informazioni specifiche sulla vulnerabilità che interessa le proprie versioni, è importante esaminare la tabella completa dei livelli di gravità e degli identificatori della vulnerabilità riportata sotto la sezione Riepilogo del bollettino sulla sicurezza.

È opportuno rivedere poi le altre informazioni tecniche, quali i Fattori attenuanti e le Domande frequenti per ciascuna vulnerabilità, e modificare di conseguenza la valutazione dei rischi in base all'ambiente e alle politiche aziendali. Le politiche aziendali possono anche richiedere che la valutazione tenga conto di fattori non tecnici e ambientali quali l'ambiente a rischio o l'importanza critica di certe applicazioni nell'organizzazione.

Al termine di questo processo, si dovrebbe disporre di una valutazione del rischio per ogni bollettino e per i relativi aggiornamenti. Tornando al nostro esempio, il team responsabile dell'amministrazione di Exchange può concludere che un aggiornamento per la protezione ponga un "rischio moderato" in base alle modifiche apportate al bollettino sulla sicurezza. In questo caso, è necessario rifarsi alle politiche aziendali per aggiornare e modificare adeguatamente il proprio programma. Ad esempio, le politiche aziendali potrebbero richiedere che per gli aggiornamenti per la protezione a rischio moderato si prevedano due o tre giorni di testing rispetto a quelli a basso rischio.

In alcuni casi, potrebbero richiedere che per i bollettini con un certo livello di gravità sia anche necessario considerare l'implementazione di soluzioni alternative. Ad esempio, le politiche aziendali potrebbero stabilire che per tutti gli aggiornamenti per la protezione classificati come critici sia necessario esaminare e implementare il prima possibile soluzioni alternative. In questo caso, si dovrà effettuare un'ulteriore valutazione dei rischi associati alle soluzioni alternative per determinare quali soluzioni implementare e quando.

Al termine di questo processo, si dovrebbe disporre di un elenco degli aggiornamenti da distribuire nel proprio ambiente, con i livelli di gravità associati a ciascuno di essi, e di un elenco delle soluzioni alternative da implementare, che dovrebbe essere utilizzato per modificare il programma di testing e distribuzione. Le modifiche al programma dovrebbero rispettare i tempi specificati dalle politiche aziendali. Ad esempio, una politica aziendale potrebbe richiedere che per tutti gli aggiornamenti per la protezione critici sia necessario implementare soluzioni alternative entro 24 ore e distribuire gli aggiornamenti necessari entro 7 giorni.

6. Determinazione del possibile impatto degli aggiornamenti per la protezione e/o delle soluzioni alternative sull'organizzazione

Determinare l'impatto degli aggiornamenti per la protezione e delle soluzioni alternative sul proprio ambiente è un passaggio fondamentale nel processo di valutazione. Nelle organizzazioni con responsabilità suddivise, questa operazione viene spesso eseguita dal team che gestisce il sistema a cui potranno essere applicati gli aggiornamenti per la protezione e le soluzioni alternative.

Determinare l'impatto potenziale può aiutare il cliente a capire meglio e a circoscrivere il rischio posto dagli stessi aggiornamenti e soluzioni alternative. Tali informazioni si trovano nella sezione "Domande frequenti relative a questo aggiornamento per la protezione" del bollettino sulla sicurezza. Le informazioni sul modo in cui l'aggiornamento per la protezione affronta la vulnerabilità sono contenute nei "Dettagli della vulnerabilità" nella sezione delle domande frequenti.

Lo scopo di questo passaggio è definire il livello di rischio associato agli aggiornamenti e alle soluzioni alternative. Tornando all'esempio precedente, il team responsabile dell'amministrazione di Exchange può concludere che un aggiornamento per la protezione ponga un "rischio moderato" in base alle modifiche apportate nel bollettino sulla sicurezza. In questo caso, è necessario rifarsi alle politiche aziendali per aggiornare e modificare adeguatamente il proprio programma. Ad esempio, le politiche aziendali potrebbero richiedere che per gli aggiornamenti per la protezione a rischio moderato si prevedano due o tre giorni di testing rispetto a quelli a basso rischio.

Potrebbe anche essere necessario rivedere le decisioni sulla distribuzione delle soluzioni alternative in base all'impatto del livello di rischio sul proprio programma. Si potrebbe scoprire, ad esempio, che occorrerebbe prolungare il testing di due giorni lasciando i sistemi non protetti per un periodo più lungo di quello consentito dalle politiche aziendali. In questo caso, si dovranno modificare le decisioni sulla distribuzione delle soluzioni alternative per conformarsi alle politiche aziendali.

Infine, le informazioni ricavate in questa fase potranno essere utilizzate per lo sviluppo di un piano di testing per gli aggiornamenti.

7. Sviluppo di un piano di testing

Per essere efficace, il testing deve essere sistematico e incluso in un piano mirato. Deve inoltre incentrarsi su quelle aree dell'ambiente che molto probabilmente evidenzieranno problemi. Essendo ogni ambiente diverso, Microsoft non può proporre un modello standard che serva a definire un piano di testing efficace.

Nelle organizzazioni con responsabilità suddivise, il piano di testing sarà spesso progettato da più team. Il team che gestisce le tecnologie e i sistemi a cui potranno essere applicati gli aggiornamenti per la protezione e le soluzioni alternative può mettere a disposizione la sua esperienza su questi sistemi. Il team addetto al testing può offrire invece l'esperienza che ha nella creazione di test case, nella scelta degli strumenti di testing e nella comprensione dei tempi pratici.

Durante questa fase, si dovrà osservare in che modo il piano di testing influisce sul livello di rischio degli aggiornamenti e delle soluzioni alternative e si dovrà modificare di conseguenza il programma di testing e distribuzione. Ad esempio, se si conclude che non si può sviluppare un piano di testing per eseguire prove sufficientemente complete di un aggiornamento, si può aumentare il livello di rischio, decidere di rimandare la distribuzione e implementare nel frattempo le soluzioni alternative.

8. Sviluppo di un piano di distribuzione

La distribuzione è il processo di implementazione della protezione fornita dagli aggiornamenti e dalle soluzioni alternative. Essendo la distribuzione l'obiettivo principale dell'intero processo, la comprensione dei metodi di distribuzione disponibili e la loro inclusione nelle valutazioni è tanto importante quanto la valutazione dei rischi di protezione. Nelle organizzazioni con responsabilità suddivise, la scelta dei possibili metodi di distribuzione degli aggiornamenti per la protezione è spesso appannaggio dei team responsabili della gestione dell'infrastruttura di aggiornamenti software, ad esempio il team di gestione di Systems Management Server (SMS). I team che si occupano della supervisione delle tecnologie di gestione della configurazione (come Active Directory) potrebbero essere coinvolti nella scelta dei possibili metodi di distribuzione delle soluzioni alternative.

Lo scopo di questa fase è capire quali siano i possibili metodi di distribuzione e sviluppare un piano che verrà utilizzato per distribuire gli aggiornamenti per la protezione e le soluzioni alternative. In questa fase è importante capire in che modo i vari metodi di distribuzione possono incidere sul piano e quindi apportare le modifiche necessarie. Ad esempio, se un aggiornamento per la protezione non è supportato da WSUS, che è il principale metodo di distribuzione dell'organizzazione, si stabilirà che la distribuzione dell'aggiornamento richiederà due giorni in più rispetto al programma originale. Si potrà quindi decidere di implementare le soluzioni alternative al fine di garantire le protezioni necessarie durante questo periodo prolungato di distribuzione.

Le informazioni riguardanti i metodi di distribuzione sono contenute nella sezione "Domande frequenti relative a questo aggiornamento per la protezione" del bollettino sulla sicurezza. Per ciascuna soluzione alternativa vengono fornite informazioni sui metodi di implementazione. Si tenga presente che ad ogni vulnerabilità sono associate varie soluzioni alternative.

Le nostre fasi di pianificazione sono ora concluse. A questo punto, si disporrà di un programma che tiene conto di tutti gli elementi delle attività di valutazione e pianificazione riguardanti i rischi per la sicurezza, il livello di rischio degli aggiornamenti per la protezione e delle soluzioni alternative, il testing e la distribuzione. Come si è osservato, queste fasi sono intrinsecamente correlate e non necessariamente lineari. In alcune organizzazioni, queste fasi sono concomitanti, mentre in altre sono sequenziali. Il cliente dovrà prendere decisioni in merito all'implementazione di queste operazioni in base alle politiche aziendali, alle esigenze e alle risorse dell'organizzazione. Nel corso di queste operazioni, la cosa fondamentale non è rispettare la struttura né l'ordine, ma verificare che le varie fasi interagiscano tra di loro. La cosa più importante di qualsiasi implementazione consiste nel rimanere flessibili e adattabili.

9. Esecuzione di test per gli aggiornamenti e le soluzioni alternative

Nella fase di testing, si esegue una verifica funzionale degli aggiornamenti per la protezione e delle soluzioni alternative nell'ambiente di testing in base al piano definito in precedenza. Lo scopo dell'ambiente di testing è riprodurre gli elementi di importanza critica presenti nell'ambiente di produzione. Quando si sottopongono a test gli aggiornamenti per la protezione e le soluzioni alternative, si cerca di individuare eventuali problemi che potrebbero verificarsi prima di distribuire il nuovo software nell'ambiente di produzione.

Poiché i problemi vengono individuati in fase di testing, è necessario determinare in questa fase la gravità del problema e le operazioni necessarie a risolverlo. I problemi individuati possono essere di entità minore e avere un livello di rischio accettabile o potrebbe trattarsi di problemi che dovranno essere risolti prima di distribuire gli aggiornamenti. Se si decide di tollerare un problema, è opportuno documentarlo per il personale addetto al supporto tecnico.

Se si deve risolvere un problema, si consiglia di aprire un caso presso il Servizio Supporto Tecnico Clienti Microsoft (PSS), che offre assistenza gratuita per i problemi associati agli aggiornamenti per la protezione. Per informazioni su come contattare PSS, visitare il sito Web support.microsoft.com/security. Poiché il tentativo di risoluzione di un problema potrebbe far ritardare il testing e la distribuzione, prima di decidere di procedere si deve considerare il potenziale impatto di questa operazione sul proprio programma.

Al termine del testing, quando tutti i problemi sono stati risolti o documentati, è possibile certificare come idonei alla distribuzione nell'ambiente di produzione gli aggiornamenti per la protezione e le soluzioni alternative.

10. Distribuzione degli aggiornamenti e delle soluzioni alternative

Dopo aver dichiarato idonei gli aggiornamenti per la protezione e le soluzioni alternative, è possibile procedere alla distribuzione. Durante la distribuzione, utilizzare il piano di distribuzione per applicare ai sistemi gli aggiornamenti e le modifiche di configurazione. I team che hanno sviluppato questo piano sono solitamente responsabili della distribuzione.

Se si verificano problemi in fase di distribuzione, ad esempio se un aggiornamento per la protezione non viene installato correttamente nell'infrastruttura di gestione degli aggiornamenti, sarà necessario esaminare il problema con attenzione. Se il problema causa ritardi, è possibile riesaminare le varie opzioni e/o considerare eventuali soluzioni alternative al fine di proteggere i sistemi.

Idealmente, il processo di testing dovrebbe individuare tutti i problemi che potrebbero verificarsi nell'ambiente di produzione prima della distribuzione. Tuttavia, se si verificano problemi dopo la distribuzione degli aggiornamenti nell'ambiente di produzione, è necessario attenersi alla stessa procedura utilizzata per affrontare un problema in fase di testing. Valutare il problema e decidere se è il caso di tollerarlo o risolverlo.

Se gli aggiornamenti per la protezione vengono applicati correttamente, le protezioni sono attive e l'obiettivo principale di questi processi è stato raggiunto. In caso contrario, i sistemi continuano a essere vulnerabili.

Poiché alcuni sistemi potrebbero non essere stati aggiornati correttamente, l'operazione finale del processo di distribuzione è molto importante perché prevede il controllo dei sistemi per verificare la correttezza della distribuzione. In alcune organizzazioni, questo controllo verrà eseguito da un team diverso, spesso collegato ai team di protezione. Gli strumenti Microsoft come WSUS, MBSA e SMS possono essere utilizzati per verificare la correttezza dell'applicazione degli aggiornamenti per la protezione. Le informazioni su come eseguire questa verifica sono contenute nella sezione "Informazioni sull'aggiornamento per la protezione" del bollettino sulla sicurezza.

Conclusioni

Con il rilascio mensile dei bollettini sulla sicurezza Microsoft, il cliente può sviluppare piani e processi sistematici per la gestione degli aggiornamenti per la protezione. L'adozione di procedure e processi sistematici consente di proteggere al meglio i sistemi e ridurre al minimo i possibili tempi di inattività.

Anche se ogni organizzazione dovrà sviluppare processi propri per la gestione degli aggiornamenti per la protezione, questi processi dovranno includere le operazioni consigliate in questo articolo. L'organizzazione non dovrà necessariamente avere due team distinti per la protezione e gli aggiornamenti, ma dovrà eseguire una valutazione dei rischi di protezione e sviluppare un piano di distribuzione.

Il concetto fondamentale di questo articolo è l'importanza della pianificazione. Con una buona pianificazione, le operazioni che comportano attività effettive, quali le fasi di testing e di distribuzione, saranno notevolmente agevolate, il che contribuirà all'esito positivo del processo di applicazione degli aggiornamenti per la protezione.

Christopher Budd è program manager per la sicurezza presso il Microsoft Security Response Center (MSRC). È specializzato nelle comunicazioni tecniche tra professionisti IT, professionisti della sicurezza e altri utenti di software.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.