(La entrada de hoy es la primera —pero no última— colaboración de Francisco Benet, un amigo de algunos de nosotros —y familia de algún otro— que tiene gran experiencia en la gestión e integración de sistemas, protección de datos de carácter personal y evaluación de soluciones de integración de software y hardware, entre otros aspectos. Esperamos que les guste.)
Habitualmente estamos acostumbrados a hablar de firewalls, defensa en profundidad y perimetral, detectores de intrusión y otros tantos artilugios tecnológicos que nos van a ayudar a mejorar la seguridad de nuestros sistemas. Pero nos dejamos por el camino puntos que son al menos igual de importantes; que no sustituyen pero se complementan entre ellos: la seguridad del código.
Es obvio que la seguridad del código no es algo cuantificable, ya que nunca podremos hacer pruebas absolutas de nuestro código, pero si que podemos dotar a nuestra metodología de procedimientos que nos permitan realizar tareas de prevención; por ejemplo auditorías de código o tests de intrusión de aplicación. No se trata de intrusión a nivel de versión del S.O., sino más bien de intrusión en cuanto a buffer overflows, cross site scripting o ataques de Ajax contra la aplicación. Y tampoco hablamos de parar el ciclo de desarrollo y dejarlo estanco hasta que no pase las pruebas correspondientes y se tenga el check del Mr. Responsable de Seguridad que todo-lo-sabe.
Centremos el tiro.
Lo que necesitamos realmente es convertirnos para que nuestra metodología incluya aspectos básicos como la definición de buenas prácticas en la programación orientadas a la calidad y a la seguridad. Si ponemos un porcentaje de comentarios dentro del código para mejorar su legibilidad y mantenimiento, ¿por qué entonces no validamos el uso de la memoria o los frameworks de desarrollo que usamos? Es necesario que las metodologías adopten estrategias que mejorando la calidad nos garanticen seguridad.
¿Cómo podemos hacerlo?
Incluyendo validadores de código, evaluando la seguridad de nuestros frameworks, valorando nuevas soluciones a problemas complejos, sin olvidar ser muy prácticos. Y debemos ser prácticos para poder garantizar los ciclos de desarrollo y las fechas, y también en seguridad, porque la seguridad no es rígida; siempre hay que buscar el equilibrio en la solución a adoptar. No es lo mismo crear un programa para gestionar un videoclub que generarlo para gestionar un banco; aunque hay mucha similitud (más de la que parece, al margen de los aspectos legales de LOPD), el “atractivo” no es el mismo, igual que no tiene el mismo “atractivo” la página web de cualquier partido politico de primera línea que la del Real Huesca Club de Fútbol, o la de la Asociación de Cazadores de Ornitorrincos. Por lo tanto, pese a que nuestra metodología es muy fiable y la mejor del mundo, ¿debemos evaluar igual ambos proyectos? Desde mi humilde punto de vista: no. La aplicación bancaria la certificaremos y explotaremos hasta que estemos seguros que el 99% de los ataques actuales están resueltos, mientras que la del videoclub funcionalmente será igual, pero tal vez se nos escape algún aspecto de seguridad “avanzada”.
Mantengamos la seguridad de la aplicación con un nivel mínimo exigible, que por definición debe ser alto, exijamos un nivel excelente a aplicaciones con alto riesgo (bien por los datos que maneja, bien por su exposición al público, bien por lo “atractiva” que sea, o por un mix de todos estos factores), pero seamos prácticos y flexibles; ganemos la batalla a esa seguridad rígida que sólo añade costes y tiempos extra, mediante la inclusión de técnicas de seguridad en la metodología de desarrollo. Re-evaluemos nuestros sistemas.
Un ejemplo.
Actualmente y desde hace algún tiempo están muy de moda los frameworks de desarrollo —por no hablar del MDA—; que sí tal framework se integra con tal otro, que si esto es un ORM de la leche, que si me abstraigo de esto y de lo otro, y que chachi que soy. Y ahora diseño una aplicación web que usa AJAX y usa un ORM que me evita el SQL-Injection, y mis frameworks me aseguran que no necesito ni seguridad; está integrada con la aplicación como el airbag en mi coche. ¿Has ido al taller? Resulta que cometemos el primer error: la seguridad del código esta integrada en mi framework. Y de repente nos vemos en la siguiente situación:
- No validamos la entra de datos en la web.
- No validamos el uso de AJAX.
- No validamos el uso de Javascript en relacion a los dominios de seguridad del navegador.
La cuestión a la que voy es que la seguridad nunca está integrada en el framework; en cualquier caso éste facilita el desarrollo de código, pero eso no nos salva de que éste esté expuesto a vulnerabilidades por una mala ‘práctica’. Eso ya no es culpa de Microsoft; ahora somos nosotros los culpables.
Porque no es lo mismo comprar software que hacer software.
(N.d.E.: Hoy, de momento, no hay encuesta, por lo que continuamos con la anterior. Estamos en Fallas y estoy poco imaginativo. Pueden proponer alguna si lo desean, y si no, pensaré algo para antes del lunes. En cualquier caso, como siempre, pasen un buen fin de semana.)
