Métodos ágiles de desarrollo y seguridad de aplicaciones

En este artículo vamos a dar una serie de pautas para el desarrollo de aplicaciones software seguras mediante las llamadas técnicas ágiles de desarrollo. Primero haremos una breve revisión de las características de estos métodos y luego veremos como adaptarlos para crear productos software con el menor nivel de riesgo residual.

Problemas típicos del desarrollo tradicional de sistemas

Los llamados métodos ágiles de desarrollo de software surgen hace aproximadamente 20 años como una reacción al fracaso de los métodos tradicionales para superar los problemas típicos de los proyectos software:

  • Finalización fuera de plazo y presupuesto
  • Incumplimiento frecuente de las expectativas de los usuarios en cuanto a la utilidad del producto final
  • Problemas en la calidad del software entregado

El método tradicional de desarrollo de software (el tan denostado método “en cascada”) se basa en hacer una estimación del coste y el calendario para la entrega del producto software a partir de una descripción funcional (requisitos) de lo que se espera que el sistema tenga que hacer; es decir, se parte a priori de una idea más o menos detallada del alcance del sistema. A partir de esta planificación se abordan fases sucesivas de análisis, diseño, construcción, pruebas y entrega del producto, bajo el supuesto de que una fase no empieza hasta que la precedente se da por cerrada definitivamente.

MET_WATERFALL_01

Obviamente este método no suele funcionar bien en una gran mayoría de situaciones en donde los requisitos iniciales no están claros desde el principio y pueden sufrir frecuentes cambios y en donde sea necesaria la entrega rápida del producto. Por ello, pronto surgieron variantes del método en cascada que daban cabida a revisitar fases previas del proceso para hacer ajustes y dotarle de mayor flexibilidad.

MET_WATERFALL_02

Métodos ágiles

En los métodos ágiles por el contrario, no se parte de un alcance funcional concreto acotado sino de un presupuesto inicial y una fecha de finalización del proyecto. A partir de aquí se empieza a desarrollar funcionalidad en iteraciones incrementales hasta agotar el presupuesto o alcanzar la fecha de cierre. La idea es ir poco a poco construyendo y entregando al usuario/cliente un producto completamente funcional desde el principio. En cada iteración, la funcionalidad se va incrementando en estrecha colaboración con el usuario final. Es decir, la funcionalidad del producto se va definiendo de manera colaborativa, poco a poco, a medida que el proyecto se desarrolla. Entre las principales ventajas:

  • Entrega de software que funciona desde el principio.
  • Se evita desarrollar funcionalidad superflua que finalmente no es usada
  • Mayor calidad del producto.

MET_INCREMENTAL_02

El carácter radical y la originalidad del enfoque ágil de desarrollo queda recogida en los principios del llamado manifiesto ágil, cuya versión oficial en español transcribimos a continuación:

Principios del manifiesto ágil

  • Nuestra mayor prioridad es satisfacer al cliente
    mediante la entrega temprana y continua de software
    con valor.
  • Aceptamos que los requisitos cambien, incluso en etapas
    tardías del desarrollo. Los procesos Ágiles aprovechan
    el cambio para proporcionar ventaja competitiva al
    cliente.
  • Entregamos software funcional frecuentemente, entre dos
    semanas y dos meses, con preferencia al periodo de
    tiempo más corto posible.
  • Los responsables de negocio y los desarrolladores
    trabajamos juntos de forma cotidiana durante todo
    el proyecto.
  • Los proyectos se desarrollan en torno a individuos
    motivados. Hay que darles el entorno y el apoyo que
    necesitan, y confiarles la ejecución del trabajo.
  • El método más eficiente y efectivo de comunicar
    información al equipo de desarrollo y entre sus
    miembros es la conversación cara a cara.
  • El software funcionando es la medida principal de
    progreso.
  • Los procesos Ágiles promueven el desarrollo
    sostenible. Los promotores, desarrolladores y usuarios
    debemos ser capaces de mantener un ritmo constante
    de forma indefinida.
  • La atención continua a la excelencia técnica y al
    buen diseño mejora la Agilidad.
  • La simplicidad, o el arte de maximizar la cantidad de
    trabajo no realizado, es esencial.
  • Las mejores arquitecturas, requisitos y diseños
    emergen de equipos auto-organizados.
  • A intervalos regulares el equipo reflexiona sobre
    cómo ser más efectivo para a continuación ajustar y
    perfeccionar su comportamiento en consecuencia.

Los métodos ágiles están imponiéndose como una alternativa para desarrollar software de calidad, de manera rápida, en entornos de negocio cambiantes con alto grado de incertidumbre.

Dentro de los métodos ágiles podemos citar aquellos orientados a la gestión del proyecto, como pueden ser Scrum o Kanban, y otros orientados a los métodos de desarrollo de software, como pueden ser Extreme Programming (XP) o Software Lean Development, por citar algunos.

Características

Los métodos ágiles de desarrollo de software comparten algunas características comunes:

  • Estrecha colaboración entre los desarrolladores y los usuarios/clientes, quienes trabajan conjuntamente con el objetivo de crear el mejor producto.
  • La programación del software se va realizando en ciclos incrementales. En cada uno de los ciclos se aborda el desarrollo completo de un conjunto acordado de funcionalidad y se pasa por todas las etapas del ciclo normal de desarrollo, desde el análisis, diseño, programación, pruebas y entrega.
  • Todo incremento de desarrollo viene impulsado por las llamadas “historias de usuario” (una forma simplificada de describir requisitos de usuario o casos de uso de alto nivel). Estas historias de usuario describen lo que el usuario final espera del sistema. A partir de estas historias de usuario, los responsables del proyecto identifican tareas concretas y casos de prueba que habrá que llevar a cabo en el incremento de desarrollo.
  • Esfuerzo activo por eliminar todo aquello que resulte superfluo y que no sea esencial para aportar valor directo al cliente/usuario. Se debe eliminar toda burocracia o proceso innecesario. En especial, la documentación técnica suele “adelgazarse” o eliminarse totalmente, compensando esto con comentarios en el código fuente y con la definición de casos de prueba. En los métodos tradicionales solía ocurrir que la documentación del sistema costaba casi tanto esfuerzo como la propia programación y aportaba poco valor ya que solía quedarse fácilmente desactualizada.

De las historias de usuario a las tareas de proyecto

Como hemos visto, las historias de usuario constituyen los requisitos funcionales del sistema que habrá que construir. En los métodos ágiles, el cliente / usuario es ayudado por el “dueño del producto” (product owner) para crear un conjunto de historias de alto nivel que se formulan típicamente en la forma: “como usuario del sistema quiero poder…:” Este conjunto de historias de alto nivel, priorizadas y seleccionadas para ser acometidas en uno de los incrementos de desarrollo, serán descompuestas por los miembros del equipo en características funcionales del sistema y tareas concretas. Por ejemplo, partiendo de la historia de usuario “como usuario del sistema quiero poder registrarme en el sistema y crear un perfil de usuario “, una característica funcional que se puede derivar es: “el sistema deberá tener una página de alta y gestión de perfiles de usuario registrados”, así como la siguiente tarea: “deberá verificarse que la dirección de correo electrónico de un usuario registrado no sea igual que la de otro usuario ya registrado”.

Criterios de aceptación

Una característica muy útil de las historias de usuario es que deben llevar asociadas los criterios de aceptación; es decir el conjunto de circunstancias objetivables y no ambigüas que habrán de cumplirse para poder determinar si la historia de usuario ha sido implementada correctamente. Estos criterios de aceptación son la base para el desarrollo de casos de prueba detallados. Los criterios de aceptación especifican aspectos del comportamiento del sistema desde la perspectiva del usuario y también suelen reflejar requisitos no funcionales del sistema, como por ejemplo los de seguridad o rendimiento de la aplicación. En muchos casos, el detalle de estos criterios de aceptación se usa como sustituto del tradicional diseño detallado.

Críticas a los métodos ágiles

Los métodos ágiles presentan sin duda un enfoque valioso, especialmente en proyectos pequeños o medianos; sin embargo, también cosechan algunas críticas:

  • Es difícil estimar de antemano el coste real de un proyecto.
  • Sólo funciona bien cuando los miembros del equipo de desarrollo son expertos.
  • Sólo proporcionan las ventajas esperadas con equipos muy motivados y en los que el compromiso y la participación de ambas partes, desarrolladores y usuarios/clientes, es alta.
  • Los productos software desarrollados con estos métodos suelen mostrar deficiencias de diseño técnico.
  • Los productos software desarrollados con estos métodos suelen presentar problemas de seguridad.
  • Frecuentemente, los proyectos desarrollados de acuerdo con estos métodos carecen de documentación técnica realmente necesaria para el mantenimiento y posterior operación del sistema.
  • Los métodos ágiles no suelen ser recomendables para proyectos de gran complejidad técnica.

Métodos ágiles y seguridad

La pregunta que se plantea es si tienen las prácticas de desarrollo de software seguro cabida en los métodos ágiles. Dado que estos métodos consideran como prescindible toda documentación técnica “excesiva” y el desarrollo de toda funcionalidad que no aporte un valor directo observable para el usuario final / cliente, parecería (y muchas veces es así) que los requisitos de seguridad y las actividades encaminadas a verificar el riesgo residual de las aplicaciones son candidatos perfectos a ser desechados como superfluos y “enemigos” naturales de la agilidad.

Los cierto es que sea cual sea el método de desarrollo usado para el desarrollo, la seguridad suele ser considerada habitualmente como un añadido de última hora; como un parche que hay que añadir al sistema ya construido cuando se presentan los problemas. A esta circunstancia también contribuye el hecho de que los desarrolladores e ingenieros de software suelen recibir poca formación en materia de seguridad de aplicaciones y los usuarios / clientes no suelen identificar en primer lugar la seguridad como un valor a perseguir.

A primera vista podría por tanto parecer que los métodos ágiles son particularmente incompatibles con la seguridad, pero esto no tendría que ser así en absoluto. De hecho, los métodos ágiles propician (al menos en teoría) el desarrollo de software de alta calidad, primando la excelencia del diseño y las pruebas continuas del software. Por ello, desde mi punto de vista es fácil incluir las prácticas de desarrollo de software seguro en el contexto de un proyecto ágil. A continuación vamos a dar unas:

Pautas para el desarrollo de aplicaciones seguras en proyectos ágiles.

Equipo multidisciplinar

El equipo de un proyecto ágil-seguro debe contar con al menos un experto en seguridad de aplicaciones. Dicho experto deberá colaborar con los desarrolladores y con el “dueño del producto” asegurando que las principales vulnerabilidades del sistema se identifican de antemano y que el producto sea construido libre de estas vulnerabilidades. Otra tarea importante del experto es dar formación al resto del equipo de desarrollo de modo que estos a su vez empiecen a adquirir experiencia que podrá ser usada en etapas o proyectos posteriores.

Identificación de las “casos de abuso” del sistema

El experto de seguridad del equipo ayudará al “dueño del producto” en la identificación temprana de los casos de abuso. Estos casos de abuso son una especie de “historias de usuario” contadas desde la perspectiva de los usuarios maliciosos (hackers, defraudadores que tratarán de explotar las vulnerabilidades del sistema para sacar provecho) y deben ser incluidas en el repositorio de requisitos del sistema como algo que el usuario legítimo no esperaría como deseable en el sistema a construir. Estos casos de abuso deben ser identificados a partir de un análisis de riesgos inicial y que deberá ir siendo revisado a medida que el proyecto avance.

Establecimiento de requisitos de seguridad y criterio de aceptación del producto

A partir de los casos de abuso se identificarán requisitos de control y seguridad de la aplicación que habrán de ser incorporados como parte del catálogo de requisitos generales del proyecto. Los requisitos de control se podrán documentar como parte del criterio de aceptación de las historias de usuario. Esta estrategia es bastante útil porque implica que se desarrollen pruebas de verificación de que los controles de seguridad se han implementado como es debido y porque permiten asociar la aceptación por parte del usuario / cliente del sistema al cumplimiento de estos criterios de seguridad.

Revisiones del diseño global

Dentro de cada incremento de desarrollo, deberá planificarse formalmente una tarea encaminada a revisar el diseño global del sistema. Esta revisión no solo irá encaminada a maximizar la calidad del diseño del sistema, sino también a identificar posibles escenarios de ataque y amenazas que puedan producirse como consecuencia del mismo. De los resultados de esta revisión, pueden derivarse nuevas tareas y/o requisitos de seguridad que habrán de ser priorizados e incorporados al catálogo de requisitos del producto.

Uso de herramientas de asistencia para codificación segura

Deberá dotarse al equipo de desarrollo de herramientas que les asistan en las prácticas de codificación segura. Estas herramientas permitirán a los programadores identificar, durante la fase de programación, las posibles vulnerabilidades de seguridad del código y les propondrán alternativas seguras de codificación. De esta manera, se asegura que el código entregado por los programadores está libre de fallos de seguridad típicos; como por ejemplo, cross-site scripting, buffer overflows, inyecciones SQL, etc. En concreto, este proceso de análisis automatizado del código fuente deberá garantizar al menos que el código generado es resistente a las vulnerabilidades del OWASP top ten. Se trata de evaluar el código fuente de manera “estática” en su fase de construcción como primer filtro de detección de vulnerabildiades.

Pen-Testing del sistema

Como una tarea más dentro de cada incremento, deberá planificarse la realización de un test de penetración (pen testing) orientado a detectar vulnerabilidades del producto terminado y en funcionamiento. Se tarta de un segundo filtro de detección de vulnerabilidades dinámico.  De acuerdo con la filosofía ágil de máximo compromiso con la calidad, los resultados de cada test; esto es, las eventuales vulnerabilidades detectadas, deberán ser priorizadas y transformadas en tareas concretas que habrán de ser corregidas dentro del propio ciclo de desarrollo o en fases posteriores. Es recomendable que este tipo de pruebas sean realizadas por expertos internos o externos.

Epílogo

Acabamos aquí este breve repaso a los métodos ágiles y su adaptación para el desarrollo de aplicaciones seguras. Esperemos que esta aportación sea de utilidad para todos aquellos embarcados en la apasionante tarea del desarrollo de aplicaciones.

Un fuerte abrazo y hasta pronto.