Seguridad por oscuridad

De Wikipedia, la enciclopedia libre

En criptografía y seguridad informática, seguridad por oscuridad (a veces seguridad por ocultación) es un controvertido principio de ingeniería de seguridad, la cual intenta utilizar el secreto (de diseño, de implementación, etc.) para asegurar la seguridad. Un sistema que se apoya en la seguridad por ocultación puede tener vulnerabilidades de seguridad teóricas o prácticas, pero sus propietarios o diseñadores creen que estos puntos débiles no se conocen, y que es probable que los atacantes no los descubran.

[editar] Introducción

Por ejemplo, podría pensarse que esconder una copia de la llave de la casa bajo el felpudo de la entrada sería una buena medida contra la posibilidad de quedar uno atrapado fuera de la casa, por culpa de un olvido o pérdida de la llave de uso habitual. Entonces estaríamos fiándonos de la seguridad por ocultación. La vulnerabilidad de seguridad teórica sería que alguien pudiera entrar en la casa abriendo la puerta con la copia de la llave. Sin embargo, los dueños de la casa creen que la localización de la llave no es conocida públicamente, y que es improbable que un ladrón la encontrara. En este ejemplo, dado que los ladrones suelen conocer los escondites frecuentes, habría que advertir al dueño de la casa contra esta medida.

En criptografía, lo contrario a la seguridad por ocultación es el principio de Kerckhoff de finales de 1880, que indica que los diseñadores del sistema deberían asumir que el diseño completo de un sistema de seguridad es conocido por todos los atacantes, con la excepción de la clave criptográfica: "la seguridad de un cifrado reside enteramente en la clave". Claude Shannon lo reformuló como "el enemigo conoce el sistema". Históricamente, la seguridad por ocultación ha sido un apoyo débil sobre el que descansar en materia de criptografía. Código oscuro, cifrados y sistemas criptográficos han cedido repetidamente bajo los ataques sin importar el grado de ocultación de sus vulnerabilidades.

El movimiento de la divulgación total va más lejos, sugiriendo que los defectos de seguridad deberían ser divulgados lo antes posible, retrasando la información no más de lo necesario para lanzar una corrección o rodeo (workaround) de la amenaza inmediata.

[editar] Argumentos contra la seguridad por oscuridad

Muchos argumentan que la seguridad por oscuridad es débil. Si la seguridad de un sistema depende única o principalmente de mantener oculta una debilidad, entonces, claramente, si esa debilidad es descubierta, la seguridad se compromete fácilmente. Se argumenta que mantener ocultos los detalles de sistemas y algoritmos ampliamente utilizados es difícil. En criptografía, por ejemplo, hay un buen número de ejemplos de algoritmos de cifrado que han pasado a ser de conocimiento público, bien por ingeniería inversa (ej. A5/1), bien por una fuga de información (ej. RC4).

Más aún, el mantener algoritmos y protocolos ocultos significa que la revisión de seguridad está limitada a unos pocos. Se argumenta que permitir a cualquier persona revisar la seguridad repercutirá en una pronta identificación y corrección de cualquier fallo o debilidad.

[editar] En la práctica

Los operadores, desarrolladores y vendedores de sistemas que confían en la seguridad por oscuridad a menudo mantienen en secreto que sus sistemas tienen fallos, para evitar crear desconfianza en sus servicios o productos y por tanto, en su imagen de mercado. Es posible que esto pudiera conducir en algunos casos a una representación fraudulenta de la seguridad de sus productos, aunque la aplicación de la ley a este respecto ha sido poco contundente, en parte porque las condiciones de uso impuestas por los vendedores como parte del contrato de licencia redimen (con más o menos éxito) sus aparentes obligaciones bajo el estatuto legal de muchas jurisdicciones que requieren una adecuación para el uso o estándares de calidad similares.

A menudo esos diseñadores o vendedores, o incluso ejecutivos, realmente creen que han garantizado la seguridad al mantener el diseño del sistema en secreto. Para quienes abordan la seguridad de esta manera les resulta difícil tener la suficiente perspectiva para darse cuenta de que están dirigiéndose a un problema, y a veces un gran problema. El autoengaño o la ignorancia son generalmente problemas muy difíciles que tienen consecuencias (casi universalmente) desafortunadas.

Estas prácticas de seguridad dejan a los usuarios frente a problemas cuando el software que usan está deliberada o accidentalmente ocultado, como ha ocurrido otras veces:

• Diebold — software de voto electrónico; publicación aparentemente accidental en un sitio web oficial.
• Microsoft — Windows y otros; penetración supuestamente deliberada en una red de desarrollo corporativa.
• RSADSI — algoritmos criptográficos; codigo de RC4 probablemente publicado con intención en Usenet.
• Cisco — sistema operativo de encaminadores; exposición accidental en una red corporativa.
• Muchos otros ejemplos.

Cuando se usa software seguro por estar oculto de manera amplia, existe un riesgo potencial de problema global; por ejemplo, vulnerabilidades en las diferentes versiones del sistema operativo Windows o sus componentes obligatorios como su navegador web Internet Explorer, o sus aplicaciones de correo electrónico (Microsoft Outlook o Outlook Express) han causado problemas a lo largo y ancho del planeta cuando virus, troyanos, gusanos y demás se han aprovechado de ellas.

Del software que es deliberadamente lanzado como Open Source no puede decirse, ni en la teoría ni en la práctica, que se apoya en la seguridad por oscuridad (el diseño está disponible públicamente), pero puede también experimentar desastres de seguridad (por ejemplo, el Gusano Morris de 1988 se difundió a través de alguna oscura vulnerabilidad -- aunque ampliamente visible a aquellos que se molestaron en mirar), aunque la frecuencia y gravedad de las consecuencias han sido bastante menos graves que en el software propietario (es decir, secreto). La razón de esta divergencia se atribuye a la teoría de que muchos ojos eliminan fallos.

[editar] Nota histórica

Por traducir...

[editar] Véase también

• inside job
• Secure by design

[editar] Enlaces externos

• A Model for when Disclosure Helps Security: What Is Different About Computer and Network Security? by Peter P. Swire
• Eric Raymond on Cisco's IOS source code 'release' v Open Source
• http://www.eplaw.us/data/ComputerSecurityPublications.pdf Computer Security Publications:
• Información de seguridad informatica

Information Economics, Shifting Liability and the First Amendment] by Ethan M. Preston and John Lofton