Todas las herramientas de inteligencia artificial, automatización del flujo de trabajo y aplicaciones de productividad que los empleados han conectado a Google y Microsoft este año han dejado algo atrás. Es un token OAuth persistente sin fecha de vencimiento, sin limpieza automática y, en la mayoría de las organizaciones, sin nadie que lo supervise. Los controles de límites no lo saben. MFA no detiene eso. Y si un atacante obtiene su contraseña, no la necesita.
Las concesiones de OAuth no caducan cuando un empleado deja la empresa. No se restablecerá incluso si se cambia la contraseña. Y en la mayoría de las organizaciones nadie los supervisa.
Este modelo tenía sentido cuando una pequeña cantidad de aplicaciones aprobadas por TI requerían acceso al calendario. Esto no funciona si cada empleado conecta individualmente herramientas de inteligencia artificial, automatización del flujo de trabajo y aplicaciones de productividad directamente al entorno de Google o Microsoft. Cada empleado recibe un token persistente y con alcance sin vencimiento automático ni visibilidad central.
No es un error de configuración. OAuth está diseñado de esa manera. La brecha es que la mayoría de los programas de seguridad no están diseñados para manejar problemas a escala.
Los CISO saben que es un problema. La mayoría no se resuelven.
Una nueva investigación en Seguridad de Materiales cuantifica la brecha entre conciencia y acción. El 80% de los líderes de seguridad cree que las concesiones de OAuth no administradas son un riesgo significativo o significativo. La mayoría de la gente lleva años diciendo lo mismo.
Sin embargo, la conciencia no está directamente relacionada con la capacidad. Una parte importante de las organizaciones (45%) no está haciendo nada para monitorear los permisos de OAuth a escala. Gran parte del resto (33%) realiza procesos manuales. Realizan un seguimiento de los permisos en hojas de cálculo, verifican los permisos ad hoc y dependen de los empleados para informar sobre comportamientos inusuales de las aplicaciones.
Las hojas de cálculo no son una respuesta a las amenazas. Estos son registros de la cantidad de riesgo que su organización desconoce.
no es un riesgo teórico
Las discusiones sobre la visibilidad de OAuth a menudo se enmarcan como si los empleados canalizaran información confidencial a herramientas de terceros sin visibilidad de TI. Es un problema real, pero es un problema mucho menor. Un problema más apremiante es que los permisos de OAuth son un vector de ataque activo. El incidente de la deriva encarna esto.
Drift, una plataforma de participación de ventas adquirida por Salesloft, mantuvo la integración de OAuth con instancias de Salesforce en cientos de organizaciones de clientes. El atacante, rastreado por la Unidad 42 de Palo Alto como UNC6395, obtuvo un token de actualización de OAuth válido, probablemente a través de una campaña de phishing anterior, y lo utilizó para acceder a entornos de Salesforce pertenecientes a más de 700 organizaciones.
La estructura del ataque es una advertencia. El token era legítimo y también lo era la integración. Desde la perspectiva del control de límites, no tenía nada de malo. Como el atacante no había iniciado sesión, se omitió por completo MFA. El atacante presentaba un token que Drift ya estaba autorizado a utilizar. Una vez dentro, UNC6395 exportó datos sistemáticamente y examinó credenciales como claves de acceso de AWS, tokens Snowflake y contraseñas.
Cloudflare, PagerDuty y decenas más se vieron afectados. La gama completa aún está bajo evaluación.
El incidente de Drift no fue un ataque de una aplicación desconocida y sospechosa. Fue un ataque de alguien en quien confiabas. La lección aquí no es que las organizaciones deban limitar la integración de OAuth. Confiar en una aplicación durante la instalación no garantiza que seguirá siendo confiable, y los permisos de OAuth requieren un monitoreo activo y continuo en lugar de una aceptación pasiva.
¿Qué tipo de seguimiento es realmente necesario?
Las herramientas de seguridad de OAuth de la generación actual abordan los riesgos de OAuth en el punto de instalación. Comprueba si el alcance del privilegio solicitado es excesivo. Podemos marcar aplicaciones de proveedores con mala reputación. Es útil, pero no suficiente. En el escenario Drift, las credenciales legítimas de las aplicaciones son posteriormente robadas y utilizadas como armas, pero no se detecta nada.
En primer lugar, el nivel de confianza del proveedor y el alcance de la aplicación son importantes, pero son sólo una parte del panorama. Monitorear el comportamiento real de su aplicación (las llamadas API que realiza y las acciones que realiza) es importante para comprender no solo lo que su aplicación puede hacer, sino también lo que realmente hace. Aún así, si una aplicación no tiene visibilidad detallada de las cuentas a las que está vinculada, todavía estás operando medio ciego. Una cosa es tener una aplicación peligrosa vinculada a la cuenta de un pasante, pero otra muy distinta es que la misma aplicación sea utilizada por un VIP con acceso a innumerables correos electrónicos, archivos y sistemas confidenciales.
El ataque Drift no involucró ninguna aplicación sospechosa que solicitara permisos inusuales durante la instalación. Se trataba de una aplicación legítima cuyas credenciales fueron posteriormente comprometidas y utilizadas como arma. No hay nada de malo en una herramienta que simplemente evalúa las subvenciones en el momento de su creación. Este riesgo quedó expuesto más tarde cuando el token fue robado y utilizado por un atacante completamente diferente.
La seguridad efectiva de OAuth requiere:
Monitoreo continuo del comportamiento en lugar de revisiones puntuales. ¿Qué hace realmente una aplicación después de que se le concede acceso? La supervisión de las llamadas API que realiza una aplicación conectada a OAuth a lo largo del tiempo revelará anomalías que las revisiones de permisos estáticos no pueden detectar, como picos repentinos en el acceso a datos, consultas con tipos de datos inusuales o acceso en momentos inesperados. Evaluación del alcance de la explosión. Una concesión de OAuth conectada a una cuenta con acceso de lectura a miles de documentos confidenciales y años de historial de correo electrónico es críticamente diferente de la misma concesión a una cuenta recientemente aprovisionada con exposición limitada. El alcance de la cuenta de un usuario determina el impacto potencial de una conexión OAuth comprometida o maliciosa. La puntuación de riesgo debería reflejar eso. Una respuesta escalonada adaptada a la tolerancia al riesgo de su organización. Las aplicaciones claramente maliciosas (proveedores desconocidos, permisos amplios, comportamiento inusual de la API desde el primer día) no deberían estar presentes en el entorno mientras se procesan los tickets en la cola. Debe cancelarse inmediatamente. Las anomalías menores en las integraciones de misión crítica de los principales proveedores requieren una revisión humana antes de tomar cualquier medida. La capa de respuesta debe ser lo suficientemente inteligente como para notar la diferencia.
Material Agente de corrección de amenazas de OAuth
El agente de corrección de amenazas OAuth de Materials Security se basa en este modelo más completo de riesgo de OAuth. Este agente se ejecuta continuamente en el entorno de Google Workspace de su organización y monitorea todas las aplicaciones conectadas a OAuth, no solo las aplicaciones nuevas a medida que se otorgan.
Para cada aplicación conectada, el agente evalúa tres factores juntos:
Análisis de alcance y confiabilidad del proveedor: una línea de base estándar donde la mayoría de las herramientas fallarían Monitoreo del comportamiento de las llamadas API reales realizadas por la aplicación (con el tiempo, revelando anomalías en el comportamiento esperado) Evaluación del alcance de la explosión en función del nivel de acceso y exposición de datos de las cuentas a las que está conectada la aplicación
Estos datos se combinan en una señal de riesgo que refleja tanto la probabilidad del problema como su impacto potencial. Cuando los agentes identifican permisos de alto riesgo, actúan de inmediato y revocan los tokens antes de que se produzca algún daño. En situaciones de baja certeza que involucran aplicaciones de misión crítica, los hallazgos se presentan a los equipos de seguridad con el contexto completo de lo que está haciendo la aplicación, sus derechos de acceso y su puntuación de riesgo.
Las organizaciones establecen sus propios umbrales. Es decir, ¿a qué nivel de riesgo se activará la remediación automática? ¿Dónde está la línea en la que se requiere la aprobación humana? El agente está diseñado para mantener a los equipos de seguridad informados sobre decisiones importantes y ciegos ante decisiones menos importantes.
cerrar la puerta trasera
Las concesiones de OAuth son la forma predeterminada para que las aplicaciones de terceros y las herramientas de inteligencia artificial se conecten a los espacios de trabajo empresariales. Eso no ha cambiado. A medida que se acelera la adopción de la IA, el número de subvenciones en la mayoría de los entornos seguirá creciendo. Decir a los empleados que no pueden utilizar herramientas de IA no es una postura de seguridad viable para la mayoría de las organizaciones. Además, incluso si una aplicación es legítima en el momento de la instalación, no protege contra amenazas que plantean aplicaciones maliciosas más adelante.
La respuesta no es menos permisos de OAuth. Mayor visibilidad de lo que existe y capacidad de operar de manera suficientemente inteligente para monitorear continuamente su comportamiento, responder a problemas críticos con la suficiente rapidez y evitar interrupciones en la integración para mantener su negocio en funcionamiento.
Si usted es un equipo de seguridad que desea visibilidad de lo que realmente está conectado a su entorno y la capacidad de reaccionar cuando algo cambia, comuníquese con Material Security para obtener una demostración del Agente de corrección de amenazas de OAuth.
Source link
