Sorpresas en la seguridad de las aplicaciones

Expertos en seguridad (entre ellos el famoso Gary McGraw) llegaron a diez sorpresivas conclusiones después de haber hecho unas entrevistas y análisis. La lectura de las diez "sorpresas" que se llevaron es interesante y la pueden leer aquí. Yo les resumo las tres que me parecieron las más relevantes.

 

a).- No hay métricas mágicas para la seguridad del software y las malas métricas de hecho hacen daño.

Es difícil que alguien venga a decirte que estas son la serie de métricas que debes de usar en tus programas de software para ver qué tan "seguros" son. No existen estas métricas "globales" que todo mundo debería usar. De hecho, usar malas métricas puede llevar a que sean mal interpretadas, abusadas o ignoradas. Lo mejor es crear métricas que funcionen para uno. ¿Cómo indicamos que una aplicación es segura por medio de métricas? Puede ser que no sea suficiente decir simplemente “esta aplicación (es/ no es) segura”.

 

b).- El diseño que contempla la seguridad es difícil (tal vez más de lo que pensamos).

Los problemas de seguridad vienen básicamente en dos fases: en la de diseño (arquitectura) y en la de implementación (codificación). ¿Quién realmente introduce la parte de seguridad en la fase de diseño (arquitectura) y también al momento de codificar? Sí, hacer un buen diseño de seguridad de un programa no es nada trivial, y no muchos lo hacen o lo hacen mal y a la ligera.

 

c).- Los programadores son los últimos en preocuparse por la codificación segura.

Los medios, los consultores y los investigadores de seguridad se preocupan más por el tema de codificación segura que los propios programadores (debería de ser exactamente lo contrario). Lo que les importa realmente a los codificadores es que un programa sea FUNCIONAL, y no realmente seguro en su diseño y en su codificación (que te pida una contraseña no significa para nada que tiene un diseño y una codificación adecuadamente segura). Apuesto una quincena a que en cualquier aplicación hecha "en casa" de una organización promedio podremos encontrar más de 50 vulnerabilidades (al menos). Efectivamente, actualmente realmente nos interesa que una aplicación sirva, no que sea segura en su diseño y codificación.

 

Si tienen unos diez minutos, recomiendo la lectura de las "diez sorpresas".