La Receta

La semana pasada y esta llevo hablando mucho del tema de la apertura de código, y como dice el Robé: "Cortame las piernas y aún podré volar", asín que, por lo cualo, os dejo un texto de una participación en Securmatica esta semana pasada de un amigo (se notan las ideas) y que tiene un estudio de un Security Researcher, que está pa examinarnos de él!:

"Existe en los medios especializados cierto debate sobre la incidencia del modelo de apertura del código, en la seguridad del mismo.

Si bien resulta un debate interesante, quizá pueda estar parcialmente incompleto dado que la apertura o no del código como criterio de seguridad tiene una relevancia muy relativa respecto a la totalidad de factores que la afectan de forma muy determinante.

Algunos miembros de las comunidades Open-Source argumentan que el código abierto es más seguro porque las vulnerabilidades son mas fáciles de detectar y corregir. Sin embargo, la comunidad de Software cerrado (o compartido) argumenta que el acceso al código facilita la labor a los atacantes.

En cualquier caso, no debemos caer en el error de simplificar de esta manera el problema.

Algunos estudios recientes (Cambridge University, Ross Anderson)
http://www.ftp.cl.cam.ac.uk/ftp/users/rja14/toulousebook.pdf
apuntan a que la apertura del código, ayuda de forma similar a “atacantes” (pueden desarrollar exploits más fácilmente) y “defensores” (pueden encontrar bugs y corregirlos mas fácilmente). El estudio concluye que, en un mundo perfecto, y en sistemas suficientemente amplios y complejos para que tenga sentido la aplicación de un modelo estadístico, el atacante y el defensor son afectados por igual por la apertura del código.

Sin embargo, los factores “humanos” juegan un papel mucho más determinante. Son los que realmente rompen esta simetría sustancialmente. ¿Porque fracasan con frecuencia los intentos de la comunidad open Source de establecer un modelo permanente y predecible de revisión de código?

Security focus aporta algunas respuestas al respecto basadas en experiencias reales (http://www.securityfocus.com/columnists/218) donde el principal fracaso reside en la falta de estímulo o motivación de los programadores para hacer el trabajo “pesado”, “sistemático” y continuo que supone una autentica auditoria de Software. En su lugar, es mas atractivo encontrar vulnerabilidades, explotarlas, y obtener el reconocimiento del resto de la comunidad.
La única contribución puntual que alimentó el proyecto, pero que no evitó su fracaso, vino del mundo académico y de entornos sin demasiada experiencia (estudiantes bajo la supervisión de un profesor)

[Extraido del artículo: "In discussing Sardonix's fall, Crispin Cowan, the project's leader, was harsh in his appraisal of the open-source community: he asserted that security researchers were only interested in finding splashy bugs and posting them to security mailing lists. I think that's oversimplifying the matter.Members of the security community tend to audit software either for a business interest, or for their own private use. Some of them do, indeed, disclose the issues they discover to mailing lists, winning reputations as Kung Fu masters. But many sit on their findings, because kudos on a mailing list or a software auditing website can never compare to the reward of unauthorized access to a high-profile system."]

Sin embargo, el modelo de código compartido, muy extendido entre los fabricantes de software, parte de diferentes conceptos:

1.- Los “ojos” que revisan el código han de ser los necesarios, pero EXPERTOS. Así como no dejar ninguna duda sobre la existencia de “motivación” o “estímulo”.
2.- La revisión de código es sólo una parte de una aproximación global. En el caso de Microsoft, hablamos del Secure Development LifeCycle (SDL). Durante el proceso de desarrollo se incluyen desarrollos de “modelos de amenazas”; herramientas de análisis de código; reviews y chequeos de seguridad durante los “Security pushes”; final security reviews por terceras partes. Etc..
En resumen, la apertura o no del código por si misma no es un criterio de seguridad. Los “atacantes” y “defensores” se pueden ver afectados por igual. Los entornos de desarrollo y teesteo en los que se producen ambos modelos, si tienen algunas diferencias evidentes que rompen esa simetría a favor de los modelos profesionales de desarrollo. No en vano, un entorno profesional dedica un 1% del tiempo destinado a resolver una incidencia de seguridad a su desarrollo, mientras que el 99% restante se dedica a pruebas intensivas"