¿Cuáles son las mejores razones que ha escuchado para no implementar la seguridad?

Descubrí una vulnerabilidad en la infraestructura de un cliente que podría causar una interrupción más la pérdida de datos. Cuando se presionó para un cálculo de costo único, el cliente acordó que podría costarle más de £ 1 millón cada vez, por lo que propuse un plan de remediación que costaría menos de £ 100k.

Lo rechazaron, ya que 1 millón de libras se encontraba por debajo de su umbral de riesgo más bajo: tenían mayores riesgos para establecer sus equipos.

Pero una decisión de riesgo válida por parte de la empresa es una respuesta correcta para volver a un equipo de seguridad, por lo que esto estuvo bien.

De lejos, la excusa más común que tengo hasta ahora es la de la antigüedad "Vamos a llegar a eso, por ahora solo lo haremos funcionar".

Varias razones para esta mentalidad incluyen:

• Proyecto urgente: todo lo que necesitan para hacer funcionar las operaciones es un prototipo apenas pulido, el resto se percibe como 'no genera ingresos' y, por lo tanto, queda atrás. El ajetreo y el bullicio del lugar de trabajo significa que este trabajo crucial se pone cada vez más en la cola hasta que simplemente se olvida.
• Fondos bajos: similar a lo anterior, el tiempo es dinero y la empresa puede tener poco efectivo para pagar a los desarrolladores.
• Ignorancia: Todavía me asombra encontrarme con los desarrolladores de PHP que han estado en la industria durante años que no conocen conceptos como los ataques CSRF, las sales de contraseña, las declaraciones preparadas y los algoritmos de hashing más allá de MD5. . No es que sean perezosos, en realidad son bastante brillantes. Simplemente no lo saben, y no es hasta que no estás seguro que te encuentras con la necesidad de hacerlo por tu cuenta.
• Arrogancia: la mayoría de las personas también tienden a tomar un "Soy solo una pequeña empresa, ¿por qué alguien nos piratea?" mentalidad, creyendo que son demasiado pequeños para valer el tiempo de un hacker. Esta percepción de los hackers como este 'todo poderoso, todo conocedor de la informática' lleva a las personas a creer que están demasiado ocupadas pirateando a Sony y la Casa Blanca como para que se molesten con las piezas de automóviles con descuento de Bob. La verdad es que Bob's Discount Car Parts podría ser un pellizco para derribar, podría caer en pruebas de penetración automatizadas o incluso en un competidor de color rojo (confía en mí, ¡lo he visto en un negocio similar!). Detrás de escena hay todo tipo de golosinas sabrosas: números CC, direcciones de correo electrónico, información personal, pedidos gratuitos de productos ...
• Falta de auditorías: la mayoría de los desarrolladores (incluso yo mismo) piensan que son disparos en la seguridad, pero simplemente no podemos decirlo hasta que se caiga. Una forma de mitigar esto es a través de auditorías de seguridad realizadas por contratistas independientes, pero son costosas, requieren mucho tiempo, son "innecesarias" ... estas personas saben cómo pensar como hackers, mientras que su trabajo es pensar como un desarrollador de software.
• Desarrollador Orgullo / Ego: No te rías, lo he visto suceder. Algunos desarrolladores son tan altos y poderosos sobre sí mismos que se niegan a implementar la seguridad porque pueden simplemente vencerlos por otros medios ("Amigo, iré a su casa y los destruiré si me piratean"), o se niegan para que alguien venga y posiblemente les diga que no son menos que un regalo de Dios para el mundo de las TI (relacionado con la "Falta de auditorías" más arriba).

  

Quiero escuchar las razones específicas por las que ha escuchado a un usuario, un administrador o un usuario de la empresa por no querer implementar una política / procedimiento / producto más seguro.

Esto es lo que siempre obtengo:

  

Nunca hemos tenido un problema, así que no lo necesitamos.

Me cuesta mucho argumentar en contra de eso, por ignorante que sea.

Supongo que lo único que puedes hacer es demostrar que el sistema es vulnerable, lo que puede ser difícil. Sin embargo, a veces tienen razón: el sistema es relativamente seguro y las medidas adicionales no son necesarias o, lo que es más importante, para ellos, lo que vale la pena el costo de implementación. En ese caso, tendrías que demostrar que vale su dólar, lo que, una vez más, puede ser difícil.

¿Es esta la "mejor" razón? Tal vez no, pero es ciertamente común.

Tomemos el ejemplo específico de contraseñas. Las mejores prácticas de seguridad nos permitirían usar contraseñas de una longitud mínima, contener letras, números, caracteres especiales, etc. y no ser fáciles de adivinar. Además, deben ser exclusivos de un sitio en particular y cambiar cada 30 o 90 días. Finalmente, si alguna vez se divulga o compromete la contraseña, debe comunicarse de inmediato al responsable de seguridad y cambiar la contraseña de inmediato. Ah, y nunca escriba su contraseña.

Eso es un gran consejo desde un punto de vista de seguridad, pero virtualmente no funciona en el mundo real. ¿Puedes recordar tantas contraseñas? Literalmente tengo 100 de ellos.

Además, ¿ha tenido alguna vez la situación en la que se distrajo o tuvo prisa y escribió la contraseña para el sitio X en el cuadro de inicio de sesión del sitio web Y? Apuesto a que si la gente fuera honesta, descubrirías que esto sucede todo el tiempo. ¿Cambió inmediatamente las contraseñas en ambos sitios?

El sistema o los datos pueden no tener mucho valor, y el costo de una infracción podría ser lo suficientemente bajo como para justificar una relativa falta de seguridad. Por ejemplo, no siempre utilizo contraseñas seguras para los foros basados en la web, ya que el sitio no almacena mi nombre ni ninguna información personal y no tengo ninguna reputación que perjudicar.

La mayoría de la gente se resiste al cambio de todo tipo y, en consecuencia, presentará infinitas falacias lógicas para luchar contra la implementación de algo nuevo.

• ese auditor / inspector / certificador es un nitpicker
• nada ha sucedido hasta ahora
• pregunte a cualquiera, esto es exagerado
• ...

Al centrarse en las racionalizaciones específicas (el enfoque de su pregunta) se perdió el problema real: la tendencia natural a evitar el cambio. Al rechazar las falacias lógicas, estás lidiando con las emociones y los sistemas de creencias. Por lo tanto, el mejor enfoque es no intentar razonar con personas que presentan racionalizaciones lógicas en contra de su propuesta, sino vender la idea de sus beneficios.

Al igual que con cualquier buena situación de ventas, debe presentar algo de valor a una persona que lo necesite. Entonces, considere quién se beneficia más directamente del nuevo paradigma de seguridad y venda a esa persona primero. Probablemente hay algunas personas que no duermen tan bien debido al problema que está tratando de resolver. Póngase en contacto con ellos y déjelos llegar a otros con una propuesta basada en un valor operacional validado. Si no puede vendérselo a la gente que está en el gancho por las consecuencias de una vulnerabilidad explotada, entonces la organización ha hablado y no hay oportunidad.

1 / Visto como demasiado restrictivo: En las aplicaciones web, la seguridad a menudo se puede percibir como una restricción de la interoperabilidad. Esto ocurre a menudo en sistemas donde los complementos / complementos de terceros pueden interactuar con los sistemas de administración de contenido (osCommerce, Joomla y Wordpress, por nombrar algunos). Con cada acceso directo que han pagado mucho, y Joomla y Wordpress continúan pagando el precio.

2 / La buena seguridad puede salir por la ventana cuando el código se almacena en directorios seguros. Por ejemplo, dependiendo de htaccess, la autenticación básica para proteger directorios puede hacer que los desarrolladores eliminen sus estándares en el ámbito de la seguridad. Esto también es lo mismo cuando los sistemas se desarrollan para funcionar en una red de área local, también existe la falsa creencia de que la seguridad no es tan crítica, por lo que los estándares pueden ser más laxos.