Ciclo di vita dello sviluppo della protezione per sistemi informatici attendibili

  • Articolo

Microsoft ha adottato un processo di sviluppo per la realizzazione di software in grado di contrastare attacchi dannosi. Le attività incentrate sulla protezione e le soluzioni che ne derivano sono ora parte integrante di ogni fase dello sviluppo.

Steve Lipner
Michael Howard
Security Engineering and Communications
Security Business and Technology Unit
Microsoft Corporation

Marzo 2005

Sintesi: In questo documento viene descritto il ciclo di vita dello sviluppo della protezione per sistemi informatici attendibili (o SDL), un processo adottato da Microsoft per lo sviluppo di software in grado di contrastare attacchi dannosi. Il processo prevede l'inserimento di una serie di attività incentrate sulla protezione e di soluzioni che ne derivano in ciascuna delle fasi del processo di sviluppo di software Microsoft. Queste attività e soluzioni includono lo sviluppo di modelli di pericoli durante la progettazione del software, l'utilizzo di strumenti di analisi statica del codice durante l'implementazione e l'esecuzione di revisioni del codice e test di protezione durante il cosiddetto "security push" (processo teso ad aumentare la protezione). Prima che il software soggetto al processo SDL possa essere rilasciato, deve essere sottoposto a un'analisi finale della protezione (detta analisi FSR, Final Security Review) eseguita da un team diverso da quello di sviluppo. Rispetto al software non sottoposto al processo SDL, il software realizzato in base a questo processo di sviluppo si caratterizza per un tasso notevolmente ridotto di segnalazioni esterne di vulnerabilità della protezione. In questo documento viene illustrato il processo SDL e viene descritta la sua implementazione nei prodotti software Microsoft. (19 pagine di stampa)

Nota Questo documento è un aggiornamento del documento "The Trustworthy Computing Security Development Lifecycle", presentato per la prima volta durante l'Annual Computer Security Applications Conference cosponsorizzata dall'IEEE e tenutasi a Tucson, in Arizona, a dicembre 2004.

Contenuto

1. Introduzione
1.1 Il processo di base
1.2 Panoramica del ciclo di vita dello sviluppo della protezione
2. Il processo SDL
2.1 Fase dei requisiti
2.2 Fase di progettazione
2.3 Fase di implementazione
2.4 Fase di verifica
2.5 Fase di rilascio
2.6 Fase di supporto e gestione
3. Implementazione del processo SDL presso Microsoft
3.1 Applicazione obbligatoria del processo SDL
3.2 Formazione obbligatoria
3.3 Criteri di misurazione per i team dei prodotti
3.4 Il team di protezione principale
4. Risultati dell'implementazione del processo SDL presso Microsoft
5. Osservazioni sull'applicazione del processo SDL
5.1 Efficacia delle componenti del processo SDL
5.2 Strumenti, test e revisioni del codice
5.3 Investimenti
5.4 Risultati
6. Conclusioni
7. Riconoscimenti
8. Bibliografia
9. Note

1. Introduzione

È indispensabile che tutti i produttori di software affrontino il problema dei pericoli per la protezione. La protezione è un requisito essenziale per i produttori di software, imposto dal mercato, dall'esigenza di proteggere infrastrutture di importanza critica e dalla necessità di creare e preservare una fiducia diffusa nei sistemi informatici. Una sfida importante per tutti i produttori di software è riuscire a creare software più sicuro che richieda meno patch di aggiornamento e attività di gestione della protezione meno onerose.

Per l'industria del software, la possibilità di soddisfare la richiesta attuale di maggiore sicurezza è legata all'adozione di processi ripetibili, in grado di garantire un miglioramento misurabile della protezione. I produttori di software devono quindi avviare la transizione a un processo di sviluppo del software più rigoroso e incentrato maggiormente sulla protezione. Tale processo è finalizzato a ridurre al minimo il numero di vulnerabilità della protezione ancora esistenti nel progetto, nella codifica e nella documentazione, e a rilevare ed eliminare tali vulnerabilità prima possibile durante il ciclo di vita dello sviluppo. La necessità di adottare un processo di questo tipo riguarda in particolare i prodotti software aziendali e di consumo presumibilmente destinati all'elaborazione di input ricevuti da Internet, al controllo di sistemi critici esposti agli attacchi o all'elaborazione di dati personali.

Vi sono tre aspetti alla base della creazione di software più sicuro: ripetibilità del processo, formazione dei tecnici, criteri di misurazione e attendibilità. La ripetibilità del processo SDL è l'argomento principale di questo documento, nel quale, tuttavia, viene trattata anche la questione della formazione dei tecnici e vengono forniti alcuni criteri generali di valutazione che mostrano l'impatto ad oggi dell'applicazione di un sottoinsieme del processo SDL.

Se l'esperienza di Microsoft può essere di esempio, l'adozione del processo SDL da parte di altre organizzazioni non dovrebbe comportare costi eccessivi per lo sviluppo del software. L'esperienza Microsoft suggerisce che i vantaggi derivanti dalla capacità di fornire software più sicuro (con meno patch e in grado di rendere i clienti più soddisfatti) hanno maggior peso rispetto ai costi.

Il processo SDL comporta la modifica dei processi di sviluppo di prodotti software adottati da un'organizzazione mediante l'integrazione di misure che assicurino una migliore protezione del software. Il presente documento riepiloga tali misure e descrive il modo in cui vengono integrate in un tipico ciclo di vita dello sviluppo del software. L'obiettivo di tali modifiche non è quello di rivedere in toto il processo di sviluppo, ma di aggiungere fasi di controllo e soluzioni di protezione ben definite.

In questo documento si presume che all'interno dell'azienda (o dell'organizzazione di sviluppo di prodotti software) vi sia un team centrale che guida lo sviluppo e l'ottimizzazione delle procedure per la protezione e i miglioramenti del processo, mette a disposizione dell'organizzazione le proprie competenze ed esegue l'analisi FSR (Final Security Review) del software prima del rilascio. In base all'esperienza di Microsoft, l'esistenza di questo tipo di organizzazione è fondamentale per l'esito positivo dell'implementazione del processo SDL e per il miglioramento della protezione del software. Tuttavia, alcune organizzazioni potrebbero prendere in considerazione l'idea di affidare il ruolo del "team di protezione principale" a un consulente esterno. In questo articolo viene descritta l'integrazione di una serie di passaggi volti a migliorare la protezione del software nel processo di sviluppo del software tipicamente utilizzato da grandi organizzazioni di sviluppo di prodotti software. Questi passaggi sono stati pianificati e attuati da Microsoft nell'ambito della cosiddetta Trustworthy Computing Initiative (iniziativa volta a creare sistemi informatici attendibili). Lo scopo di questi miglioramenti del processo è ridurre il numero e la gravità delle vulnerabilità della protezione nel software utilizzato dai clienti. In questo documento il processo modificato di sviluppo del software, attualmente adottato da Microsoft, viene definito "ciclo di vita dello sviluppo per sistemi attendibili" (o più semplicemente processo SDL).

Secondo l'esperienza Microsoft, il team di protezione deve essere disponibile a interagire di frequente durante la progettazione e lo sviluppo del software e garantire la riservatezza di informazioni di carattere tecnico e commerciale. Per questi motivi è preferibile istituire un team di protezione all'interno dell'organizzazione di sviluppo di prodotti software (anche se potrebbe essere opportuno avvalersi di consulenti per costruire il team e formarne i membri).

1.1 Il processo di base

Il processo di sviluppo del software generalmente accettato e utilizzato da Microsoft segue a grandi linee il diagramma di flusso mostrato in figura 1. In linea di massima, si tratta di un processo tipico previsto dalle procedure del settore.

Fare clic per visualizzare l'immagine ingrandita.

Figura 1 Processo di sviluppo standard di Microsoft (fare clic sull'immagine per ingrandirla)

Anche se la figura 1 mostra cinque fasi e sembra suggerire un processo di sviluppo "a cascata", in realtà il processo è riconducibile a una spirale. I requisiti e il progetto vengono spesso rivisti durante l'implementazione, in risposta alle esigenze mutate del mercato e a quanto si verifica durante l'implementazione del software. Inoltre, il processo di sviluppo evidenzia la necessità di avere codice in esecuzione in quasi tutti i passaggi. Pertanto, ogni fase principale è di fatto suddivisa nella produzione di una serie di build che possono essere testate e utilizzate in un contesto operativo (dal team di sviluppo) su base continuativa.

1.2 Panoramica del ciclo di vita dello sviluppo della protezione

All'esperienza acquisita in materia di protezione del software in situazioni reali si deve una serie di principi generali utili per la creazione di software più sicuro. Microsoft definisce questi principi SD3+C (Protezione in base alle caratteristiche progettuali, Protezione per impostazione predefinita, Protezione nella distribuzione + Comunicazioni). Ecco alcune brevi definizioni di questi principi:

  • Protezione in base alle caratteristiche progettuali: il software deve essere architettato, progettato e implementato per proteggere se stesso e le informazioni che elabora e per resistere agli attacchi.

  • Protezione per impostazione predefinita: nel mondo reale, il software non avrà un grado di protezione perfetto, quindi i progettisti devono presupporre l'esistenza di difetti di protezione. Per ridurre al minimo i danni che si verificano quando gli hacker sfruttano questi difetti, la configurazione predefinita del software deve promuovere la protezione. Ciò significa, ad esempio, che il software deve essere eseguito con il minor numero possibile di privilegi, e i servizi e le caratteristiche che non sono necessari su larga scala devono essere disattivati per impostazione predefinita o resi accessibili solo a un piccolo gruppo di utenti.

  • Protezione nella distribuzione: il software deve essere corredato di strumenti e istruzioni per consentire agli utenti e/o agli amministratori di utilizzarlo in modo sicuro. Inoltre, gli aggiornamenti devono essere facili da distribuire.

  • Comunicazioni: gli sviluppatori del software devono essere preparati a scoprire vulnerabilità del prodotto e comunicare apertamente e in modo responsabile con gli utenti finali e/ogli amministratori supportandoli nell'adozione di misure protettive (quali applicazione di patch o distribuzione di soluzioni alternative).

Anche se ogni elemento della formula SD3+C impone requisiti al processo di sviluppo, i primi due elementi - la protezione in base alle caratteristiche progettuali e la protezione per impostazione predefinita - assicurano i maggiori vantaggi in termini di sicurezza. La protezione in base alle caratteristiche progettuali richiede processi volti a prevenire in primis l'introduzione di vulnerabilità, mentre la protezione per impostazione predefinita prevede che l'esposizione del software (la "superficie d'attacco") sia ridotta al minimo per impostazione predefinita.

L'introduzione di misure di protezione volte a integrare gli elementi della formula SD3+C nel processo di sviluppo esistente produce la strutturazione globale del processo mostrata in figura 2.

Fare clic per visualizzare l'immagine ingrandita.

Figura 2. Miglioramenti apportati da SDL al processo di sviluppo Microsoft (fare clic sull'immagine per ingrandirla)

Nella sezione 2 di questo documento vengono descritte le componenti del processo SDL. Nella sezione 3 viene fornito un riepilogo delle specifiche dell'implementazione del processo SDL da parte di Microsoft. La sezione 4 contiene dati che dimostrano come l'applicazione precoce del processo SDL durante lo sviluppo di Microsoft Windows Server 2003 e di altri prodotti software abbia comportato la riduzione del numero di vulnerabilità della protezione e del loro livello di gravità rispetto alle versioni precedenti. La sezione 5 contiene osservazioni qualitative sulle componenti del processo basate sull'esperienza Microsoft nell'applicazione del processo SDL. Infine, nella sezione 6 vengono tratte le conclusioni.

2. Il processo SDL

Come osservato in precedenza, la formazione dei tecnici non rientra negli intenti di questo documento, ma è importante notare che un programma di formazione è fondamentale per l'esito positivo del processo SDL. I neolaureati in informatica e discipline correlate non hanno generalmente la formazione necessaria per essere in grado di progettare, sviluppare e testare software sicuro quando entrano nel mondo del lavoro. E anche coloro che hanno seguito corsi sulla protezione si sono imbattuti più probabilmente in algoritmi di crittografia e modelli di controllo dell'accesso piuttosto che in sovraccarichi dei buffer o difetti di canonicalization. In generale, progettisti del software, tecnici e tester del settore non hanno competenze adeguate in materia di protezione.

Date queste circostanze, un'organizzazione che intenda sviluppare software sicuro deve prendersi la responsabilità di garantire che il personale tecnico riceva la formazione adeguata. I modi specifici per affrontare questa sfida variano a seconda delle dimensioni dell'organizzazione e delle risorse disponibili. Un'organizzazione con molti tecnici in organico potrebbe impegnarsi a creare un programma interno di formazione continua sulla protezione per i propri tecnici, mentre un'organizzazione più piccola potrebbe affidarsi a corsi di formazione esterni. In Microsoft tutto il personale coinvolto nello sviluppo del software deve seguire corsi di formazione annuali per tenersi aggiornato sulla protezione.

2.1 Fase dei requisiti

La necessità di considerare la protezione sin dall'inizio è un principio fondamentale per lo sviluppo di sistemi sicuri. Anche se molti progetti di sviluppo producono "versioni successive" basate sulle release precedenti, la fase dei requisiti e la pianificazione iniziale di una nuova release o versione offrono la migliore opportunità di creare software sicuro.

Durante la fase dei requisiti, il team del prodotto contatta il team di protezione principale per richiedere l'assegnazione di un consulente di protezione (denominato "security buddy" nell'implementazione del processo SDL in Microsoft) che funge da punto di contatto, risorsa disponibile e guida durante la pianificazione. Il consulente di protezione assiste il team del prodotto esaminando i piani, fornendo consigli e assicurando che il team di protezione pianifichi sufficienti risorse per supportare il piano del team del prodotto. Il consulente di protezione consiglia il team del prodotto per quanto concerne le fasi della protezione e i criteri finali cui sarà necessario attenersi in base alla dimensione e complessità del progetto e ai rischi che esso comporta. Il consulente di protezione rimane il punto di contatto tra il team del prodotto e il team di protezione dall'avvio del progetto fino al completamento dell'analisi FSR e al rilascio del software. Il consulente di protezione funge anche da contatto tra i manager del team di protezione e del team del prodotto, comunicando loro se il progetto procede secondo i piani per quanto riguarda il fattore della protezione, in modo da evitare spiacevoli sorprese in una fase avanzata del processo.

La fase dei requisiti rappresenta per il team del prodotto l'opportunità di considerare le modalità di integrazione della protezione nel processo di sviluppo, individuare gli obiettivi principali della protezione e incrementare al massimo la protezione del software cercando al contempo di ridurre al minimo le interruzioni nei piani e nei programmi. Nell'ambito di questo processo, il team deve considerare come le funzionalità di protezione e le misure di garanzia del software in fase di sviluppo si integreranno con altri software che saranno presumibilmente utilizzati con esso. (L'interazione con altri software è un aspetto cruciale per soddisfare le esigenze degli utenti che hanno necessità di integrare singoli prodotti in sistemi sicuri.) Il punto di vista generale del team del prodotto sugli obiettivi di protezione, le sfide da affrontare e i piani deve riflettersi nei documenti di pianificazione che vengono redatti durante la fase dei requisiti. Sebbene i piani siano soggetti a modifiche man mano che il progetto procede, la strutturazione tempestiva di questi piani consente di assicurare che nessun requisito sia trascurato o che non vengano aggiunti nuovi requisiti all'ultimo minuto.

Ogni team del prodotto deve considerare i requisiti delle funzionalità di protezione come parte di questa fase. Mentre alcuni requisiti delle funzionalità di protezione saranno individuati in risposta alla modellazione dei pericoli, è probabile che i requisiti degli utenti impongano l'integrazione delle funzionalità di protezione in risposta alle esigenze dei clienti. I requisiti delle funzionalità di protezione deriveranno anche dalla necessità di conformarsi agli standard del settore e ai processi di certificazione, ad esempio Common Criteria. Il team del prodotto deve riconoscere questi requisiti e conformarsi ad essi nell'ambito del normale processo di pianificazione.

2.2 Fase di progettazione

Nella fase di progettazione vengono individuati i requisiti e la struttura complessiva del software. Dal punto di vista della protezione, i fattori chiave della fase di progettazione sono:

  • Definizione dell'architettura di protezione e delle linee guida di progettazione: definizione della struttura complessiva del software dal punto di vista della protezione e identificazione di quei componenti il cui funzionamento corretto è essenziale per la protezione (la cosiddetta "base informatica attendibile"). Identificazione delle tecniche di progettazione applicabili al software nel suo complesso, quali layering, utilizzo di linguaggio tipizzato in modo sicuro, applicazione di meno privilegi e riduzione al minimo della superficie d'attacco. (Layering fa riferimento all'organizzazione del software in componenti ben definiti e strutturati in modo da evitare dipendenze circolari tra di essi: i componenti sono organizzati in livelli e un livello superiore può dipendere dai servizi dei livelli inferiori, mentre ai livelli inferiori è vietato dipendere dai livelli superiori.) Le specifiche dei singoli elementi dell'architettura verranno descritte dettagliatamente nelle specifiche del progetto, ma l'architettura di protezione fa riferimento a una prospettiva globale del progetto di protezione.

  • Documentazione degli elementi della superficie d'attacco del software. Dato che il software non raggiungerà un grado di protezione perfetto, è importante che solo le funzionalità che verranno utilizzate da gran parte degli utenti siano disponibili per tutti gli utenti per impostazione predefinita, e che le funzionalità siano installate con il livello minimo possibile di privilegi. La misurazione degli elementi della superficie d'attacco fornisce al team del prodotto un criterio di valutazione continuo della protezione predefinita e consente di rilevare le istanze in cui il software è più esposto agli attacchi. Sebbene alcune istanze di aumento della superficie d'attacco possano essere giustificate dalle funzioni e dall'utilizzabilità migliorate del prodotto, è importante rilevare e mettere in discussione ciascuna di queste istanze durante la progettazione e l'implementazione, in modo che il software venga fornito in una configurazione predefinita che sia la più sicura possibile.

  • Esecuzione della modellazione dei pericoli. Il team del prodotto esegue la modellazione dei pericoli a livello dei singoli componenti. Utilizzando una metodologia strutturata, il team dei componenti identifica le risorse che il software deve gestire e le interfacce dalle quali è possibile accedere a tali risorse. Il processo di modellazione dei pericoli identifica i pericoli che possono danneggiare ogni risorsa e la probabilità che il danno si verifichi (valutazione dei rischi). Il team dei componenti identifica quindi le contromisure atte a ridurre i rischi (o sotto forma di funzionalità di protezione come la crittografia o sotto forma di funzionamento corretto del software che protegge le risorse da eventuali danni). La modellazione dei pericoli consente pertanto al team del prodotto di identificare i requisiti delle funzionalità di protezione nonché le aree in cui occorre eseguire in modo particolarmente accurato le revisioni del codice e i test di protezione. Il processo di modellazione dei pericoli deve essere supportato da uno strumento che acquisisca i modelli dei pericoli in formato leggibile dalla macchina per l'archiviazione e l'aggiornamento.

  • Definizione dei criteri di fornitura supplementari. Mentre i criteri di fornitura della protezione di base devono essere definiti a livello dell'organizzazione, i vari team dei prodotti o le release software possono avere criteri specifici da soddisfare prima del rilascio del software. Ad esempio, il team di un prodotto che sviluppa una versione aggiornata di un software per i clienti soggetto ad attacchi su vasta scala può decidere che la nuova versione debba essere priva di vulnerabilità segnalate da fonti esterne per un certo periodo di tempo prima di considerarla pronta per il rilascio. Ciò significa che durante il processo di sviluppo occorre aver individuato ed eliminato tali vulnerabilità prima che vengano segnalate piuttosto che far affidamento sul team del prodotto perché le corregga dopo che sono state segnalate.

2.3 Fase di implementazione

Durante la fase di implementazione, il team del prodotto codifica, esegue test e integra il software. Le operazioni effettuate per eliminare i difetti di protezione o prevenire il loro inserimento iniziale durante questa fase sono ampiamente utilizzate perché riducono in modo significativo le probabilità che eventuali vulnerabilità della protezione si verifichino nella versione definitiva del software che verrà fornito ai clienti.

I risultati della modellazione dei pericoli forniscono indicazioni particolarmente importanti durante la fase di implementazione. Gli sviluppatori prestano particolare attenzione alla correttezza del codice volto a ridurre i rischi ad alta priorità e i tester si concentrano sui test per assicurarsi che tali rischi vengano di fatto bloccati o ridotti.

Le attività del processo SDL applicabili alla fase di implementazione sono:

  • Applicazione degli standard di codifica e test. Grazie agli standard di codifica, gli sviluppatori evitano di introdurre difetti che possono provocare vulnerabilità della protezione. Ad esempio, l'utilizzo di una gestione delle stringhe più sicura e coerente e dei costrutti di manipolazione dei buffer possono consentire di ridurre l'introduzione delle vulnerabilità associate al sovraccarico dei buffer. Gli standard dei test e le procedure consigliate garantiscono che i test si incentrino sul rilevamento delle possibili vulnerabilità della protezione e non solo sul funzionamento corretto delle funzioni e caratteristiche del software.

  • Applicazione degli strumenti per i test della protezione, compresi gli strumenti di fuzzing. La tecnica del "fuzzing" fornisce input strutturati ma non validi alle API (Application Programming Interface) e alle interfacce di rete in modo da aumentare al massimo la probabilità di rilevare errori che potrebbero causare vulnerabilità nel software.

  • Applicazione degli strumenti per l'analisi statica del codice. Gli strumenti possono rilevare alcuni tipi di errori nel codice che danno origine a vulnerabilità, compresi sovraccarichi dei buffer, sovraccarichi dei numeri interi e variabili non inizializzate. Microsoft ha investito molto nello sviluppo di tali strumenti (quelli che sono utilizzati da più tempo sono PREfix e PREfast) e li migliora continuamente man mano che vengono scoperti nuovi tipi di difetti del codice e nuove vulnerabilità del software.

  • Esecuzione di revisioni del codice. Le revisioni del codice completano i test e gli strumenti automatizzati poiché consentono di applicare gli sforzi di sviluppatori qualificati all'esame del codice sorgente per rilevare ed eliminare possibili vulnerabilità della protezione. Sono importantissime nel processo di eliminazione delle vulnerabilità della protezione dal software durante il suo sviluppo.

2.4 Fase di verifica

Nella fase di verifica il software è completo dal punto di vista funzionale e comincia ad essere sottoposto ai test fase beta. Durante questa fase, mentre il software viene sottoposto ai test fase beta, il team del prodotto esegue il cosiddetto "security push", che include revisioni del codice di protezione diverse da quelle completate nella fase di implementazione e nei test incentrati sulla protezione.

Microsoft ha introdotto il security push durante la fase di verifica di Windows Server 2003 e di altre versioni software all'inizio del 2002. I motivi alla base dell'introduzione del security push nel processo sono stati due:

  • Il ciclo di vita del software per le versioni in questione aveva raggiunto la fase di verifica, che era ideale per eseguire le revisioni del codice e i test necessari.

  • L'esecuzione del security push durante la fase di verifica assicura che la revisione del codice e i test avvengano sulla versione definitiva del software e offre l'opportunità di analizzare sia il codice sviluppato e aggiornato durante la fase di implementazione che il codice preesistente non modificato.

Il primo di questi motivi è legato a un episodio storico: la decisione di eseguire un security push è stata presa per la prima volta durante una fase di verifica. Microsoft è comunque giunta alla conclusione che eseguire un security push durante la fase di verifica è pratica consigliabile, sia per garantire che il software definitivo soddisfi i requisiti, sia per consentire un'analisi più approfondita di tutto il codice preesistente (già presente nelle versioni software precedenti).

È importante osservare che le revisioni del codice e i test del codice ad alta priorità (codice appartenente alla "superficie d'attacco" del software) sono fondamentali in molti componenti del processo SDL. Ad esempio, queste revisioni e test sono necessari nella fase di implementazione per permettere la risoluzione tempestiva di qualsiasi problema e l'identificazione e la correzione della causa di tali problemi. Sono inoltre fondamentali nella fase di verifica, quando il prodotto sta per essere completato.

2.5 Fase di rilascio

Durante la fase di rilascio, il software deve essere sottoposto all'analisi FSR (Final Security Review). Lo scopo dell'analisi FSR è rispondere a questa domanda: "Dal punto di vista della protezione, il software è pronto per essere consegnato ai clienti?". L'analisi FSR viene eseguita per un periodo che va da due a sei mesi prima del completamento del software, a seconda delle dimensioni di quest'ultimo. Il software deve essere in una condizione stabile prima dell'analisi FSR e si devono prevedere solo modifiche minime non relative alla protezione.

L'FSR è un'analisi indipendente del software condotta per conto dell'organizzazione dal team di protezione principale. Il consulente di protezione del team di protezione comunica al team del prodotto in merito qual è lo scopo dell'analisi FSR necessaria per il software e consegna a questo team un elenco di requisiti delle risorse prima dell'esecuzione dell'FSR. Il team del prodotto provvede a fornire al team di protezione le risorse e le informazioni necessarie per eseguire l'FSR. L'FSR comincia con la compilazione di un questionario da parte del team del prodotto, seguita da un colloquio con un membro del team di protezione addetto all'FSR. Qualsiasi FSR comporterà un'analisi degli errori (bug) considerati inizialmente errori di protezione, ma che hanno dimostrato di non avere un impatto sulla protezione in base ad analisi successive, per verificare che queste siano state condotte correttamente. Un'analisi FSR include anche l'analisi della capacità del software di resistere alle vulnerabilità segnalate di recente che interessano prodotti software simili. Un'analisi FSR per una versione principale del software richiederà test di penetrazione e, all'occorrenza, il ricorso a consulenti esterni che supportino il team di protezione.

L'FSR non è una semplice un'analisi che dispensa sufficienze e/o insufficienze né il suo obiettivo è trovare tutte le vulnerabilità ancora esistenti nel software, perché ciò non sarebbe fattibile. L'FSR fornisce piuttosto al team del prodotto e all'alta direzione dell'organizzazione un quadro generale dello stato della protezione del software e delle probabilità che sia in grado di contrastare gli attacchi dopo il rilascio ai clienti. Se l'FSR rileva un tipo di vulnerabilità ancora esistente, la risposta appropriata non consiste semplicemente nell'eliminare le vulnerabilità individuate, ma nel rivedere la fase precedente e prendere ulteriori misure per correggere le cause di tali vulnerabilità (ad esempio, migliorare la formazione, potenziare gli strumenti, ecc.).

2.6 Fase di supporto e gestione

Nonostante l'applicazione del processo SDL allo sviluppo, nessuna procedura di sviluppo attuale, per quanto avanzata, fornisce software del tutto esente da vulnerabilità e vi sono buoni motivi per credere che ciò non avverrà mai. Anche se il processo di sviluppo potesse eliminare tutte le vulnerabilità del software al momento della fornitura, si verificherebbero in seguito nuovi attacchi e il software "sicuro" risulterebbe di nuovo vulnerabile. I team dei prodotti devono pertanto essere pronti a rispondere alle nuove vulnerabilità segnalate nel software che viene fornito ai clienti.

Una componente del processo di risposta comporta la preparazione del personale a valutare i report sulle vulnerabilità e a rilasciare informazioni e aggiornamenti per la protezione al momento opportuno. L'altra componente del processo di risposta consiste nel condurre un'analisi post-mortem delle vulnerabilità segnalate e nell'adottare le azioni necessarie. Le azioni in risposta a una vulnerabilità sono diverse e vanno dal rilascio di un aggiornamento per correggere un errore isolato all'aggiornamento degli strumenti di analisi del codice, all'esecuzione di revisioni del codice dei sottosistemi principali. L'obiettivo durante la fase di risposta è imparare dagli errori e utilizzare le informazioni contenute nei report sulle vulnerabilità per rilevare e eliminare altre vulnerabilità prima che vengano scoperte sul campo e utilizzate per danneggiare i clienti. Il processo di risposta consente inoltre al team del prodotto e al team di protezione di adattare i processi in modo che errori simili non si verifichino in futuro.

3. Implementazione del processo SDL presso Microsoft

L'implementazione del processo SDL presso Microsoft si è evoluta dal 2002, anno in cui sono stati introdotti i "security push". Per avviare il processo SDL e avere un impatto sui prodotti in fase avanzata di sviluppo, i security push sono divenuti attività relativamente brevi che sono state distribuite in più fasi del processo SDL. I security push hanno avuto un impatto significativo sui piani dei team dei prodotti, sulle risorse e sui programmi e sarebbe stato molto più difficile eseguirli senza il sostegno attivo dell'alta direzione di Microsoft. I security push si incentravano sulla modellazione dei pericoli, le revisioni del codice e i test della protezione (compresi i test di penetrazione). L'analisi FSR (Final Security Review) è stata introdotta tra la fine del 2002 e l'inizio del 2003, prima del rilascio di Windows Server 2003, e ha avuto un impatto notevole sulla configurazione predefinita di Windows Server 2003 al momento della sua fornitura.

Dopo i security push e le analisi FSR iniziali, Microsoft ha avviato un progetto per formalizzare il processo SDL. Vale la pena menzionare specificamente quattro risultati prodotti da questo progetto:

  • Criteri per l'implementazione dell'applicazione obbligatoria del processo SDL

  • Formazione obbligatoria del personale tecnico

  • Criteri di misurazione per i team dei prodotti

  • Ruolo del team di protezione principale

Nelle seguenti sezioni viene descritto ogni risultato.

3.1 Applicazione obbligatoria del processo SDL

Considerati i vantaggi comprovati del processo SDL (vedere la sezione 5), Microsoft ha deciso di formalizzare il requisito che richiede l'applicazione del processo SDL a un'ampia gamma di software. A partire dalla redazione di questo documento, il processo SDL diventa obbligatorio per qualsiasi software per il quale:

  • Si prevede l'utilizzo per l'elaborazione di dati personali o riservati

  • Si prevede l'utilizzo in un'azienda o in un'altra organizzazione (comprese università, enti governativi o organizzazioni non-profit)

  • Si prevede l'utilizzo in una connessione Internet o un ambiente di rete

I prodotti software per i quali il processo SDL non è obbligatorio includono le applicazioni autonome non conformi ai criteri specificati sopra (ad esempio i giochi per bambini, come quelli della serie "The Magic School Bus"). Significativamente, SDL impedisce a tali prodotti software di interferire con la protezione della piattaforma (sistema operativo o altro software) su cui risiedono.

3.2 Formazione obbligatoria

Un aspetto fondamentale dei security push dell'inizio del 2002 è stata la formazione ricevuta da tutti i team dei prodotti, in particolare da tutti gli sviluppatori, i tester, i program manager e il personale addetto alla documentazione. Microsoft ha formalizzato un requisito che comporta un corso di formazione annuale sulla protezione per i tecnici delle organizzazioni il cui software è sottoposto al processo SDL. La necessità di un corso di aggiornamento annuale è dettata dal fatto che la protezione è un argomento in continua evoluzione, dato che i pericoli, gli attacchi e le difese cambiano costantemente. Di conseguenza, anche i tecnici qualificati e competenti sugli aspetti della protezione che interessano il software su cui lavorano devono seguire corsi di formazione supplementari man mano che lo scenario dei pericoli si modifica. Ad esempio, l'importanza delle vulnerabilità legate al sovraccarico dei numeri interi è aumentata notevolmente negli ultimi quattro anni ed è stato dimostrato di recente che alcuni algoritmi di crittografia presentano vulnerabilità in precedenza sconosciute.

Microsoft ha sviluppato un'introduzione e un aggiornamento comuni sulla protezione che vengono presentati ai tecnici in corsi di formazione "dal vivo" e sotto forma di supporti digitali. Microsoft ha utilizzato questi corsi come base per la formazione specializzata basata sulle tecnologie software e sui ruoli ricoperti dai tecnici. Microsoft sta preparando un corso di formazione sulla protezione che sarà caratterizzato da una maggiore specializzazione in base alla tecnologia utilizzata, al ruolo e al livello di esperienza degli studenti.

Molti partner e clienti di Microsoft hanno chiesto informazioni sulla disponibilità di corsi di formazione e processi di protezione utilizzati da Microsoft. Microsoft Press ha pubblicato libri basati sulle procedure interne dell'azienda in materia di progettazione sicura, codifica e modellazione dei pericoli e Microsoft Learning offre corsi basati sulle procedure interne di Microsoft.

3.3 Criteri di misurazione per i team dei prodotti

In qualità di azienda, Microsoft si lascia guidare dalla massima che "non si può gestire quello che non si può misurare". Anche se è molto difficile ideare criteri che misurino in modo affidabile la protezione del software, vi sono ovviamente dei criteri di misurazione che fungono da riferimento per la protezione del software. Questi criteri sono diversi e variano dai corsi di formazione per il personale tecnico (all'inizio del ciclo di vita dello sviluppo) alla percentuale di vulnerabilità individuate nel software fornito ai clienti.

Microsoft ha ideato una serie di criteri di misurazione che i team dei prodotti possono utilizzare per monitorare i risultati positivi ottenuti nell'implementazione del processo SDL. Questi criteri riguardano l'implementazione del processo SDL da parte dei team a partire dalla modellazione dei pericoli, alla revisione del codice accompagnata dai test di protezione, fino alla protezione del software da sottoporre all'analisi FSR. Dato che questi criteri vengono implementati nel tempo, devono consentire ai team di monitorare le proprie prestazioni (miglioramenti, peggioramenti e risultati invariati), come pure le prestazioni rispetto ad altri team. I criteri di misurazione verranno raggruppati e comunicati ai dirigenti dei team dei prodotti e ai quadri direttivi di Microsoft con cadenza regolare.

3.4 Il team di protezione principale

Già prima dell'adozione dei security push del 2002, Microsoft aveva istituito il team SWI ("Secure Windows Initiative") con l'obiettivo di migliorare la protezione del software, ridurre le vulnerabilità in Windows e fornire il supporto per la protezione ai team dei prodotti non Windows. Il team SWI ha avuto un ruolo fondamentale nell'organizzare e gestire il security push di Windows Server 2003 e ha fornito formazione, assistenza e consulenza per tutti i security push eseguiti all'inizio del 2002. Il team SWI ha anche condotto l'analisi FSR per Windows Server 2003, svolgendo un'attività pionieristica per tale analisi.

Con la distribuzione formale del processo SDL, il team SWI ha assunto il ruolo di team di protezione principale per Microsoft. Le responsabilità del team SWI includono:

  • Sviluppo, gestione e miglioramento del processo SDL, compresa la definizione degli aspetti obbligatori del processo.

  • Sviluppo, miglioramento ed erogazione della formazione dei tecnici.

  • Fornitura di "consulenti di protezione" che guidino i team dei prodotti nel corso del processo, eseguano revisioni per i team dei prodotti e garantiscano che le domande dei team dei prodotti ricevano risposte tempestive, accurate e autorevoli.

  • Ruolo di esperti in un'ampia gamma di argomenti per garantire che le domande per i consulenti di protezione (o formulate attraverso queste figure) ricevano risposte tempestive e accurate.

  • Esecuzione delle analisi FSR (Final Security Reviews) prima del rilascio del software.

  • Indagine tecnica delle vulnerabilità segnalate nel software che è stato fornito ai clienti per garantire che le cause vengano individuate e che venga avviato il livello di risposta appropriato.

La disponibilità e l'efficienza del team SWI si sono dimostrate fattori fondamentali nell'implementazione di SDL presso Microsoft. Microsoft mira ad avere un processo scalabile per lo sviluppo di software più sicuro e ciò comporta la necessità di disporre di competenze in materia di protezione ampiamente distribuite in tutti i team dei prodotti. Tuttavia, disporre di un team di protezione principale e altamente qualificato è importantissimo per garantire l'efficienza dei team dei prodotti dell'azienda e per sostenerli nel loro lavoro finalizzato alla creazione di un software più sicuro. Tale team assicura inoltre che qualcuno al di fuori del team del prodotto esegua l'analisi FSR.

4. Risultati dell'implementazione del processo SDL presso Microsoft

Microsoft ritiene prematuro trarre conclusioni definitive e dichiarare che il processo SDL migliora la protezione del software Microsoft, ma i risultati ottenuti sino ad oggi sono incoraggianti.

Windows Server 2003 è stato il primo prodotto Microsoft per il quale sono state implementate componenti importanti del processo SDL. La figura 3 mostra il numero di bollettini sulla sicurezza pubblicati nell'anno del rilascio dei due ultimi sistemi operativi per server Microsoft: Windows 2000 e Windows Server 2003. (Quando Windows 2000 è stato rilasciato, Microsoft non aveva un sistema formale per la valutazione del livello di gravità dei bollettini sulla sicurezza. Microsoft ha esaminato quindi ogni bollettino sulla sicurezza relativo a Windows 2000 in base al sistema attuale per la valutazione del livello di gravità.) Come è stato già esplicitato in questo documento, Windows Server 2003 è stato sviluppato con quasi tutti (ma non tutti ) i processi SDL; Windows 2000 non è stato sviluppato con questi processi.

Figura 3. Bollettini sulla sicurezza di Windows critici e importanti prima e dopo l'adozione del processo SDL

Le categorie dei livelli di gravità sono disponibili all'indirizzo https://www.microsoft.com/technet/security/bulletin/rating.mspx.

Anche ad altre release software Microsoft sono state applicate componenti del processo SDL. Sia il team del prodotto SQL Server che il team del prodotto Exchange Server hanno eseguito un security push (comprensivo di modellazione dei pericoli, revisioni del codice e test di protezione) prima di rilasciare il service pack (release software che raggruppa correzioni per le vulnerabilità della protezione e altri problemi). I risultati del security push per SQL Server sono stati integrati in SQL Server 2000 Service Pack 3 e quelli del security push di Exchange Server sono stati integrati in Exchange 2000 Server Service Pack 3. Le figure 4 e 5 mostrano i numeri dei bollettini sulla sicurezza pubblicati in periodi identici prima e dopo il rilascio del rispettivo service pack (si tratta di un periodo di 24 mesi per SQL Server 2000 e di 18 mesi per Exchange 2000 Server).

Figura 4. Bollettini sulla sicurezza per SQL Server 2000 prima e dopo l'adozione del processo SDL

Figura 5. Bollettini sulla sicurezza per Exchange Server 2000 prima e dopo l'adozione del processo SDL

Un altro esempio incoraggiante è il componente Internet Information Server di Windows Server 2003 (IIS 6): nei due anni successivi al suo rilascio, Microsoft ha pubblicato un solo bollettino sulla sicurezza per il server Web riguardante un componente (WebDAV) che non viene installato per impostazione predefinita.

Anche se gli esempi di vulnerabilità della protezione sono ancora pochi e i periodi di tempo limitati, questi risultati mostrano che il processo SDL è efficace. Microsoft continuerà a controllare il tasso delle vulnerabilità individuate in Windows Server 2003 e nei service pack di Exchange Server e SQL Server per verificare se le tendenze rilevate continuano. Microsoft analizzerà anche altri prodotti software Microsoft man mano che saranno disponibili nuove versioni per le quali il processo SDL è stato implementato in toto per determinare se i numeri e i livelli di gravità delle vulnerabilità della protezione continuano a diminuire.

5. Osservazioni sull'applicazione del processo SDL

I dati presentati nella sezione precedente fornivano una panoramica sui "risultati" che il processo SDL si propone di ottenere. In questa sezione si tenterà di rispondere ad alcune domande su "come" funziona il processo in questione. Mentre la sezione precedente si basava sui numeri (per monitorare rigorosamente i report sulle vulnerabilità e i bollettini sulla sicurezza) questa sezione si basa su dati storici riportati in forma di osservazioni e opinioni del personale del team SWI.

5.1 Efficacia delle componenti del processo SDL

Il processo SDL è costituito da molti sottoprocessi che sono distribuiti nel ciclo di vita dello sviluppo del software. Al team SWI è stato chiesto di assegnare le priorità ai sottoprocessi in termini di efficacia, a partire da quelli che comportano i maggiori vantaggi a quelli che sono stati provati ma si sono rivelati meno efficaci.

Il team SWI è concorde nel dichiarare che la modellazione dei pericoli è la componente a cui va assegnata la priorità più alta nel processo SDL. Ovviamente, la modellazione dei pericoli non viene applicata isolatamente: questa comporta attività di progettazione, analisi del codice e test; un processo che implementasse solo la modellazione dei pericoli ma non adottasse misure in risposta ai modelli (non testando l'efficacia delle riduzioni disponibili, ad esempio) non sarebbe affatto efficace. Le statistiche basate sul conteggio degli errori (bug) tendono a sminuire il ruolo della modellazione dei pericoli perché il maggior contributo della modellazione consiste nell'assicurare che gli errori che potrebbero causare vulnerabilità della protezione non vengano mai creati. Tuttavia, il ruolo della modellazione dei pericoli nel processo di sviluppo di software sicuro è talmente importante da farle occupare il primo posto nell'elenco.

SDL è ancora un processo relativamente nuovo per Microsoft e non vi sono ancora stati casi in cui una componente del processo sia stata eliminata. Una scoperta, tuttavia, non sarà accolta con sorpresa dai ricercatori dediti da molto tempo alla protezione: i test di penetrazione non costituiscono un metodo adeguato per garantire la protezione. I test di penetrazione fanno parte dell'analisi FSR (Final Security Review) per una release principale del software, ma le attività del team del prodotto durante l'intero ciclo di vita si incentrano sulla modellazione dei pericoli, le revisioni del codice, l'utilizzo degli strumenti automatizzati e dei test casuali invece dei test di penetrazione. Queste misure sono molto più complete nel prevenire ed eliminare gli errori di protezione rispetto ai classici test di penetrazione ad hoc. La componente dei test di penetrazione dell'analisi FSR è un mezzo che consente di determinare se il software è pronto per il rilascio ma non di rilevare e correggere gli errori di protezione. Se il test di penetrazione eseguito nel corso dell'analisi FSR rileva molti bug di protezione è perché le fasi precedenti non sono state abbastanza efficaci; in tal caso, la risposta corretta è rivedere le attività che si ritenevano complete in quelle fasi invece di correggere semplicemente gli errori rilevati dal test di penetrazione e rilasciare il software.

5.2 Strumenti, test e revisioni del codice

Gli strumenti di analisi statica, i test casuali e la revisione del codice sono complementari. Microsoft ha investito molto negli strumenti di analisi statica e il loro utilizzo è parte integrante del processo SDL. Tali strumenti sono efficaci nel trovare molti errori del codice che possono provocare vulnerabilità della protezione, specialmente sovraccarichi del buffer. Tuttavia, gli attuali strumenti, benché avanzati, non sono in grado di trovare tutti gli errori. Le analisi manuali del codice sono ancora necessarie per il processo SDL, sia per rilevare errori che gli strumenti non rilevano sia per individuare opportunità di miglioramento negli strumenti. L'articolo di Michael Howard pubblicato nel sito MSDN (Microsoft Developer Network) e menzionato nella bibliografia fornisce una panoramica sul metodo generale utilizzato nell'esecuzione delle analisi di protezione del codice che Microsoft insegna ai propri tecnici.

L'importanza del ruolo attribuito ai test casuali è un'aggiunta relativamente recente al processo SDL, ma i risultati ad oggi sono molto incoraggianti. Diversamente dagli strumenti di analisi del codice, gli strumenti per i test casuali devono essere creati (o quanto meno configurati) per ogni formato di file e/o protocollo di rete da testare; per questo motivo, sono spesso in grado di trovare errori che gli strumenti di analisi statica non hanno rilevato. I modelli dei pericoli consentono ai team dei prodotti di assegnare le priorità alle interfacce e ai formati per i test. I risultati dei test casuali non sono completamente deterministici (gli strumenti vengono eseguiti per un numero limitato di cicli e non è garantito che trovino tutti gli errori), ma l'esperienza dimostra che è probabile che un numero modesto di test casuali trovi errori "interessanti", che potrebbero altrimenti essere sfruttati come vulnerabilità della protezione.

5.3 Investimenti

La formazione obbligatoria sulla protezione costituisce un investimento significativo per un'azienda come Microsoft che dà lavoro a moltissimi tecnici. Per formazione si intende una combinazione di corsi "dal vivo" (tenuti da un istruttore) e materiale online. Il materiale online è una risorsa particolarmente preziosa se si desidera formare piccoli team di tecnici dislocati in uffici diversi dalla sede centrale di Microsoft. I corsi di formazione dal vivo si sono dimostrati efficaci soprattutto quando hanno partecipato tutti i membri dei team che si preparavano per i security push e altre attività fondamentali: in questi casi, l'esperienza di Microsoft suggerisce che la formazione dei team si ottiene non solo dai corsi in classe ma anche dall'esecuzione dei security push. L'efficacia della formazione sulla protezione (che solitamente dura mezza giornata) è amplificata dal fatto che tutti i membri del gruppo di lavoro si occupano della protezione.

Il team di protezione principale (o team SWI) è cresciuto in modo considerevole negli ultimi anni, sulla scia della maggiore enfasi posta da Microsoft sulla sicurezza. Per ragioni di progettazione, il team ha dimensioni ridotte rispetto al numero totale di tecnici di Microsoft, il che sottolinea l'importanza della "scalabilità" dei metodi per garantire che le responsabilità e le risorse per la produzione di software più sicuro rimangano all'interno dei team dei prodotti. Alcune strategie che riflettono l'importanza della scalabilità includono l'enfasi posta sulla formazione e gli strumenti, la fornitura di consulenti di protezione che aiutino il team del prodotto a risolvere i propri problemi (invece di risolvere i problemi presentati al team), e l'utilizzo di analisi (compresa l'analisi FSR) per fornire al team del prodotto il feedback necessario a stabilire se il software è pronto per il rilascio.

5.4 Risultati

La prova fondamentale a cui viene sottoposto il processo SDL serve a stabilire in quale misura il processo elimina e riduce le vulnerabilità nel software Microsoft. L'esperienza maturata, riassunta nella sezione 4, dimostra che il processo SDL supera questa prova. Microsoft valuta inoltre le vulnerabilità segnalate da fonti esterne per verificarne l'effetto sulle versioni software in fase di sviluppo. L'esperienza recente ha dimostrato che le misure di protezione pianificate o implementate nelle nuove versioni bloccano gli attacchi che sono stati sferrati efficacemente contro le versioni meno recenti in un numero crescente di casi. Windows XP Service Pack 2, rilasciato di recente, è stato rivisto in questo modo, e le modifiche di protezione che erano state pianificate ma non ancora implementate o presentate pubblicamente hanno dimostrato di poter eliminare un numero significativo di vulnerabilità che erano state segnalate nelle versioni precedenti di Windows dai ricercatori dediti alla protezione esterni a Microsoft.

6. Conclusioni

L'esperienza maturata da Microsoft indica che il processo SDL è efficace nel ridurre l'incidenza delle vulnerabilità della protezione. L'implementazione iniziale di SDL (in Windows Server 2003, SQL Server 2000 Service Pack 3 ed Exchange 2000 Server Service Pack 3) ha reso più efficace la protezione del software, e le successive versioni software, che riflettono i miglioramenti apportati a SDL, sembrano evidenziare caratteristiche di protezione ulteriormente potenziate.

L'implementazione graduale delle componenti che costituiscono il processo SDL ha prodotto ulteriori miglioramenti, e Microsoft ritiene che questo sia un segno della sua efficacia. Il processo, non ancora perfetto, è in fase di evoluzione ed è improbabile che raggiunga la perfezione o smetta di evolversi nell'immediato futuro.

Lo sviluppo e l'implementazione di SDL rappresenta un importante investimento per Microsoft e un cambiamento radicale nel modo in cui il software viene progettato, sviluppato e testato. L'importanza crescente del software nella società mette ancor più in evidenza la necessità che Microsoft e il settore IT nel suo complesso continuino a migliorarne la protezione; in quest'ottica, sia questo documento sul processo SDL che i volumi riguardanti tecniche specifiche (consultare la bibliografia) sono stati pubblicati per trasmettere l'esperienza maturata da Microsoft ad altri professionisti del settore.

7. Riconoscimenti

L'idea iniziale di questo documento è nata alla fine del 2002 come risultato della collaborazione degli autori odierni. Le bozze sono state aggiornate parallelamente all'evolversi del processo SDL e la versione attuale è stata preparata durante l'estate e l'autunno del 2004. Gli autori ringraziano Matt Thomlinson, Matt Lyons, Jamil Villani e Eric Bidstrup (del team Microsoft Secure Windows Initiative) per il loro contributo alla definizione e al miglioramento del processo SDL. Oltre alle persone menzionate, Scott Charney e Phil Reitinger di Microsoft e Jeannette Wing della Carnegie Mellon University hanno fornito commenti particolarmente utili durante la stesura delle bozze. Gli autori ringraziano inoltre Martin Abadi, Virgil Gligor, Dick Kemmerer, Chris Mitchell, Fred Schneider, Neeraj Suri e James Whittaker per i commenti e i suggerimenti proposti per il presente documento.

8. Bibliografia

Mundie, Craig, Trustworthy Computing White Paper

Howard, Michael, Attack Surface: Mitigate Security Risks by Minimizing the Code You Expose to Untrusted Users, MSDN Magazine, novembre 2004

Howard, Michael, Expert Tips for Finding Security Defects in Your Code, MSDN Magazine, novembre 2003

Howard, Michael & David LeBlanc, Writing Secure Code, Second Edition, Microsoft Press, Redmond, Washington, 2003

Swiderski, Frank & Window Snyder, Threat Modeling, Microsoft Press, Redmond Washington, 2004

9. Note

Le informazioni contenute nel presente documento rappresentano le conoscenze attuali di Microsoft Corporation sull'argomento trattato, alla data della pubblicazione. Poiché Microsoft deve far fronte alle mutevoli condizioni del mercato, il documento non è impegnativo per Microsoft e Microsoft non garantisce l'accuratezza delle informazioni qui contenute, dopo la data della pubblicazione.

Questo documento è esclusivamente per scopi informativi. MICROSOFT ESCLUDE OGNI GARANZIA ESPRESSA, IMPLICITA O DI LEGGE IN QUESTO DOCUMENTO.

Il rispetto di tutte le applicabili leggi in materia di copyright è esclusivamente a carico dell'utente. Fermi restando tutti i diritti coperti da copyright, nessuna parte di questo documento potrà comunque essere riprodotta o inserita in un sistema di riproduzione o trasmessa in qualsiasi forma e con qualsiasi mezzo (in formato elettronico, meccanico, su fotocopia, come registrazione o altro) per qualsiasi scopo, senza il permesso scritto di Microsoft Corporation.

Microsoft può essere titolare di brevetti, domande di brevetto, marchi, copyright o altri diritti di proprietà intellettuale relativi all'oggetto del presente documento. Salvo quanto espressamente previsto in un contratto scritto di licenza Microsoft, la consegna del presente documento non implica la concessione di alcuna licenza su tali brevetti, marchi, copyright o altra proprietà intellettuale.

© 2005 Microsoft Corporation. Tutti i diritti riservati. Alcune parti del presente white paper sono protette dal copyright © 2004 Institute of Electrical and Electronics Engineers, Incorporated. Tutti i diritti riservati.

Microsoft, MSDN, Windows e Windows Server sono marchi o marchi registrati di Microsoft Corporation negli Stati Uniti e/o in altri Paesi.