Por Juan Pablo Amón
21 de julio de 2021
Describir los requisitos de seguridad al inicio del proyecto, revisar el diseño para verificar si los requisitos se han incorporado y realizar pruebas de seguridad antes de la puesta en funcionamiento. ¿Esto le suena familiar? Pues deberías hacerlo.
Muchas empresas gestionan sus proyectos utilizando el método predictivo (cascada), en el cual los riesgos deben “despejarse” antes de que la iniciativa pueda avanzar. En ciertos hitos de control se pudiera tomar la decisión de no seguir adelante (aceptando obviamente todos los costos irrecuperables hasta esa instancia) si pareciera improbable que se obtuviesen los beneficios esperados.
Este enfoque funciona muy bien en entornos estructurados con objetivos claros y poca incertidumbre. También hay muchos aspectos positivos desde el punto de vista de la seguridad: el equipo que trabaja en esta área se involucra desde el inicio de proyecto, ya que normalmente tendrá que dar su aprobación en ciertas etapas, por lo que al gerente de proyecto debe interesarle involucrarlos temprano para evitar demoras en el desarrollo del proyecto; sin embargo, si los requisitos del proyecto no son tan claros o si están constantemente iterando para aprender más sobre las necesidades de las partes interesadas para elaborar progresivamente los requisitos, es probable que sea preferible utilizar metodologías ágiles.
La integración de la seguridad en el desarrollo ágil está menos establecida y hay más de una forma de hacerlo. Cuando se habla de seguridad en empresas como Startups u otras que adoptan enfoques ágiles, se pone mucho énfasis en automatizar las pruebas de este tipo y educar a los desarrolladores sobre el desarrollo de software seguro. Aunque estas iniciativas tienen sus méritos, no son lo único que se debe hacer. Los especialistas en seguridad deben tener en mente el panorama general y trabajar con el equipo de desarrollo, no solo para evitar vulnerabilidades en el código, sino también para influir en la estrategia general del producto, esforzándose por lograr la seguridad y la privacidad desde el diseño. Agregar funciones de seguridad, revisar y perfeccionar los requisitos existentes para que el producto sea más seguro. Para lograr esto de manera efectiva, es fundamental desarrollar relaciones con los equipos de desarrollo y los interesados. Especialmente el dueño del producto debe ser su mejor aliado, ya que a menudo el especialista de seguridad tendrá que persuadirlo para que incluya sus requisitos de seguridad dentro de las historias de usuario de los sprints.
Recuerde, que un especialista en seguridad es un interesado más que el dueño del producto debe gestionar. Además, existe una cantidad limitada de funciones que el equipo de desarrollo puede ofrecer en cada sprint, por lo que articular el valor y la importancia de las sugerencias del área de seguridad se convierte en una habilidad esencial.
Pocas personas notan la seguridad hasta que falta, momento en el que generalmente es demasiado tarde. Vemos esto una y otra vez cuando organizaciones de varios tamaños están lidiando con robos de datos e incidentes de seguridad. Es trabajo del especialista en seguridad articular la importancia de priorizar las mejoras de seguridad al principio del proyecto para mitigar el posible reproceso y el impacto negativo en el futuro.
Las recomendaciones de seguridad a menudo se comunican en forma de historias de usuarios. Por ejemplo: "los datos personales del cliente deben almacenarse de forma segura" o "como usuario registrado, me gustaría acceder a mi información confidencial (que se almacena de forma segura) a través de un canal de comunicación seguro para poder realizar las acciones autorizadas". Aunque la forma de trabajar de cada organización es diferente, hay que tratar de ser lo más concreto posible, mencionando tecnologías y protocolos específicos, si es necesario.
Al escribir historias de usuarios de seguridad se debe tratar de especificar, tanto como sea posible sobre el problema que está tratando de resolver, el valor que proporcionará, si se resuelve y los criterios de aceptación que incluirán requisitos de seguridad detallados.
Si se está siguiendo Scrum o un marco de referencia similar, es importante que el equipo de seguridad participe en la planificación del sprint para contribuir a las estimaciones y ayudar al dueño del producto con la priorización. También vale la pena asistir a otras reuniones de equipo, como el refinamiento y las reuniones diarias, para poder aclarar sus requisitos (incluido el valor, el riesgo, las fechas de vencimiento y las dependencias) y ayudar a eliminar los impedimentos relacionados con la seguridad.
Una cultura de colaboración entre equipos es esencial para que el enfoque ágil sea efectivo. Es preferible tratar la seguridad como una característica de producto de valor agregado. Sin embargo, depende de los especialistas en seguridad reconocer el contexto más amplio en el que operan y aceptar el hecho de que la seguridad es solo uno de los requisitos que el equipo debe considerar. Si la empresa no puede generar ingresos porque faltan características cruciales que los clientes demandan, es poco consuelo que se hayan abordado las vulnerabilidades de seguridad. Después de todo, es genial tener un producto seguro, pero esto es insignificante si nadie lo está usando.
