Quali sono i migliori motivi che hai sentito per non aver implementato la sicurezza?

Ho scoperto una vulnerabilità nell'infrastruttura di un cliente che potrebbe causare un'interruzione oltre alla perdita di dati. Quando si è premuto per un calcolo del costo una tantum, il cliente ha convenuto che potrebbe costare fino a £ 1 milione ogni volta, quindi ho proposto un piano di riparazione che sarebbe costato meno di £ 100k.

L'hanno rifiutato, dato che 1 milione di sterline era inferiore alla soglia di rischio inferiore - avevano maggiori rischi per impostare le proprie squadre.

Ma una decisione di rischio valida da parte dell'azienda è una risposta corretta per tornare a un team di sicurezza con, quindi andava bene.

Di gran lunga la scusa più comune che ottengo finora è la vecchiaia "Ci prenderemo cura di esso, per ora basta farlo funzionare".

Diversi motivi per questa mentalità includono:

• Progetto urgente: un prototipo appena lucidato è tutto ciò di cui hanno bisogno per far funzionare le operazioni, il resto è percepito come "non generatrice di entrate" e quindi occupa un posto in secondo piano. Il trambusto del posto di lavoro significa che questo lavoro cruciale viene messo sempre più in basso fino a quando non viene semplicemente dimenticato.
• Fondi bassi: come sopra, il tempo è denaro e l'azienda potrebbe essere a corto di denaro per pagare gli sviluppatori.
• Ignoranza: mi sorprende comunque imbattersi in sviluppatori PHP che sono nel settore da anni che non conoscono concetti come attacchi CSRF, password, istruzioni preparate e algoritmi di hashing oltre MD5 . Non è che sono pigri, in realtà sono piuttosto brillanti. Semplicemente non lo sanno, e non è fino a quando non vieni superato che non ne hai mai sentito il bisogno da solo.
• Arroganza: la maggior parte delle persone tende anche a prendere "Sono solo una piccola azienda, perché qualcuno ci dovrebbe hackerare?" mentalità, credendo di essere troppo piccoli per meritare il tempo di un hacker. Questa percezione degli hacker come questo "potente e onnisciente del calcolo" porta le persone a credere che siano troppo occupate a hackerare come Sony e la Casa Bianca per essere disturbati da Bob's Discount Car Parts. La verità è che le parti di auto scontate di Bob potrebbero essere un colpo da abbattere, potrebbero cadere in test di penetrazione automatizzati o persino in un concorrente rouge (credetemi, l'ho visto accadere con un'attività simile!). Dietro le quinte ci sono tutti i tipi di golosità: numeri CC, indirizzi e-mail, informazioni personali, ordini di prodotti gratuiti ...
• Mancanza di audit: la maggior parte degli sviluppatori (anche me stesso!) pensa che sono hotshots alla sicurezza, ma semplicemente non possiamo dirlo finché non cade. Un modo per mitigare questo è attraverso controlli di sicurezza da parte di contraenti indipendenti, ma sono costosi, dispendiosi in termini di tempo, "inutili" ... queste persone sanno come pensare come hacker, mentre il tuo compito è pensare come uno sviluppatore di software.
• Pride / Ego dello sviluppatore: non ridere, l'ho visto accadere. Alcuni sviluppatori sono così alti e potenti su se stessi che si rifiutano di implementare la sicurezza perché o possono semplicemente batterli con altri mezzi ("Amico, andrò a casa loro e li distruggerò se mi hackeranno"), oppure rifiutano avere qualcuno che arriva e potenzialmente dire loro che sono qualcosa di meno del dono di Dio al mondo dell'IT (collegato a "Mancanza di audit" sopra).

I want to hear the specific reasons you have heard for a user, a manager, or a company user for not wanting to implement a more secure policy/procedure/product.

Questo è quello che ottengo sempre:

We've never had a problem so we don't need it.

Ho difficoltà a fornire un argomento contro questo, per quanto possa sembrare ignorante.

Credo che l'unica cosa che puoi fare è dimostrare che il sistema è vulnerabile, il che può essere difficile. A volte, però, hanno ragione: il sistema è relativamente sicuro e non sono necessarie misure aggiuntive o, cosa più importante (per loro), vale il costo dell'implementazione. In tal caso, dovresti dimostrare che vale il loro dollaro, che ancora una volta può essere difficile.

Questa è la ragione "migliore"? Forse no, ma è certamente comune.

Consente di prendere l'esempio specifico di password. Le migliori pratiche di sicurezza ci farebbero utilizzare password di lunghezza minima, contenere lettere, numeri, caratteri speciali ecc. E non essere facili da indovinare. Inoltre dovrebbero essere unici per un particolare sito e cambia ogni 30 o 90 giorni. Infine, se la password è mai divulgata o compromessa, deve essere immediatamente comunicata al responsabile della sicurezza e la password cambiata immediatamente. Oh e non scrivere mai la tua password.

Questo è un ottimo consiglio da un punto di vista della sicurezza, ma praticamente impraticabile nel mondo reale. Riesci a ricordare che molte password? Ne ho letteralmente 100.

Inoltre, hai mai avuto la situazione in cui eri distratto o in fretta e hai digitato la password per il sito X nella casella di accesso per il sito web Y? Scommetto che se le persone fossero oneste, scopriresti che succede sempre. Hai cambiato immediatamente le password su entrambi i siti?

Il sistema oi dati potrebbero non avere molto valore e il costo di una violazione potrebbe essere abbastanza basso da giustificare una relativa mancanza di sicurezza. Ad esempio, non utilizzo sempre password complesse per i forum basati sul Web, poiché il sito non memorizza il mio nome o alcuna informazione personale e non ho alcuna reputazione di offuscare.

La maggior parte delle persone resiste al cambiamento di tutti i tipi e di conseguenza presenterà innumerevoli errori logici per combattere l'implementazione di qualcosa di nuovo.

• quell'auditor / ispettore / certificatore è un nitpicker
• non è successo nulla finora
• chiedi a chiunque, questo è esagerato
• ...

Concentrarsi su specifiche razionalizzazioni (il focus della tua domanda) ha mancato il vero problema - la naturale tendenza ad evitare il cambiamento. Nel respingere gli errori logici si tratta di emozioni e sistemi di credenze. Pertanto, l'approccio migliore non è tentare di ragionare con le persone che presentano razionalizzazioni logiche contro la proposta, ma piuttosto di vendere l'idea sui suoi benefici.

Come in ogni buona situazione di vendita, dovresti presentare qualcosa di valore a una persona che ne ha bisogno. Quindi, considera chi trae direttamente maggior beneficio dal nuovo paradigma di sicurezza e vende prima quella persona. Probabilmente ci sono alcune persone che non stanno dormendo così bene a causa del problema che stai cercando di affrontare. Accompagnali e lasciali raggiungere agli altri con una proposta basata su un valore operativo convalidato. Se non riesci a venderlo a chi è alle prese con le conseguenze di una vulnerabilità sfruttata, l'organizzazione ha parlato ed è un no.

1 / Visto troppo restrittivo: Nelle applicazioni web, la sicurezza può essere spesso percepita come una limitazione dell'interoperabilità. Ciò si verifica spesso nei sistemi in cui plug-in / componenti aggiuntivi di terze parti possono interagire con i sistemi di gestione dei contenuti (osCommerce, Joomla e Wordpress per nominarne alcuni). Con ogni scorciatoia hanno pagato molto, e Joomla e Wordpress continuano a pagare il prezzo.

2 / Una buona sicurezza può uscire dalla finestra quando il codice è memorizzato in directory sicure. Ad esempio, a seconda dell'autenticazione base di htaccess per proteggere le directory, gli sviluppatori potrebbero abbandonare i loro standard nel campo della sicurezza. Questo è anche lo stesso quando i sistemi sono sviluppati per funzionare in una rete locale, anche lì è una falsa credenza che la sicurezza non sia così importante, quindi gli standard possono essere più lassisti.