Solo a los efectos de ponerte en contexto, el contenido que leerás a continuación corresponde a la unidad 1. Security Paradigms del programa de estudios del ISTQB STE (Certified Tester Security Test Engineer Syllabus) v1.0.1.

Esta unidad comprende las siguientes secciones:

1.1. Asset Security Levels.
1.2. Security Audits
1.3. The Concept of Zero Trust
1.4. Open-Source Software (OSS)

Cada una de estas secciones las estuve estudiando y publiqué el análisis que hice.

El objeto de este artículo es tener un análisis global de las cuatro secciones y luego hacer un comparativo, como para tener una visión más general que me ayude a medida que vaya avanzando en mi estudio, con los contenidos de las otras unidades e identificar las vinculaciones que seguramente hay.

Sintético de cada sección

1.1 Asset Security Levels (Niveles de Seguridad de los Activos)

Los activos son cualquier recurso de valor dentro de una organización, como información, software, hardware o reputación. Para protegerlos, se utilizan diferentes niveles de seguridad según su importancia.

Ejemplo:
Un documento con datos personales de clientes debe tener una protección alta (confidencialidad), mientras que un aviso público en la página web de la empresa puede necesitar solo un nivel básico de seguridad (disponibilidad).

Desde el punto de vista de software testing, los activos incluyen software, datos y sistemas críticos dentro de una organización. En nuestra práctica, la seguridad de los activos se evalúa para asegurarse de que la información sensible está correctamente protegida.

Ejemplo en Software Testing:
Durante las pruebas de seguridad de una aplicación bancaria, los testers clasifican los activos de acuerdo a su sensibilidad:

• Baja sensibilidad: Avisos de promociones en la app (se prueba solo disponibilidad).
• Media sensibilidad: Historial de transacciones (se prueba integridad y control de acceso).
• Alta sensibilidad: Credenciales de usuarios (se prueban encriptación y autenticación).

Punto para la reflexión: Debemos ser conscientes de varios temas aquí. Conocer muy bien el negocio a partir del cual se está desarrollando la solución informática para poder identificar en las épicas y/o historias de usuario, ausencias de seguridad como así también atributos de criticidad, para implementar debidamente el correspondiente testing. Ahora bien, ¿Cómo lograr una clasificación similar a la del ejemplo? ¿Qué práctica debemos realizar para entender la relación de los niveles de sensibilidad con la acción correspondiente a aplicar? Es aquí, a mi modo de ver, que podemos comenzar a pensar en apoyarnos en la IA Generativa. Teniendo un portfolio de «prompt frameworks» como primer nivel de mejores prácticas, podríamos superar gran parte de esta instancia.

1.2 Security Audits (Auditorías de Seguridad)

Las auditorías de seguridad son revisiones independientes que evalúan la efectividad de las medidas de seguridad en una organización. Se realizan con el fin de detectar vulnerabilidades, comprobar el cumplimiento de normativas y proponer mejoras.

Ejemplo:
Una empresa de e-commerce realiza auditorías periódicas para asegurarse de que los datos de tarjetas de crédito de los clientes están protegidos y que no existen accesos indebidos a los servidores.

Desde el punto de vista de software testing, las auditorías de seguridad incluyen revisiones de código, configuraciones y pruebas de seguridad para identificar fallos y vulnerabilidades en el software antes de su despliegue.

Ejemplo en Software Testing:
Un tester de seguridad realiza una auditoría estática de código en un sistema de gestión de salud. Durante la revisión, detecta que las contraseñas de los usuarios están almacenadas en texto plano en la base de datos, lo que representa un riesgo alto y debe ser corregido antes del lanzamiento.

Punto para la reflexión: Las revisiones de código se pueden realizar de manera manual remitiéndonos a la técnicas de caja blanca y sus mejores prácticas, con herramientas como SonarQube y ahora, con IA Generativa.

1.3 The Concept of Zero Trust (El Concepto de Confianza Cero)

El modelo Zero Trust se basa en la idea de no confiar en nadie ni en nada dentro o fuera de la red corporativa sin antes verificar su identidad y permisos. Se aplican controles estrictos para minimizar los riesgos.

Ejemplo:
Un empleado que trabaja desde casa debe autenticarse con múltiples factores (como contraseña y código en su teléfono) antes de acceder a documentos internos de la empresa.

En software testing, Zero Trust significa probar que cada acceso a un sistema debe verificarse sin asumir que un usuario o dispositivo es seguro solo porque ya está dentro de la red.

Ejemplo en Software Testing:
Al probar una plataforma de colaboración en la nube, los testers intentan acceder a recursos desde diferentes usuarios y ubicaciones. Descubren que una vez autenticado, un usuario puede acceder a archivos sin necesidad de volver a verificar su identidad. Esto va en contra del principio de Zero Trust, por lo que se recomienda implementar autenticación continua.

1.4 Open-Source Software (OSS) (Software de Código Abierto)

El software de código abierto es desarrollado de manera colaborativa y puede ser utilizado y modificado libremente. Sin embargo, su uso en entornos empresariales implica riesgos, ya que cualquiera puede modificar el código, incluyendo atacantes malintencionados.

Ejemplo:
Una empresa usa una librería de código abierto para su aplicación web. Si esa librería tiene una vulnerabilidad conocida y no se actualiza a tiempo, los atacantes podrían explotarla para acceder a los datos de los usuarios.

El uso de librerías y frameworks de código abierto es común en el desarrollo de software, pero pueden incluir vulnerabilidades. En software testing, se deben realizar pruebas de seguridad para detectar riesgos en estos componentes.

Ejemplo en Software Testing:
Un equipo de testing analiza una aplicación web que usa una versión antigua de Log4j (una librería de código abierto). Mediante pruebas de seguridad, detectan que la versión tiene una vulnerabilidad conocida (Log4Shell) que permitiría a un atacante ejecutar código remoto. La recomendación es actualizar a la última versión segura antes del lanzamiento.

Punto para la reflexión: Aquí hay dos temas para mencionar. Selenium WebDriver como herramienta OSS y por lo tanto, candidato a estar monitoreado para conocer sus últimas correcciones y vulnerabilidades detectadas. Así como esta herramienta, los testers usan una gran cantidad así como también los desarrolladores. Entonces me cabe una pregunta, ¿En tu equipo o proyecto o área, han implementado una política de actualización periódica de librerías? ¿Esta tarea ha sido estimada para ejecutarla durante el Sprint? ¿Se ha analizado el impacto de dicha actualización y su grado de afectación?

Análisis comparativo

Conclusiones: Las desventajas podrían ser tratadas mediante «prompt frameworks» genéricos. Representarían los primeros ensayos a realizar. Es una idea tan solo y que puede demostrarse mediante candidatos que actualmente no tengo.

Fuente de inspiración: Programa de estudios ISTQB STE