Tuve un trabajo en el que un gerente dijo que le gustaba poner nombres a los servidores después de los lugares porque, si se los nombraba de manera descriptiva, por ejemplo. "servidor de base de datos de contraseñas" se convierten en objetivos obvios. De alguna manera generalicé este concepto y cuando escribo código, evito nombrar variables como "contraseña". ¿Esto ayuda a la seguridad o confunde a las personas con las que debería trabajar?
Dar nombres no obvios a las cosas es similar a seguridad a través de la oscuridad que generalmente está mal visto en estas partes. El problema con ese tipo de seguridad no es que no funcione; de hecho, tiene algún valor, que se demostró muchas veces a través de la Historia (por ejemplo, es por eso que un tanque se llama "tanque" y no "carro blindado"). Pero no puede cuantificar la seguridad a través de la oscuridad. No puedes saber "cuánto" la seguridad te compra; y, en particular, no puede saber si funciona en absoluto (y aunque a menudo funciona bien, a menudo también falla espectacularmente).
Por lo tanto, cuando piense en gestión de riesgos , el valor de los nombres no estándar debe considerarse bajo. Esto no sería un problema si pudiera hacerse "gratis"; pero los nombres no estándar tienen un enorme costo oculto: si confunden a los atacantes, es probable que también confundan a los administradores de sistemas. Desviará el tiempo de pensamiento y los recursos, y aumentará la latencia de la reacción si surgen problemas.
Realmente, en seguridad de TI y en TI en general, los nombres descriptivos son imprescindibles.
Este sería un excelente ejemplo de Seguridad a través de la oscuridad . Si bien esto proporciona un valor de seguridad de algo , la ganancia es generalmente muy mínima y no se debe confiar en nunca como defensa definitiva.
Al igual que con cualquier medida de seguridad, la organización debe decidir cómo equilibrar la seguridad y la facilidad de uso. Si puede llegar a una convención de nomenclatura conveniente que sea razonablemente oscura para los forasteros, pero fácil de aprender para usted y su equipo, puede ser una consideración que valga la pena. Si constantemente se encuentra con problemas significativos porque la gente no puede recordar, o no puede encontrar fácilmente una lista de servidores esenciales o nombres de variables, entonces podría ser el momento de volver a considerar si Esta solución en particular es adecuada para usted.
Si está escribiendo un fragmento de código sensible a la seguridad, le corresponde a usted utilizar nombres que expliquen claramente cuál es toda la información sensible.
Si un fragmento de texto es una contraseña, pero lo llama string1 , entonces el siguiente programador que ingresa después de escribir el código que no trata la variable con el cuidado adecuado.
Por ejemplo, él o ella puede agregar una declaración de depuración que distribuya el contenido de string1 en un registro, poniendo las contraseñas a disposición de alguien que pueda activar la depuración y obtener acceso a los registros.
De todos modos, el código fuente no contiene contraseñas, solo variables llamadas contraseñas, a menos que sean terriblemente inseguras. Nadie va a obtener contraseñas buscando variables llamadas password en el código fuente.
Hay una gran diferencia entre la selección de nombres para servidores que no identifican su funcionalidad, lo que posiblemente los convierte en objetivos más obvios para los piratas informáticos y el uso de nombres poco claros en el código del programa.
Los nombres que usa para las variables en su código no terminan en el archivo binario / ejecutable final del programa. Esos nombres solo existen en su código fuente. Si alguien tiene acceso al código fuente, los nombres oscuros brindarán poca protección. Sin embargo, para los pobres mantenedores que te siguen será realmente inconveniente. De hecho, a largo plazo, incluso puede disminuir la seguridad del programa, ya que los mantenedores posteriores tienen más probabilidades de malinterpretar o malinterpretar para qué se utiliza la variable.
Al escribir código, el primer y más importante objetivo es la corrección. Después de eso, es la comunicación del algoritmo y la intención del código. El uso de nombres de variables que no reflejen con exactitud el propósito de la variable restará valor a esto y dificultará el mantenimiento. Es el algoritmo que determinará qué tan segura es su solución, no qué nombres usa para las variables.
La ganancia principal que puede obtener de la asignación de nombres de servidores es aumentar la necesidad de adivinar y facilita la implementación de algo como un honeypot para intentar identificar a los atacantes. Todavía es seguridad a través de la oscuridad y no proporciona ninguna seguridad por derecho propio.
En cuanto al uso de la ofuscación en el código de programación, es importante tener en cuenta que, dependiendo del idioma, esto ya se puede hacer por usted. Muchos lenguajes compilados descartarán los nombres de los métodos y las variables en las versiones y las herramientas de ofuscación de código están disponibles para muchos idiomas que no están compilados o que hacen un seguimiento de los nombres de variables (como .Net).
El principal problema con los nombres confusos en el código es que disminuye la seguridad al disminuir la legibilidad. El código complejo, que no se puede mantener, es casi siempre menos seguro, ya que la complejidad agregada aumenta los errores y los errores pueden conducir a agujeros de seguridad. La mejor opción es escribir un código muy simple y fácil de mantener cuando es crítico para la seguridad y luego, si lo desea, puede ofuscarlo con un paquete comercial para que a los atacantes les resulte más difícil analizar lo que deben hacer para intentar atacarlo.
Lea otras preguntas en las etiquetas source-code server