CISA y NIST han publicado orientaciones destinadas a proteger los sistemas de identidad en la nube del ámbito federal frente al robo, la falsificación y el uso indebido de tokens de autenticación. El anuncio aparece en la página de noticias de CISA. En el momento de redactar este artículo, el anuncio incluía un titular pero ningún resumen, por lo que este informe se limita a lo que el título indica y al contexto documentado públicamente sobre el problema que aborda.

Tres conclusiones son claras solo a partir del titular. La publicación es conjunta entre CISA y NIST. Su audiencia son las agencias federales que operan sistemas de identidad en la nube. Y su objeto son los tokens: los artefactos firmados que permiten a un usuario, dispositivo o carga de trabajo demostrar que ya se ha autenticado. En la práctica, esto abarca tokens de acceso y de refresco de OAuth, tokens ID de OIDC, aserciones SAML, tokens de refresco primarios y cookies de sesión.

Que los tokens merezcan sus propias orientaciones no es ningún misterio para quien haya leído un informe de incidente en los últimos años. La mayoría de los tokens son instrumentos al portador, lo que es una forma educada de decir que funcionan como el efectivo: quien posee uno puede utilizarlo. Un token robado elude la contraseña, el mecanismo de MFA y, con frecuencia, la comprobación del dispositivo, porque los tres ya ocurrieron cuando se emitió el token. Los kits de phishing que actúan como proxy del inicio de sesión y extraen la cookie de sesión, el malware que rastrea cachés de tokens y el abuso del consentimiento de OAuth explotan todos la misma debilidad.

La falsificación es la variante más grave. La revisión del Cyber Safety Review Board sobre la intrusión de Storm-0558 documentó cómo una clave de firma de Microsoft robada se utilizó para falsificar tokens que otorgaban acceso a buzones de Exchange Online, incluidos los de agencias federales. En ese caso no se engañó a ningún usuario mediante phishing. El atacante simplemente imprimió su propio dinero. Ese episodio es la razón pública más evidente por la que las orientaciones federales sobre identidad tratan ahora las claves de firma y la validación de tokens como controles de primer orden, y no como aspectos internos del proveedor.

Ambas agencias cuentan con trabajo previo relevante. El proyecto Secure Cloud Business Applications (SCuBA) de CISA publica líneas base de configuración segura para Microsoft 365 y Google Workspace. La serie SP 800-63 de NIST abarca autenticación, gestión de sesiones y federación, incluyendo cómo deben validar las aserciones las partes que confían en ellas. Si las nuevas directrices amplían esos documentos, reemplazan partes de ellos o son independientes no se indica en el titular del anuncio, y este artículo no lo conjeturará.

Lo que aún no se conoce a partir del material fuente:

• Si las orientaciones son vinculantes para las agencias o meramente consultivas, y si se aplica algún plazo de implementación
• Qué proveedores de identidad en la nube y protocolos de federación están cubiertos, y si se prescribe alguna configuración específica por proveedor
• Qué requisitos de detección o registro introduce para la emisión de tokens y la reproducción de estos
• Si el alcance se limita a usuarios humanos o también abarca cuentas de servicio e identidades de carga de trabajo

Los profesionales deberían leer el documento en sí una vez que el texto completo esté disponible, en lugar de basarse en coberturas secundarias, incluido este artículo. Lo alentador es que la defensa de tokens es un problema resuelto en principio. Las duraciones cortas de los tokens, la evaluación continua del acceso, los tokens vinculados al dispositivo o restringidos al emisor (DPoP para OAuth, protección de tokens en el Acceso Condicional de Entra ID donde esté disponible), la rotación rigurosa de claves de firma y la validación de audiencia e emisor en cada parte que confía ya están disponibles hoy. La mayoría de las organizaciones ya disponen de los controles. Simplemente no los han activado todos, lo que es menos una brecha tecnológica que una tarde del martes que alguien sigue posponiendo.

Por el lado crítico, las agencias federales son la audiencia designada, pero los mismos tokens, los mismos protocolos y los mismos atacantes aparecen en cualquier tenant comercial. Tratar esto como una tarea de cumplimiento ajena sería una elección deliberada.

Los equipos de identidad y seguridad deberían verificar tres cosas ahora mismo. Revisar la duración de los tokens y las sesiones en su proveedor de identidad y confirmar que las aplicaciones de alto valor exigen reautenticación o evaluación continua, en lugar de confiar en una cookie de un día de antigüedad. Inventariar quién controla las claves de firma de SAML y OIDC, cómo se almacenan, cuándo se rotaron por última vez, y si cada parte que confía valida el emisor, la audiencia y la firma en lugar de simplemente decodificar el payload. Por último, confirmar que los registros de inicio de sesión y emisión de tokens se conservan y son consultables, y crear al menos una detección para un token utilizado desde una IP, dispositivo o ubicación que no realizó la autenticación original.