Controllo della protezioneIsland hopping: limitazione delle dipendenze non desiderate

Jesper M. Johansson

Nel numero dell'ultimo mese di Controllo della protezione sono state trattate le fasi iniziali dell'utilizzo di un'unità memoria flash USB per sferrare un attacco contro una rete. L'attacco è stato eseguito collegando un'unità memoria flash USB infetta a un computer. Successivamente, è stato eseguito il codice dannoso, automaticamente o con un intervento minimo da parte dell'utente (mediante l'uso di una semplice tecnica di

ingegneria sociale). Sebbene si trattasse di un attacco locale alla workstation, è evidente che il malware avrebbe potuto diffondersi anche al resto della rete. Ho descritto in modo dettagliato questa forma di attacco in una rete nel mio ultimo libro, disponibile a breve, Windows Server 2008 Security Resource Kit (Microsoft Press®, 2008), e ho adattato alcune parti estratte da questo libro al presente articolo.

Ovviamente, un metodo appropriato per garantire la protezione consiste nel proibire l'utilizzo di unità rimovibili. Non vi è alcun dubbio che questo sia un comportamento prudente, anche se è altrettanto chiaro che un tale "sacrificio" non sia gradito affatto dagli utenti. L'opzione migliore, appropriata a tutti gli ambienti, ad eccezione di quelli più critici per le strategie aziendali, consiste nel tentare di gestire i rischi coinvolti e contenere l'esposizione a potenziali attacchi.

Inoltre, le unità rimovibili rappresentano l'unico metodo per compromettere un computer client. Ricordi l'articolo "Le 10 leggi immutabili della protezione" (disponibile all'indirizzo microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx)? Il sentimento generale della terza legge è ancora valido: "Se un utente malintenzionato ha accesso fisico illimitato al tuo computer, non devi considerarlo più il tuo computer". Nel contesto di questa discussione, se un utente malintenzionato ha accesso a un computer, tale computer deve essere considerato compromesso. Questo attacco può anche essere perpetrato in modalità remota se l'utente malintenzionato riesce a indurre l'utente vittima dell'attacco a eseguire codice dannoso sul relativo computer. In questa affermazione è possibile riconoscere la prima delle 10 leggi immutabili: "Se un malintenzionato riesce a convincerti a eseguire il suo programma sul tuo computer, non è più il tuo computer".

È possibile presumere in tutta sicurezza che le leggi immutabili hanno ancora validità, in quanto si sono dimostrate notevolmente adattabili ed è poco probabile che cambino in modo significativo finché non si apportano modifiche radicali alla dinamica di funzionamento dei computer. Pertanto, considerando l'applicabilità di queste leggi allo scenario delineato, è di importanza fondamentale rendere innocue le unità rimovibili. A tal fine, è sufficiente apportare alcune modifiche al Registro di sistema.

Ovviamente, è necessario utilizzare anche livelli di protezione aggiuntivi. È ragionevole presupporre che la maggior parte dei computer client sia già stata compromessa o che venga utilizzata da utenti non sempre spinti dal predominante interesse a garantire il massimo livello di protezione. Questo implica la necessità di ridurre i relativi effetti sul resto della rete e accresce l'importanza di comprendere, analizzare e limitare le dipendenze di protezione.

Definizione di una dipendenza di protezione

Una dipendenza di protezione si verifica quando la protezione di un computer è dipendente dalla protezione di un altro computer. È probabile che sia capitato di sentire affermazioni del tipo "se il controller di dominio è vittima di un attacco, l'intera rete è sotto attacco". Questo è un modo semplicistico di affermare che tutti i membri del dominio sono dipendenti dai controller di dominio per la relativa protezione. Se non si garantisce la protezione del controller di dominio, non si assicura neppure la protezione dei computer membro. Se un utente malintenzionato può modificare la configurazione di protezione del dominio, potrà assumere il controllo di qualsiasi computer all'interno del dominio aggiungendo, ad esempio, nuovi account al gruppo Administrators su un computer membro. Qualsiasi vulnerabilità che consenta la compromissione di un sistema da parte di un amministratore non suscita alcun interesse. Si suppone che un amministratore abbia accesso completo a tutte le aree che gestisce.

Le dipendenze nei sistemi informatici sono inevitabili. In effetti, le dipendenze sono frequenti e spesso auspicabili; tuttavia, ciò non implica che tutte le dipendenze sono accettabili. In questo articolo verranno illustrati i tipi di dipendenze considerati accettabili e non accettabili, verranno analizzati i diversi tipi di dipendenze e verrà descritto come limitarle. In Windows Server 2008 Security Resource Kit, le specifiche dipendenze vengono descritte in maggiore dettaglio e viene illustrato come gestirle.

Dipendenze accettabili

In generale, una dipendenza è accettabile quando un sistema meno critico per le strategie aziendali dipende per la protezione da un sistema più critico. I computer e i sistemi in generale possono essere suddivisi in classi in base al relativo livello di importanza strategica. Lo specifico set di classi in uno specifico ambiente è irrilevante per la discussione generale: ciò che importa è che siano presenti classificazioni intrinseche. Ai fini di questa discussione, si suppongano due classificazioni: workstation e controller di dominio. In tale scenario, è accettabile che le workstation dipendano dai controller di dominio per la relativa protezione. La classe controller di dominio è molto più critica per le attività aziendali rispetto alle workstation e, ovviamente, necessita di una difesa più efficace.

La stessa argomentazione può essere applicata agli account utente. È accettabile che un amministratore possa compromettere i dati di proprietà di un utente. Il motivo risiede nel fatto che gli amministratori hanno maggiori responsabilità e dispongono di accesso illimitato (anche se non sempre diretto o ovvio) al computer e a tutti gli elementi in esso contenuti. Se si comprende questo punto e si gestiscono i computer in modo appropriato, una dipendenza di questo tipo non costituisce alcun problema.

Anche il software può essere analizzato dallo stesso punto di vista. È certamente accettabile che un componente software meno critico per le attività aziendali, come un browser Web, utilizzi e dipenda per la relativa protezione da un componente software più strategico per le attività aziendali, come un sistema operativo. Se il sistema operativo presenta un bug, il fatto che il browser Web diventi vulnerabile a un nuovo problema non sorprende e non costituisce affatto una priorità nell'elenco delle preoccupazioni imminenti, in quanto il punto focale dell'attenzione sarà rappresentato principalmente dal sistema operativo e da altre applicazioni e dati critici. In particolare, l'attenzione sarà rivolta alle modalità di correzione dei bug e ai componenti a cui applicare gli aggiornamenti rapidi; la correzione di un bug deve avvenire il più vicino possibile all'area problematica. In tal modo, l'impatto protettivo della correzione risulterà incrementato. Pertanto, anziché aggirare il problema nel browser Web, è necessario correggere il bug nel sistema operativo.

In alternativa, è possibile rimuovere la dipendenza modificando la progettazione del sistema. È possibile, ad esempio, riscrivere il browser Web in modo da ridurre le relative dipendenze dal sistema operativo. Quest'ultimo approccio risulta appropriato nei casi in cui le funzionalità dei componenti più protetti (in tal caso il sistema operativo) non siano state affatto progettate per essere utilizzate nel modo in cui vengono utilizzate dal componente meno strategico per le attività aziendali (il browser Web).

Dipendenze non accettabili

Sulla base della descrizione sopra fornita delle dipendenze accettabili, la definizione di una dipendenza non accettabile dovrebbe essere ovvia. In sostanza, un sistema più critico per le strategie aziendali non deve mai dipendere per la relativa protezione da un sistema meno critico.

Se la compromissione di una workstation implica che la protezione del controller di dominio è stata violata, ci si trova di fronte a un serio problema di protezione. È impossibile proteggere una rete se la relativa protezione globale dipende dalla protezione di ogni singolo computer all'interno di tale rete.

Considerare questo aspetto da un punto di vista statistico. Se ogni computer nella rete è "protetto" per il 99,999% del tempo, si potrebbe pensare che si dispone di una rete estremamente protetta. In effetti, tale percentuale è probabilmente lontana dalla realtà di ciò che accade effettivamente oggi in tutte le reti, ad eccezione delle reti di piccole dimensioni. Tuttavia, si supponga che la propria rete includa 40.000 computer, ciascuno dei quali risulta vulnerabile lo 0,001% del tempo. Da un punto di vista statistico, la rete globale potrebbe rimanere in uno stato non protetto per il 40% del tempo.

Ovviamente nel caso di dipendenze non gestite, è sufficiente un solo computer vulnerabile per lo 0,001% del tempo per compromettere l'intera rete. In questi termini, qual è il livello di protezione della rete? Ovviamente, è assolutamente fondamentale che i sistemi più critici per le strategie aziendali siano protetti dai sistemi meno critici.

Questa argomentazione può essere facilmente estesa agli account utente e al software. Ad esempio, il nuovo client Servizi terminal per Windows® consente di memorizzare i nomi e le password degli utenti per garantire un accesso trasparente a Servizi terminal. Tali credenziali vengono memorizzate mediante l'API Gestione credenziali e sono protette dalle credenziali utilizzate per la sessione di accesso principale.

Questo può creare una dipendenza di protezione. Si consideri il caso di un amministratore di rete che accede alla workstation personale. L'amministratore utilizza questa workstation per la posta elettronica, l'esplorazione del Web e altre attività tipiche degli Information Worker. Naturalmente, l'amministratore utilizza per tali attività un account di dominio con privilegi di basso livello.

A un certo punto nel corso della giornata, l'amministratore si connette a un controller di dominio per eseguire alcune attività di gestione. A tal fine, utilizza il client Servizi terminal e sceglie di memorizzare la password in modo da rendere più agevoli le connessioni future. Questa situazione crea almeno una e probabilmente due dipendenze di protezione inaccettabili. La prima riguarda il fatto che le credenziali dell'account amministrativo di dominio ora sono protette dalle credenziali degli Information Worker con privilegi di basso livello. Se questo account utente con privilegi di basso livello viene compromesso, anche l'account utente amministrativo di dominio verrà compromesso e, pertanto, risulterà compromesso l'intero dominio.

La seconda dipendenza deriva dal fatto che l'amministratore ha digitato una credenziale amministrativa di dominio in un controller non di dominio. A meno che il livello di protezione della workstation personale non sia identico a quello dei controller di dominio, e probabilmente non è così, una situazione di questo tipo determina una dipendenza in cui la protezione dei controller di dominio dipende dalla protezione della workstation personale dell'utente. Se un dipendente insoddisfatto nello stesso ufficio, ad esempio, ha installato un keystroke logger nella workstation dell'amministratore di rete, le credenziali amministrative di dominio a questo punto sono state acquisite. Ogni volta che si digita una credenziale amministrativa di dominio in un controller non di dominio, si espone l'intero dominio alle potenziali vulnerabilità di protezione presenti nel controller non di dominio.

Ora si supponga che un utente malintenzionato inserisca un'unità rimovibile in un computer a cui un amministratore di dominio è correntemente connesso o a cui si è connesso in precedenza o a cui si connetterà. Il computer dell'amministratore di dominio in questione viene compromesso e, per estensione, risulta compromesso anche l'intero dominio. È assolutamente necessario comprendere questa situazione in modo da poter evitarla. Ovviamente, la stessa situazione può verificarsi con il software quando un'applicazione protetta si basa sulle funzionalità di un'applicazione meno protetta per eseguire una determinata attività.

Analisi di un attacco

In precedenza sono state illustrate le situazioni che possono verificarsi se un'unità rimovibile dannosa viene inserita in un computer. Tuttavia, può risultare ovvio solo ciò che accade al computer in cui viene inizialmente inserita l'unità. Si supponga che il computer in questione faccia parte di un dominio, come illustrato nella Figura 1.

Figura 1** Dipendenze di dominio ideali **

Nello scenario riportato nella figura viene illustrata una dipendenza ideale. Le frecce sono direzionali e fanno riferimento al punto da cui la dipendenza viene ereditata. Ad esempio, la protezione della workstation dipende dalla protezione del controller di dominio, e la protezione dell'utente dipende dalla protezione della workstation. L'utente malintenzionato potrebbe compromettere la workstation, il che comprometterebbe tutte le informazioni memorizzate nella workstation in questione, ma la compromissione sarebbe isolata a tale dispositivo.

Tuttavia, si supponga che l'utente che si connette alla workstation sia un membro del gruppo di amministratori locali sul server e che l'amministratore di dominio acceda di frequente al server. Un situazione di questo tipo ha come risultato le dipendenze illustrate nella Figura 2.

Figura 2** Dipendenze di dominio compromesse **

Modificando semplicemente l'ipotesi relativa al tipo di utente che ha accesso ai computer in questione, la protezione dell'intera rete risulta completamente compromessa. Poiché un amministratore di dominio accede al server, la protezione del controller di dominio e, quindi, l'intero dominio dipende dalla protezione del server in questione.

Questa dipendenza sarebbe accettabile se il server venisse gestito con lo stesso livello di protezione garantito per il controller di dominio. Tuttavia, in questo caso, un utente che accede alla workstation è membro del gruppo Administrators sul server. Pertanto, la protezione del server dipende dalla protezione della workstation. Ne consegue che la protezione dell'intero dominio dipende dalla protezione della workstation. E guarda un po': l'utente della workstation ha eseguito involontariamente lo strumento dell'utente malintenzionato.

Esistono probabilmente pochi concetti nel mondo della protezione delle informazioni attuale che rivestono un'importanza maggiore rispetto alle dipendenze di protezione. Se si inizia con un'analisi della rete e si tenta di comprendere quali sono le dipendenze presenti, quasi certamente si rileveranno dipendenze inaccettabili. Nello scenario peggiore, che è molto più comune di quanto si potrebbe pensare, la protezione dell'intera rete dipende dall'intera rete; in altre parole, la protezione di ogni singolo computer dipende, in qualche modo, dalla protezione di ogni altro computer. È pertanto impossibile creare in questo tipo di ambiente una strategia di gestione dei rischi ragionevole e realistica in quanto le relazioni sfuggono a ogni tipo di controllo e la complessità risulta incomprensibile. La soluzione consiste nell'analizzare e nel gestire le dipendenze rilevate.

In questo articolo è stata presentata solo una breve panoramica delle dipendenze ed è stato illustrato come analizzarle e ridurle. Ulteriori informazioni sono disponibili nel mio libro Windows Server 2008 Security Resource Kit. Il libro contiene un intero capitolo dedicato all'argomento della protezione della rete in cui le dipendenze vengono analizzate e gestite sia mediante tecniche sofisticate, ad esempio la funzionalità di isolamento di server e domini, che mediante tecniche più comuni, come la gestione di account amministrativi.

Vorrei ringraziare David LeBlanc per aver contribuito con le sue idee alla realizzazione di questo articolo.

Jesper M. Johansson, Software Architect, si occupa dei problemi di protezione software e collabora con TechNet Magazine in qualità di redattore. Ha conseguito il titolo di PhD in MIS e ha oltre 20 anni di esperienza nel settore della protezione.

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