L'* oscurità * tutta * è oggetto di discussione? [duplicare]

Question

L'* oscurità * tutta * è oggetto di discussione? [duplicare]

#1 da (3 voti)
#2 da (0 voti)

1

Sono un principiante e sto leggendo sugli atteggiamenti verso la "sicurezza dall'oscurità". Capisco che ci sono vari gradi di veemenza nell'opposizione all'uso dell'oscurità, ma sto cercando di chiarire da solo quanto sia assoluto.

Capisco che fare affidamento esclusivamente sull'oscurità sia piuttosto unanimemente disapprovato. Sto solo discutendo di tipi di oscurità che potrebbero essere aggiunti a strategie di difesa approfondite.

Ad esempio, cose come la configurazione degli host per non rispondere alle richieste echo ICMP (nei casi in cui ciò ha senso) o disinfettare le informazioni del banner per oscurare la topologia o il software della mia rete sembrano pratiche senza costi che lo rendono un fare di più per un attaccante non determinato a bersagliare la mia rete.

C'è qualche linea di delineazione alla quale tutti sono d'accordo sul fatto che l'oscurità è una buona idea, o c'è qualcosa che mi manca in cui anche questi tipi di oscurità sarebbero scoraggiati? C'è forse un termine o una categoria diversa per questi tipi di oscurità?

obscurity

posta Y e z 28.01.2018 - 22:51

fonte

2 risposte

Leggi altre domande sui tag obscurity

Dovremmo usare il certificato x 509 V1 per una nuova CA radice? La registrazione di audit relativa a SELinux? [chiuso]

score 3 · Answer 1

La cosa fondamentale da capire è principio di Kerckhoff ; il nemico conosce il sistema. Ciò significa che devi lavorare sulla base del fatto che l'oscurità ha fallito e che l'hacker sa tutto su come il tuo sistema dovrebbe funzionare. Quindi, come hai concluso, non si deve fare affidamento sull'oscurità.

Tuttavia, non hai alcun obbligo di aiuto che il nemico conosca il tuo sistema. Così sicuro, vale la pena di fare i metodi a basso costo che citi. Non stai facendo affidamento su di loro, ma non fanno male e potrebbero aiutare.

score 0 · Answer 2

Il principio non ti è chiaro, perché non lo hai definito.

Una buona definizione è NIST, in una pubblicazione leggermente obsoleta però: < em> "La sicurezza del sistema non deve dipendere dalla segretezza dell'implementazione o dai suoi componenti" . Due punti importanti qui sono "dipendono" e "implementazione" . Prendi il tuo esempio: se la sicurezza di una rete dipende in qualche modo su tutta la topologia della rete che è top secret, è un cattivo progetto. Ma finché ci sono altre dipendenze (firewall, gestione patch, crittografia e così via), e la segretezza della topologia non è un requisito ma semplicemente un suggerimento per forza migliore, questo va bene.

Inoltre, anche questa regola può avere eccezioni. Un esempio che posso facilmente ottenere sono le sfide CAPTCHA che al giorno d'oggi sono al sicuro solo fino a quando l'autore dell'attacco non ha accesso al codice sorgente di un implementazione del generatore di challenge . Ovviamente sei libero di definirlo un cattivo design, tuttavia, al momento, non abbiamo una soluzione migliore di CAPTCHA per una lunga lista di problemi. Ciò non significa, tuttavia, che si possa semplicemente ignorare il principio; qualsiasi discrepanza con esso deve essere completamente giustificata.