Domanda:
Una "misura di sicurezza" che non fornisce un vantaggio per la sicurezza è effettivamente dannosa?
Damovisa
2010-11-19 04:00:04 UTC
view on stackexchange narkive permalink

Se viene implementata una misura di sicurezza che non fornisce alcun vantaggio di sicurezza aggiuntivo, può essere considerata dannosa?

Ad esempio, si consideri una pagina di accesso in cui all'utente viene chiesto di inserire il proprio nome utente, e poi la loro password due volte (per "motivi di sicurezza").

Ci sono due argomenti qui:

  1. Se dà tranquillità all'utente e non lo è diminuendo la sicurezza, qual è il danno?
  2. Se non ci sono vantaggi effettivi, l'ulteriore "tranquillità" data all'utente è dannosa perché dà loro un maggiore senso di sicurezza di quanto non lo sia valido.

Ho spesso sostenuto il secondo punto, ma la prima opinione sembra essere più comune, in particolare nella comunità imprenditoriale.

Cosa ne pensi? Le misure di sicurezza ridondanti dovrebbero essere rimosse attivamente o non c'è davvero alcun danno nel mantenerle?

Nota: l'esempio non è un caso reale

Penso tu abbia ragione. Due rischi: 1) può dare agli utenti un falso senso di sicurezza, inducendoli a comportarsi in modo meno cauto / sicuro altrove, portando a una perdita complessiva di sicurezza; 2) può infastidire gli utenti, incentivandoli a bypassare deliberatamente il sistema di sicurezza (ad esempio, scegliendo una password più corta e debole, in modo che non debbano digitare così tanto) o diminuendo la loro disponibilità a rispettare le misure di sicurezza.
Sette risposte:
Peter Stone
2010-11-19 04:27:09 UTC
view on stackexchange narkive permalink

Qualsiasi funzionalità che "non fornisce alcun vantaggio [...] aggiuntivo" dovrebbe essere rimossa, relativa alla sicurezza o altro. Oltre ad aumentare la complessità e l'attrito, può introdurre una superficie di attacco aggiuntiva e finire per renderti meno sicuro.

Sono sicuro che sottrae risorse anche a funzionalità / progetti legittimi che fornirebbero un vantaggio.
Rory Alsop
2010-12-03 01:16:35 UTC
view on stackexchange narkive permalink

Sono d'accordo con i commenti di cui sopra, oltre a una questione aziendale pertinente: le misure di sicurezza costano denaro (nello stesso modo in cui le funzionalità del software costano denaro) e un'azienda ha un budget limitato per la sicurezza, di solito non abbastanza. I due lati negativi dei controlli inefficaci sono che un po 'di budget viene sprecato e che l'impressione che il consiglio di amministrazione avrà del proprio team di sicurezza è più scarsa o meno efficace di quanto dovrebbe essere.

Morten
2010-11-19 04:20:47 UTC
view on stackexchange narkive permalink

No, è lo stesso con le funzionalità del software.

Se produci qualcosa che non aggiunge valore, è uno spreco. Quando si tratta di sicurezza ridondante, lo spreco è ancora maggiore poiché ogni secondo sprecato in un sistema IT viene moltiplicato per ogni utente. Ciò presuppone che la "funzione" di sicurezza aggiuntiva richieda tempo all'utente.

Anche se non influisce direttamente sugli utenti, come la doppia crittografia con chifers non aggiunge ulteriore sicurezza (come Ceasar per esempio) quindi ridurrà comunque le prestazioni.

Nell'esempio che ho fornito, il tempo supplementare è trascurabile ʻif (primo == secondo) ... `. Lo considereresti ancora uno spreco se non degradasse le prestazioni?
E più precisamente, è * dannoso * oltre che dispendioso?
Logica aggiuntiva aggiuntiva che non aumenta la sicurezza, aumenta la quantità di codice da mantenere e la quantità di sicurezza del codice e il problema relativo alle funzionalità possono essere nascosti. quindi sì, "funzionalità" extra è direttamente dannoso per la sicurezza.
Phoenician-Eagle
2010-11-19 04:50:42 UTC
view on stackexchange narkive permalink

di solito, come ha detto Peter Stone, aumenta la superficie di attacco. bene il punto è che poiché non viene utilizzato, verrà dimenticato e quindi non rimarrà considerato per nessuna patch in caso di necessità. pertanto, l'attaccante può concentrarsi su queste funzionalità di sicurezza o funzionalità prive di patch per eseguire l'attacco, che può ad esempio essere l'escalation di privilegi ...

Thomas Pornin
2011-01-14 21:50:31 UTC
view on stackexchange narkive permalink

Di solito, quando una pagina richiede che la stessa password sia inserita due volte, è per rilevare errori di battitura - che sono più comuni con le password a causa della "voce cieca". In particolare con le pagine di registrazione, perché una password inserita erroneamente implica una successiva procedura di recupero, procedura che ha necessariamente un costo diverso da zero. Affermare che la doppia iscrizione è per "motivi di sicurezza" è solo un modo per far rispettare l'utente; gli utenti sono abituati a superare strani ostacoli purché si tratti di "una questione di sicurezza". Ma non si tratta veramente di sicurezza.

Più in generale, c'è un delicato equilibrio tra alcune caratteristiche desiderabili:

  1. L'utente accetta di rispettare le caratteristiche di sicurezza.
  2. L'utente acquisirà fiducia nel fatto che il sistema sia protetto.
  3. Il sistema sarà protetto.
  4. L'utente dovrebbe essere in grado di comportarsi in modo non ossessionato dalla sicurezza.

Il punto 4 è importante se l'utente è un potenziale cliente e vogliamo che finalmente inserisca il numero della sua carta di credito e acquisti qualcosa. Il punto 3, ovviamente, è importante se vuoi evitare guai. Il punto 2 riguarda la "tranquillità". Il punto 1 significa che l'utente può diventare il nemico abbastanza velocemente.

Queste caratteristiche non sono indipendenti l'una dall'altra. Ad esempio, se si desidera un sistema sicuro (punto 3) e quindi si richiede agli utenti di avere password lunghe (ad esempio più di 12 caratteri), gli utenti si ribelleranno e inizieranno a selezionare password lunghe ma deboli o le annoteranno su carta note (guasto al punto 1, che implica un guasto al punto 3). Parlare troppo di sicurezza potrebbe rendere alcuni utenti ossessionati al riguardo. Costruire la fiducia dell'utente è anche una parte (ma solo una parte) per rendere l'utente non paranoico.

Si può fare un'analogia con la sicurezza aeroportuale. La sicurezza del sistema (punto 3) si ottiene attraverso varie misure nascoste, la maggior parte delle quali è la scansione a raggi X del bagaglio e un enorme lavoro di intelligence della polizia sui viaggiatori. La fiducia degli utenti (punto 2) è costruita attraverso una visualizzazione di funzioni di sicurezza visibili , come scanner per tutto il corpo e orde di guardie dall'aspetto meschino. In questo caso, la fiducia degli utenti consiste nel rendere le persone consapevoli che il potere che è sta facendo qualcosa per i problemi di sicurezza di cui si preoccupa; tuttavia, non è realmente necessario che le funzionalità di sicurezza che gli utenti vedono siano anche le funzionalità di sicurezza che effettivamente migliorano la sicurezza. La conformità all'uso (punto 1) è imposta da quei cartelli spaventosi che ti avvertono, come viaggiatori in aereo, che "fare dichiarazioni sulla sicurezza" può farti precipitare in guai seri, tra cui perdere l'aereo, pagare una grossa multa o possibilmente finire in prigione . In una certa misura, i viaggiatori vengono resi non paranoici (punto 4) esponendoli ai dipendenti aeroportuali che sembrano tutti completamente ossessionati dalla sicurezza; il viaggiatore reagisce istintivamente assumendo la posizione opposta. Tutto questo, ovviamente, è costoso (uno scanner completo del corpo non è il pezzo di hardware più economico di sempre e le guardie ricevono regolarmente lo stipendio).

Quindi non c'è nulla di male nell'avere una sicurezza caratteristica che è inutile per quanto riguarda la sicurezza effettiva, purché fornisca qualche guadagno da qualche parte, ad es nel costruire la fiducia degli utenti. Tuttavia , potrebbero esserci dei costi e, poiché gli esseri umani non sono macchine, valutare tale costo può rivelarsi difficile.

Oy. Stavo * andando * a fare +1 su di te un sacco, ** fino a ** non sono arrivato alla parte sulla sicurezza dell'aeroporto. * Completamente * in disaccordo con te su questo - ma poi, dal momento che la domanda * è * contrassegnata con "[security-theater]", non dovrei lamentarmi, giusto?
user185
2010-11-19 04:26:15 UTC
view on stackexchange narkive permalink

Può o meno causare direttamente una riduzione della sicurezza del sistema, è necessario esaminare il modello di minaccia per deciderlo. Potrebbe infastidire i tuoi utenti e devi indagare. Certamente ti costa denaro da implementare e forse da mantenere, e questa è sicuramente una risorsa sprecata.

Tuttavia, può anche essere che questa (errata) caratteristica introduca altre vulnerabilità, essendo mal codificata o configurata male. Probabilmente dovresti rimuoverlo.

Woot4Moo
2010-11-19 04:20:25 UTC
view on stackexchange narkive permalink

Direi che è dannoso. Fornire una copertura di sicurezza a un utente finale è completamente inutile. Ad esempio, se devo inserire la mia password due volte per accedere allo stesso sito, diventerò sospettoso sul motivo per cui il sito necessita delle mie informazioni due volte. Il che mi porta a pensare che qualcuno abbia fatto qualcosa al sito in questione. In realtà, sta diminuendo la sicurezza in quanto fornisce un vettore di attacco aggiuntivo per una persona maligna.

L'esempio che stai usando non è molto buono. Molti siti impongono una nuova autenticazione di un utente durante l'elaborazione di transazioni sensibili (ad esempio, un trasferimento finanziario che è al di fuori del modello di transazioni finanziarie che sono state eseguite in passato). A parte l'esempio specifico, concordo con il resto del tuo commento.
@ygjb "_Molti siti impongono una nuova autenticazione di un utente durante l'elaborazione di transazioni sensibili (ad esempio, un trasferimento finanziario che è al di fuori del modello di transazioni finanziarie che sono state eseguite in passato) ._" Quando è utile?
La teoria è che forzando un reauth si riduce la probabilità che una transazione fuori schema sia il risultato di un dirottamento di sessione o di un attacco replay. Inoltre, ci scusiamo per il ritardo nella risposta o_O


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 2.0 con cui è distribuito.
Loading...