He trabajado para varias organizaciones en el pasado que utilizan prácticas que están justificadas por lo que describiría como " Security through Obscurity " incluyendo lo siguiente:
- Hash / Vulnerable dos veces hashing de contraseñas
- La utilización de varias API / Utilidades las conoce todas para contener vulnerabilidades graves
- Varias formas de datos / ofuscación de código
- Gestión descuidada / sin usuario
- El uso continuado de contraseñas increíblemente inseguras
- (La lista sigue y sigue ...)
Muchas veces las soluciones a estos problemas no implican una gran inversión / cambio y me resulta fácil alinear los recursos para resolverlos. Mi problema está en la justificación de cualquier posible solución, cuando estas prácticas son cuestionadas, normalmente las inquietudes se descartan con comentarios como:
- "solo el grupo xyz tiene acceso a esa red / producto / máquina / inicio de sesión / cualquiera"
- "eso no es una gran preocupación": la versión no declarada de:
- "nadie podría adivinar eso / saber para probar eso"
Incluso en entornos donde la seguridad se toma muy en serio y las auditorías son una preocupación constante, siempre me ha resultado difícil convencer a otros (especialmente a los tipos no técnicos / gerenciales) de la importancia de diseñar y mantener sistemas que sean < a href="https://en.wikipedia.org/wiki/Secure_by_design"> secure by design .
Descubrí que cuando se usa un ejemplo, la gente estará de acuerdo con usted sobre el director, pero la lección realmente nunca se adentra. Cuando se enfrenta a una explicación detallada de por qué un sistema / subsistema particular es vulnerable, la administración a menudo recurre a El argumento "no es una prioridad en este momento" (no lo puedo defender y no me importa), válido por derecho propio, pero más de las veces en lugar de identificar y registrar el problema, reflexionar sobre las lecciones aprendidas y establecer un programa para cumplir con un cierto nivel de cumplimiento predeterminado, la administración a menudo descarta cualquier evidencia contraria al cumplimiento total, garantiza a todas las partes relacionadas que el sistema mencionado anteriormente es "seguro" y envía el producto.
Creo que seguridad a través de la oscuridad no es un método efectivo parte de un sistema seguro y que los recursos gastados en tales esquemas son recursos mejor utilizados para otras partes de la aplicación.
A lo largo de mi carrera, he descubierto que la parte más difícil de implementar un sistema seguro no es convencer a otros del valor de un sistema seguro o reunir los recursos necesarios, sino convencer a otros de este principio. esfuerzos realizados a mejorar la seguridad de una organización a menudo se convierte en cruzadas de un solo hombre en lugar de cambios sistemáticos ya largo plazo en la cultura y la práctica.
A riesgo de ser amplio o generalmente basado en opiniones, ¿cuáles son las mejores estrategias para enseñar a otros el valor y el razonamiento para evitar la "Seguridad a través de la oscuridad"?