Sicurezza

Il grande dibattito: la sicurezza tramite segretezza

Jesper M. Johansson and Roger Grimes

Panoramica:

• Definizione della sicurezza tramite segretezza
• Valutazione delle misure di sicurezza tramite segretezza
• Importanza della ridenominazione dell'account Administrator
• Come prendere decisioni di gestione dei rischi consapevoli

La definizione "sicurezza tramite segretezza" incontra spesso la derisione del personale della sicurezza, in particolar modo di coloro che si considerano esperti. Letteralmente sottovalutata da molti, la sicurezza

tramite segretezza, come evidenziato in Wikipedia (http://it.wikipedia.org/wiki/Security_through_obscurity), rappresenta uno degli aspetti più controversi inerenti la sicurezza. La definizione "sicurezza tramite segretezza" viene spesso utilizzata per fare riferimento ad attività di scarsa importanza.

In poche parole, la sicurezza tramite segretezza è una violazione del principio di Kerckhoff, che sostiene che un sistema dovrebbe essere sicuro di per sé e non perché la sua struttura è sconosciuta all'avversario. Il principio di Kerckhoffs si basa sulla premessa che i segreti non rimangono tali per molto tempo.

Come esempio di ciò, prendiamo in considerazione il protocollo di autenticazione Windows NT® LAN Manager (NTLM), considerato inizialmente un segreto. Per implementare il prodotto di interoperabilità Samba per i sistemi operativi basati su UNIX, il team Samba è stato costretto a eseguire il reverse engineering del protocollo. Si ottenne così la più vasta documentazione disponibile sul protocollo NTLM (monyo.com/technical/samba/translation/ntlm.en.html) oltre che l'identificazione di una serie di bug. Visto che gran parte della sicurezza si sviluppava dalla crittografia e molti progetti segreti erano stati rivelati, molti professionisti della sicurezza ritennero che tutta la sicurezza delle informazioni dovesse seguire il principio di Kerckhoff.

Ma è vero che la sicurezza tramite segretezza è sempre inefficace? In questo articolo, verrà illustrata la sicurezza tramite segretezza, verranno indicati i motivi per i quali molti (ma non tutti) la considerano una perdita di tempo e verrà mostrato come la questione sia, come al solito, molto più complicata di come potrebbe sembrare di primo impatto.

Introduzione alla sicurezza tramite segretezza

Non modificare le impostazioni predefinite di Steve Riley

Io sono uno di quelli che pensano che non si dovrebbero modificare i nomi account Questo in realtà non è un problema di sicurezza, ma piuttosto un problema di gestione dei sistemi. E, visto che mi ritrovo sempre più spesso a pensare allo spazio di gestione dei sistemi (dato che la gestione e la sicurezza stanno diventando un'unica questione), divento sempre di più un sostenitore del non fare nulla che possa potenzialmente aumentare la vulnerabilità di un sistema. Un modo sicuro per aumentare la vulnerabilità consiste nel modificare le impostazioni predefinite. Esistono ben due (o tre) motivi per i quali le persone modificano le impostazioni predefinite:

• Esiste l'esigenza della funzionalità fornita dalla modifica.
• Si pensa che la modifica possa migliorare la sicurezza.
• (Ricordare: non è affatto vero.) Qualcuno ne ha sentito parlare in un articolo di giornale.

Se si ha bisogno di modificare un nome predefinito per il motivo 1, procedere alla modifica. Questi tipi di modifiche in genere non comportano un'instabilità del sistema, spesso perché sono state già testate.

Se si desidera apportare una modifica per il motivo 2, è necessario fermarsi un attimo e riflettere. Questi tipi di modifiche non vengono quasi mai testate dal produttore del software e, di conseguenza, quest'ultimo non sa prevedere quale sarà la reazione del sistema alla modifica. Inoltre, di solito esistono alternative di gran lunga migliori che saranno in grado di fornire una sicurezza efficace.

Cosa accade se un malintenzionato scopre un nome account? Sarà la password, e la sua complessità, a tenere il malintenzionato lontano dal sistema. L'impellenza di modificare i nomi account predefiniti come Administrator e Guest in nomi difficili da ricordare è spesso realmente indicativa del desiderio di evitare password o passphrase complesse. È sufficiente risolvere il vero problema (segreti inappropriati) per evitare la vulnerabilità (modificando i nomi predefiniti).

La sicurezza tramite segretezza non include misure che sono del tutto inefficaci per la risoluzione di un problema. Ad esempio, un'organizzazione che blocca il protocollo Network News Transfer Protocol (NNTP) sui router di confine per impedire ai dipendenti di leggere i newsgroup ma consente il protocollo Secure Shell (SSH) in uscita non sta utilizzando la sicurezza tramite segretezza. Dato che il protocollo SSH può effettuare il tunneling di ogni protocollo, il problema non viene nascosto; la scarsa attenuazione implementata riesce solo a impedire che utenti legittimi eseguano attività legittime senza violare i criteri di sicurezza. Tali misure non costituiscono la sicurezza tramite segretezza; sono semplicemente inappropriate e inutili.

Come il termine "sicurezza" incluso nella definizione "sicurezza tramite segretezza" implica, è possibile ottenere un certo grado di sicurezza dalla misura. Tuttavia, è implicito anche che (e questo è il problema) non si sta facendo nulla per bloccare un attacco su uno o più vettori. (Un vettore di attacco è fondamentalmente un mezzo attraverso il quale un autore di un attacco riesce ad accedere a un sistema.)

Si supponga, ad esempio, di avere un server Web vulnerabile che può essere attaccato sulla porta TCP 80 utilizzando un exploit pubblico. Per chiudere quel particolare vettore, è possibile applicare una patch al server Web oppure disattivarlo; entrambe le azioni sono in grado di bloccare completamente il vettore. È possibile bloccare il vettore di attacco parzialmente utilizzando un firewall o IPsec per lasciare aperta la porta 80 solo per alcuni computer prescelti. In questo modo, il vettore di attacco non viene bloccato completamente, ma il problema risulta attenuato significativamente.

D'altra parte, la sicurezza tramite segretezza implica l'adozione di alcune misure che non bloccano il vettore di attacco, ma si limitano semplicemente a nasconderlo. Ad esempio, si può decidere di spostare il server Web sulla porta 81 anziché 80 per fare in modo che possa essere trovato solo da coloro che sanno dove trovarlo. Per lo meno, questa è la teoria. In realtà, lo spostamento del server Web sulla porta 81 blocca solo alcuni attacchi e crea grandi inconvenienti per l'utente finale. È sufficiente che un intruso esperto esegua uno scanner per porta e un richiamo di banner Web per un'ampia serie di porte per individuare i server Web sulle porte non standard. Non appena ne trova uno, può inviare l'exploit contro il server dato che il vettore di attacco non è stato realmente eliminato, ma solo (temporaneamente) nascosto.

Ciò vuol dire che non si dovrebbe nemmeno tentare? Dipende. Come sempre avviene nell'area della sicurezza delle informazioni, è tutta una questione di gestione dei rischi. Per comprendere i fattori fondamentali da prendere in considerazione, verranno esaminate brevemente alcune altre misure di sicurezza tramite segretezza e ne verrà illustrata uno (la ridenominazione dell'account Administrator) in modo più dettagliato.

Valutazione della misure di sicurezza

Gli esempi di sicurezza tramite segretezza possono essere svariati. Possono essere azioni eseguite dagli amministratori di rete e di sistema oppure avviate dagli sviluppatori software. Tuttavia, hanno tutte un fattore in comune, ovvero l'intenzione di attenuare una vulnerabilità nascondendola dai potenziali autori di attacchi.

Alcune di queste procedure non potrebbero avere quanto meno un effetto benefico? È davvero giusto dire che tutta la sicurezza tramite segretezza è inefficace? Non è difficile trovare dei sostenitori di almeno alcune di queste misure. Ad esempio, in Windows® è possibile nascondere le lettere di unità in Esplora risorse. Molti ambienti, quali i laboratori informatici delle scuole, utilizzano questa tecnica per impedire agli utenti di salvare i dati sul disco rigido. Ovviamente, la maggior parte delle applicazioni potrà continuare a salvare i dati sul disco fisso; quindi, questa misura non garantisce una sicurezza massima. Tuttavia, gli istituti che l'hanno implementata dichiarano spesso che riduce la quantità di dati sul disco rigido.

Un altro tipo di procedura di scurezza tramite segretezza spesso implementata su Windows è la disattivazione delle condivisioni di rete amministrative (ad esempio, C$, Admin$ e così via). Si ritiene che in questo modo si possa impedire a un autore di un attacco di connettersi al computer in remoto. Ciò è vero, ma un autore di un attacco con un account che consente di utilizzare le condivisioni amministrative è comunque in grado di riabilitarle in remoto. Tuttavia, molte organizzazioni affermano che la disabilitazione di tali condivisioni riduce le incidenze di malware sulle loro reti.

Uno dei migliori esempi di sforzo inutile è l'impostazione "Dispositivi: consenti il disinserimento senza dover effettuare l'accesso" di Windows. Se è disabilitata, il pulsante "Disinserisci computer" viene nascosto dalla schermata di accesso. L'idea è che in questo modo un autore di un attacco non può disinserire normalmente il computer. Naturalmente, un intruso può semplicemente inserire sia il computer che l'alloggiamento di espansione in una borsa e portarseli via con sé, indipendentemente dalla disponibilità di quel pulsante. Questa possibilità non corrisponde alla sicurezza tramite segretezza neanche a livello marginale.

Un altro esempio chiaro è l'impostazione "Controller di dominio: consenti agli operatori dei server di pianificare le attività", che consente agli utenti membri del gruppo Server Operators di pianificare le attività. Questo è un problema delicato perché tali attività possono essere eseguite come processi di sistema locale e solo gli amministratori dovrebbero pianificare attività di questo tipo. Naturalmente, gli operatori dei server possono agire da amministratori attraverso una serie di vettori diversi; di conseguenza, impedire loro di pianificare le attività in questo modo non produce realmente grandi effetti.

Tuttavia, a molte organizzazioni piace questa impostazione in quanto consente ai loro sistemisti di agire da operatori dei server anziché da amministratori e, in tal modo, è meno probabile che distruggano involontariamente il server. Ciò potrebbe apportare qualche beneficio.

Allora, qual è il verdetto? Ovviamente, alcuni di questi problemi possono essere davvero complicati. Abbiamo fatto lunghi dibattiti su questi tipi di misure. Roger è fermamente convinto che tali procedure generino enormi vantaggi. Jesper, da parte sua, crede che nella maggior parte dei casi siano al massimo una perdita di tempo. È ora possibile dare uno sguardo a uno dei casi più citati (e più discussi) che riguardano la sicurezza tramite segretezza, ovvero la ridenominazione dell'account Administrator. Roger sarà a favore della misura, mentre Jesper sarà contrario. Intervengono anche gli esperti della sicurezza Aaron Margosis e Steve Riley, rispettivamente nelle intestazioni laterali "Rinominare l'account dell'amministratore" e "Non modificare le impostazioni predefinite".

Come nascondere l'account Administrator

Rinominare l'account Administrator, identificatore relativo (RID) 500, assegnandogli un nome sconosciuto a gran parte degli utenti è una procedura spesso consigliata dai professionisti della sicurezza ed è un suggerimento fornito anche in diverse guide alla protezione avanzata di Microsoft. Anche Criteri di gruppo include un'impostazione per rinominare l'account Administrator, come mostrato nella Figura 1. L'idea è che, se l'account Administrator viene rinominato, sarà più difficile per un autore di un attacco accedere come vero amministratore. Naturalmente, il problema ovvio relativo all'uso di Criteri di gruppo per questa operazione è che l'account Administrator rinominato avrà lo stesso nome su ogni computer in cui è stato applicato questo oggetto Criteri di gruppo. Ciò riduce il valore della segretezza di questa particolare misura.

Figura 1** Ridenominazione dell'account Administrator **(Fare clic sull'immagine per ingrandirla)

In questo contesto, è importante comprendere anche che qualsiasi utente con un account valido può recuperare il nome dell'account Administrator, indipendentemente dal fatto che sia stato rinominato o meno. L'account Administrator ha sempre un RID di 500. Chiedendo semplicemente il nome dell'account con RID 500, qualsiasi utente può scoprire il suo vero nome, come mostrato nella Figura 2.

Figura 2** Ricerca degli account Administrator rinominati **(Fare clic sull'immagine per ingrandirla)

Posizione di Roger

Il principale motivo che mi spinge a essere contrario alla ridenominazione dell'account Administrator è la facilità con cui è possibile convertire il nome account di una qualsiasi entità di sicurezza nel relativo identificatore di sicurezza (SID) e scoprirne il RID. E l'account Administrator ha sempre un RID di 500. Pertanto, se l'autore di un attacco può convertire senza difficoltà i nomi di account utente nelle combinazioni SID/RID e trovare RID 500, perché preoccuparsi tanto?

Ma la storia non è così semplice. Per eseguire le conversioni da nome di account utente a SID/RID, è necessario disporre dell'accesso alla porta NetBIOS o LDAP. La maggior parte dei firewall perimetrali non consentono quel tipo di accesso su Internet e, quindi, fin quando l'autore di un attacco non aggira completamente il firewall, non riuscirà ad eseguire alcuna conversione. Inoltre, le conversioni SID anonime non funzionano con Windows XP e le versioni successive di Windows, tranne che sui controller di dominio. Per i computer che si trovano più vicini al perimetro (quelli più esposti al rischio), l'autore di un attacco ha bisogno di credenziali autenticate per eseguire le conversioni da nome a SID.

Pertanto, è necessario aggirare una buona serie di reali ostacoli di difesa in profondità per iniziare un attacco di conversione. E persino se l'autore dell'attacco riesce nel suo intento, si ritrova nello stesso punto in cui sarebbe finito se il nome account non fosse stato convertito. La ridenominazione dell'account Administrator non può che migliorare la sicurezza, o quanto meno non la peggiorerà.

Un altro segreto Se l'autore di un attacco non conosce il nome account Administrator, diventa un'altra etichetta "segreta", simile a una password, che l'autore dell'attacco deve riuscire a scoprire. È vero, è molto meno probabile che i nomi di account utente siano complessi come una password amministrativa, ma rappresentano sempre un ostacolo che potenzialmente complica il problema dell'individuazione della password. Se qualcuno ha provato a individuare una password, avrà scoperto quanto è più difficile riuscire a individuare sia il nome utente che la password. Rende più gravosa un'attività già difficile di per sé e rende il tutto molto più complicato.

Contrasta il malware automatizzato e gli script kiddie Sono 22 anni che mi occupo della strategia di sicurezza di Windows e, negli ultimi 5 anni, ho fatto uso di otto honeypot Windows, esposti a Internet. In tutto questo periodo, non ho mai visto un malware automatizzato (che rappresenta la quasi totalità degli attacchi) che non utilizzasse un'etichetta di account utente che non fosse Administrator (oppure root, nel caso dei sistemi *NIX). Se si rinomina l'account Administrator, viene immediatamente stroncato tutto il malware basato sul nome Administrator. E ciò comporta una riduzione del rischio per la sicurezza.

Lo stesso vale per gli script kiddie. Tutti i manuali relativi agli attacchi Windows "kewl" che conosco menzionano le tecniche di conversione da nome a SID; tuttavia, non ne ho mai vista una messa in pratica nei miei honeypot nel caso in cui avessi avuto un account Administrator "fittizio" per sbarazzarmi di loro. I pirati informatici davvero esperti dovrebbero sempre verificare che l'account Administrator trovato sia il vero account Administrator (RID 500), ma non lo fanno. Non so perché. Penso dipenda dalla pigrizia dei pirati informatici e da una tipica indole dell'uomo.

Blocca anche la maggior parte dei pirati professionisti Questo fatto sorprende molte persone. Dopo aver utilizzato gli honeypot per alcuni anni, si riconosce subito la differenza tra gli attacchi automatizzati, gli script kiddie e i pirati professionisti. Negli ultimi cinque anni, con milioni di attacchi registrati contro i miei honeypot, non ho mai visto pirati professionisti eseguire la conversione SID in presenza dell'account Administrator fittizio.

Sono certo che alcuni di loro la eseguono, ma spero si tratti di una piccola minoranza. Perché i pirati professionisti dovrebbero fare ciò? Immagino che loro stessi non vedano alcuna ragione per provare a fare qualcosa che il resto del mondo non fa.

Semplifica gli avvisi A questo punto, coloro che sostengono la tesi opposta alla mia potrebbero affermare che se la ridenominazione dell'account Administrator si diffondesse troppo, perderebbe il suo valore come tecnica di segretezza. Il motivo è che il malware, gli script kiddie e i pirati professionisti modificherebbero le loro tattiche predefinite per ricercare altri nomi diversi da Administrator. E questo è un motivo assolutamente valido. Fortunatamente, non modifica la condizione essenziale. In primo luogo, se l'account super-privilegiato di Windows non è denominato Administrator, il pirata informatico malintenzionato deve lavorare più duramente. Questo è un puro fatto. E se il pirata informatico deve lavorare di più, è meno probabile che proverà quella via di attacco e potrà così consentire a una delle altre tecniche di difesa in profondità di individuare l'attività dannosa in modo più rapido.

E ciò introduce il mio ultimo punto a favore della ridenominazione. Se l'account Administrator non viene mai denominato Administrator ed è possibile creare un altro account con tale nome, come mostrato nella Figura 3, vuol dire che il meccanismo di avviso è davvero efficace. Se il monitoraggio degli eventi individua un tentativo di accesso che utilizza il nome predefinito, l'evento dovrà essere analizzato immediatamente.

Figura 3** I tentativi di accesso a un account fittizio denominato Administrator possono fungere da sistema di avviso tempestivo **(Fare clic sull'immagine per ingrandirla)

I nostri registri eventi sono pieni di accessi "non riusciti" che non hanno alcun significato. In genere, si tratta di un utente (o di Windows) che sta tentando di accedere utilizzando una password non valida o qualcosa di simile. Tuttavia, se l'account Administrator è denominato effettivamente Administrator, come è possibile distinguere i tentativi di accesso validi da quelli dannosi? Se si ha un account di accesso denominato Administrator e viene rilevato un tentativo di accesso con tale nome, l'intento sarà certamente dannoso. Un avviso tempestivo con un segnale acustico di bassa intensità si rivela prezioso nei sistemi di difesa di oggi.

L'opinione di Jesper

Rinominare l'account Administrator di Aaron Margosis

Jesper, in un mondo ideale, avresti sicuramente ragione. Le password sarebbero sempre sufficientemente complesse da bloccare l'individuazione delle password e gli account di amministratore locale -500 verrebbero utilizzati solo per i ripristini di emergenza. Tuttavia, nel mondo reale le cose non sono così.

Nonostante il tuo grande impegno nel descrivere l'importanza di un sistema di sicurezza efficace e gli articoli da te scritti a tale proposito ("The Great Debates: Pass Phrases vs. Passwords" parte 1, 2 e 3 agli indirizzi go.microsoft.com/fwlink/?LinkId=113157, go.microsoft.com/fwlink/?LinkId=113159 e go.microsoft.com/fwlink/?LinkId=113160), molti amministratori di sistema non hanno ancora capito come creare una password complessa.

Non è trascorso molto tempo da quando una password costituita da otto caratteri derivanti da più set di caratteri era davvero complessa; la legge di Moore rese ciò obsoleto. La formazione degli utenti (e degli amministratori di sistema) costituisce un punto debole e molto probabilmente resterà tale, almeno fino a quando l'argomento della complessità delle password non susciterà l'interesse dei canali di informazioni via cavo.

Pertanto, considerato che l'individuazione delle password del mondo reale di oggi richiede pochissimo tempo, l'aggiunta di un moltiplicatore x1000 può rivelarsi un autentico vantaggio. E contro i molti attacchi automatizzati che tentano di identificare l'account denominato Administrator, la ridenominazione rende l'account invulnerabile.

Il tempo e gli sforzi profusi per la ridenominazione dell'account Administrator in genere sono pochi; si tratta, come tu hai messo in evidenza, di impostare l'oggetto Criteri di gruppo. In effetti, la Federal Desktop Core Configuration del Governo degli Stati Uniti (csrc.nist.gov/fdcc) richiede la ridenominazione dell'account -500. La ridenominazione è solo una delle numerose impostazioni necessarie e ho sperimentato che nessuna di loro richiede un'eccessiva quantità di tempo o grande attenzione. Non ho neanche mai visto nessuno farsi cullare da un falso senso di sicurezza riguardo al suo valore; non ho mai sentito nessuno dire: "Non abbiamo bisogno della gestione delle patch visto che abbiamo rinominato i nostri account Administrator".

La ridenominazione ha valore quando l'account viene rinominato allo stesso modo nell'intera organizzazione? Non ha grande valore, ma qualche vantaggio lo apporta: in primo luogo, blocca gli attacchi automatizzati contro l'account Administrator; in secondo luogo, l'insieme dei potenziali autori di attacchi non è necessariamente un sottoinsieme di coloro che conoscono il nuovo nome. (Il rischio più grande si ha quando gli account di amministratore locale, rinominati o meno, condividono una stessa password in tutta l'organizzazione. Gestire tali account resta il problema sicuramente più grande. Per risolverlo, è possibile disabilitare l'account -500, anche se in questo modo viene bloccata un'importante via di ripristino quando gli account di dominio non possono essere utilizzati.) Intendo sottolineare anche che le nostre guide sulla sicurezza hanno sempre consigliato di rinominare gli account predefiniti e, quindi, quanto suggerito risulta già testato e supportato.

Penso che tutti sappiamo bene che le misure di segretezza non costituiscono da sole una difesa adeguata. Ma possono contribuire a potenziare altre misure di sicurezza, come illustrato chiaramente dai dati di Roger. Fin quando il costo di implementazione resta basso, le organizzazioni non dovrebbero escluderle.

Così come esistono validi motivi a favore della ridenominazione dell'account Administrator, ve ne sono altrettanti per non rinominarlo. Tuttavia, prima di passarli in rassegna, è opportuno riconoscere la validità dell'ultimo punto avanzato da Roger. Eppure, in un ambiente a elevata gestione, è opportuno valutare qualsiasi accesso con l'account Administrator dato che tale account dovrebbe essere utilizzato solo nei casi di ripristino di emergenza.

È superfluo Il rischio principale che si prevede venga attenuato dalla ridenominazione dell'account Administrator è l'individuazione della sua password in remoto. Ma in questo modo verrebbe contrastato solo un utente che non dispone di un altro account autorizzato sul computer. Un autore di attacchi di questo tipo in genere tenta di accedere all'account Administrator utilizzando una serie di password casuali. Tuttavia, riceverebbe lo stesso messaggio di errore indipendentemente dal fatto che abbia individuato il nome account errato o la password errata.

Ciò suggerisce che uno dei principali motivi a favore della ridenominazione dell'account Administrator (che fa scappare gli script kiddie) presenta dei difetti. Non scappano quando l'account Administrator viene rinominato, ma quando ha il nome originale, che loro non riescono a individuare! Gli script kiddie individueranno lo stesso insieme di password casuali e quindi passeranno alla vittima potenziale successiva.

Ciò vuol dire che fin quando la password dell'account Administrator è sufficientemente complessa per respingere gli attacchi, la ridenominazione non fornisce valore aggiuntivo. Supponiamo di avere una password di 15 caratteri per l'account Administrator, composta di lettere minuscole e maiuscole, numeri e simboli. Individuare tale password sulla rete richiederà circa 591.310.404.907 anni. Si tratta di un numero di anni di 43 volte superiore agli anni di vita dell'universo.

A questo punto, supponiamo di rinominare l'account Administrator e di renderlo uno dei 1.000 valori possibili. In questo caso, gli anni necessari per individuare la password saranno 591.310.404.906.787, ovvero un periodo di tempo di 43.161 volte superiore agli anni di vita dell'universo. Siamo più sicuri così? Sì, lo siamo. Siamo riusciti a fare in modo che fosse meno probabile per l'autore dell'attacco individuare la nostra password? Bene, in entrambi i casi la probabilità è infinitamente bassa. In altre parole, nel mondo reale, riusciamo a essere realmente sicuri solo con il nome account Administrator originale. Solo perché rinominare l'account uccide il malware che tenta di utilizzarlo non significa che il malware sarebbe riuscito nella sua impresa se non avessimo rinominato l'account. In effetti, se si utilizza una password complessa, come si dovrebbe fare, si potrà essere quasi certi che il malware non riesca a individuarla, indipendentemente dal nome dell'account.

Molte guide sulla sicurezza suggeriscono di rinominare l'account Administrator; ma ciò non ne fa una misura di sicurezza preziosa o valida. Evita semplicemente di dover prendere una decisione di gestione dei rischi efficace. Le guide sulla sicurezza hanno spesso richiesto l'uso di impostazioni inutili e, in molti casi, anche inesistenti. Alla fine, per ottenere successi nel campo della sicurezza, è necessario andare oltre i requisiti, analizzare effettivamente i problemi e capire se vale la pena o no tentare di mitigarli. A questo punto, è importante ricordare un punto critico, ovvero che non è necessario modificare una funzione per il semplice fatto che questa rappresenta l'obiettivo dell'autore di un attacco. È necessario modificare una funzione solo se si prevede che un attacco possa riuscire senza tale modifica.

Se prendiamo in considerazione una password complessa, la probabilità di successo è praticamente nulla sia che l'account venga rinominato o meno. Pertanto, fin quando si utilizza una password complessa, non si ha praticamente alcun motivo per rinominare l'account. Inoltre, se si agisce, come faccio io, in base al principio che un computer possa essere più stabile con il minor numero di modifiche possibili (questo è un fatto comprovato), esistono tutte le ragioni per non rinominare l'account Administrator.

Attenzione alle attenuazioni di valore minimo Un problema inerente le attenuazioni della sicurezza tramite segretezza di valore minimo è il rischio che l'attenzione delle organizzazioni venga distolta dalle attenuazioni di maggiore valore. Ad esempio, il tempo e gli sforzi profusi per rinominare l'account Administrator non possono essere utilizzati per qualcos'altro. Se qualcos'altro fornisce maggiore valore rispetto alla ridenominazione degli account Administrator, l'organizzazione ha perso un'opportunità. Questo fatto potrebbe non sembrare un costo reale, ma basta immaginare di dover rinominare 50.000 account Administrator e si inizierà ad avere un'idea della situazione.

Un ulteriore inconveniente è la reale possibilità che, una volta implementata l'attenuazione di valore minimo, i responsabili dell'organizzazione inizino a rilassarsi troppo. I responsabili potrebbero non comprendere il valore minimo fornito dalle attenuazioni della sicurezza tramite segretezza e potrebbero non prendere ulteriori misure di sicurezza. Ciò può comportare un rischio significativo per l'organizzazione, anche se tale rischio può essere evitato laddove i responsabili impieghino il tempo e gli sforzi necessari per capire il valore delle attenuazioni che vengono implementate.

Gestione onerosa Infine, a seconda di come viene implementata, l'attenuazione può comportare una gestione troppo onerosa. Se si imposta semplicemente un oggetto Criteri di gruppo per rinominare l'account Administrator, il costo risulta molto basso. Tutti conosceranno il nome e il costo della distribuzione è praticamente nullo. Tuttavia, anche il valore fornito risulta essere minimo in quanto, come è già stato spiegato, tutti coloro che hanno un account conosceranno il nome. Quindi, per ottenere più valore da questa attenuazione, è necessario utilizzare nomi diversi su host diversi, cosa che rende più onerosa la gestione del sistema.

Sarebbe molto meglio utilizzare uno strumento come passgen (protectyourwindowsnetwork.com/tools.htm) per impostare una password completamente casuale di 100 caratteri per tutti gli account Administrator sulla rete e utilizzare account diversi per la gestione giornaliera. Considerato che l'account Administrator è specifico per i ripristini di emergenza (tranne che su Windows Small Business Server 2003), non dovrebbe avere alcun impatto sul sistema di gestione della rete. Inoltre, l'autore dell'attacco potrebbe riuscire più facilmente a trovare un ago nel pagliaio che a individuare correttamente la password di uno degli account Administrator. Concentrandosi invece su password complesse e univoche, gli script kiddie possono riuscire a individuare tutto ciò che vogliono.

L'importanza della gestione dei rischi

In pratica, qualsiasi misura di sicurezza tramite segretezza può essere analizzata come è stato fatto qui. Esistono i vantaggi e gli svantaggi in qualsiasi schema e non è detto che un approccio adatto per una organizzazione sia altrettanto adatto per un'altra organizzazione. Alla fine, il tutto diventa un problema di gestione dei rischi. I rischi prevalgono sui costi di implementazione della soluzione? Qualsiasi decisione presa per la protezione del patrimonio di informazioni deve essere una decisione di gestione dei rischi consapevole e raramente si tratta di una decisione netta.

In realtà, alcune decisioni sono già state prese al posto dell'utente. Ad esempio, anche se è possibile scegliere di non crittografare le informazioni delle carte di credito o archiviare i codici di verifica delle carte, entrambe le azioni porteranno all'impossibilità di accettare le carte di credito come forma di pagamento. Il possibile impatto negativo che la decisione provoca sull'azienda è che non si ha una vera possibilità di scelta. In altre parole, anche se riguarda la gestione dei rischi, si tratta di una decisione abbastanza facile da prendere.

Analogamente, è anche vero che nessuno sano di mente collegherebbe una rete wireless aperta al back-end della rete interna in un archivio fisico. Tuttavia, ciò non vuol dire che non si tratti di una decisione di gestione dei rischi. In realtà è proprio una decisione del genere. Si può decidere di fare ciò, e se lo si fa, si deve essere in grado anche di sopportare le eventuali conseguenze (che si spera non arrivino mai).

L'azione fondamentale da intraprendere a questo punto è valutare chiaramente il problema da affrontare, le soluzioni proposte per il problema e i vantaggi e gli svantaggi di ciascuna di esse. Fatto ciò, si disporrà di tute le informazioni necessarie per prendere una decisione di gestione dei rischi consapevole. Senza tale informazioni, le decisioni vengono prese in base a mere idee e raramente si rivelano soluzioni efficaci.

Jesper M. Johansson, Software Architect, si occupa del software di sicurezza 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 MVP nella sicurezza aziendale. L'ultimo libro di Jesper è Windows Server 2008 Security Resource Kit.

Roger Grimes (CPA, CISSP, MCSE: Security), Senior Security Consultant per il team ACE di Microsoft, ha scritto, o ha collaborato alla stesura, di otto libri sulla sicurezza dei computer ed è autore di 200 articoli di giornale. Spesso partecipa come relatore a conferenze sulla sicurezza e scrive articoli sulla sicurezza su InfoWorld.

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