La seguridad es una de las características técnicas relacionadas con las áreas de riesgos que debemos tener identicadas como agile testers.
Esta identificación es un proceso colaborativo y se basa en las características de calidad del producto (según la norma ISO 25010).
Como testers debemos identificar aquellos riesgos técnicos que pueden estar afectandor el producto que estemos desarrollando a lo largo de los sprints planificados. Esto implica colaborar de manera activa con diversas partes interesadas (product owners, desarrolladores, arquitectos, ingenieros de operaciones, etc.).
Además de la identificación de los riesgos también debemos considerar las tareas de evaluación y mitigación de riesgos que se complementan y que no debemos olvidarnos.
Estas tareas se llevan a cabo iterativamente a lo largo del proyecto, en cada uno de los sprints, para gestionar los riesgos de manera dinámica y adaptarse a los cambios en el entorno y en las prioridades del proyecto. Esta metodología asegura que el esfuerzo de pruebas se centre en las áreas de mayor riesgo, optimizando recursos y tiempos para la entrega de un producto de mayor calidad y fiabilidad.
La identificación así como la evaluación y mitigación debe quedar registrado en herramientas como por ejemplo Xray integrado con Jira Software, como para que todo el equipo esté en conocimiento y que se pueda seguir en los sprints que corresponda.
Ahora bien, ¿Cómo comenzar con la tarea de identificación de riesgos? Una respuesta rápida es aplicando el modelo de checklist y aquí te dejo algo como para ayudarte.
Recordemos que el modelo de checklist esta recomendado en el Programa de Estudios del ISTQB CTFL v4.0, sección 5.2. Uso de Checklist en las Revisiones. Los checklists:
– se utilizan durante las revisiones para recordar a los participantes que verifiquen puntos concretos durante la revisión.
– ayudan a despersonalizar la revisión.
– pueden ser genéricos y utilizarse para todas las revisiones o centrarse en características o áreas de calidad específicas.
– pueden centrarse en cuestiones de seguridad o de eficacia del rendimiento.
Sobre este último aspecto me inspiré para generar este artículo basado no sólo en este programa de estudios sino en el Programa de Estudios Certified Tester Advanced Level Technical Test Analyst (CTAL-TTA) Syllabus.
Bueno, basta de palabras, voy a punto.
A continuación, te comparto un checklist para identificar los escenarios más relevantes en cuanto a características técnicas de seguridad en una primera instancia exploratoria:
- Confidencialidad:
- ¿La aplicación previene el acceso no autorizado a datos sensibles?
- ¿Está la información sensible encriptada tanto en reposo como en tránsito?
- ¿Se eliminan adecuadamente los datos sensibles después de su uso, evitando que queden en caché o en almacenamiento temporal no seguro?
- ¿Se valida y sanitiza correctamente toda la entrada de datos del usuario para evitar inyecciones (e.g., SQL, scripts en campos de entrada)?
- ¿Hay mecanismos que prevengan la modificación no autorizada de los datos, como hashes o firmas digitales?
- ¿Se auditan y registran los cambios en datos críticos, incluyendo quién y cuándo se modificaron? .
- ¿La aplicación proporciona un registro detallado de auditoría de todas las acciones críticas realizadas por los usuarios?
- ¿Se requiere autenticación sólida y control de sesión para acceder a áreas sensibles?
- ¿Está configurado el sistema para evitar que los usuarios nieguen acciones realizadas en el sistema (e.g., mediante autenticación multifactor)?
- Autenticidad:
- ¿Se tienen en el radar los certificados digitales o autenticación fuerte para verificar la identidad de los usuarios?
- ¿Están adecuadamente protegidas las credenciales de acceso, como contraseñas encriptadas y autenticación mediante token?
- ¿Existe un mecanismo de verificación de integridad para los datos que se intercambian entre sistemas externos?
- Accesos y privilegios:
- ¿Hay controles implementados para que los usuarios solo puedan ver y modificar lo que les corresponde según sus permisos?
- ¿Se validan y verifican regularmente los roles y permisos de los usuarios?
- ¿Se revisa periódicamente que no existan usuarios con permisos más elevados de lo necesario?
- Pruebas de vulnerabilidades:
- ¿Se han identificado las necesidades más comunes utilizando herramientas estándar como OWASP o NIST?
- ¿Existen pruebas que simulen posibles ataques de usuarios malintencionados, como ataques de fuerza bruta, DoS o XSS?
- ¿Los componentes externos (bibliotecas, APIs) han sido evaluados para posibles riesgos de seguridad? .
Este checklist una vez identificadas las áreas de riesgo respecto de la característica seguridad, te permitirá pensar en todo lo que necesitarás para realiza el testing basado en riesgos, además de facilitar el cumplimiento de estándares como los definidos por ISO 25010 y OWASP.
Recuerda también, que varios de estos temas los he tratado en artículos anteriores y que se encuentran publicado en mi blog.
Muchas gracias por leer mis artículos y seguirme también en LinkedIn.
Fuente de inspiración: Certified Tester Advanced Level Technical Test Analyst (CTAL-TTA) Syllabus v4.0
