it-swarm-es.com

El papel válido de la oscuridad.

Que la seguridad a través de la oscuridad es una mala cosa se recibe sabiduría y dogma en la seguridad de la información. Decirle a la gente por qué se debe evitar algo puede ser considerablemente más difícil cuando no hay una línea que delinee lo que está tratando de prohibir de estrategias aparentemente efectivas.

Por ejemplo, ejecutando ssh en un puerto no predeterminado y golpe de puerto se sugieren como formas de mejorar la seguridad de ssh y se critica por ser ineficaces a través de la oscuridad.

En este caso particular, ambas soluciones reducen la visibilidad del sistema ante intentos automatizados. Esto no hace nada para mejorar la efectividad de ssh como herramienta o reducir la necesidad de otras medidas de seguridad de ssh. Sin embargo, proporciona una forma de separar los intentos serios de los transeúntes automáticos, lo que mejora la capacidad de administración del sistema.

  • Además de la manejabilidad/efectividad, ¿qué distinciones describen el límite entre los usos válidos/inválidos de la oscuridad?
  • ¿Qué analogías describen el uso efectivo de la oscuridad o hacen la distinción entre este y el uso ineficaz?
  • ¿Qué analogías que aparentemente respaldan la efectividad de la oscuridad no se sostienen y por qué?
  • ¿Qué otras implementaciones específicas son ejemplos del rol válido de la oscuridad?
43
Bell

Interesante pregunta. Mis pensamientos sobre esto son que ocultar información es útil para la seguridad en muchos casos, ya que puede obligar a un atacante a generar más "ruido" que se puede detectar.

Donde la oscuridad es una "cosa mala" puede ser donde el defensor confía en esa oscuridad como un control crítico, y sin esa oscuridad, el control falla.

Por lo tanto, además del que proporcionó anteriormente, un uso efectivo de la oscuridad podría ser eliminar la información del nombre y la versión del software de los servicios de Internet. Las ventajas de esto son:

  • Si un atacante quiere saber si una versión vulnerable del servicio está en uso, tendrá que hacer varias consultas (por ejemplo, buscar archivos predeterminados o quizás probar las respuestas de tiempo para algunas consultas). Es más probable que este tráfico se muestre en los registros de IDS que una sola solicitud que devolvió la versión. Además, los protocolos de huellas digitales no están bien desarrollados para todos los servicios, por lo que en realidad podría ralentizar considerablemente al atacante
  • El otro beneficio es que el número de versión no será indexado por servicios como Shodan . Esto puede ser relevante cuando se realiza un ataque automatizado para todas las instancias de una versión particular de un servicio (por ejemplo, cuando se ha descubierto un día 0 para esa versión). Esconder esto del banner puede impedir que una instancia determinada del servicio caiga presa de ese ataque.

Dicho esto, nunca debería ser la única línea de defensa. En el ejemplo anterior, el servicio aún debe ser reforzado y parcheado para ayudar a mantener su seguridad.

Donde creo que la oscuridad falla es donde se confía. Cosas como contraseñas codificadas que no se cambian, ofuscar secretos con "encriptación local" o basar una decisión de riesgo sobre si parchar un servicio en la idea de que nadie lo atacará. Entonces, el tipo de idea de que nadie encontrará/conocerá/atacará esto generalmente falla, posiblemente porque los defensores están limitando su concepto de quién podría ser un atacante válido. Está muy bien decir que un atacante externo desmotivado puede no tomarse el tiempo para desentrañar un control oscuro, pero si el atacante resulta ser un ex empleado descontento, esa contraseña codificada podría causar algunos problemas graves.

41
Rory McCune

Has caracterizado mal la sabiduría convencional. La sabiduría convencional no dice que la oscuridad es mala. Dice que confiar en la seguridad a través de la oscuridad es malo: generalmente conduce a sistemas frágiles o inseguros. Tenga en cuenta la diferencia. La oscuridad puede agregar seguridad adicional, pero no debe confiar en ella, y no debería ser su defensa principal. Debes estar preparado para que la oscuridad pueda ser perforada, y estar seguro de que tienes las defensas adecuadas para manejar ese caso.

Un concepto importante aquí es el principio de Kerckhoff . En la década de 1800, Kerckhoff ya articuló las razones por las cuales deberíamos ser escépticos sobre la seguridad a través de la oscuridad, y cómo trazar una línea entre los usos apropiados e inapropiados de la criptografía. El artículo de Wikipedia sobre el principio de Kerckhoff es muy bueno y un excelente punto de partida.

Aquí hay algunos puntos para reflexionar:

  • Como dice el artículo de Wikipedia, "Cuanto menos y más simples sean los secretos que uno debe guardar para garantizar la seguridad del sistema, más fácil será mantener la seguridad del sistema". Por lo tanto, si todo lo demás es igual, mientras menos cosas tengamos que mantener en secreto, más fácil será asegurar el sistema.

  • En términos generales, hay pocas esperanzas de mantener en secreto el diseño o los algoritmos utilizados en el sistema de los atacantes dedicados. Por lo tanto, cualquier sistema cuya seguridad se base en el secreto de su diseño está, a la larga, condenado, y a corto plazo, está asumiendo un riesgo innecesario.

  • El peor tipo de secreto es uno que no se puede cambiar si se ve comprometido o se filtra a partes no autorizadas. El mejor tipo de secreto es uno que se puede cambiar fácilmente si se sospecha que se filtró. La construcción de un sistema donde la seguridad depende de mantener en secreto el diseño del sistema es uno de los peores usos posibles del secreto, porque una vez que se implementa el sistema, si su secreto se filtra, es muy difícil cambiarlo (debe reemplazar todas las copias implementadas del sistema con una implementación totalmente nueva, que generalmente es extremadamente costosa). Construir un sistema donde la seguridad se base en que cada usuario seleccione una frase de contraseña aleatoria es mejor, porque si la contraseña se filtra (por ejemplo, el usuario escribe su contraseña en un sitio de phishing y luego dice "¡Vaya!"), Es relativamente fácil cambiarla. la contraseña del usuario sin molestar a los demás.

  • O, como Kerckhoff escribió en la década de 1800, el diseño de un criptosistema no debe ser un secreto, y debe ser capaz de caer en manos del enemigo sin inconvenientes. Esto es básicamente una reformulación de mi punto anterior, en un dominio particular.

Por estas razones, los sistemas bien diseñados generalmente tratan de minimizar la medida en que confían en los secretos; y cuando los secretos son necesarios, uno generalmente los diseña para concentrar todo el secreto requerido en una clave criptográfica o frase de contraseña que se pueda cambiar fácilmente si se ve comprometida.

15
D.W.

Es la seguridad a través oscuridad que es la parte mala. La oscuridad puede aumentar la seguridad, pero no puede depender solo de la oscuridad para proporcionar seguridad.

Los mantras absolutos son siempre dañinos. ;) Es esencial entender el razonamiento detrás del mantra y las compensaciones involucradas.

Por ejemplo, esconder una llave fuera de tu casa cuando vas a correr es seguridad a través de la oscuridad, pero podría ser un riesgo aceptable si vas a volver en 30 minutos (¿y no eres un objetivo de alto riesgo?).

Lo mismo puede decirse de "nunca use goto". A veces, goto es la mejor manera de escribir código claro en ciertas situaciones. Como profesional experimentado, debe comprender los motivos de las pautas, para que pueda comprender las compensaciones.

5
Bradley Kreider