La seguridad a través de la oscuridad se subestima

En seguridad de la información, hemos desarrollado una serie de axiomas que no se aceptan para discutir:



  • Nunca implemente su propia criptografía.

  • Utilice siempre TLS.

  • La seguridad por oscuridad es mala.


Etc. La mayoría de ellos son generalmente correctos. Sin embargo, me parece que la gente está siguiendo ciegamente estos axiomas como un culto al cargo. Y muchos realmente no piensan en excepciones a la regla. En este artículo, plantearé mis objeciones a la idea de que la seguridad a través de la oscuridad es mala.



Riesgo, defensa en capas y queso suizo



Una de las principales tareas de la seguridad de la información es reducir los riesgos. Según la metodología OWASP, el riesgo de un problema se calcula mediante la fórmula:



Riesgo = Probabilidad * Impacto


Con esta fórmula, el problema de la ejecución remota de código (RCE) presenta un riesgo mayor que el problema de la secuencia de comandos entre sitios, porque el RCE tiene un mayor impacto. Aquí todo es sencillo. Pero, ¿qué pasa con la métrica de probabilidad? Según OWASP, la probabilidad se define de la siguiente manera:



En el nivel más alto, es una estimación aproximada de las posibilidades de que un atacante revele y explote una vulnerabilidad en particular.


Por lo tanto, si reducimos la probabilidad, reducimos el riesgo general. Es bueno. De hecho, esto es muy similar al conocido concepto de "defensa en profundidad". También se le llama "modelo de queso suizo".







Según este modelo, debe construir mecanismos de defensa en un modelo en capas de tal manera que incluso si un atacante pasa el primer nivel, será detenido en otros.



Seguridad a través de la oscuridad



Así que hablemos de seguridad a través de la oscuridad. Es una mala idea usarlo como su única capa de defensa. Si el atacante lo pasa, nada más te protegerá. Pero en realidad es bastante bueno como nivel "extra". Porque tiene un bajo coste de implementación y suele funcionar bien.



Consideremos varios escenarios:



  • En mi servidor, SSH se ejecuta en el puerto predeterminado 22 y las credenciales root:123456. ¿Cuál es la probabilidad de compromiso?


La probabilidad es casi del 100%, ya que los piratas informáticos de Internet son servicios de fuerza bruta con credenciales estándar.



  • SSH se ejecuta en el puerto 22 y las credenciales utku:123456. ¿Cuál es la probabilidad de compromiso?


Bueno, hemos eliminado el peligro de la fuerza bruta con credenciales estándar. Se reducen la probabilidad y el riesgo. Sin embargo, todavía nos enfrentamos a un montón de ataques dirigidos. Alguien podría adivinar el nombre de usuario de utku ya que ese es mi nombre real.



  • SSH se ejecuta en el puerto 64323 y las credenciales utku:123456. ¿Cuál es la probabilidad de compromiso?


Hemos cambiado el número de puerto predeterminado. ¿Ayudará? Primero, hemos eliminado el peligro de la fuerza bruta estándar una vez más, ya que solo escanea puertos comunes. ¿Qué pasa con el resto? Hice una pequeña encuesta en mi twitter para averiguar el comportamiento de las personas al escanear puertos.





Como puede ver, muchos tienden a escanear solo los puertos estándar y más populares. Por lo tanto, si cambia el puerto de 22 a 64323, eliminará algunos de los posibles ataques. Reducirá la probabilidad y el riesgo.



Lo mismo ocurre con las vulnerabilidades del software. Si se encuentra una vulnerabilidad en el Protocolo de escritorio remoto de Microsoft, todo Internet comenzará a escanear el puerto 3389. Puede mitigar los riesgos simplemente cambiando el puerto predeterminado.



Otras aplicaciones



Por supuesto, además de cambiar los valores predeterminados, puede utilizar la misma metodología en otras áreas. En algunos casos (no siempre) se pueden aplicar las siguientes ideas.



  • Ofuscación del código : por supuesto, esto es de conocimiento común. Los hackers también son personas. Si ofuscas bien tu código, tendrán que dedicar más tiempo a buscar problemas. Eventualmente pueden darse por vencidos.

  • Nombres de variables aleatorios para una aplicación web : puede utilizar caracteres aleatorios en lugar de nombres de variables descriptivos. Puede ayudar de la misma manera que la ofuscación de código.

  • : encryption_algorithm(data, key). , — decryption_algorithm(data, key). , , , . - - , (, SQL-), .




La seguridad a través de la oscuridad se usa ampliamente en seguridad física / real. Por ejemplo, el presidente conduce del punto A al punto B con una caravana de 30 coches. Pero no se sienta en su auto presidencial, no sea que se convierta en un blanco fácil. Puede estar en cualquier máquina de la tupla y esto reduce el riesgo de un ataque.







Los animales también aprovechan la seguridad a través de la oscuridad: es camuflaje. El sigilo reduce la probabilidad de que te maten. Por lo tanto, en el proceso de evolución, adquirieron esta habilidad.







Salida



La seguridad a través de la oscuridad por sí sola no es suficiente. Siempre se deben aplicar las mejores prácticas. Pero si puede reducir su riesgo sin costo, entonces debería hacerlo. La oscuridad es una buena capa en el sistema de seguridad general.



All Articles