Seguridad

El gran debate: la seguridad por oscuridad

Jesper M. Johansson and Roger Grimes

De un vistazo:

• Definición de seguridad por oscuridad
• Evaluación de medidas en la seguridad por oscuridad
• Evaluación del valor del cambio de nombre de la cuenta de administrador
• Toma de decisiones bien documentadas acerca de administración de riesgos

El término "seguridad por oscuridad" suele suscitar burlas en las personas que trabajan con la seguridad, especialmente los que se consideran expertos. La reacción es similar a cuando en algunos círculos se dice una palabrota y es que la seguridad

por oscuridad, tal como se indica en Wikipedia (en.wikipedia.org/wiki/Security_through_obscurity), representa uno de los aspectos más polémicos en esta materia. Se suelen hacer referencias burlonas como "no es más que seguridad por oscuridad" que desestiman el esfuerzo de algunas personas.

La seguridad por oscuridad es, en pocas palabras, una infracción del principio de Kerckhoffs, que afirma que un sistema debe ser seguro por su diseño, no porque un adversario no conozca su diseño. La premisa básica del principio de Kerckhoffs es que los secretos dejan de serlo en poco tiempo.

Como ejemplo, el diseño del protocolo de autenticación de Windows NT® LAN Manager (NTLM) inicialmente se consideró un secreto. Para implementar el producto de interoperabilidad Samba para sistemas operativos basados en UNIX, el equipo de Samba tuvo que invertir la ingeniería del protocolo. Como consecuencia, se creó una documentación más completa de NTLM (monyo.com/technical/samba/translation/ntlm.en.html), además de detectarse algunos errores. Debido a que la mayor parte de la seguridad dejó de usar la criptografía y se han revelado tantos secretos de diseño, muchos encargados de la seguridad creen que la seguridad de la información debería seguir el principio de Kerckhoffs.

¿Pero la seguridad por oscuridad es poco recomendable en cualquier situación? En este artículo, explicaremos qué es la seguridad por oscuridad, trataremos de esclarecer por qué muchos la consideran una pérdida de tiempo, y por qué otros no, y le mostraremos por qué, como de costumbre, la respuesta es mucho más complicada de lo que parece al principio.

Introducción a la seguridad por oscuridad

No cambie los valores predeterminados, de Steve Riley

En cuanto al problema de cambiar el nombre, me decanto por "no cambiarlo". Ni siquiera tiene que ver con la seguridad, se trata de un problema de administración de sistemas. Y a medida que pienso en el espacio de administración de sistemas (porque la administración y la seguridad se están fusionando), estoy cada vez más convencido de que no se debe hacer nada que pueda aumentar potencialmente la fragilidad de un sistema. Una manera segura de aumentar la fragilidad es cambiar los valores predeterminados. Existen dos (bueno, dejémoslo en tres) razones por las que los usuarios cambian la configuración predeterminada:

• El cambio proporciona a la funcionalidad un requisito conocido necesario.
• Se presume que el cambio mejorará la seguridad.
• (Cuidado con la estupidez.) Alguien lo leyó en un artículo.

Si debe realizar el cambio de un nombre predeterminado debido a la razón número 1, hágalo. Este tipo de cambios no suelen originar inestabilidad en el sistema porque se suelen probar anteriormente.

Si desea cambiar un valor predeterminado debido a la razón número 2, deténgase un momento y vuelva a considerarlo. Este tipo de cambios casi nunca los ha probado el fabricante del software y, por lo tanto, no puede predecir cómo se comportará el sistema una vez realizado. Además, generalmente existen mejores alternativas que le proporcionarán una seguridad completa.

¿Qué sucederá si la persona incorrecta averigua el nombre de cuenta? Lo que impide la entrada a los usuarios incorrectos a su sistema es la contraseña, y la seguridad de dicha contraseña. El impulso de cambiar los nombres de cuenta predeterminados como la de administrador e invitado por otros más difíciles de adivinar en realidad suele ser indicativo de evitar contraseñas y frases de contraseña seguras. Corrija el problema real (los secretos a voces) y evitará la fragilidad (cambio de los nombres predeterminados).

En la seguridad por oscuridad no se incluyen las medidas que no aportan nada a la mitigación de un problema. Por ejemplo, una organización que bloquea el Protocolo de transferencia de noticias a través de la red (NNTP) de los enrutadores de borde para evitar que los empleados lean grupos de noticias pero que permita el shell seguro (SSH) saliente no se considera seguridad por oscuridad. Debido a que SSH puede abrirse paso en cada protocolo, el problema no está oculto; la estúpida mitigación implementada no puede hacer nada más que evitar que los usuarios legítimos consigan realizar tareas legítimas sin infringir las directivas de seguridad. Dichas medidas no son seguridad por oscuridad; son estúpidas e injustificadas.

Tal como indica la palabra "seguridad" en la frase "seguridad por oscuridad", se obtiene protección de la medida. Sin embargo, lo que también indica, y aquí está el problema, es que no está haciendo nada para detener ataques a algún vector. Básicamente, un vector de ataque es un medio por el cual un atacante puede obtener acceso a un sistema.

Por ejemplo, con un servidor web vulnerable, le pueden atacar a través del puerto TCP 80 mediante una vulnerabilidad pública. Para cerrar ese vector particular puede incorporar revisiones al servidor web o apagarlo; cualquiera de estas acciones detendrá el vector por completo. Puede detener parcialmente el vector de ataque mediante un firewall o IPsec para cerrar el puerto 80 a todos los equipos excepto a algunos seleccionados. Aunque esto no bloqueará el vector de ataque por completo, mitigará el problema de forma significativa.

Por otro lado, la seguridad por oscuridad implica llevar a cabo alguna medida que no detenga el vector de ataque sino que simplemente lo oculte. Por ejemplo, puede decidir mover el servidor web al puerto 81 en lugar de al 80, de forma que tan sólo los usuarios que saben dónde encontrar su servidor web lo podrán hacer. Al menos, ése es el argumento. En realidad, al mover el servidor web al puerto 81, sólo se detienen algunos ataques y, en la mayoría de los casos, sólo causa inconvenientes al usuario final. Un intruso competente tan sólo tendrá que ejecutar un escáner del puerto y un captador de pancartas web contra un gran número de puertos para descubrir servidores web en puertos no estándar. Al encontrar uno, se podrá aprovechar de la vulnerabilidad de su servidor debido a que usted en realidad no eliminó el vector de ataque, sino que tan sólo lo ocultó (temporalmente).

¿Significa esto que ni siquiera debe intentarlo? Depende. Al igual que con las demás opciones del campo Seguridad de la información, todo se reduce a la administración de riesgos. Para comprender los factores clave a tener en cuenta, echaremos una ojeada a otras medidas de la seguridad por oscuridad y, a continuación, analizaremos una de ellas (cambiar el nombre de la cuenta del administrador) en más detalle.

Evaluación de las medidas de seguridad

Abundan los ejemplos de la seguridad por oscuridad. Puede tratarse de acciones que llevan a cabo los administradores del sistema y de la red, o bien, los pueden iniciar los desarrolladores de software. Sin embargo, lo que todos tienen en común es que tratan de mitigar una vulnerabilidad ocultándola de posibles atacantes.

¿Estos procedimientos tienen al menos algún efecto beneficioso? ¿Es justo decir que todas las características de la seguridad por oscuridad son poco recomendables? Existen defensores de algunas de estas medidas. Por ejemplo, en Windows® es posible ocultar las letras de unidades en el Explorador de Windows. Muchos entornos, entre los cuales los más notables son los laboratorios informáticos de las escuelas, usan esta técnica para evitar que los usuarios guarden datos en el disco duro. Por supuesto, la mayoría de aplicaciones puede guardar datos en el disco duro, de forma que tiene poco valor como medida de seguridad exclusiva. Sin embargo, las instituciones que las han implementado afirman que reducen los datos del disco duro.

Otro tipo de práctica en la seguridad por oscuridad implementada en Windows es desactivar los recursos compartidos de red administrativos (como C$ y Admin$, entre otros). Está pensada para evitar que los atacantes se puedan conectar al equipo de forma remota. En realidad, no sólo es falso, sino que un atacante con una cuenta que puede usar los recursos compartidos administrativos puede volver a habilitar estos recursos compartidos de forma remota. Todavía hay muchas organizaciones que juran que estos recursos compartidos reducen los incidentes de malware en sus redes.

Uno de nuestros ejemplos favoritos de esfuerzo perdido es la configuración "Permitir desacoplamiento sin tener que iniciar sesión" de Windows. Si está deshabilitada, el botón "Desacoplar equipo" estará oculto en la pantalla de inicio de sesión. La idea que se deriva de la situación es que de este modo un atacante no puede desacoplar el equipo. Por supuesto, los intrusos podrían sencillamente meter el equipo y la estación de acoplamiento en una bolsa y llevárselos, aunque el botón no esté visible. Esta posibilidad es remota incluso si se usa la seguridad por oscuridad.

Otro claro ejemplo es la configuración "Permitir a los operadores de servidor programar tareas" que, como su nombre indica, permite a los miembros del grupo de operadores de servidor programar tareas. Se trata de un problema sensible porque dichas tareas se pueden ejecutar como Sistema Local y sólo los administradores deben poder programar tareas que se ejecuten como Sistema Local. Por supuesto, los operadores de servidor pueden convertirse en administradores a través de un número diferente de vectores, de manera que en realidad impedirles programar las tareas de esta forma tiene un valor mínimo.

Todavía hay muchas organizaciones que aceptan esta configuración porque permite que los ingenieros sean operadores de servidores en lugar de administradores, lo que significa que es menos probable que destruyan el servidor por accidente. Esto puede suponer alguna ventaja.

Entonces, ¿cuál es el veredicto? Obviamente, algunos de estos problemas pueden ser muy complicados. Hemos pasado muchas horas agradables debatiendo acerca de este tipo de medidas. Roger está del lado de los usuarios que valoran dichas prácticas. Por su parte, Jesper cree que son, en el mejor de los casos, una pérdida de tiempo. Exploremos uno de los casos más citados, y dudoso, de la seguridad por oscuridad: cambio de nombre de la cuenta de administrador. Roger defenderá la medida, mientras que Jesper la desaprobará. Los prestigiosos expertos en seguridad Aaron Margosis y Steve Riley también participarán en las barras laterales "Cambiar el nombre de la cuenta de administrador" y "No cambiar los valores predeterminados", respectivamente.

Ocultación de la cuenta de administrador

Los profesionales de la seguridad suelen recomendar el cambio de nombre de la cuenta de administrador, el identificador relativo (RID) 500, por un nombre que desconozca el público general; asimismo, esta medida se incluye en varias guías de refuerzo de Microsoft. Además, la directiva de grupo incluye una configuración para cambiar el nombre de la cuenta de administrador, tal como se muestra en la figura 1. La idea es que si se cambia el nombre de la cuenta de administrador, un atacante tendrá más difícil el inicio de sesión como administrador real. Por supuesto, el problema obvio de usar la directiva de grupo en esta operación es que la cuenta de administrador a la cual se le cambia el nombre tendrá el mismo nombre en todos los equipos a los que se aplique dicha directiva. Esto disminuye el valor de oscuridad de esta medida de seguridad particular.

Figura 1** Cambio de nombre de la cuenta de administrador **(Hacer clic en la imagen para ampliarla)

En este contexto, también es importante darse cuenta de que cualquier usuario con una cuenta legítima puede recuperar el nombre de la cuenta de administrador, independientemente de si se lo cambia. La cuenta de administrador siempre tiene un RID de 500. Con tan sólo pedir el nombre de la cuenta mediante RID 500, cualquier usuario con una cuenta puede consultar su denominación real, tal como se muestra en la figura 2.

Figura 2** Búsqueda de cuentas de administrador a las que se les haya cambiado el nombre **(Hacer clic en la imagen para ampliarla)

Turno de Roger

El argumento principal que existe contra el cambio de nombre de la cuenta de administrador es que es muy fácil convertir cualquier nombre de cuenta principal de seguridad en su identificador de seguridad relacionado (SID) y averiguar su RID. La cuenta de administrador real siempre tiene un RID de 500. Así que, si un atacante puede convertir fácilmente los nombres de cuenta de usuario en las combinaciones SID/RID y encontrar el RID 500, ¿por qué preocuparse?

Pero no es tan sencillo. Para conseguir una traducción del nombre de cuenta de usuario a SID/RID, debe disponer de acceso a los puertos NetBIOS o LDAP. La mayoría de firewalls perimetrales no permiten ese tipo de acceso en Internet, por tanto, hasta que esquive completamente el firewall, no podrá traducir nada. Además, las traducciones SID anónimas no influyen negativamente en Windows XP y las versiones posteriores de Windows, salvo en los controladores de dominio (DC). Para la mayoría de equipos orientados externamente (los que están más en peligro), el atacante necesitaría credenciales autenticadas para hacer las traducciones del nombre a SID.

Por tanto, existen un buen número de obstáculos de defensa exhaustiva que se deben esquivar para empezar un ataque de traducción. Incluso si el atacante llega tan lejos, terminará en el mismo punto en el que estaría si el nombre de cuenta no se hubiera cambiado. El cambio de nombre de la cuenta de administrador sólo puede mejorar la seguridad. Definitivamente, no lo puede dañar.

Otro secreto Si un atacante no conoce el nombre de cuenta de administrador, se convierte en otra etiqueta "secreta", análoga a una contraseña, que también debería conocer. De acuerdo, los nombres de cuenta de usuario no suelen ser tan complejos como una contraseña administrativa, aunque son otro obstáculo que complica de manera exponencial el problema de adivinar o descodificar la contraseña. Si alguna vez ha realizado pruebas de penetración de contraseñas, ya sabrá el trabajo que supone adivinar el nombre de usuario y la contraseña. Si ya de por sí es una tarea difícil, esto es más complicado todavía.

Combate el malware automatizado y los cracker inexpertos He probado la defensa de seguridad de Windows durante 22 años y he ejecutado ocho servidores trampa ("honeypots") de Windows, expuesto a Internet los últimos 5 años. En todo ese tiempo, no he visto que el malware automatizado (que comprende la gran mayoría de los ataques) use etiquetas de cuenta de usuario salvo la de administrador (o la raíz, en el caso de los sistemas *NIX). Si cambia el nombre de su cuenta de administrador, eliminará inmediatamente todo el malware que depende del nombre de administrador. Y eso se traduce en un menor riesgo de seguridad.

Sucede lo mismo con los cracker inexpertos. Los manuales de piratería "guays" de Windows que conozco mencionan las técnicas de traducción de nombre a SID aunque, por alguna razón, no he visto ningún caso de estos en mis servidores trampa porque también contaba con una cuenta de administrador "falsa" para echarlos. Los piratas informáticos buenos deben comprobar que la cuenta de administrador encontrada es el administrador real (RID 500), pero no lo hacen. No sé por qué. Culpo a los piratas informáticos perezosos y al comportamiento habitual de los seres humanos.

También detiene a la mayoría de los profesionales Esto sorprende a muchas personas. Al ejecutar servidores trampa durante unos años, se reconoce rápidamente la diferencia entre los ataques automatizados, de los crackers sin experiencia y los profesionales. En los últimos cinco años, teniendo millones de ataques notificados contra mis servidores trampa, no he visto que ningún profesional me haga una traducción SID cuando la cuenta de administrador falsa estaba presente.

Estoy seguro de que algunos profesionales no autorizados llevan a cabo traducciones SID, pero apuesto a que se trata de una minoría que no he encontrado en la práctica. ¿Por qué no lo harían los profesionales? Supongo que no ven ninguna razón para intentar hacer algo que no hacen la mayoría de usuarios.

Simplifica las alertas Ahora, el otro lado puede sostener que si el cambio de nombre de la cuenta de administrador se convierte en algo frecuente, perderá su valor de técnica de oscuridad. El argumento es que el malware, los crackers inexpertos y los profesionales cambiarían sus tácticas predeterminadas para buscar nombres que no sean sólo Administrador. Y esta preocupación tiene su razón de ser. Afortunadamente, no cambia el estado básico. Primero, si el nombre de la cuenta con muchos privilegios de Windows no es Administrador, el pirata informático malintencionado deberá trabajar más. Es un hecho. Si el pirata informático malintencionado debe trabajar más, probablemente no intentará este tipo de ataques, y quizás esto permita que una de las demás técnicas de defensa exhaustiva de compensación detecte la actividad malintencionada más rápidamente.

Esta idea me lleva al último punto a favor del cambio de nombre. Si la cuenta de administrador nunca se denominó administrador y crea otra cuenta con dicho nombre, tal como se muestra en la figura 3, dispone de un buen mecanismo de alerta. Si la supervisión de eventos detecta un intento de inicio de sesión mediante el nombre predeterminado, se analizará inmediatamente.

Figura 3** Los intentos de inicio de sesión a una cuenta señuelo denominada Administrador pueden servir de primera advertencia **(Hacer clic en la imagen para ampliarla)

Nuestros registros de eventos están llenos de inicios de sesión "incorrectos" que no significan nada. Normalmente, sólo se trata de un usuario (o Windows) que trata de iniciar sesión con una contraseña incorrecta o algo parecido. Aunque, si su cuenta de administrador se denomina Administrador, ¿cómo puede diferenciar con facilidad los intentos de inicio de sesión malintencionados? Si nunca ha tenido una cuenta de inicio de sesión denominada Administrador y detecta un intento de inicio de sesión con este nombre de cuenta, seguramente el intento sea malintencionado. Una primera advertencia poco importante tiene mucho valor en la defensa de hoy en día.

Turno de Jesper

Cambio de nombre de la cuenta de administrador, de Aaron Margosis

En un mundo ideal, Jesper tendría toda la razón. Las contraseñas serían lo suficientemente seguras para adivinarlas mediante ataques de fuerza bruta y las cuentas de administrador locales de -500 sólo se usarían para una recuperación de emergencia. Aunque, en el mundo real, nada de esto es cierto.

A pesar de la gran seguridad que predica, y en particular la magnífica serie acerca de frases de contraseña que creó ("Los grandes debates: frases de contraseñas vs. contraseñas", partes 1, 2 y 3, en go.microsoft.com/fwlink/?LinkId=113157, go.microsoft.com/fwlink/?LinkId=113159 y go.microsoft.com/fwlink/?LinkId=113160), actualmente muchos administradores del sistema no saben lo que significa una contraseña segura.

Hasta no hace mucho tiempo, una contraseña de ocho caracteres aleatorios procedentes de varios conjuntos de caracteres era segura; la ley de Moore dejó obsoleta esta definición. La educación del usuario (y administrador del sistema) es un vínculo no seguro que probablemente no cambiará, al menos hasta que el tema de la seguridad de las contraseñas sea un tema de actualidad en los telediarios.

De esta forma, dado que hoy en día el hecho de adivinar contraseñas en el mundo real no requiere 600 mil millones de años, al contrario, a menudo se puede realizar durante la comida, agregar un multiplicador de 1000 puede ser el valor real. Y frente a los diferentes ataques automatizados que tratan de introducirse en la cuenta denominada Administrador, cambiar el nombre de la cuenta la hace invulnerable.

El tiempo y esfuerzo que implica cambiar el nombre de la cuenta de administración no suelen ser muy elevados; normalmente, como ha mencionado usted, es una configuración de GPO sencilla. De hecho, la configuración central de escritorio federal del gobierno de los EE. UU. (csrc. nist. gov/fdcc) requiere el cambio de nombre de la cuenta -500. El cambio de nombre no sólo es una de las diferentes configuraciones necesarias ni de las que precisa una cantidad desmesurada de tiempo o atención. Tampoco creo que nadie esté aletargado en un sentimiento de seguridad falso con respecto a su valor; todavía no he oído decir a nadie: "No necesitamos la administración de revisiones porque cambiamos el nombre de las cuentas de administración".

¿El cambio de nombre tiene algún valor cuando se da el mismo nombre de cuenta para toda la organización? No se trata de un gran valor, pero algo es algo: primero, bloquea los ataques automatizados que espera el administrador, y segundo, el conjunto de atacantes posibles no es necesariamente un subconjunto de "todos" los que conocen el nuevo nombre. El mayor riesgo se presenta cuando las cuentas de administración locales (una vez se les ha cambiado el nombre) comparten una contraseña común en toda la organización. Administrarlas es el mayor problema y el más importante. Deshabilitar la cuenta -500 es una forma de llevarlo a cabo, pero esto bloquea una recuperación importante cuando no se pueden usar las cuentas de dominio. Además, me gustaría señalar que nuestras guías de seguridad recomiendan el cambio de nombre de las cuentas predeterminadas, ya que se ha probado y es totalmente compatible.

A estas alturas, todos sabemos que las medidas de oscuridad (por sí solas) no constituyen una defensa adecuada. Pero pueden mejorar otras medidas de seguridad y los datos de Roger lo demuestran con claridad. Siempre que el costo de implementación sea bajo, las organizaciones no las deben descartar.

Tal como sucede con los argumentos que defienden la medida, existen argumentos válidos en contra del cambio de nombre de la cuenta de administrador. Antes de analizarlos, debo reconocer que el último punto de Roger es bastante válido. Sin embargo, en un entorno administrado, cualquier inicio de sesión con la cuenta de administrador se debe investigar porque dicha cuenta no se usará de otra manera que no sea en recuperaciones de emergencia.

Es superfluo El riesgo principal que se supone mitigará el cambio de nombre de la cuenta de administrador es el de que alguien adivine su contraseña de forma remota. Pero sólo se combatirá a los usuarios que no tienen otra cuenta autorizada en el equipo mediante el cambio de nombre de la cuenta de administrador. Dicho atacante normalmente intentaría una serie de contraseñas aleatorias para iniciar sesión en la cuenta de administrador. Sin embargo, recibiría el mismo mensaje de error independientemente de si adivinó el nombre de cuenta o la contraseña incorrectos.

Esto sugiere que uno de los argumentos principales para cambiar el nombre de la cuenta de administrador (que hace desaparecer a los cracker sin experiencia) no sirve. No desaparecen antes por cambiar el nombre de la cuenta de administrador en lugar de respetar el nombre original porque no lo pueden asegurar. Adivinarán el mismo conjunto de contraseñas aleatorias independientemente de los obstáculos y, a continuación, pasarán a la siguiente víctima posible.

Esto significa que siempre que la contraseña de la cuenta de administrador sea suficientemente segura para rechazar los ataques, el cambio de nombre de la cuenta no ofrece un valor adicional. Supongamos que nuestra cuenta de administrador tiene una contraseña de 15 caracteres compuesta de letras mayúsculas y minúsculas, números y símbolos elegidos de todo el teclado. Adivinar esa contraseña a través de la red costará unos 591.310.404.907 años. En comparación, es aproximadamente 43 veces más de la existencia del universo.

Ahora, supongamos que cambiamos el nombre de la cuenta de administrador y lo convertimos en uno de los 1.000 valores posibles. Ampliaríamos el tiempo de adivinar la contraseña a 591.310.404.906.787 años, es decir, 43.161 veces más de la existencia del universo. ¿Realmente estamos más seguros? Claro que sí, estamos tres órdenes de magnitud más protegidos. ¿Es menos probable que el atacante adivine nuestra contraseña? Es infinitesimalmente menos probable, en cualquier caso. En otras palabras, en términos reales, no estamos completamente mejor que con el nombre de cuenta de administrador original. Sólo porque el cambio de nombre de la cuenta elimina el malware que trata de usarla no significa que el malware lo hubiera conseguido de no cambiar el nombre de la cuenta. De hecho, si usa una contraseña segura, como debería, puede garantizar virtualmente que no lo conseguirá, independientemente del nombre de la cuenta.

Está claro que muchas guías de seguridad requieren el cambio de nombre de la cuenta de administrador; pero no es esa la medida de seguridad más valiosa, ni tan siquiera la más válida. Sencillamente, elimina su capacidad de tomar una decisión apropiada acerca del asunto en la administración de riesgos. Con frecuencia, las guías acerca de seguridad requieren configuraciones que no aportan ninguna diferencia y, en muchos casos, configuraciones que ni tan sólo existen. Finalmente, para progresar en el campo de la seguridad, debemos dar un paso más allá de los requisitos y analizar realmente los problemas, además de valorar si las mitigaciones tienen algún sentido. Es importante recordar un punto importante: el hecho de que un atacante se oriente hacia una característica no es, de por sí, una razón suficiente para modificar dicha característica. Deberá modificarla tan sólo si tiene la convicción razonable de que se llevará a cabo un ataque con éxito a menos que la modifique.

Si tenemos una contraseña segura, la probabilidad de éxito eficazmente es cero tanto si se cambia el nombre de la cuenta como si no. Por tanto, si tiene una contraseña segura, no tiene ninguna razón de seguridad particular para cambiar el nombre de la cuenta. Además, si tiene en cuenta el principio de que un equipo seguramente será más estable cuantos menos ajustes y cambios se le realice, al igual que pienso yo (un hecho con fundamento, por cierto), es una razón más para no cambiar el nombre de la cuenta de administrador.

Cambia el enfoque a las mitigaciones de poco valor Un problema que suponen las mitigaciones de la seguridad de oscuridad de poco valor es que se arriesgan a cambiar el enfoque de la organización de las mitigaciones de valores más altos. Por ejemplo, el tiempo y el esfuerzo que se dedica al cambiar el nombre de la cuenta de administrador no se puede usar en otras acciones. Si las otras acciones proporcionan un valor mayor que el cambio de nombre de las cuentas de administrador, la organización pierde una oportunidad. Es posible que no parezca suponer un costo real, pero imagínese el cambio de nombre de 50.000 cuentas de administrador y se hará una idea.

Peor aún es la posibilidad muy real de que el liderazgo de la organización se confíe una vez que se ha controlado la mitigación de poco valor. Es posible que la administración no siempre entienda el valor mínimo que tienen las mitigaciones de la seguridad por oscuridad y puede que no tome medidas adicionales. En realidad, esto puede suponer un riesgo significativo para la organización, aunque se podría evitar si la administración dedica simplemente tiempo y esfuerzo a entender el valor de las mitigaciones que se implementan.

Administración costosa Por último, en función del éxito de implementar la mitigación, puede llegar a ser bastante costosa de administrar. Si tan sólo establece un objeto de directiva de grupo (GPO) para cambiar el nombre de la cuenta de administrador, el costo es muy bajo. Todos sabrán el nombre, y el costo de la implementación es casi nada. Sin embargo, el valor que ofrece es también bastante mínimo porque, tal como mencioné, cada persona que tenga una cuenta sabrá cuál es el nombre. De esta forma, para obtener un gran valor de esta mitigación, necesita usar diferentes nombres en host y esto empieza a encarecer la administración del sistema.

Sería mucho mejor usar una herramienta como passgen (protectyourwindowsnetwork.com/tools.htm) para establecer una contraseña completamente aleatoria de 100 caracteres en todas las cuentas de administrador a través de la red y usar cuentas diferentes para la administración diaria. Debido a que la cuenta de administrador es básicamente para propósitos de recuperación ante desastres (salvo en Windows Small Business Server 2003), esta situación no debería impresionar a su sistema de administración de redes. Además, el atacante tendría más oportunidades de encontrar una aguja en el fondo del océano Pacífico que de adivinar correctamente la contraseña de cualquiera de sus cuentas de administrador. Al centrarse en las contraseñas seguras y únicas, los cracker inexpertos pueden intentar adivinar lo que quieran.

Todo se reduce a la administración de riesgos

Virtualmente, las medidas de seguridad por oscuridad se pueden analizar de la manera siguiente. Todos los esquemas tienen ventajas y desventajas, y el enfoque correcto para una organización no se ajusta necesariamente a una organización diferente. Por último, esto supone un problema para la administración de riesgos. ¿Pesan más los riesgos que los costos de implementar la solución? Todas las decisiones que tome para proteger sus activos de información deben estar bien documentadas en función de la administración de riesgos y rara vez será como elegir entre negro o blanco.

Es cierto, ya se han tomado por usted algunas decisiones. Por ejemplo, mientras con toda certeza puede elegir no cifrar información de la tarjeta de crédito ni almacenar los códigos de verificación de la tarjeta de crédito, es probable que cualquier acción proporcione la pérdida de capacidad para aceptar tarjetas de crédito como modo de pago. La posible repercusión negativa de dicha decisión hacia su negocio es tal que ni siquiera tiene elección. En otras palabras, debido a que con toda certeza es mayoritariamente una decisión de la administración de riesgos, es bastante fácil de tomar.

Igualmente, también es cierto que nadie en su sano juicio conectaría una red inalámbrica abierta al servidor de la red de comercio de una tienda física. Sin embargo, esto no significa que la decisión no sea una decisión de la administración de riesgos. Lo es. Se puede elegir hacerlo y, en ese caso, debería cargar con las consecuencias (que desafortunadamente no suelen suceder).

El paso clave que se debe llevar a cabo es articular con claridad el problema en el que debe centrarse, las soluciones propuestas a dicho problema, y los pros y contras de cada una. Una vez que ha realizado todo esto, tendrá la información necesaria para tomar una decisión bien documentada acerca de la administración de riesgos. Sin dicha información, tomará las decisiones en función de una corazonada, y éstas son las que suelen salir mal.

Jesper M. Johanssones un arquitecto de software que trabaja en el campo del software de seguridad y es editor colaborador de TechNet Magazine. Tiene un doctorado en sistemas de información de administración, más de 20 años de experiencia en el ámbito de la seguridad y es MVP de Microsoft en seguridad empresarial. Su último libro es Windows Server 2008 Security Resource Kit.

Roger Grimes (CPA, CISSP, ingeniero de sistemas de Microsoft (MCSE) de seguridad), consultor jefe de seguridad del equipo ACE de Microsoft, es autor y colaborador de ocho libros acerca de seguridad de equipos, y autor de más de 200 artículos. Es ponente habitual en congresos de seguridad y columnista especializado en seguridad de InfoWorld.

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos. Queda prohibida la reproducción parcial o total sin previa autorización.