El estado de la Seguridad Agil/Lean (Respaldo del Blog)


(ChileAgil) #1

Este es un artículo del viejo blog de chileagil, publicado el 19 febrero de 2012 por Cristián Rojas

Durante el tiempo que llevo como consultor y profesor de seguridad de software, un tema que ha rondado bastante en mi cabeza es si realmente la seguridad de la información en general, y la seguridad de software en particular, son temas importantes en la comunidad tecnológica de nuestro país. Y la verdad es que esta duda no deja de ser importante, sobre todo en tiempos en los cuales las amenazas al software se hacen cada vez más ubicuas, se van profesionalizando y además están dejando de ser sólamente un tema para “hackers”, ya que las herramientas de ataque están al alcance de la mano de cualquier usuario, y pueden ser utilizadas incluso para el llamado cyberactivismo.

Es por eso que, después de meses en los cuales pasé de considerar que la seguridad es importante, a darme el porrazo en el suelo de que tal vez no lo sea para el resto de la comunidad, decidí dar un primer paso y consultar con la comunidad Ágil/Lean, una comunidad la cual he observado que prospera cada día más, la cual integra nuevas herramientas y crea herramientas que crean valor y lo crean rápido. Decidí preguntarles qué tan importante es para ellos la seguridad, y para ello lancé una encuesta en Google Docs.

Y los resultados fueron sorprendentes. La conclusión general es que la seguridad es importante para la comunidad Ágil/Lean, sin embargo muchas veces no saben cómo integrarla a sus procesos de desarrollo. ¿Por qué ocurre esto? Principalmente por el hecho de que nosotros como desarrolladores, la mayor parte del tiempo, aprendemos a programar y listo. No aprendemos a hacerlo bien y mucho menos en forma segura. Además hay otros factores:

  • “Sinergia”: Eso de que el todo es mayor que la suma de sus partes, es una falacia en seguridad. La verdad es que, muchas veces tomamos cosas que son seguras cada una por su cuenta, sin embargo al integrarlas en una sóla solución, surgen las vulnerabilidades.
  • Mientras nosotros descansamos en la abstracción que nos ofrecen nuestras herramientas de desarrollo, los chicos malos se fijan en los detalles.
  • Decimos que trabajamos usando tecnología moderna, pero aún utilizamos tecnologías desarrolladas en otra época (UNIX, BSD Sockets, etc.) las cuales han tenido muchas veces que ser parchadas.
  • Preferimos hacer cosas bacanes en vez de andar pensando cómo, quién y cuándo va a reventar nuestro software.
  • Por el mismo punto anterior, ¿Quién haría user stories de seguridad?

¿Qué hacer? La respuesta a esta pregunta es difícil, ya que el punto de partida es educar a los miembros del equipo de desarrollo: Que conozcan qué es un SQL Injection, un Cross-Site Scripting, un Buffer Overflow, cómo aplicar conceptos como el Principio de Privilegio Mínimo o el Principio de Completa Mediación, etc. Una medida interesante es partir “desde abajo”, utilizando técnicas como fuzzing (pruebas automatizadas de penetración) o análisis estático de código a la hora de la integración continua. ¿Respecto de las user stories? Una técnica que podría servir es tomar un miembro del equipo versado en seguridad y convertirlo en “anticliente”, que piense cómo abusar de la aplicación y genere las llamadas “abuser stories” o “evil user stories”.