Primer planteo que me hice
¿Cómo impacta y se aplica en nuestras pruebas de seguridad el modelo Zero Trust ? Claro que antes deberíamos conocer el concepto de Zero Trust.
Toda una incógnita esta relación hasta que comencé a leer y analizar el alcance de este concepto, y que realmente me permitió tener otro panorama del alcance que le debemos dar a nuestras pruebas.
Segundo planteo
¿Porqué el modelo “Zero Trust en Security Testing” (Confianza Cero en el Testing de Seguridad) considera importante al contexto y la necesidad?
Los entornos de TI modernos han evolucionado de redes estáticas y controladas a ecosistemas dinámicos y distribuidos. Tenemos factores como:
- Trabajo remoto y entornos híbridos.
- Interacciones con terceros y proveedores externos.
- Aplicaciones y datos dispersos en múltiples entornos.
que han originado que los enfoques tradicionales de seguridad, basados en la confianza dentro de un perímetro de red, sean insuficientes, es decir que ya no bastan, y aquí es donde el modelo Zero Trust (confianza cero) se convierte en un principio clave para la prueba de seguridad.
😎Punto para reflexionar: ¿Pero sabemos cuál es el alcance que le debemos dar a este tipo de pruebas? Antes debemos necesariamente conocer los siguientes puntos.
Principios de Zero Trust Aplicados a Security Testing
Para adaptar la seguridad a este nuevo paradigma, Zero Trust introduce principios clave en las pruebas de seguridad:
1. Monitoreo y Verificación Continua
- Cada acceso debe verificarse en todo momento.
- Las sesiones expiran y deben ser re autenticadas periódicamente.
- Se deben registrar y analizar todas las actividades de acceso.
2. Principio de Menor Privilegio
- Los usuarios, dispositivos y aplicaciones solo obtienen los permisos mínimos necesarios.
- Las pruebas de seguridad deben evaluar si existen permisos excesivos.
3. Autenticación Multifactor (MFA)
- Se requiere más de un factor de autenticación.
- No basta con una contraseña; puede incluir biometría, tokens o claves físicas.
4. Monitoreo de Endpoints y Dispositivos
- Todos los dispositivos que acceden a la red deben cumplir con estándares de seguridad.
- Se realizan pruebas de seguridad para identificar dispositivos vulnerables.
5. Microsegmentación
- Se divide la red en pequeños segmentos para limitar el acceso entre partes del sistema.
- Las pruebas de seguridad deben verificar que no haya accesos no autorizados entre segmentos.
6. Restricción del Movimiento Lateral
- Un atacante no debe moverse libremente dentro de la red en caso de brecha.
- Las pruebas deben evaluar si un atacante puede escalar privilegios o acceder a otros segmentos.
7. Protección de Datos
- Los datos deben estar cifrados en tránsito y en reposo.
- Se deben realizar pruebas de seguridad para detectar datos expuestos sin cifrar.
😎Punto para reflexionar: ¿Y si recurro a la IA Generativa para aterrizar este tema?¿No sería bueno? OK. Te comparto parte del proceso:
1. Seleccionar uno de los 7 principios para llevar a cabo la prueba de concepto con IA Gen.
2. Evaluar para el principio seleccionado cuál es el «framework de prompts» más adecuado.
3. Una vez seleccionado el framework, revisar nuevamente su alcance.
4. Desarrollar el framework de prompts con el objetivo de que sea genérico.
📌 Selección y Análisis del Principio 1: Monitoreo y Verificación Continua
Este principio del modelo Zero Trust en Security Testing establece que cada acceso debe verificarse en todo momento, asegurando que:
✅ Cada solicitud de acceso será autenticada y verificada.
✅ Las sesiones expiran y serán re autenticadas periódicamente.
✅ Todas las actividades de acceso serán registradas y analizadas.
El objetivo es evitar accesos no autorizados y detectar comportamientos sospechosos a través de registros y auditorías constantes.
😎Punto para reflexionar: Para comenzar a aterrizar el tema, los aspectos definidos en este principio (entre otros) deberían estar alcanzados y/o definidos en el requerimiento original expresado en el lenguaje del usuario final y convertido a una épica e historias de usuario por parte del Product Owner expresado con un lenguaje que el equipo de desarrollo (testers y developers) pueda entenderlo y de esta manera «desarrollar el producto» (el developer codificando y probando y el tester, testeado).
Evalué el framework de prompts más adecuado de entre varios (E.R.A., S.T.A.R., R.I.S.E., C.A.R.E., T.R.A.C.E., entre otros).
📌 Selección del Framework de Prompts más conveniente
Para el principio 1 – Monitoreo y Verificación Continua, el mejor enfoque -a mi entender- es el T.R.A.C.E. porque se centra en la evaluación continua de eventos y registros, asegurando una auditoría activa en tiempo real.
T.R.A.C.E. = Tracking, Recording, Auditing, Compliance, Enforcement
- Tracking (Seguimiento): Se rastrean todas las solicitudes de acceso.
- Recording (Registro): Se almacena toda la actividad en logs detallados.
- Auditing (Auditoría): Se analizan y revisan registros para detectar anomalías.
- Compliance (Cumplimiento): Se validan los accesos según políticas establecidas.
- Enforcement (Aplicación): Se imponen medidas correctivas cuando se detectan violaciones.
📌 Justificación de la Elección
1️⃣ Alineación Directa con los Componentes del Principio
El principio de Monitoreo y Verificación Continua exige un enfoque basado en:
✅ Registro de accesos en tiempo real.
✅ Expiración de sesiones y reautenticación periódica.
✅ Revisión y auditoría de actividades de acceso.
Cada uno de estos puntos se relaciona directamente con los cinco ejes del framework T.R.A.C.E., lo que garantiza que todas las dimensiones críticas del monitoreo y la verificación estén cubiertas.
2️⃣ Desglose del Framework en Relación con el Principio
| Componente de T.R.A.C.E. | Relación con Monitoreo y Verificación Continua |
| Tracking (Seguimiento) | Se asegura que cada solicitud de acceso sea registrada y rastreada en tiempo real. |
| Recording (Registro) | Se mantiene un historial detallado de accesos, intentos de autenticación y sesiones activas. |
| Auditing (Auditoría) | Se implementan revisiones automáticas y manuales para detectar patrones sospechosos. |
| Compliance (Cumplimiento) | Se verifica que el monitoreo y la verificación sigan las políticas de seguridad establecidas. |
| Enforcement (Aplicación) | Se ejecutan acciones de mitigación en caso de detectar accesos no autorizados o anomalías. |
Este desglose demuestra que T.R.A.C.E. cubre todos los aspectos esenciales del principio.
Evalué otras alternativas como S.M.A.R.T., R.I.S.E, C.A.R.E. , pero no aplicaban para este principio.
T.R.A.C.E. Es la mejor opción, ya que se enfoca en el rastreo, registro, auditoría y aplicación de medidas correctivas en accesos y autenticaciones.
😎Punto para reflexionar: Los frameworks de prompts nos ayudan a organizar y enfocar las instrucciones de una forma bien específica atendiendo determinados escenarios de manera eficiente y eficaz. Por lo tanto, no todos los frameworks se pueden usar para cualquier escenario.
📌 Framework de Prompts: T.R.A.C.E. para Monitoreo y Verificación Continua
📌 Prompt Base:
«¿El requerimiento contempla un mecanismo de monitoreo y verificación continua de accesos, asegurando que todas las sesiones sean autenticadas y registradas adecuadamente?»
📌 Subprompts de Validación:
🔍 Tracking (Seguimiento)
«¿Existe una política definida para rastrear todas las solicitudes de acceso y registrar la identidad de cada usuario/dispositivo?»
🔍 Recording (Registro)
«¿El sistema almacena logs detallados con timestamps, intentos de acceso fallidos y actividad del usuario?»
🔍 Auditing (Auditoría)
«¿Se establecen procesos automáticos y manuales de revisión de registros para detectar anomalías?»
🔍 Compliance (Cumplimiento)
«¿Los accesos cumplen con los estándares de seguridad de la organización y están alineados con Zero Trust?»
🔍 Enforcement (Aplicación)
«¿Se aplican medidas de mitigación en caso de detectar accesos anómalos, como bloqueos automáticos o alertas de seguridad?»
😎Punto para reflexionar: Hay que entender que estas instrucciones debemos ir utilizándolas con la IA Generativa, en este caso usé ChatGPT pero aplican perfectamente a un Gemini u otra, mediante interacciones y que hasta incluso, podemos ir refinándolas en base a los resultados que vayamos obteniendo sobre la base del análisis que se vaya haciendo del requerimiento y/o historia de usuario.
📌 Aplicación del Framework en Historias de Usuario
Si el requerimiento o historia de usuario NO contempla algunos de estos aspectos, el Líder Técnico de Calidad o el Tester Ágil a cargo, debe recomendar al Product Owner o a quien corresponda:
✅ Incluir políticas de autenticación continua y expiración de sesiones.
✅ Implementar registros detallados de acceso con revisiones periódicas.
✅ Automatizar auditorías para identificar accesos sospechosos en tiempo real.
✅ Definir reglas claras de bloqueo y mitigación en caso de actividad anómala.
Impacto de Zero Trust en las Pruebas de Seguridad
Dado este nuevo enfoque, las pruebas de seguridad deben adaptarse para evaluar cómo Zero Trust está implementado en la organización.
Las pruebas de seguridad pueden detectar fallas en la aplicación de los principios de Zero Trust en diferentes áreas:
- Redes:
- Pruebas de tráfico entre microsegmentos para validar que los accesos están correctamente restringidos.
- Datos:
- Evaluar que la información sensible siempre esté cifrada en tránsito y en reposo.
- Identidades y accesos:
- Verificar que los permisos no sean más amplios de lo necesario.
- Probar si usuarios no autorizados pueden acceder a recursos restringidos.
- Dispositivos:
- Evaluar si los endpoints tienen protección de seguridad adecuada.
- Realizar pruebas de penetración sobre dispositivos expuestos.
- Limitación del impacto en caso de ataque:
- Realizar pruebas periódicas para verificar que una brecha en un área no se extienda al resto de la infraestructura.
La adopción del modelo Zero Trust transforma la forma en que se deben realizar las pruebas de seguridad. En lugar de asumir que ciertos usuarios o dispositivos son confiables, las pruebas de seguridad deben validar continuamente:
- Que los accesos sean estrictamente controlados.
- Que las identidades y permisos sean los mínimos necesarios.
- Que los datos estén protegidos en todo momento.
El Security Test Engineer (STE) debe diseñar casos de prueba que evalúen la correcta implementación de los principios de Zero Trust en la red, los accesos, los dispositivos y la protección de datos.
😎Punto para reflexionar: Para finalizar, ¿Te imaginas tener una batería de framework de prompts genéricos y utilizar la misma para cada uno de los principios?
Fuente de inspiración: ISTQB Certified Tester Security Test Engineer Syllabus v1.0.1
