Il ruolo valido dell'oscurità

Domanda interessante. Il mio pensiero su questo è che informazioni oscure sono utili alla sicurezza in molti casi in quanto possono costringere un utente malintenzionato a generare più "rumore" che può essere rilevato.

Laddove l'oscurità è una "cosa negativa" può essere il punto in cui il difensore fa affidamento su quell'oscurità come controllo critico, e senza quell'oscurità, il controllo fallisce.

Quindi, oltre a quello che hai fornito sopra, un uso efficace dell'oscurità potrebbe rimuovere il nome del software e le informazioni sulla versione dai servizi di connessione a Internet. I vantaggi di questo sono:

• Se un utente malintenzionato vuole scoprire se una versione vulnerabile del servizio è in uso, dovrà effettuare più query (ad esempio, cercare i file predefiniti o magari testare le risposte temporali ad alcune query). È più probabile che questo traffico si visualizzi nei log IDS rispetto a una singola richiesta che ha restituito la versione. Inoltre, i protocolli di impronte digitali non sono ben sviluppati per tutti i servizi, quindi potrebbe rallentare notevolmente l'aggressore
• L'altro vantaggio è che il numero di versione non verrà indicizzato da servizi come Shodan . Questo può essere rilevante quando viene eseguito un attacco automatico per tutte le istanze di una particolare versione di un servizio (ad esempio, se è stato scoperto un 0 giorni per quella versione). Nascondendolo dal banner, può effettivamente impedire a una determinata istanza del servizio di cadere preda di quell'attacco.

Detto questo, non dovrebbe mai essere l'unica linea di difesa. Nell'esempio precedente, il servizio dovrebbe essere ancora aggiornato e corretto per mantenere la sua sicurezza.

Dove penso che l'oscurità fallisca è dove è invocato. Cose come password hard-coded che non vengono modificate, che nascondono segreti con "crittografia nazionale", o basano una decisione sul rischio se applicare o meno un servizio all'idea che nessuno lo attaccherà. Quindi il tipo di idea che nessuno troverà / saprà / attaccherà in genere fallirà, probabilmente perché i difensori stanno limitando il loro concetto di chi potrebbe essere un aggressore valido. Dice tutto molto bene che un attaccante esterno non motivato non può prendersi il tempo per svelare un controllo oscuro, ma se l'aggressore risulta essere un ex dipendente scontento, quella password hard-coded potrebbe causare alcuni seri problemi.

Hai sbagliato la saggezza convenzionale. La saggezza convenzionale non dice che l'oscurità è cattiva. Dice che affidarsi alla sicurezza attraverso l'oscurità è negativo: di solito porta a sistemi fragili o insicuri. Prendi nota della differenza. L'oscurità potrebbe aggiungere un po 'di sicurezza aggiuntiva, ma non dovresti fare affidamento su di essa, e non dovrebbe essere la tua difesa primaria. Dovresti essere preparato affinché l'oscurità possa essere trafitta e confida di avere difese adeguate per gestire quel caso.

Un concetto importante qui è il principio di Kerckhoff . Già nel 1800, Kerckhoff aveva già espresso le ragioni per cui dovremmo essere scettici sulla sicurezza attraverso l'oscurità e su come tracciare una linea tra usi appropriati e inappropriati della crittografia. L' articolo di Wikipedia sul principio di Kerckhoff è molto buono e un ottimo punto di partenza.

Ecco alcuni punti su cui riflettere:

• Come dice l'articolo di Wikipedia, "quanto meno e più semplici sono i segreti che è necessario mantenere per garantire la sicurezza del sistema, tanto più facile è mantenere la sicurezza del sistema". Pertanto, a parità di tutti gli altri, meno cose dobbiamo mantenere segrete, più facile sarà per proteggere il sistema.

• In generale, ci sono poche speranze di mantenere il design o gli algoritmi utilizzati nel sistema segreto dagli aggressori dedicati. Pertanto, qualsiasi sistema la cui sicurezza si basi sulla segretezza del suo design è, a lungo termine, condannato - e nel breve periodo, sta assumendo un rischio non necessario.

• Il peggior tipo di segreto è uno che non può essere modificato se è compromesso o trapelato a parti non autorizzate. Il miglior tipo di segreto è quello che può essere facilmente cambiato se si sospetta che sia trapelato. Costruire un sistema in cui la sicurezza si basa sul mantenere segreto il design del sistema è uno dei peggiori usi possibili della segretezza, perché una volta implementato il sistema, se si verificano perdite segrete, è molto difficile cambiare (è necessario sostituire tutte le copie distribuite del sistema con un'implementazione totalmente nuova, che di solito è estremamente costosa). Costruire un sistema in cui la sicurezza si basa su ogni utente per selezionare una passphrase casuale è meglio, perché se la password è trapelata (ad esempio, l'utente digita la password in un sito di phishing e poi dice "Oops!"), È relativamente facile cambiare la password dell'utente senza disturbare gli altri.

• Oppure, come scrisse Kerckhoff nel 1800, il design di un criptosistema non deve essere richiesto per essere segreto, e deve essere in grado di cadere nelle mani del nemico senza inconvenienti. Questa è fondamentalmente una riformulazione del mio punto precedente, in un dominio particolare.

Per questi motivi, i sistemi ben progettati in genere cercano di minimizzare la misura in cui si affidano ai segreti; e quando i segreti sono necessari, di solito li progettano per concentrare tutta la segretezza necessaria in una chiave crittografica o passphrase che può essere facilmente modificata se compromessa.

È la sicurezza attraverso l'oscurità che è la parte peggiore. L'oscurità può aumentare la sicurezza, ma non è possibile dipendere solo dall'oscurità per fornire sicurezza.

I mantra assoluti sono sempre dannosi. ;) È essenziale comprendere il ragionamento dietro il mantra e il tradeoff coinvolto.

Ad esempio, nascondere una chiave fuori casa quando si sta andando a correre è la sicurezza attraverso l'oscurità, ma potrebbe essere un rischio accettabile se si torna in 30 minuti (e non si tratta di un obiettivo ad alto rischio ?).

Lo stesso si può dire per "non usare mai goto". A volte goto è il modo migliore per scrivere codice chiaro in determinate situazioni. Come professionista esperto, è necessario comprendere le ragioni delle linee guida, in modo da poter comprendere i compromessi.