Security WatchPrincipi di sicurezza quantistica

Jesper M. Johansson

Può essere molto divertente dire qualcosa di assolutamente imprevisto, ma pertinente, in una conversazione. Ho scelto di utilizzare il principio di indeterminazione di Heisenberg per spiegare i concetti correlati alla sicurezza. (Chi ha sentito la mia storia sull'unicorno sa già che mi piace fare le mie considerazioni prendendo in prestito le teorie fondamentali di altre discipline.) Per quanto

strano possa sembrare, esistono delle verità per la sicurezza delle informazioni che si deducono dai concetti fondamentali di altre branche della scienza.

Il principio di indeterminazione di Heisenberg, derivante dalla fisica quantistica, si basa sull'equazione mostrata nella figura 1. Il principio stesso afferma che la posizione di una particella (p) e il momento della particella (x) sono correlati al punto tale che se si aumenta la precisione di misurazione della precisione, viene ridotta la precisione di misurazione del momento. Il limite per la precisione dei due fattori è un piccolo multiplo fisso della costante di Planck. In parole semplici, questo principio afferma che non è possibile osservare contemporaneamente con la massima precisione determinati fatti relativi a una stessa particella.

Figura 1** Principio di indeterminazione di Heisenberg **

Ciò è associato direttamente alla previsione delle bande di incertezza, che consentono di predire il proprio livello di incertezza sullo stato di una coppia di fatti relativi a una particella. Anche se non è ancora possibile predire le bande, il fatto di non poter prevedere con certezza in che modo due variabili in un'unica rete di computer incideranno sulla sicurezza della stessa è estremamente importante.

Sono necessari anche dei compromessi. Anche se si potrebbe non essere vincolati dalla costante di Planck nella sicurezza delle informazioni, in effetti lo si è. Il compromesso più importante da fare è quello tra fattori quali la sicurezza e l'utilizzabilità o l'utilità. Se si ignora la disponibilità per un momento (e francamente ritengo che il personale della sicurezza dovrebbe essere responsabile per la disponibilità solo per quanto riguarda agli attacchi Denial of Service), il modo migliore per rendere sicuro un componente consiste nel disattivarlo completamente. In questo modo, non potrà più essere vittima di attacchi. Tuttavia, l'utilità diminuisce considerevolmente.

Analogamente, anche se più impegnativo, è possibile impedire la perdita di dati molto di più implementando un costoso prodotto per la prevenzione delle perdite di dati anziché inviando un messaggio di posta elettronica a tutti i dipendenti una volta all'anno per informarli che le applicazioni di messaggistica immediata non sono adatte per l'uso aziendale. Ma l'organizzazione è disposta a spendere per l'acquisto di uno strumento di prevenzione delle perdite di dati? A questo punto, viene illustrato in che misura la fisica quantistica risulta correlata alla sicurezza.

Gatto di Schrödinger

Un altro concetto della fisica quantistica correlato è espresso nella parabola del gatto di Schrödinger. Si dice che Erwin Schrödinger, un eminente fisico del ventesimo secolo, ebbe una discussione durata a lungo con Albert Einstein (un altro eminente fisico del ventesimo secolo di cui probabilmente si è già sentito parlare) sul concetto di sovrapposizione. Schrödinger individuò le aree della meccanica quantistica che avevano elementi esistenti nella sovrapposizione di due stati paradossali.

Per sostenere ciò, Schrödinger propose un esperimento mentale in cui un gatto veniva rinchiuso in una scatola sigillata ermeticamente. L'altro elemento inserito nella scatola era un contenitore di materiale radioattivo, il cui rilascio veniva controllato da una (immaginaria) particella radioattiva subatomica. Se la particella si fosse disintegrata, il materiale radioattivo sarebbe stato rilasciato e il gatto sarebbe morto.

La particella subatomica, essendo sottoposta alle leggi della meccanica quantistica, esiste in una sovrapposizione di stati. Di conseguenza, anche il gatto atomico, dato che il suo stato dipende interamente dallo stato della particella subatomica, esiste nella sovrapposizione di stati. Solo con un'osservazione diretta del gatto è possibile affermare se il suo stato sia di essere vivo o morto.

Ovviamente, con questo paradosso, Schrödinger intendeva illustrare quanto assurde siano alcune leggi della meccanica quantistica quando applicate ai sistemi atomici. Nonostante ciò, il suo esempio viene spesso ritenuto all'origine di quel concetto profanamente definito "effetto osservatore". Tale effetto, anche se non si applica ai sistemi subatomici della meccanica quantistica, risulta interessante per i professionisti della sicurezza. In parole semplici, afferma che è possibile modificare un qualcosa semplicemente osservandolo.

Effetto osservatore

Per spiegare ulteriormente il concetto, si prenda in considerazione l'esempio di una tazza di tè. Per scoprire quanto è caldo il tè, è possibile inserire un termometro nella tazza. Supponiamo che quando si inserisce il termometro nel tè la sua temperatura sia di 80 °C e che il termometro a sua volta abbia una temperatura di 22 °C (la temperatura ambiente). Non appena il termometro entra a contatto con il tè, inizia ad assorbire il calore del tè e quest'ultimo perde parte del suo calore per far scaldare il termometro. Alla fine, il termometro e il tè avranno la stessa temperatura. Tuttavia, la temperatura del tè non sarà né di 80 °C né tanto meno di 22 °C, ma sarà compresa in tale intervallo. In questo modo, attraverso la misurazione, la temperatura del tè è stata modificata.

L'effetto osservatore può essere applicato anche alla sicurezza delle informazioni. Ogni volta che si fa qualcosa per attenuare un problema di sicurezza, vengono potenzialmente modificate le condizioni di sicurezza dato che si modifica il sistema. In mancanza di un termine più adatto, questo effetto verrà chiamato effetto SPFE (Security Posture Fluidity Effect).

Uno degli esempi più semplici di questo effetto è quello delle dipendenze degli account di servizio. Nel capitolo 8 del libro Protect Your Windows Network (protectyourwindowsnetwork.com), viene illustrata l'installazione di un servizio di identificazione di intrusione (IDS) sui sistemi per rilevare gli eventuali attacchi. Tuttavia, il servizio IDS accede a un sistema centrale e richiede un accesso con privilegi di alto livello ai sistemi monitorati. Generalmente, ciò vuol dire che il servizio viene eseguito in un account del servizio con privilegi di alto livello.

Se uno di tali sistemi viene compromesso, l'autore dell'attacco può ottenere l'accesso alle credenziali dell'account del servizio e accedere a tutti gli altri sistemi, oltre che disabilitare il servizio IDS stesso. Questo è un perfetto esempio di effetto SPFE. Installando un componente per fornire sicurezza all'ambiente in uso, viene creato un nuovo potenziale problema di sicurezza.

Esistono numerosi altri esempi che spiegano l'effetto SPFE. La descrizione di Steve Riley del motivo per il quale 802.1x presenta tali problemi sulle reti cablate (microsoft.com/technet/community/columns/secmgmt/sm0805.mspx) è un altro ottimo esempio. In numerosi ambienti è auspicabile l'uso di firewall basati su host. Tuttavia, se utilizzati insieme a 802.1x, contribuiscono a creare un ambiente che fa aumentare la probabilità di specifici tipi di attacco. Occorre di nuovo ricordare che una tecnologia di sicurezza modifica le condizioni di sicurezza dell'ambiente e consente un attacco che altrimenti non sarebbe possibile.

Tuttavia, niente di tutto ciò indica che tali misure sono inutili e che devono essere evitate. È semplicemente necessario prendere in considerazione le implicazioni in termini di sicurezza a un livello generale. Quando si implementa la gestione dei rischi, è necessario considerare gli effetti che vengono prodotti sulla sicurezza dalle azioni e dalle misure di prevenzione adottate. Quando si tenta di risolvere un problema, non ci si dovrebbe fermare dopo aver implementato le contromisure. In effetti, la sicurezza è un processo. È necessario implementare una strategia di difesa in profondità, ma si ha bisogno di considerare in che modo tale strategia modificherà le condizioni di sicurezza e come sarà possibile affrontare le minacce che emergeranno dalla stessa.

Una strategia di protezione avanzata efficace

Sono impegnato nello sviluppo di linee guida per la protezione avanzata da oltre 10 anni. Ripensando alle prime linee guida su cui ho lavorato, mi rendo conto che erano poco più che semplici elenchi di impostazioni che gli utenti avrebbero dovuto attivare. A quell'epoca, la strategia generale per la sicurezza era estremamente semplice: se si pensava che qualcosa potesse fornire sicurezza, doveva semplicemente essere attivato. Il fatto che potessero esistere validi motivi per non farlo era assolutamente irrilevante.

Alla fine, mi resi conto che il processo per implementare una strategia di protezione avanzata efficace è molto complesso e occorre prendere in considerazione anche tutte le minacce alle quali viene esposto il sistema. Questa rivelazione ha portato alla creazione dell'elenco di scenari illustrati nella guida Windows 2000 Security Hardening Guide (go.microsoft.com/fwlink/?LinkID=22380). Da quel momento, ho pensato di suddividere le linee guida in base ai diversi livelli di minaccia, come illustrato nella guida Windows Server 2003 Security Guide (go.microsoft.com/fwlink/?linkid=14846).

Nonostante ciò, continuavo a essere tormentato dal fatto che fosse sempre possibile irrompere in un sistema in cui erano state adottate tutte le linee guida impartite. Ciò era dovuto all'assenza di alcune patch, all'implementazione di determinate procedure operative o all'installazione di un software di terze parti non sicuro.

Risulta quindi chiaro che tutte le linee guida fornite in queste due guide non si rivelano molto utili per creare delle condizioni di sicurezza generali. Tutto si riduceva ad alcuni fattori fondamentali. In effetti, il sistema più sicuro che abbia mai creato (msdn2.microsoft.com/library/aa302370) utilizzava solo quattro o cinque delle modifiche di sicurezza indicate nelle guide e nessuna di loro riusciva a bloccare gli eventuali attacchi a cui veniva esposto il sistema. Sfortunatamente, le persone desiderano semplicemente avere a disposizione un grande pulsante in grado di fornire automaticamente la protezione avanzata ai sistemi, ma la sicurezza è un fattore molto più complicato.

Come affrontare il rischio

Per essere realmente protetti (e non solo limitatamente sicuri), è necessario affrontare i rischi adottando un approccio ragionevole. È necessario comprendere quali sono i rischi a cui si dovrà far fronte, decidere quali di essi si desidera attenuare e quindi comprendere come farlo: tutto ciò non può esser fatto semplicemente con delle opzioni.

In generale, tali opzioni di sicurezza sono progettate per specifici scenari e non permettono necessariamente di creare la configurazione migliore per il proprio caso. In realtà, rappresentano un buon punto di partenza e sono disponibili principalmente perché la maggior parte del mercato ne ha bisogno. Molte di loro risultano attivate per impostazione predefinita nelle applicazioni moderne ed è probabile che quelle che non lo sono abbiano dei significativi effetti collaterali.

Inoltre, rendere disponibile un grande numero di opzioni può generare un sistema non supportabile e instabile che potrebbe non riuscire a eseguire le attività desiderate (e tutto per attenuare delle minacce non ancora identificate). L'effetto SPFE e la fisica quantistica insegnano a fare un'ulteriore analisi del sistema dopo aver implementato le misure di sicurezza, ma sono ancora troppo poche le organizzazioni che lo fanno. In realtà, non si preoccupano di partire da un'analisi delle minacce. Se si parte da un'analisi delle minacce, ci si renderà conto che ciò che fa davvero la differenza non sono le restrizioni anonime per gli elenchi dei nomi account e le modifiche generali degli elenchi di controllo di accesso.

Ciò che rende davvero diverse le cose è stabilire se il sistema deve fornire un particolare servizio e quali sono i destinatari, nonché applicare tali criteri. Il fattore fondamentale è verificare che solo i sistemi e gli utenti che hanno assolutamente bisogno di comunicare con voi ricevano l'autorizzazione per farlo. È inoltre importante accertarsi che a tutti gli utenti e le applicazioni vengano assegnati i privilegi di livello inferiore. In breve, ciò che fa davvero la differenza è adottare un approccio ragionevole alla sicurezza e svolgere le difficili attività di analisi per assegnare a ciascun sistema la responsabilità della propria sicurezza.

Questo è il motivo per il quale l'approccio attuale alla sicurezza ora impiega strumenti quali la soluzione Server and Domain Isolation (microsoft.com/sdisolation), Configurazione guidata impostazioni di sicurezza nei prodotti Windows Server® e gli strumenti di Server Manager per la gestione dei ruoli in Windows Server 2008. Questi strumenti consentono di comprendere gli scenari da supportare e permettono di bloccare i sistemi nel modo appropriato. È vero, questi strumenti non offrono un rimedio universale, ma consentono di creare una configurazione supportabile che possa realmente eseguire le attività per le quali è stato acquistato il software.

Applicare la sicurezza dove necessario

Quello che è stato detto finora indica che non è possibile implementare la sicurezza facendo affidamento su altri o applicando semplici modifiche di sicurezza. Ogni risorsa deve essere in grado di difendersi autonomamente perché concetti come "perimetro" e "rete interna" oggi hanno perso completamente di significato.

Nella migliore delle ipotesi, la maggior parte delle reti aziendali sono "semi-ostili". Bisogna capire ciò e prendere le dovute misure, senza fare affidamento esclusivamente su linee guida per la protezione avanzata automatiche. Per iniziare, è necessario capire quali siano le proprie esigenze. Quindi, si dovrebbero ricercare le linee guida da coloro che hanno capito tali esigenze.

Un ospite in una trasmissione webcast di recente ha consigliato agli utenti delle aziende di piccole dimensioni di accedere al sito del Department of Homeland Security e scaricare le linee guida per la protezione avanzata per Internet Explorer®. Perché ci si dovrebbe aspettare che un ente governativo con il compito di proteggere il sistema di sicurezza nazionale e militare fornisca linee guida per rendere sicuro un browser Web in un'azienda di piccole dimensioni? Si tratta di un perfetto esempio della debole logica che ancora prevale nel campo della sicurezza informatica. Il presupposto da cui si parte è che, visto che le linee guida vengono impartite da un ente governativo, i risultati ottenuti siano necessariamente della massima sicurezza.

Generalmente, viene chiesto di optare per una "sicurezza di alto livello" o una "sicurezza di basso livello". Sarebbe meglio che la scelta fosse tra una "sicurezza di alto livello " e una "sicurezza adeguata". La sicurezza non è una soluzione valida per tutti sempre allo stesso modo.

In effetti, una sicurezza di alto livello in genere va bene solo in pochissimi casi. Non è un obiettivo finale al quale si dovrebbe mirare. Si tratta di una configurazione specifica per quei sistemi la cui eventuale compromissione verrebbe sentita come un'autentica tragedia. Se la sicurezza di alto livello si addice al proprio profilo e modello di rischio, è opportuno utilizzarla.

Se invece non risulta appropriata, se ne dovrebbe scegliere un altro tipo. È quasi sicuro che tutte le eventuali modifiche configurabili siano già impostate, per impostazione predefinita, su un livello di profilo di rischio moderato. Tale stato predefinito, utilizzato al momento nella maggior parte dei prodotti Microsoft, fornisce un compromesso ragionevole tra sicurezza, utilizzabilità, utilità e prestazioni, Per ciò che riguarda la protezione avanzata, fa al caso proprio.

È ora necessario prendere in considerazione altre operazioni per la sicurezza. Un buon punto di partenza è il sito TechNet Security Center (microsoft.com/technet/security) e, naturalmente, libri come Windows Server 2008 Security Resource Kit.

Gestione dei rischi

È probabile che a questo punto si sia compreso che il fattore primario è la gestione dei rischi. Il messaggio fondamentale del principio di indeterminazione di Heisenberg è la necessità dei compromessi. Quella parte del principio non è scienza missilistica.

Nonostante ciò, il messaggio che emerge dalla storia del gatto di Schrödinger è qualcosa che viene ignorato dalla gente fin troppo spesso. Il fattore importante non è solo analizzare tutti i lati del problema e prendere una decisione in merito ai compromessi, ma anche prendere in considerazione le modifiche introdotte dalle soluzioni. Una strategia di gestione dei rischi efficace prende in considerazione il modo in cui tale modifiche incidono sul sistema e se sono state implementate nell'ambito di una strategia di attenuazione dei rischi o per un qualsiasi altro motivo.

Perdita annuale attesa

Il modo più comune per quantificare il rischio, e il metodo appreso in numerosi corsi di certificazione per la sicurezza, è l'equazione relativa alla perdita annuale attesa (Annual Loss Expectancy, ALE), mostrata nella figura 2. L'ALE standard è estremamente semplice. Viene stabilita la probabilità di un incidente e il costo di ogni singola ricorrenza e, quindi, si moltiplicano i due valori. Ciò restituisce la cifra che si prevede di pagare per gli incidenti di sicurezza su base annua. Se il costo del rischio è abbastanza alto, viene implementata la strategia di attenuazione.

Figura 2** L'ALE rappresenta la probabilità di una perdita, moltiplicata per il costo della perdita per incidente **(Fare clic sull'immagine per ingrandirla)

In questo caso, il problema è che l'ALE standard non giustifica il costo per l'attenuazione. Oltre ad avere un proprio costo, le strategie di attenuazione producono anche effetti collaterali, ai quali sono associati ulteriori costi.

Bisogna prendere in considerazione una delle principali modifiche di sicurezza standard: il blocco account. Molte organizzazioni distribuiscono il blocco account, apparentemente per impedire agli autori degli attacchi di identificare le password. Viene calcolata matematicamente la probabilità che un autore di attacchi riesca a identificare una singola password. Con un po' di fantasia, è possibile prevedere un costo medio per la violazione risultante nel caso in cui un autore di attacchi riesca a identificare una password. In base a questi due numeri, molte organizzazioni hanno deciso che l'ALE non è sufficiente e, di conseguenza, hanno implementato un blocco account.

Tuttavia, questo particolare tipo di strategia di attenuazione ha un costo, che non si dovrebbe sottovalutare. Si tratta del costo per la sua implementazione, anche se è assolutamente minimo. Per essere precisi, il calcolo dovrebbe includere anche i costi degli effetti collaterali derivanti dalla strategia di attenuazione.

In primo luogo, esiste un costo associato all'operazione di sblocco degli account per gli utenti da parte dell'help desk. Se un account viene bloccato per un periodo di tempo ridotto, diciamo 15 minuti, esiste comunque un costo per la produttività persa in tale periodo. Questo fattore viene considerato come il costo di ogni incidente, moltiplicato per la probabilità per la quale l'incidente può verificarsi nel periodo in questione. In questo caso, il costo viene moltiplicato per il numero di eventi di blocco previsti (tale numero è fornito dai registri in uso).

Si dovrebbe prendere in considerazione anche il fattore di aggravamento relativo agli utenti. Prove anedottiche indicano che gli utenti tendono a utilizzare password meno complicate se sono soggetti a un blocco account, in quanto sono più facili da digitare. Pertanto, la probabilità che si verifichi l'incidente che si desidera evitare non scende interamente a zero dopo aver implementato la strategia di attenuazione.

Infine, possono esistere delle vulnerabilità introdotte dalla strategia di attenuazione e non presenti nel sistema prima della sua introduzione. Nel caso del blocco account, un autore di attacchi può usare tale funzione per disabilitare tutti gli account nella rete semplicemente digitando ripetutamente le password non corrette. Esiste la probabilità che si verifichi anche questa situazione, con un costo associato di ciascun incidente.

Prendendo in considerazione tutti questi fattori, risulta evidente che è necessario modificare l'equazione relativa alla perdita attesa. In primo luogo, è necessario modificare la probabilità dell'incidente. Questo incidente dovrebbe avere meno probabilità di verificarsi rispetto al passato, anche se la probabilità, come già illustrato, potrebbe non essere scesa completamente a zero. Anche il costo di ogni incidente potrebbe essere cambiato. A tale prodotto è necessario aggiungere il costo della strategia di attenuazione stessa. Si tratta del costo costituito dal costo di implementazione più il costo annuale di tutti gli effetti collaterali. Ognuno dei costi annuali è il prodotto della probabilità dell'effetto collaterale verificatosi e del costo di ogni incidente associato a tale effetto. Semplificando leggermente l'equazione, si ottiene l'equazione per l'analisi dei rischi più accurata mostrata nella figura 3.

L'equazione della figura 3 fornisce un modo molto più accurato per analizzare il rischio di un particolare problema. Diverse organizzazioni hanno già adottato tale metodo per analizzare i loro rischi. Tuttavia, molte di loro hanno ancora una visione semplificata del rischio che non mette adeguatamente in evidenza la necessità di analizzare l'impatto delle strategie di attenuazione. Utilizzando la nuova equazione ALE, tale esigenza ottiene una considerazione fondamentale.

Figura 3** Considerazione dei costi aggiuntivi per l'attenuazione **(Fare clic sull'immagine per ingrandirla)

Conclusioni

Dopo aver letto questo articolo, si dovrebbe mettere in discussione l'approccio convenzionale alla base delle strategie di sicurezza. La maggior parte di ciò che viene fatto nel campo della sicurezza delle informazioni si basa su una visione stereotipata del mondo e molte delle supposizioni risultano ora superate.

Gli attacchi sono cambiati. Gli autori degli attacchi ora sono dei veri professionisti, che svolgono la loro attività per denaro, per primeggiare a livello nazionale e per ideologia. Non ci si può permettere di perdere tempo e denaro con modifiche di sicurezza che non migliorano affatto la sicurezza. Ciò vuol dire anche che è necessario adottare un approccio molto più sofisticato alla gestione dei rischi.

In primo luogo, è importante comprendere che tutto ciò che viene fatto comporta un compromesso. Non è possibile sapere tutto con una certezza assoluta.

In secondo luogo, è necessario capire che si agisce in un sistema interdipendente. Introducendo modifiche di sicurezza in un sistema di questo tipo, viene modificato il sistema stesso e quindi diventa necessario poterlo rianalizzare.

È opportuno che ciò venga fatto prima di implementare tali modifiche perché esse hanno, fin troppo spesso, enormi conseguenze sul sistema e producono un impatto più negativo che positivo. Se si utilizzano strumenti di analisi migliori che ricordano di analizzare tali modifiche, è molto meno probabile che non vengano prese in considerazione.

Infine, non bisogna dimenticare mai il fattore umano. L'obiettivo primario di qualsiasi operazione svolta nel campo della sicurezza delle informazioni è consentire all'azienda, e ai suoi utenti, di agire nel modo più sicuro possibile.

In una recente presentazione, ho sottolineato il fatto che oggi non esiste un solo utente che acquisti un computer per eseguire un programma antivirus. La sicurezza è il nostro obiettivo principale, ma non quello dell'azienda. Le organizzazioni che si occupano della sicurezza perché è nei loro migliori interessi lo fanno solo momentaneamente. Non bisogna dimenticare mai che il gruppo di sicurezza delle informazioni è a disposizione dell'azienda e non il contrario. Se si ignora questo fatto, gli utenti saranno disposti a tutto per svolgere il proprio lavoro, anche se ciò comporta non rispettare i controlli di sicurezza che non capiscono o non accettano.

Jesper M. Johansson, Software Architect, si occupa dei problemi di sicurezza del software e collabora con TechNet Magazine come redattore. Ha conseguito il titolo di PhD nei sistemi di gestione delle informazioni e vanta di oltre venti anni di esperienza nel campo della sicurezza; è inoltre Microsoft Most Valuable Professional (MVP) nella sicurezza aziendale. Il suo ultimo libro è Windows Server 2008 Security Resource Kit.

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