Security

Garanzia della sicurezza della posta elettronica tramite i certificati digitali

Matt Clapham and Blake Hutchinson

Panoramica:

• Creazione di un'identità verificabile
• Aggiornamento dello stato dei certificati
• Recupero e scambio di certificati
• Risoluzione dei problemi del sistema S/MIME

Per millenni, gli esseri umani hanno utilizzato diversi metodi per nascondere le informazioni in transito, convalidare il mittente e autenticare il messaggio. Con l'evoluzione della civiltà umana, è stato sviluppato un metodo per l'esecuzione di tutte e tre le tre attività che va acquisendo una diffusione sempre maggiore. Secure Multi-Purpose Internet Mail

Extensions (S/MIME) è un sistema per l'invio in modo sicuro della posta elettronica mediante l'uso della crittografia e delle firme digitali.

Le tecnologie di crittografia correnti rientrano in due categorie principali: algoritmi a chiavi simmetriche (segrete), come Data Encryption Standard (DES) o Advanced Encryption Standard (AES), e algoritmi a chiavi asimmetriche (pubbliche/private), come RSA o Elliptical Curve Cryptography (ECC). Gli strumenti moderni per la convalida del mittente sono funzioni matematiche unidirezionali denominate hash che garantiscono l'univocità delle firme. Due metodi di hash comunemente utilizzati sono l'algoritmo Message Digest 5 (MD5) e Secure Hash Algorithm (SHA). I computer possono utilizzare questi metodi per generare un hash univoco o un numero che corrisponda al singolo testo di origine (l'hash di testi di origine identici è impostato sullo stesso valore). Questi strumenti semplici vengono utilizzati e combinati per creare un sistema di infrastruttura a chiave pubblica (PKI).

Identità verificabile

Risorse per l'Autorità di certificazione

• Utilizzo di un'Autorità di certificazione per il servizio Crittografia file system
• Impossibile rinominare o rimuovere dalla rete i server Autorità di certificazione
• Come rimuovere n'Autorità di certificazione attendibile dai computer del dominio
• Come rimuovere le autorizzazioni di un'Autorità di certificazione dell'organizzazione (enterprise) Windows e come rimuovere tutti gli oggetti correlati da Windows Server 2003 e Windows 2000 Server
• Come spostare un'Autorità di certificazione su un nuovo server in esecuzione su un controller di dominio

Le identità all'interno di un sistema PKI vengono gestite mediante certificati digitali, che non sono diversi dal documento di identificazione governativo utilizzato per attraversare un confine internazionale, ovvero il passaporto. Lo standard del settore dei certificati digitali per il passaporto è il formato X.509, che viene ampiamente utilizzato per la firma e la crittografia in tecnologie come S/MIME, Internet Protocol Security (IPsec), Secure Shell (SSH), sicurezza della rete wireless, reti private virtuali (VPN) e, persino, comunicazioni server sicure (come i siti Web SSL).

I certificati sono basati sulla crittografia asimmetrica e sugli hash. Per creare un certificato, il richiedente (l'entità che desidera una chiave firmata da un'autorità più elevata) genera una chiave privata. La chiave viene tenuta in un luogo sicuro in modo che la relativa autenticità non venga mai messa in discussione. Insieme alla chiave privata, viene anche generata una chiave pubblica corrispondente. Come implica lo stesso nome, la parte pubblica della coppia non è segreta e viene distribuita liberamente, ma sempre utilizzando metodi che ne garantiscano l'autenticità.

Questa coppia di chiavi consente due operazioni fondamentali. Primo, tutti possono utilizzare la chiave pubblica per crittografare dati che solo la chiave privata è in grado di decrittografare; secondo, la chiave pubblica può essere utilizzata per decrittografare dati crittografati con la chiave privata. Questo è importante per verificare una firma che potrebbe essere stata creata solo da una chiave privata.

La richiesta all'Autorità di certificazione include dettagli come l'identità della persona o del computer a cui la chiave è destinata, il tipo e la complessità dell'algoritmo e la parte pubblica della coppia di chiavi. L'Autorità di certificazione (CA) riceve e convalida le informazioni nella richiesta e, utilizzando un algoritmo hash, crea un identificatore univoco corrispondente alle informazioni ricevute.

Utilizzando la relativa chiave privata, la CA esegue la crittografia dell'hash delle informazioni e lo assembla in un formato standard, come X.509, creando un certificato corrispondente alla richiesta originale. Il certificato X.509 contiene un elenco di attestazioni che includono l'identità del certificato (soggetto), un intervallo di validità, la chiave pubblica e le operazioni per le quali è possibile utilizzare il certificato. Il certificato viene quindi restituito al richiedente; si tratta di un token in cui è possibile ravvisare un'affermazione di questo tipo: "Io, in quanto Autorità di certificazione, garantisco per questa chiave pubblica e la parte privata corrispondente nonché per tutti gli utilizzi ivi descritti".

Per le Autorità di certificazione radice, ovvero quelle al livello più elevato della catena di certificati, i certificati sono autofirmati. Le Autorità di certificazione radice più accettabili sono preinstallate nel sistema operativo o nell'applicazione di base ma possono essere aggiornate o modificate tramite pacchetti o la configurazione dell'organizzazione. Tra la CA radice e un nodo foglia, che descrive in genere una singola persona o un sistema, è possibile che sia presente una o più CA intermedie.

La catena è costituita da tutti i nodi e tutti i certificati precedenti in essi incorporati, firmati dalla CA a tale livello. Una terza parte che tenta di convalidare il certificato può controllare l'hash calcolato localmente e confrontarlo con quello decrittografato dal certificato utilizzando la chiave pubblica corrispondente per una specifica CA o uno specifico utente. In tal modo si ottiene una catena di certificati completamente convalidata, dai nodi fogli alla radice, presupponendo ovviamente che la radice sia attendibile.

Aggiornamento dello stato dei certificati

Ogni CA valida dispone di un metodo per distribuire un elenco di certificati che non devono più essere considerati attendibili. In questo elenco di revoche di certificati (CRL) vengono descritti gli elementi emessi che sono stati specificamente negati dalla CA. Per comodità, la posizione dell'elenco di revoche di certificati è in genere una proprietà del certificato CA.

Gli elenchi di revoche di certificati vengono in genere emessi dalle CA in base a una pianificazione (probabilmente ogni due settimane) o un evento (un'occorrenza che indica che un certificato emesso non deve più essere considerato attendibile). Gli elenchi di revoche di certificati vengono firmati da una CA quando vengono pubblicati. Quando un sistema ricevente valuta la validità di una catena, tenta in genere di acquisire l'elenco di revoche di certificati per ciascuna CA di emissione nella catena (tramite i dettagli incorporati nei certificati stessi o attraverso un meccanismo di distribuzione predefinito attendibile). Se non è disponibile alcun elenco di revoche di certificati, il client potrebbe ricorrere a una copia recente memorizzata nella cache, purché non sia precedente al periodo di aggiornamento dell'elenco di revoche di certificati specificato. In caso contrario, tuttavia, sui sistemi client viene visualizzata in genere una sorta di messaggio di errore che indica che il certificato sembra valido ma non è possibile determinare lo stato della revoca.

Molte applicazioni, se non sono in grado di convalidare la catena o l'elenco di revoche di certificati per ogni nodo della catena, richiedono una notevole quantità di tempo per il caricamento di un certificato. La decisione dell'utente di considerare attendibile o meno un certificato dipende dal tipo di dati protetti dal certificato. Un punto di distribuzione CRL ampiamente diffuso e aggiornato periodicamente è assolutamente necessario per ogni CA, in particolare per le radici pubbliche.

Le radici sono la base della catena di certificati, mentre il concatenamento costituisce la base di tutte le gerarchie dei certificati. La maggior parte delle applicazioni o dei sistemi client presuppone che un certificato di un nodo foglia sia valido solo se è collegato a una radice attendibile. Tale radice può essere rappresentata da una CA dell'organizzazione (enterprise), posseduta e gestita da una specifica azienda, o da una CA radice pubblica, come VeriSign.

È necessario che le CA radice pubbliche dispongano di un significativo livello di competenze operative in modo da garantire l'integrità. Le organizzazioni devono garantire che le relative operazioni interne raggiungano lo stesso livello, in quanto l'integrità di una CA radice in tale contesto è altrettanto importante. Per un livello di protezione ottimale, è opportuno mantenere le CA radice in modalità non in linea e utilizzarle solo per emettere i certificati e aggiornare gli elenchi di revoche di certificati. Per ulteriori informazioni sulle procedure operative consigliate relative alle CA, vedere gli articoli elencati nell'intestazione laterale "Risorse per l'Autorità di certificazione".

Un aspetto importante da considerare è il recupero chiavi. Per semplificare le ricerche e assicurare che i dati non vengano irrecuperabilmente bloccati da un utente, è opportuno che l'organizzazione esegua copie di backup di tutte le chiavi emesse dall'utente. Inoltre, queste copie di backup devono essere memorizzate in un archivio sicuro. In tal modo, se la chiave di un utente scompare, ad esempio nel caso in cui una smart card venga lasciata in un taxi, è comunque possibile continuare ad accedere al contenuto protetto dalla chiave in questione.

Infine, ogni sistema di crittografia efficace è basato sul concetto di gestione del ciclo di vita. Quanto più la velocità dei computer aumenta, tanto più vulnerabili diventano gli algoritmi. Un sistema di crittografia efficace deve essere in grado nel corso del tempo di rinnovarsi e di passare all'utilizzo di nuovi algoritmi e dimensioni di chiavi. Quando vengono identificati dei punti deboli nel sistema crittografico e determinate funzioni vengono gradualmente introdotte o sostituite, è opportuno aggiornare le CA in modo appropriato.

Implementazione di S/MIME

L'avvio, la composizione, l'invio e la ricezione di un messaggio di posta elettronica firmato o crittografato mediante S/MIME prevede diverse fasi. In questo articolo verranno illustrati i dettagli, i problemi e le potenziali soluzioni sulla base dell'analisi di uno scenario S/MIME tipico: due utenti che si inviano l'un l'altro messaggi di posta elettronica firmati e/o crittografati da due diverse foreste di Active Directory® e da catene di Autorità di certificazione differenti, ovvero da entità separate dal punto di vista operativo, all'interno o meno della stessa azienda, utilizzando Microsoft® Office Outlook® 2007.

L'analisi di questo scenario presuppone che l'infrastruttura necessaria sia già stata implementata per abilitare le operazioni che verranno descritte. In questo scenario di esempio viene utilizzato un server per certificati dell'organizzazione integrato in Active Directory.

Recupero di certificati

La prima attività consiste nel recuperare i certificati appropriati. A tal fine, aprire la console MMC di gestione dei certificati (certmgr.msc), fare clic con il pulsante destro del mouse su Cartella personale, selezionare Tutte le attività nell'elenco popup, quindi selezionare Richiedi nuovo certificato dall'elenco.

Verrà avviata la procedura guidata di registrazione dei certificati, come illustrato nella Figura 1. Per impostazione predefinita, vengono visualizzate diverse opzioni di livello aziendale, ma la più importante è Certificato utente. Questa opzione verrà utilizzata più avanti nell'articolo per attivare i processi di firma e crittografia. È necessario che sia possibile utilizzare il certificato per le seguenti attività:

Figura 1** Richiesta di un certificato **(Fare clic sull'immagine per ingrandirla)

• Firme digitali (creando un messaggio con un sigillo di autenticità da parte del relativo creatore)
• Crittografia a chiave (proteggendo una chiave con un'altra per tecnologie come Crittografia file system)
• Sicurezza della posta (messaggistica crittografata che può essere letta solo dal destinatario in possesso della chiave privata corrispondente)

Per l'invio dei messaggi di posta elettronica firmati S/MIME, la proprietà di crittografia a chiave non è necessaria. Tuttavia, per l'invio o la ricezione di un messaggio crittografato, questa proprietà è necessaria, mentre la proprietà di firma non è necessaria. Per impostazione predefinita, queste tre proprietà sono abilitate nei modelli in Servizi certificati Windows®. Se all'utente non è consentito richiedere nuovi certificati, all'avvio della procedura guidata non verrà visualizzato alcun certificato. Se non è disponibile alcuna CA dell'organizzazione (enterprise), all'utente verrà visualizzato il messaggio "Errore di registrazione" che indica che non è possibile contattare il dominio o la CA. Ai fini di questa procedura dettagliata,si presupporrà un singolo certificato che consente sia la firma che la crittografia a chiave.

Scambio di certificati

Il metodo più semplice per due utenti per iniziare a inviare messaggi di posta elettronica crittografati consiste semplicemente nell'inviare l'un l'altro messaggi firmati. Dopo aver composto un messaggio, l'utente fa clic sul pulsante Firma. Questo pulsante, per impostazione predefinita, è nascosto in Outlook fino a quando non viene utilizzato almeno una volta. È possibile individuare questo pulsante facendo clic sull'impostazione Opzioni per i nuovi messaggi, facendo clic sul pulsante "Impostazioni protezione...", quindi selezionando la casella "Aggiungi una firma digitale a questo messaggio" nella finestra di dialogo Proprietà di protezione. Il pulsante di firma (una piccola busta gialla con una barra multifunzione rossa con la dicitura Firma) consente di aggiungere una firma digitale al messaggio per stabilire l'autenticità della relativa origine.

Una volta fatto clic sul pulsante Invia, è possibile che all'utente venga chiesto di fornire token aggiuntivi per dimostrare che è in possesso della chiave, come l'inserimento di una smart card o l'immissione di un codice PIN. Questo dipende dagli specifici metodi di protezione delle chiavi implementati all'interno dell'organizzazione.

L'utente che riceve il messaggio firmato con S/MIME deve visualizzare e fare clic con il pulsante destro del mouse sul nome del mittente (dopo la casella Da:), quindi selezionare "Aggiungi a contatiti di Outlook" dal menu di scelta rapida in modo da aggiungere una nuova voce di contatto o aggiornarne una esistente. Il certificato viene quindi associato alla specifica voce di contatto. Notare che in un ambiente Active Directory comune (due utenti nella stessa foresta o azienda), la distribuzione di certificati utente pubblici viene eseguita automaticamente tramite gli attributi nell'oggetto Active Directory dell'utente.

Un altro metodo per lo scambio di certificati prevede che ciascun utente invii il relativo certificato S/MIME come allegato. A tal fine, entrambe le parti devono esportare i relativi certificati in un file CER. È necessario che gli utenti visualizzino il certificato e seguano il processo di esportazione che verrà illustrato più avanti, facendo attenzione a non esportare la chiave privata insieme al certificato, come illustrato nella Figura 2.

Figura 2** Durante lo scambio dei certificati, non esportare la chiave privata **(Fare clic sull'immagine per ingrandirla)

Ciascun destinatario crea manualmente una voce di contatto in Outlook e aggiunge il certificato alla voce del mittente. Una volta scambiati i certificati, i due utenti saranno in grado di scambiarsi reciprocamente i messaggi di posta elettronica crittografati.

Risoluzione dei problemi

A volte il destinatario ha difficoltà ad aprire il messaggio crittografato. Le tre cause più probabili dei problemi riscontrati in questa area sono rappresentate dalla mancata attendibilità delle CA radice, dall'impossibilità di convalidare le CA intermedie e dalla mancata disponibilità degli elenchi di revoche di certificati.

Una CA radice non attendibile in genere viene visualizzata in Outlook come messaggio di errore associato alla firma: "Sono stati rilevati problemi per la firma. Fare clic sul pulsante della firma per visualizzare i dettagli". Per risolvere il problema, aprire il certificato da Outlook e fare clic sul pulsante "Visualizza autorità di certificazione" nella finestra di dialogo popup. Esaminare il messaggio nella scheda Generale della finestra di dialogo delle proprietà del certificato. Se il messaggio indica che il certificato radice CA non è attendibile e deve essere installato, accedere alla scheda Dettagli. Fare clic sul pulsante "Copia su file..." e seguire la procedura guidata, accettando tutte le impostazioni predefinite e specificando, quando richiesto, un nome file e una cartella.

Aprire una nuova console MMC (Microsoft Management Console) come amministratore di computer. Accedere a File|Aggiungi/Rimuovi snap-in (Ctrl+M), selezionare il nodo Certificati e aggiungerlo per l'account del computer, scegliendo Computer locale, quando richiesto. Espandere il nodo Certificati nell'albero a sinistra, quindi espandere Autorità di certificazione radice disponibile nell'elenco locale. Fare clic con il pulsante destro del mouse e selezionare Tutte le attività|Importa dal menu popup. Importare il file di certificato esportato menzionato in precedenza in Autorità di certificazione radice disponibile nell'elenco locale e fare clic su Fine. Indicare all'utente interessato di riavviare Outlook.

Queste istruzioni devono essere utilizzate solo per aggiungere una CA radice considerata attendibile. Non tutte le radici vengono create uguali. Prima di utilizzare questo metodo per aggiungere una radice all'archivio per l'intero sistema, valutare attentamente chi possiede e gestisce la CA radice. Se la propria organizzazione controlla l'elenco delle radici attendibili tramite Criteri di gruppo, la configurazione verrà inserita nei sistemi client. In tal caso, le istruzioni potrebbero non funzionare. Se si verifica una situazione di questo tipo, potrebbe essere necessario esplorare ulteriori alternative, come server o siti Web sicuri per lo scambio di dati, in quanto l'invio della posta elettronica non avverrà in modo protetto e trasparente.

Il secondo problema, correlato all'impossibilità di convalidare le CA intermedie, in genere si verifica in due situazioni: un client che tenta di convalidare il certificato non è in grado di accedere al percorso Accesso alle informazioni dell'autorità (AIA) definito nel certificato o il client include una versione del certificato della CA intermedia che non corrisponde a quello emesso dalla CA (il client è in genere indietro di una o due versioni). Queste condizioni sono molto simili nell'interfaccia utente di Outlook. Questo problema è stato riscontrato solo in una circostanza molto specifica, quando una CA di livello intermedio nella catena è scaduta ed è stata emessa nuovamente prima della scadenza degli altri certificati subordinati da essa emessi.

In sostanza, questo problema si verifica in presenza di spazi vuoti nella catena. È possibile che alcuni certificati padre non siano documentati in modo adeguato o non siano incorporati nel nodo foglia in modo appropriato, complicando ulteriormente la situazione.

Per risolvere questo problema, il mittente deve aprire un nuovo messaggio e fare clic su Opzioni nel nuovo messaggio, quindi sul pulsante Impostazioni protezione e, infine, sul pulsante Cambia impostazioni. A questo punto, occorre fare clic sul pulsante Scegli per il certificato di firma e sul pulsante Visualizza certificato nella finestra di dialogo popup. Accedere alla scheda del percorso del certificato, selezionare l'autorità emittente del nodo foglia (al livello superiore nella catena) e fare clic sul pulsante Visualizza certificato. Fare clic sulla scheda Dettagli, quindi sul pulsante Copia su file... e completare l'Esportazione guidata, selezionando PKCS #7 (.P7B). Assicurarsi che l'opzione "Includi tutti i certificati nel percorso certificazione" sia selezionata, come illustrato nella Figura 3. Infine, inviare il file della catena esportato al destinatario desiderato.

Figura 3** Correzione di spazi vuoti in una catena di certificati **(Fare clic sull'immagine per ingrandirla)

Una volta ottenuta la catena di certificati esportata, il destinatario dovrà aprire e importare la catena seguendo una procedura simile a quella utilizzata in precedenza per l'importazione di una radice. L'unica differenza è che la cartella di archiviazione scelta deve essere Autorità di certificazione intermedia. Se il messaggio viene aperto e il certificato viene visualizzato come valido in Outlook, questo indica che non esiste alcun problema.

Quanto al terzo problema, la mancata disponibilità degli elenchi di revoche di certificati, la correzione è relativamente semplice. La risposta iniziale di Outlook sembrerà molto simile a quella fornita al problema precedente. Tuttavia, l'errore viene visualizzato anche se le CA di firma radice o intermedie sono attendibili. Per ogni livello della catena di certificati al di sopra della foglia, aprire le proprietà del certificato, fare clic sulla scheda Dettagli ed esaminare il campo "Punti di distribuzione Elenco di revoche di certificati (CRL)".

Per ogni punto di distribuzione CRL elencato, in particolare quelli accessibili da Internet, verificare che sia possibile aprire l'URL del file CRL. Una volta convalidato un livello, spostarsi al livello superiore della catena. Se non è possibile acquisire alcun elenco di revoche di certificati, quest'ultimo rappresenta probabilmente l'origine del problema. Per risolvere il problema, occorre verificare che i criteri di rete locali non blocchino l'accesso. In caso contrario, provare a contattare l'azienda proprietaria della CA o attendere che il punto di distribuzione CRL della CA ritorni allo stato operativo.

Distribuzione di certificati

La distribuzione è la parte più semplice. In sostanza, il messaggio firmato viene trasmesso a un server di posta, che lo invia da una posizione locale a un'altra tramite un metodo noto, SMTP. L'unico problema riscontrato con la posta firmata o crittografata in transito è che alcuni sistemi di posta rifiutano o interrompono i messaggi firmati o crittografati che passano attraverso di essi. La correzione di questo problema prevede l'utilizzo del gestore IT del sistema per ottenere i tipi di messaggi consentiti. Ovviamente, occorre tenere presente che alcuni tipi di messaggi sono bloccati. La parte ricevente potrebbe avere buone ragioni per non consentire messaggi crittografati in uno specifico ambiente operativo.

Crittografia delle risposte

Per creare una risposta crittografata (presupponendo che il processo di avvio sopra descritto sia stato completato), il mittente deve solo creare un messaggio e fare clic sul pulsante Crittografa (la piccola busta di colore giallo che include il blocco blu con la dicitura Crittografa) nella finestra di composizione del messaggio. Se il pulsante Crittografa non è disponibile, seguire la procedura per l'invio di un messaggio firmato, eccetto l'ultimo passaggio, e selezionare la casella di controllo "Crittografa contenuto e allegati del messaggio".

La firma S/MIME non è necessaria per l'invio di un messaggio crittografato a un destinatario, ma le due funzioni funzionano bene insieme in quanto la firma consente al lettore di convalidare il mittente (la funzione di crittografia non fa alcuna richiesta relativamente al mittente). Il processo di crittografia tenterà di crittografare il messaggio con le chiavi pubbliche note di tutti i destinatari. Se il sistema non è in grado di identificare i certificati per alcuni dei destinatari desiderati, questi verranno contrassegnati in una finestra di dialogo popup in cui viene chiesto se si desidera inviare i messaggio in formato non crittografato, come illustrato nella Figura 4.

Figura 4** È possibile decidere di inviare un messaggio non crittografato se si verifica un problema con un certificato **(Fare clic sull'immagine per ingrandirla)

Per impostazione predefinita, la firma e la crittografia funzionano correttamente con altri sistemi client configurati in modo analogo, ma talvolta lo scambio di messaggi crittografati o firmati tra versioni diverse può presentare dei problemi quando non viene fornito il supporto per versioni precedenti. Tale problema è stato riscontrato durante l'invio di un messaggio di posta elettronica firmato (utilizzando SHA-512 come algoritmo hash) a un computer su cui veniva eseguito Windows XP SP2. Poiché il sistema ricevente non forniva il supporto per l'hash, l'utente non è stato in grado di convalidare la firma o leggere il messaggio. Tuttavia, è poco probabile che gli utenti incontrino molti problemi in questa fase, a meno che le impostazioni predefinite di Outlook non siano state modificate.

Una volta ricevuto il messaggio, il destinatario previsto sarà in grado di aprirlo, purché sia disponibile la chiave privata associata al certificato pubblico. È possibile che all'utente venga di nuovo chiesto di fornite un token aggiuntivo per dimostrare di essere proprietario della chiave privata, a seconda della relativa modalità di distribuzione. È possibile che altri utenti che hanno completato un processo di avvio simile partecipino a comunicazioni firmate e crittografate simili con il mittente. Se, a un certo punto, un utente modifica la relativa chiave privata, ad esempio in conseguenza dello smarrimento del computer, dovrà richiedere i certificati e ridistribuire un messaggio firmato o un file di certificato ad altri utenti che desiderano scambiare posta crittografata.

Conclusioni

Lo scambio di messaggi S/MIME firmati e crittografati tra due utenti in due directory o organizzazioni differenti non presenta, in genere, ulteriori difficoltà rispetto a quelle già illustrate nel presente articolo. La firma è molto utile quando utilizzata correttamente, in quanto aggiunge autenticità al messaggio. Per i dettagli riservati, i messaggi crittografati forniscono un ulteriore livello di riservatezza per i dati in transito. Le due funzioni, utilizzate in combinazione, garantiscono l'autenticità dell'origine e la riservatezza dei dati. Sulla base del processo descritto in questo articolo, non sarà un'impresa ardua per gran parte degli utenti sfruttare i vantaggi offerti da queste funzionalità.

Matt Clapham, CISSP, è Security Engineer presso Microsoft IT. Esegue revisioni della sicurezza sulle applicazioni LOB di giorno e si diletta di tecnologia, giochi, musica per computer o sicurezza di notte. Talvolta, partecipa alle discussioni della community per la sicurezza IT di Puget Sound. È possibile contattarlo all'indirizzo matt.clapham@microsoft.com.

Blake Hutchinson è Support Analyst nel gruppo Business Online Services Group (BOSG) di Microsoft. Il suo ruolo prevede supporto operativo e revisione di progetti di strumenti LOB creati internamente per i clienti aziendali del gruppo BOSG. Blake si diletta di fotografia, gli piace sciare e ama i giochi per computer. È possibile contattarlo all'indirizzo blakeh@microsoft.com.

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