«Zero Trust» continuo

La arquitectura Zero Trust se basa en el principio de «nunca confiar, siempre verificar». En la práctica, la mayoría de las implementaciones de Zero Trust verifican la identidad en el momento del acceso: cuando un usuario inicia sesión, se comprueban sus credenciales y el estado de su dispositivo, y se concede o deniega el acceso en función de esa evaluación en ese momento concreto. La brecha es todo lo que ocurre entre los eventos de inicio de sesión. Un empleado que se autentica correctamente a las 9:00 h con credenciales válidas puede haber sufrido el robo de esas mismas credenciales por parte de un malware de robo de información a las 8:00 h. El motor de políticas no lo sabe porque solo evaluó la identidad en el momento del inicio de sesión. Un atacante que adquiera la cookie de sesión robada a ese empleado en un mercado negro a las 10:00 h puede reproducirla en una sesión autenticada que la política de «Zero Trust» nunca considerará sospechosa, ya que la autenticación original fue legítima. La norma NIST 800-207 define el modelo «Zero Trust» como un sistema que requiere una validación continua, no solo en el momento del inicio de sesión. La mayoría de las implementaciones no cumplen este requisito, ya que carecen de un mecanismo para detectar señales de compromiso tras el inicio de sesión. SpyCloud cubre esta laguna al proporcionar continuamente al motor de políticas información procedente de la darknet sobre credenciales, cookies e infecciones por malware, de modo que las decisiones de acceso puedan adaptarse en tiempo real a lo que los delincuentes tienen realmente en su poder.

SpyCloud se integra directamente con las tres principales plataformas de identidad empresarial. En los entornos de Okta, Okta Workforce Guardian utiliza Okta Workflows para comparar continuamente las contraseñas de los empleados con los datos recuperados de la darknet por SpyCloud, lo que activa automáticamente el restablecimiento de contraseñas, la revocación de sesiones activas, la desactivación de cuentas o cambios en las políticas de autenticación adaptativa cuando se confirma una exposición. En entornos de Microsoft Entra ID, Entra ID Guardian se ejecuta en un contenedor de Azure y se integra con Microsoft Defender y Sentinel para garantizar la higiene de las credenciales y detectar señales de exposición relacionadas con el malware, junto con la telemetría existente de Entra ID Protection. En entornos de Active Directory locales, Active Directory Guardian se ejecuta localmente en un controlador de dominio o un servidor miembro, cotejando las credenciales de AD con el conjunto de datos recuperados por SpyCloud —incluidos los análisis de IDLink que revelan la reutilización de contraseñas entre el ámbito personal y el laboral— y activando restablecimientos forzados automáticos en un plazo de cinco minutos tras confirmarse una coincidencia. Las tres integraciones envían las señales de exposición de SpyCloud al motor de políticas como una entrada continua, en lugar de como una alerta puntual, lo que constituye la definición operativa de la verificación continua en una arquitectura Zero Trust.

La supervisión continua de identidades de SpyCloud cumple los requisitos de varios marcos normativos que exigen una verificación continua de credenciales e identidades. La norma NIST SP 800-207 (Arquitectura Zero Trust) define un algoritmo de confianza que debe evaluar continuamente la identidad del usuario y el estado del dispositivo, en lugar de considerar suficiente la autenticación inicial; SpyCloud proporciona los datos de telemetría de la darknet que la mayoría de las implementaciones de Zero Trust no incluyen en este algoritmo. La sección 5.1.1.2 de la norma NIST SP 800-63B exige una supervisión continua comparada con listas de credenciales comprometidas que se actualizan con frecuencia, con restablecimientos forzados automatizados: Identity Guardians cumple este requisito directamente con documentación de auditoría exportable para evaluaciones de cumplimiento. Las funciones «Gobernar» y «Detectar» del NIST CSF 2.0 requieren una supervisión continua de las amenazas y la exposición: los datos de SpyCloud sobre brechas de seguridad, malware y phishing satisfacen este requisito. Los controles 5 (Gestión de cuentas) y 6 (Gestión del control de acceso) de la versión 8 de los controles CIS exigen a las organizaciones que restrinjan el acceso no autorizado y corrijan las cuentas afectadas por malware; SpyCloud automatiza ambas tareas. Tanto DORA como NIS2 exigen pruebas de una supervisión continua de las amenazas y una corrección rápida de las exposiciones relacionadas con la identidad para las entidades reguladas en el sector de los servicios financieros y las infraestructuras críticas de la UE.

SpyCloud no sustituye a los proveedores de ZTNA, a los proveedores de identidad ni a ningún componente existente de una arquitectura Zero Trust. Proporciona la capa de inteligencia sobre la exposición de la identidad que esos sistemas necesitan como dato de entrada, pero que no pueden generar por sí mismos. Las plataformas ZTNA (Zscaler, Cloudflare, Palo Alto Prisma Access y otras) toman decisiones sobre las políticas de acceso basándose en la identidad del usuario, el estado del dispositivo y las señales del contexto de la red. Los proveedores de identidad (Okta, Entra ID, Ping Identity) autentican a los usuarios y gestionan el ciclo de vida del acceso. Ninguna de estas categorías tiene visibilidad del mercado negro, donde circulan credenciales robadas, cookies de sesión y registros de malware antes de que se produzcan los ataques. La función de SpyCloud es aportar al motor de políticas pruebas en tiempo real de la compromisión de identidades procedentes de ese mercado negro, de modo que las decisiones de acceso reflejen lo que los atacantes tienen realmente, y no solo lo que los sistemas internos de la organización pueden observar. Una arquitectura «Zero Trust» que carezca de esta señal externa de compromiso opera con información incompleta. SpyCloud subsana esa laguna específica sin alterar el resto de componentes de «Zero Trust».

La compromisión de la capa de sesión es el vector de ataque que aprovecha de forma más directa la brecha de «solo inicio de sesión» en las implementaciones de Zero Trust. Cuando una infección por malware de robo de información o un ataque de phishing AitM roba las cookies de sesión activas y los tokens de actualización de un empleado, el atacante dispone de una sesión autenticada válida que el motor de políticas de Zero Trust considera legítima, ya que se originó a partir de un inicio de sesión correcto. El dispositivo del empleado sigue superando las comprobaciones de estado de seguridad. Las credenciales siguen siendo válidas. Nada en el entorno interno indica que haya un problema. SpyCloud detecta la compromisión de la sesión de forma externa, desde el lado del delincuente: recuperando los artefactos de la sesión robada de los mercados del crimen y de los canales de distribución de malware de robo de información, antes o durante el intervalo en el que el atacante los tiene en su poder. Cuando se confirma una coincidencia, SpyCloud avisa al proveedor de identidad para que revoque el token de actualización, termine la sesión de SSO a nivel del IdP (lo que se propaga en cascada a todas las aplicaciones posteriores de la instancia de SSO) y fuerce una nueva autenticación. Esta es la única vía de corrección que expulsa por completo a un atacante que ha capturado tokens posteriores a la autenticación, y requiere una capa de inteligencia externa de la que los motores de políticas de Zero Trust no disponen de forma nativa.