Cómo encajar las actividades de seguridad en el backlog de un proyecto ágil

Como continuación de  nuestro anterior artículo sobre metodologías ágiles, en este post vamos a analizar con mayor detalle la forma en que las tareas principales de seguridad y gestión de riesgos de un proyecto software tienen encaje en el product backlog del proyecto.

Dentro del desarrollo software  podemos identificar las siguientes  actividades relacionadas con la seguridad:

Actividades de seguridad en el desarrollo de software

Realización de análisis de riesgos  (modelo de amenazas y vulnerabilidades del sistema)

Como norma básica, el análisis de riesgos de la aplicación irá encaminado a la identificación temprana de los escenarios de riesgo principales a los que estará expuesta la aplicación (por ejemplo, en el caso de una aplicación de pagos, un escenario de riesgo relevante sería la usurpación de la identidad del usuario por parte de un delincuente y la realización de pagos fraudulentos). El objetivo es que la aplicación incorpore de manera intrínseca en su diseño las características que la hagan resistente a estas amenazas.

Aunque el análisis de riesgos puede ser una tarea que sea necesario que se lleve a cabo de manera recurrente a lo largo de los distintos incrementos de desarrollo; es importante que en las sesiones iniciales del proyecto, en donde se hace la concepción inicial del producto, se haga una identificación de las principales amenazas, lo que servirá para identificar las características de seguridad básicas del sistema…

Definición de controles para mitigar o eliminar las amenazas

Como hemos visto, las características de seguridad de la aplicación son identificadas como consecuencia del ejercicio de análisis de riesgos. Estas características son los controles que la aplicación deberá incorporar, como por ejemplo, disponer de un sistema de autenticación de usuarios, cifrado de los datos en tránsito, etc…

Análisis estático del código fuente

Durante la fase de programación de la aplicación, la ejecución de herramientas de análisis automatizado del código fuente asistirá a los programadores en su tarea, permitiendo depurar las líneas de código y ayudando a que los programas estén libres de las vulnerabilidades típicas (inyecciones de código, desbordamiento de búffer, etc). En proyectos donde esta tarea no está automatizada, el objetivo se puede cumplir mediante la edición de guías de estándares de codificación segura y revisiones manuales del código generado; sin embargo, este método es normalmente menos eficaz (y ágil) que el basado en herramientas automáticas.

Pruebas funcionales de controles

Una vez que el código está en fase de pruebas, es importante que además de las pruebas típicas de usuario para comprobar que la funcionalidad del programa es la requerida, se efectúen casos de prueba para comprobar que los controles definidos como parte del análisis de riesgos se han implementado de manera efectiva. En esta fase se comprobarán funciones del sistema como el control de acceso, gestión de permisos de usuario, registro de actividades en el log de uso del sistema, cifrado de datos, etc..

Pen testing (evaluación dinámica de vulnerabilidades)

En este tipo de pruebas se  ejecutan sobre el programa en funcionamiento herramientas para verificar que el código está libre de vulnerabilidades. Las herramientas usadas son similares (a veces las mismas) que usarán los hackers para vulnerar la aplicación. Se trata por tanto de un último filtro que complementa a las pruebas de análisis estático del código llevadas a cabo en la fase de programación y normalmente el resultado de estas pruebas debe ser decisivo a la hora de aceptar la entrega del producto.

Otras actividades de seguridad

En esta categoría incluimos tareas del tipo: “documentar la definición de riesgo residual del sistema”, “obtener aprobación del riesgo residual del sistema por parte del cliente y archivar en la documentación del proyecto”, “obtener la certificación PCI del módulo XXXXX, por parte de los auditores externos…

Composición del backlog de un  proyecto ágil

Como vimos en nuestro anterior post, el backlog del producto es el eje alrededor del cual se estructura el trabajo de los equipos de proyectos ágiles. Como ya comentamos, en un proyecto basado en metodologías ágiles, aquello que no está incluido en el backlog, sencillamente, no existe. Por eso es fundamental que las actividades de seguridad tengan un encaje en este repositorio.

Pero, ¿de qué tipo de elementos se compone el backlog de un proyecto?. Pues de los siguientes elementos:

Historias de usuario de alto nivel o épicas

Con este curioso nombre se designan requisitos funcionales de muy alto nivel que se expresan de forma sencilla, típicamente con la fórmula: “Como usuario del sistema, quiero que la aplicación haga…<lo que sea> de modo qué…“. Por ejemplo: “Como usuario del sistema, quiero poder gestionar mis datos de manera sencilla de modo que no pierda mucho tiempo” o “Como usuario quiero que la aplicación asegure la privacidad de mis datos…

Historias de usuario

Las historias de usuario de alto nivel  suelen descomponerse en historias de usuario más concretas y sencillas; por ejemplo: “Como usuario de la aplicación quiero poder bloquear mis credenciales de pago de modo que no puedan ser usadas para pagar” o “Como usuario quiero que la información de mi geolocalización no esté accesible a terceros a menos que yo especifique lo contrario, de modo que se preserve la privacidad”.

El número de niveles de descomposición de las épicas en historias de usuario de menor nivel puede variar dependiendo del proyecto concreto, pero en cualquier caso, esta tarea fundamental es realizada por el “dueño del producto” en colaboración con el resto del equipo técnico del proyecto.

Cómo vimos en nuestro anterior artículo sobre métodos ágiles, existen una serie de casos particulares de historias de usuario que tienen relevancia desde el punto de vista de la seguridad; se trata de:

  • Historias de abuso: Describen situaciones negativas que no deberían producirse con el sistema o aplicación. “Como hacker quisiera poder vulnerar el control de acceso de la aplicación, de modo que pueda usurpar fácilmente la identidad de un usuario registrado
  • Historias de seguridad/control: Expresan los requisitos desde la perspectiva de otros intervinientes como pueden ser los auditores, reguladores bancarios, responsables de seguridad, inspectores de la agencia de protección de datos; por ejemplo: “Como responsable de seguridad de la información, quiero que cada interfaz de la aplicación sea resistente a las entradas de datos erróneos o malformados; de modo que se preserve la integridad de la información y los ataques a la aplicación

Características funcionales

El equipo del proyecto trabaja sobre las historias de usuario de más bajo nivel y las descompone a su vez en elementos más concretos aún, como características funcionales concretas que la aplicación deberá incorporar; por ejemplo: “La aplicación debe tener un “botón del pánico” que permita bloquear una tarjeta de manera rápida“.

Tareas

El mayor nivel de descomposición en el backlog es la tarea. Se trata de los ítems de trabajo concreto que habrá que llevar a cabo para que se puedan implementar las características funcionales y las historias de usuario. La tarea es el elemento terminal en la jerarquía del backlog,  que puede ser asumida por un miembro del equipo para su trabajo diario. Por ejemplo: “Obtener información sobre la estructura del mensaje de bloqueo de tarjeta en el protocolo del servicio web del banco” y “Programar la función que traduce los datos de entrada de la aplicación en un mensaje de bloqueo en el protocolo del servidor“. Es importante tener en cuenta que algunas de estas tareas pueden ser de carácter repetitivo a lo largo de la vida del proyecto, mientras que otras serán tareas que se ejecutarán una sola vez.

Cómo encajar las actividades de seguridad en el backlog del proyecto

Veamos ahora la forma de incluir dentro del backlog los distintos tipos de actividades  de seguridad que hemos identificado al inicio de este artículo. De este modo nos aseguraremos de que estas tareas se llevarán a cabo, ya que en las metodologías ágiles “lo que no está en el backlog no existe”.

Actividad de Seguridad Encaje en el backlog del proyecto
Análisis de riesgos La forma de incluirlo consiste en definir el análisis de riesgos como una tarea que se incluye en el backlog y que se vincula como parte del criterio de aceptación de una característica funcional o historia de usuario.Un buen momento para la toma de decisiones relativas a las necesidades de realización de análisis de riesgos y el cómo abordarlo suele ser la fase de planificación de cada sprint del proyecto.Por otro lado, el análisis de riesgos inicial de alto nivel del proyecto puede ser abordado como parte del sprint inicial del proyecto.
Controles de seguridad Cuando no existe duda sobre el modo de implementar un control de seguridad, entonces, el modo más recomendable de incluirlo es en la forma de una característica funcional de la aplicación.Sin embargo, cuando los controles de seguridad han sido definidos de una manera genérica y no está todavía claro cómo se deben implementar técnicamente, entonces el control de seguridad se expresa en la forma de una historia de abuso o de seguridad del sistema.Las historias de abuso se describen de  la misma forma que las historias de usuario; sin embargo, describen situaciones negativas que no deberían suceder. Otra forma de documentar como requisitos los controles, es mediante la definición de historias de seguridad o control, que expresan los requisitos desde la perspectiva de otros intervinientes como pueden ser los auditores, reguladores bancarios, responsables de seguridad, inspectores de la agencia de protección de datos…
Análisis estático del código fuente El análisis del código fuente puede ser incluido en el backlog como una tarea recurrente  vinculada dentro del criterio de aceptación de cualquier característica funcional de la aplicación, de modo que no se alcanzará el criterio de aceptación hasta que el código fuente esté “limpio” de vulnerabilidades.
Pruebas funcionales de controles Puede ser incluido en el backlog como una tarea recurrente que se vinculará como parte del criterio de aceptación de cualquier característica funcional de la aplicación.Como consecuencia de los resultados de las pruebas, cuando el criterio de aceptación no se ha cumplido, los defectos pendientes de resolver se pueden incluir en la forma de tareas orientadas a la resolución de estos defectos.
Pen testing (evaluación dinámica de vulnerabilidades) Lo normal es que este tipo de pruebas se incluyan como parte del criterio de aceptación global de cada incremento de desarrollo.  Por tanto, estos test se materializan en forma de tareas que se definen en la fase de planificación inicial de cada sprint.
Otras actividades de seguridad Incluirlas como  tareas en el backlog. Si se cree conveniente, estas tareas pueden ser vinculadas como parte del criterio de aceptación.Lo normal es que estas actividades se definan con la ayuda de los expertos de seguridad del equipo durante la fase de planificación inicial del sprint.

Como hemos visto, en gran medida, las actividades de seguridad forman parte del criterio de aceptación de características funcionales y/o historias de uso. Por tanto, una fase crítica a la hora de valorar el resultado de estas tareas es durante la revisión final de cada sprint, en donde el equipo de proyecto responde a la pregunta de si los objetivos del sprint de desarrollo se han alcanzado o no. Es decir, de este modo, la seguridad forma parte explícita de la definición de “hecho” o “no hecho”.

Damos por finalizado aquí este artículo. Esperamos que sea de utilidad. En el futuro volveremos sobre este interesante tema de los métodos ágiles de desarrollo y la seguridad. Hasta entonces, un fuerte abrazo.
Consulta este artículo en nuestro nuevo site
 

 

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s