El concepto de Zero Trust (Confianza Cero) es un modelo de seguridad basado en la premisa de «no confiar en nada, verificar todo». Este modelo se fundamenta en el principio de aplicar controles de acceso estrictos y no confiar automáticamente en ninguna entidad, incluso si está dentro del perímetro de la red.
Principales características del modelo Zero Trust
- No existe la confianza implícita: No se asume que los dispositivos o usuarios dentro de la red sean confiables.
- Verificación continua: Se requiere autenticación y autorización para cada solicitud de acceso, incluso para dispositivos o usuarios previamente autenticados.
- Principio de menor privilegio: Se otorgan los permisos mínimos necesarios para realizar una tarea específica.
- Microsegmentación: Se dividen las redes en segmentos más pequeños para reducir la superficie de ataque.
- Múltiples factores de autenticación (MFA): Se requieren varias formas de verificación antes de otorgar acceso.
- Monitoreo y Auditoría constante: Se implementan registros de eventos y análisis de comportamiento para detectar accesos sospechosos.
- Protección de datos: Se asegura que los datos estén cifrados y protegidos en tránsito y en reposo.
Razones para implementar Zero Trust
- Aumento de las amenazas: Con el crecimiento de los servicios en línea y la computación en la nube, las vulnerabilidades han aumentado.
- Reducción del impacto de un ataque: Limita el acceso de los atacantes en caso de una brecha de seguridad.
- Protección contra el robo de credenciales: Reduce el riesgo de ataques de phishing y credenciales comprometidas al requerir autenticación continua.
Si necesitas más detalles sobre este tema, mi fuente de inspiración ha sido: la sección 1.3.1. «What is Zero Trust?” en el programa de estudios ISTQB Security Testing, en donde se explica cómo este modelo impacta las estrategias y técnicas de pruebas de seguridad.
Profundizando un poco con Prompts
Considerando los siguientes ítems, ¿Porqué no comenzar a pensar de que manera la IA Generativa nos puede ayudar a mejorar el entendimiento del Requerimiento y/o Historia de Usuario?, o sea, ¿Cómo podemos identificar presencia floja o ausencia de algunos de estos apartados y que son de considerar a la hora de salvaguardar nuestros activos mediante el desarrollo del alcance definido en la Historia de Usuario?
✅ No se confía automáticamente en nadie, ni siquiera dentro de la red.
✅ Se aplican controles estrictos de acceso en cada solicitud.
✅ Se requiere autenticación continua, minimizando riesgos.
✅ La microsegmentación impide movimientos laterales de atacantes.
✅ Protege datos cifrados en tránsito y en reposo.
OK, te compartiré la base mínima de instrucciones como para que sirva de “disparador” en la evaluación de este artículo y que te permita explorar e investigar nuevos campos.
🔍 Prompt 1: No se confía automáticamente en nadie, ni siquiera dentro de la red
📝 Prompt:
«¿El requerimiento define explícitamente que ninguna entidad (usuario, dispositivo o sistema) tiene acceso por defecto, incluso si está dentro de la red?
- Si no está contemplado, recomienda:
- Incluir un mecanismo de verificación de identidad para cada acceso.
- Especificar controles que limiten accesos predeterminados dentro de la red interna.
📌 Si esto no se aclara en el requerimiento, su implementación podría quedar abierta a interpretaciones y generar brechas de seguridad.
🔍 Prompt 2: Se aplican controles estrictos de acceso en cada solicitud
📝 Prompt:
«¿El requerimiento especifica controles estrictos de acceso por cada solicitud de usuario, aplicación o dispositivo?
- Si no está detallado, recomienda:
- Definir políticas de autenticación y autorización obligatorias.
- Implementar validaciones por sesión y restricciones basadas en roles y atributos.
📌 Si el control de acceso no está alineado con Zero Trust, un atacante podría explotar accesos débiles o mal configurados.
🔍 Prompt 3: Se requiere autenticación continua, minimizando riesgos
📝 Prompt:
«¿El requerimiento contempla autenticación continua y revalidación periódica del usuario, evitando sesiones indefinidas o persistentes?
- Si no está cubierto, recomienda:
- Incluir autenticación multifactor (MFA) en cada acceso crítico.
- Definir políticas de expiración y revalidación de sesión.
📌 Sin autenticación continua, una sesión secuestrada podría permanecer activa indefinidamente.
🔍 Prompt 4: La microsegmentación impide movimientos laterales de atacantes
📝 Prompt:
«¿El requerimiento establece microsegmentación para evitar movimientos laterales en caso de compromiso de un nodo o usuario?
- Si no está presente, recomienda:
- Definir restricciones de comunicación entre segmentos de red.
- Implementar controles granulares de acceso entre microsegmentos.
📌 Si la microsegmentación no está clara en el requerimiento, un atacante podría moverse libremente dentro de la red interna.
🔍 Prompt 5: Protege datos cifrados en tránsito y en reposo
📝 Prompt:
«¿El requerimiento especifica el uso obligatorio de cifrado para datos en tránsito y en reposo?
- Si no lo menciona, recomienda:
- Incluir cifrado TLS 1.2+ en las comunicaciones.
- Asegurar el cifrado de bases de datos y almacenamiento con AES-256.
📌 Si los datos no están cifrados, cualquier atacante con acceso podría exponer información sensible.
Punto para reflexionar: Que se entienda bien, estos prompts representan una base como para pensar en crear un framework robusto y genérico que te pueda servir para ser aplicado a la mayoría de las circunstancias que debas enfrentar y de esa forma lograr mejorar la calidad del producto en lo que refiere a la seguridad. Por otra parte y como siempre lo digo, cuanto más conozcamos acerca de nuestra práctica, mejor será nuestra elaboración de prompts y por lo tanto, mejor interacción tendremos con la inteligencia artificial generativa y por ende, mejores resultados (a refinar siempre). 🙂
