El rol válido de la oscuridad

Pregunta interesante. Mi opinión sobre esto es que ocultar la información es útil para la seguridad en muchos casos, ya que puede forzar a un atacante a generar más "ruido" que se puede detectar.

Donde la oscuridad es una "cosa mala" puede ser que el defensor esté confiando en esa oscuridad como un control crítico, y sin esa oscuridad, el control falla.

Entonces, además del que mencionó anteriormente, un uso efectivo de obscurity podría ser eliminar el nombre del software y la información de la versión de los servicios que se encuentran frente a Internet. Las ventajas de esto son:

• Si un atacante quiere saber si una versión vulnerable del servicio está en uso, tendrá que realizar múltiples consultas (por ejemplo, buscar archivos predeterminados o tal vez probar respuestas de tiempo para algunas consultas). Es más probable que este tráfico aparezca en los registros de IDS que en una sola solicitud que devolvió la versión. Además, los protocolos de toma de huellas dactilares no están bien desarrollados para todos los servicios, por lo que 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 lleva a cabo un ataque automatizado para todas las instancias de una versión particular de un servicio (por ejemplo, cuando se ha descubierto un día de 0 para esa versión). Al ocultarlo de la pancarta, en realidad puede evitar 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 parchado para ayudar a mantener su seguridad.

Donde creo que falla la oscuridad es donde se confía. Cosas como las contraseñas codificadas que no se modifican, los secretos confusos con el "cifrado local" o la decisión de riesgo de parchear un servicio con la idea de que nadie lo atacará. Entonces, el tipo de idea que nadie encontrará / sabrá / 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 no puede 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.

Has malinterpretado la sabiduría convencional. La sabiduría convencional no dice que la oscuridad sea mala. Dice que la seguridad de confiar en a través de la oscuridad es mala: generalmente conduce a sistemas frágiles o inseguros. Note la diferencia. La oscuridad puede agregar cierta seguridad adicional, pero no debes confiar en ella, y no debe ser tu defensa principal. Debes estar preparado para que la oscuridad pueda ser perforada, y tener la confianza 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 que deberíamos ser escépticos acerca de 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, cuantas menos cosas tengamos que mantener en secreto, más fácil será proteger el sistema.

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

• El peor tipo de secreto es uno que no se puede cambiar si se compromete o se filtra a personas no autorizadas. El mejor tipo de secreto es aquel que se puede cambiar fácilmente si se sospecha que se ha filtrado. Construir un sistema donde la seguridad se basa en 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 de cambiar (debe reemplazar todas las copias implementadas del Sistema con una implementación totalmente nueva, que suele ser extremadamente costosa). Crear un sistema en el que la seguridad dependa de cada usuario para seleccionar una contraseña aleatoria es mejor, ya que si la contraseña se filtra (por ejemplo, el usuario escribe su contraseña en un sitio de phishing y luego dice "¡Ups!"), Es relativamente fácil de cambiar la contraseña del usuario sin incomodar a otros.

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

Por estas razones, los sistemas bien diseñados generalmente intentan minimizar la medida en que dependen de los secretos; y cuando los secretos son necesarios, por lo general uno los diseña para concentrar todo el secreto requerido en una clave criptográfica o frase de contraseña que se puede cambiar fácilmente si se compromete.

Es la seguridad a través de la 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 la compensación implicados.

Por ejemplo, esconder una llave fuera de su casa cuando sale a correr es seguridad, pero puede ser un riesgo aceptable si regresará en 30 minutos (y no es un objetivo de alto riesgo) ?).

Lo mismo se puede decir para "nunca usar goto". A veces, goto es la mejor manera de escribir código claro en ciertas situaciones. Como profesional con experiencia, debe comprender los motivos de las directrices para poder comprender las ventajas y desventajas.