Las amenazas (y ataques) a la seguridad del software crecen a diario. Tal vez desde tu posición no lo sepas y tal vez no hayas sufrido el impacto, no obstante imagino que estarás consciente de esta realidad que día a día sigue evolucionando y en aumento.
Así como hay personas preocupadas y ocupadas en anticiparse y/o evitar que no ocurran estas amenazas y/o ataques, también están las personas que están preocupadas y ocupadas en lograr llegar con sus amenazas y/o ataques. Ambos grupos además, cuentan desde hace un tiempo con la inteligencia artificial como impulsor de nuevas soluciones y/o herramientas.
Pero vuelvo a lo nuestro: Las técnicas de prueba en pruebas de seguridad.
El rol del Security Test Engineer (STE) se vuelve cada vez más importante y clave, según mi humilde opinión, y lo estaré fundamentando en cada una de los contenidos que publicaré.
Más allá de aplicar escaneos automáticos, este perfil analiza arquitecturas, identifica vectores de ataque y diseña pruebas específicas para proteger los activos más valiosos de un sistema. Pero, ¿Cómo se eligen y aplican las técnicas de prueba en pruebas de seguridad? En este artículo te compartiré una síntesis.
🔍 ¿Qué técnicas se usan en pruebas de seguridad?
Las técnicas más utilizadas se clasifican de acuerdo al nivel de conocimiento que tengamos del sistema bajo prueba (SUT):
- Caja negra: simulamos un atacante externo, sin conocer el código ni la infraestructura. Para esta técnica recordemos que no nos interesan estas capas. Sí nos interesa el input y el output que lo deberemos tener definido y conocido, para chequear el resultado que obtengamos tras nuestro testing. Estos datos deberán estar presentes en la historia de usuario como criterio de aceptación, ya que el tema es de dominio del Product Owner.
- Caja blanca: analizamos internamente el código, los flujos de datos y las reglas de seguridad. Para esta técnica debemos necesariamente tener conocimiento: del lenguaje de programación con el cual ha sido desarrollado el SUT, de base de datos para tener muy bien identificadas las tablas y las bases de datos que estén comprometidas, del flujo que siguen los datos a ser testeados ya que muy probablemente afecten diversos sistemas involucrados, pasen por diferentes estados, sufran transformaciones, requieran de ciertas autorizaciones, y demás situaciones que desde el flujo sólo podremos conocer, y por supuesto de las reglas que se hayan definido e implementado desde seguridad informática. ¿Te vas dando cuenta de todos los roles que están involucrados? A cada una de las personas que cumplan roles que administren los datos antes mencionados, los deberemos molestar de alguna manera para entender el alcance de nuestras pruebas.
- Caja gris: combinación de ambas, accediendo a documentación parcial y roles con permisos limitados. Aquí no hay mucho más para comentar, sólo que de querer profundizar en esta técnica, deberás explorar el sitio de NIST.
Cada una permite descubrir distintos tipos de vulnerabilidades, por eso el STE debe elegir según el objetivo: amenazas internas vs externas, profundidad de análisis, o contexto del sistema.
El objetivo a perseguir en nuestras pruebas, deberá estar definido en la historia de usuario. Claro está que muy posiblemente no esté definido técnicamente como lo estamos tratando, sino que estará enunciado en un criterio de aceptación que se interpretará como tal por todo el equipo de desarrollo, que se chequeará y acordará con el Product Owner y líderes que correspondan.
🧪 Caso práctico: aplicación web médica
Al aplicar pruebas de seguridad sobre un sistema de salud, analizamos componentes como:
- La arquitectura para encontrar zonas expuestas.
- El código fuente en busca de errores de validación.
- El flujo de datos para detectar fugas o transmisiones inseguras.
- Los mecanismos de autenticación, cortafuegos y registros.
Este análisis permite diseñar pruebas específicas con herramientas como revisiones de código (con SonarQube) o simulaciones de ataques (spoofing, tampering, DoS, etc.), todas alineadas con el modelo de amenazas STRIDE.
🧠 STRIDE: nos permite pensar como un atacante
STRIDE es un modelo que ayuda a clasificar amenazas en seis categorías:
- Spoofing: suplantación de identidad.
- Tampering: manipulación de datos.
- Repudiation: acciones sin trazabilidad.
- Information Disclosure: fuga de información.
- Denial of Service: bloqueo del sistema.
- Elevation of Privilege: escalada de permisos.
Este marco permite diseñar mejores pruebas, priorizar riesgos y anticiparse a incidentes reales.
Punto para reflexionar: Para lograr una cobertura de testing en cada una de estas seis categorías habrá que interactuar con varias personas, estar autorizados para acceder a diferentes entornos, y por supuesto tener cierto conocimiento técnico para abordar estas áreas. Sólo a modo de un breve ejercicio: ¿Cómo podríamos recrear / simular un escenario en el que se esté intentando una suplantación de identidad de una persona al SUT? ¿Qué datos necesitaríamos tener? ¿Cuál sería el workflow a seguir? ¿Cuál debería ser el resultado esperado del testing a efectuarse? ¿En qué medida estaríamos cubriendo el criterio de aceptación definido en la historia de usuario? ¿Cuáles serían las reglas de seguridad a controlar?
📋 Checklist de seguridad para Historias de Usuario
Aunque muchos de estos aspectos no se reflejan directamente en las Historias de Usuario, es fundamental tener un checklist de seguridad que acompañe su análisis. Preguntas clave como:
- ¿Qué roles tienen acceso?
- ¿Se registra la acción en logs?
- ¿Los datos están protegidos?
- ¿Puede esta funcionalidad ser usada para un abuso?
… permiten elevar la calidad de las HU y facilitar el trabajo de testers y desarrolladores.
Punto para reflexionar: ¿Podrías elaborar tu propio checklist de seguridad de las historias de usuario que se están desarrollando para el sprint actual? ¿En base a qué referencia se puede elaborar el checklist? ¿Debiera chequearse y actualizarse cuando la historia de usuario pasa por un refinamiento?
🤝 Seguridad: responsabilidad compartida
Finalmente, recordar que la seguridad no es solo tarea del STE o del desarrollador. El Product Owner, los líderes técnicos, DevOps y testers deben colaborar activamente para que la información sobre autenticación, arquitectura, red y flujos esté disponible y actualizada.
Punto para reflexionar: Siempre terminamos en el concepto inicial de nuestra práctica y de la metodología ágil: el equipo completo. 😎 Ahora bien, todos sabemos que este concepto no se encuentra implementado en todos los proyectos, ¿verdad?
Conclusión :
Aplicar correctamente las técnicas de prueba en pruebas de seguridad no es solo cuestión de utilizar herramientas (como puede ser SonarQube), sino de conocer de metodología y buenas prácticas en esta área de conocimiento, entender el sistema que se encuentra bajo prueba (SUT), sus amenazas, y trabajar como equipo. Al integrar modelos como STRIDE y prácticas de threat modeling (es una práctica de análisis proactivo de seguridad cuyo objetivo es identificar, entender y mitigar amenazas potenciales a un sistema antes de que se conviertan en vulnerabilidades explotadas), junto con un checklist de seguridad, los equipos pueden prevenir antes que lamentar. Muchas empresas han sufrido y siguen sufriendo amenazas y ataques diversos. Todo lo que podamos hacer desde nuestro lugar como testers será siempre poco. Uno de los grandes desafíos que tenemos (por cuestiones operativas y económicas) es que desde la gerencia a niveles inferiores (líderes de desarrollo, líderes de seguridad, líderes de arquitectura, líderes de infraestructura, otros) comprendan muy bien la importancia que tiene aplicar este tipo de testing (y me refiero a security testing) en el desarrollo de los productos, además de tener implementado alguno de los siguientes: testing funcional para aplicaciones web, testing de aplicaciones mobile, testing automatizado, testing de performance y otros.
