it-swarm-es.com

¿Cómo definir los requisitos de seguridad para garantizar que los desarrolladores ... no brinden seguridad por oscuridad?

Traté de explicar que la seguridad por oscuridad no debería usarse, ¡pero digamos que fui desafiado!

Recibí la respuesta para enumerar la seguridad conocida por oscuridad que conozco, como una especie de mala práctica y que no debe seguirse. De hecho, es bastante difícil definir la seguridad por oscuridad, pero no estoy convencido de que enumerar una mala práctica tampoco sea la forma correcta.

Por eso mis preguntas:

  • ¿Alguien tiene una lista de soluciones de seguridad por oscuridad que pueda enumerar?
  • ¿No sería mejor definir requisitos que detengan la seguridad por oscuridad? pero ¿cómo definir esos requisitos? Me preguntaba si alguien sabe cuáles serían los requisitos adecuados para configurar para no permitir la seguridad por oscuridad.
10
Phoenician-Eagle

Un ejemplo es el sistema de codificación de contenido para evitar que se copien los DVD. Si bien se desconocía el sistema de codificación, esto funcionó. Luego, un adolescente llamado Jon Lech Johansen lo descubrió, escribió DeCSS y se rompió.

Como señala @GrahamLee, los mecanismos de seguridad en los que se debe confiar deben funcionar aún cuando los malos los conozcan.

En estos días, la criptografía proporciona seguridad en muchas aplicaciones, por lo que es fundamental que se implemente correctamente. Debido a que las matemáticas están más allá de la mayoría de las personas, hay una escuela de pensamiento que aboga por publicar los algoritmos y dejar que las personas de todo el mundo intenten encontrar fallas. Lo bueno: muchos ojos. La desventaja: si el algoritmo ya está implementado, un atacante puede encontrar una falla y poder usarlo, por lo que hacerlo antes de la implementación es muy útil.

El otro punto de vista es ocultar el algoritmo para evitar que los atacantes sepan cómo funciona: el problema con la oscuridad es que se ha demostrado una y otra vez que confiar en la seguridad a través de la oscuridad falla porque en algún momento los malos descubren el secreto.

Vale la pena leer esto publicación de Bruce Schneier, un conocido oponente de la seguridad a través de la oscuridad y autor de varios algoritmos criptográficos que han sido probados por la comunidad, como un ejemplo de dónde la oscuridad ha funcionado, pero solo porque los criminales no se enteraron del plan.

No sé si realmente es posible responder la última parte de su pregunta sin más contexto. Por ejemplo, si se trata de un código desarrollado por terceros, podría exigir una revisión del código, pero lo que realmente podría buscar es un tercero que publique sus algoritmos/código, etc., como código abierto.

9
Rory Alsop

El contraejemplo canónico de la seguridad a través de la oscuridad es el Principio de Kirchkoffs: los diseñadores de criptografía deben asumir que el sistema criptográfico será capturado por el enemigo, por lo que aún debe ser seguro si se conoce todo sobre él excepto la clave .

Sin embargo, tenga en cuenta que esto no dice que la oscuridad sea mala y no se debe confiar en ella: dice que la oscuridad no puede ser la única defensa. Eso es porque es frágil. Pero la oscuridad aún puede ralentizar o disuadir a los atacantes no calificados.

7
user185

La oscuridad es lo que no se puede cuantificar.

La seguridad adecuada viene con estimaciones de costos. Decimos que una clave de cifrado de 128 bits es segura porque podemos estimar cuánto costaría (en procesadores dedicados y energía eléctrica, y finalmente en dólares) encontrar la clave mediante una búsqueda exhaustiva (probando todas las claves posibles de 128 bits). Cuando el costo es mucho más alto de lo que un atacante estaría dispuesto a gastar y, en particular, cuando es mucho más alto de lo que podría gastar cualquier atacante con tecnología basada en la Tierra, entonces hemos logrado la seguridad.

Cuando tal estimación no es posible, entonces es seguridad por oscuridad. Por ejemplo, suponga que tiene algún tipo de sistema de cifrado en un software que mantiene en secreto. ¿Cuánto secreto es ese software? Está escrito en algunos discos duros. Ha sido desarrollado en alguna parte, el código fuente existe, almacenado en alguna parte. ¿Qué tan difícil es para un atacante recuperar el algoritmo? Los archivos almacenados se filtran en muchos lugares, p. Ej. computadoras viejas desechadas, laptops robadas, indiscreciones de los subcontratistas (el código fuente del software está en archivos, pero también en el cerebro de algunos programadores) ... si el atacante puede hacerse con el binario, puede desmontarlo, un proceso que es no inmediata, sino limitada únicamente por el ingenio del atacante.

El punto de todo esto es que, si bien hacer que algún código sea secreto hace que la tarea sea más difícil para el atacante, es muy difícil decir cuánto se vuelve más difícil, cuando quieres expresarlo en dólares.

Así que aquí está mi respuesta a su pregunta: para evitar que los implementadores utilicen la seguridad por oscuridad, ordene que deben producir estimaciones de costos justificadas detalladas para los ataques.

6
Thomas Pornin

Si está tratando de construir pautas de codificación seguras para desarrolladores internos, esa rueda ya se ha inventado. OWASP , por ejemplo, tiene una visión general amplia que incluye medidas cautelares contra confiar en la seguridad a través de la oscuridad; y CERT tiene estándares muy detallados para C y C++.

1
user502