Ya sabéis como es esta nuestra profesión cuando algo se pone de moda (el desarrollo software… se mueve por modas), aparecen cosas que antes no se escuchaban y de repente todo el mundo parece hablar de ello. Algunas de esas “cosas” de moda acaban quedando para siempre (y podríamos decir que entonces dejan de ser modas) y algunas desaparecen al tiempo.
Lo último que parece estar de moda, yo ya lo he escuchado varias ocasiones, y ya ha sido tema de varias conversaciones entre chic@s de 233 Grados de TI, es “la seguridad ágil”. La agilidad llevada a la seguridad o la seguridad llevada a la agilidad, según se mire, en cualquier caso seguridad ágil.
Si vienes del mundo del desarrollo software y no te dedicas a la seguridad, véase el caso de este quien te escribe, seguramente conozcas la agilidad y te quedes raro cuando escuches lo de seguridad ágil… ¿En qué consiste la seguridad ágil? ¿De qué estamos hablando cuando escuchamos lo de llevar la agilidad a la seguridad?
Como suele ser típico por estas páginas, vamos a darle una vuelta breve y concisa al tema, para evitar caras raras al escuchar ciertos términos.
Seguridad Ágil: Introducir “necesidades”, “requisitos” y “tareas” de seguridad en un proceso ágil
Después de leer prácticamente todo lo que he encontrado por el ancho Google y después de preguntar a todo aquel que he pillado que pudiera saber del tema, sin haber encontrado, como es típico en tecnología, una definición que acote qué es “Seguridad Ágil”, puedo resumir, aun a riesgo de equivocarme por la brevedad, que cuando alguien habla de “Seguridad Ágil” esta hablando de incorporar a los conceptos (artefactos si quieres) típicos de un proceso Scrum (o ágil en general) la palabra Seguridad.
Hablamos principalmente de aquellos “artefactos” relacionados con requisitos y tareas, así, si en un Scrum “de toda la vida” (o ágil en general) podemos hacer uso de Epopeyas, Historias de Usuario, Tareas, Spikes, etc., cuando alguien te habla de “Seguridad Ágil” te está normalmente hablando de hacer uso en un proceso Scrum (o ágil en general) de Epopeyas de Seguridad, Historias de Seguridad (tipología que nace haciendo un símil con el concepto de historia de usuario), Tareas de Seguridad, Spikes de Seguridad, etc.
Prácticamente casi todos los artículos que tratan el tema (por ejemplo, otro ejemplo, un ejemplo más) lo enfocan de esa manera. De hecho, en los enlaces anteriores, hay documentos que recomiendan cómo hacer “historias de seguridad” y “tareas de seguridad”, lugares que hablan del OWASP y las historias de seguridad, etc.
Es decir, y te dejo un ejemplo literal extraído de el último enlace, estamos hablando de tener un:
«As a hacker, I can send bad data in URLs, so I can access data and functions for which I’m not authorized.»
Realmente… ¿Es correcto tener historias de usuario (más bien ítems) sobre seguridad? ¿O estamos confundiendo historias con criterios de aceptación?
Pero a la vez que se escucha la “Seguridad Ágil”, en los términos anteriores, se pueden encontrar múltiples críticas a este enfoque (ejemplo).
El caso de las “historias de seguridad”, generalizando, es el mismo caso que aquel de… ¿Hay que añadir historias de rendimiento, facilidad de uso, calidad, mantenimiento, fiabilidad, etc.? Hablamos de restricciones o requisitos no-funcionales.
Y lo cuestionable viene de… ¿no será más correcto usar la seguridad (u otras restricciones) como criterio de aceptación para una, o varias, “historias de usuario” y hacer uso de el “definition of DONE”?
Hablamos de hacer uso de las condiciones que se tratan y cierran con el Product Owner bajo las cuáles se dará por completada una historia de usuario, donde una de ellas puede ser la seguridad, si no conoces el tema del “definition of DONE”, lee el post de en un proyecto ágil, acordar una buena definición de lo que significa terminado (el done))
Algunas notas finales…
Aunque en este caso, en el caso que aquí tratamos de la seguridad, seguimos dentro del ámbito tecnológico, este es un caso similar al ya comentado de la agilidad aplicada a contextos que no son de desarrollo software.
Un ejemplo más de cómo la agilidad nace en el mundo de desarrollo pero poco a poco se va extendiendo a otros ámbitos tecnológicos (seguridad, operaciones, etc.) y no tecnológicos (marketing, creación e negocios, etc.)
Veremos como avanza el tema, por lo pronto hay por ahí ya un manifiesto de la seguridad ágil
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- OKRs sin Lado Oscuro, IA para OKRs y alternativas para evaluarlos - 25 julio, 2024
- Por qué seguimos usando técnicas ágiles anticuadas: Efecto Einstellung - 18 julio, 2024
- Cómo crear una IA personalizada (me llevó meses, pero te lo enseño en 2 min) - 11 julio, 2024
En un proyecto en el que llevo ya un par de años, tratamos los requisitos de seguridad como criterios de aceptación y efectivamente, nos ha ido bien :).
El único problema que hemos encontrado particularmente con los criterios de aceptación de seguridad, es que suele ser más difícil automatizar una prueba que asegure que dicho criterio se cumple.
Y luego aunque los criterios de aceptación de seguridad, especifiquen lo que a nivel de seguridad se tiene que tener en cuenta en una historia, siempre cabría la posibilidad de reservar tiempo en los sprints para realizar unas pruebas de seguridad del sistema completo (quizás reservando sprints o un porcentaje de un sprint para realizar este tipo de pruebas al igual que se haría con pruebas de rendimiento, carga, etc?)
Un saludo.