Falsos positivos en detecciones de Okta: VPN, móvil, ajuste

TL;DR. Las detecciones de identidad son heurísticas. Los falsos positivos más comunes vienen de VPN corporativas y pasarelas de seguridad que salen por redes cloud (hallazgos de proveedor de hosting y de sesión multirred), de móviles que pasan del wifi a los datos (una sesión, dos ASN) y de restablecimientos reales del helpdesk. Los falsos negativos más comunes vienen de exportaciones incompletas, ataques distribuidos entre muchas IP y técnicas que las reglas todavía no cubren. Verifica cada hallazgo con las personas implicadas y lee un veredicto limpio como «nada coincidió», nunca como «no pasó nada».

Prefiero que confíes un poco menos en el analizador y lo uses bien. Esta página enumera lo que no ve y dónde reacciona de más, regla por regla.

Límites de los datos

Retención de 90 días. La API del System Log no devuelve eventos de más de 90 días (Okta Developer). Un IdP creado hace cuatro meses, o los primeros pasos de una intrusión lenta, simplemente no están en la exportación.
Exportaciones filtradas. Una exportación buscada por un usuario pierde al agente del helpdesk que lo restableció y al administrador que lo ascendió. Exporta toda la organización.
Eventos tardíos. Okta advierte de que algunos eventos de un rango reciente pueden llegar con retraso. Vuelve a exportar las últimas horas más tarde durante un incidente en curso.
Fidelidad del CSV. Los CSV aplanados pierden o renombran campos. El analizador lee cabeceras con rutas de LogEvent y columnas _raw; las columnas aplanadas Okta_CL de Sentinel todavía no se mapean. Prefiere el JSON de la API.
debugData no es un contrato. Campos como privilegeGranted, behaviors, risk, threatSuspected y tunnels varían entre organizaciones y versiones. Las reglas que los leen pueden quedarse mudas si un campo cambia de nombre.
Historial corto, líneas base débiles. «Red nueva para este usuario» se calcula a partir de la propia exportación. Con dos días de historial, todas las redes son nuevas.

Límites de las detecciones

Las 25 reglas aparecen con su gravedad en la página principal. Lo que no hacen (todavía):

No cubierto	Alternativa
Spraying distribuido entre muchas IP (se agrupa por IP)	agrupa los fallos por ASN y user agent a mano, consulta password spraying
Viaje imposible / país nuevo por usuario	ordena por hora los inicios de sesión de un usuario en la tabla de eventos
`risk = HIGH` o `behaviors` como detección	visibles en el detalle del evento; filtra por usuario
Consentimiento de aplicaciones OAuth y abuso de client credentials	busca eventos `app.oauth2.*`
Cambios en reglas de grupo y de enrutamiento	revisa entera la sesión de administración del atacante
Usuario nuevo creado y ascendido a administrador de inmediato	comprueba `user.lifecycle.create` junto a los hallazgos de concesión de administración
Cada inicio de sesión a través de un IdP entrante	enumera `user.authentication.auth_via_IDP` para cualquier IdP nuevo
Lo que ocurrió dentro de las aplicaciones posteriores	usa los registros propios de la aplicación

Falsos positivos, regla por regla

Inicios de sesión desde proveedores de hosting y anonimizadores

access.hosting_provider busca palabras clave en securityContext.asOrg e isp (hosting, VPS, centro de datos y los nombres de grandes proveedores cloud y de hosting). Se dispara cuando:

tu VPN corporativa o pasarela web segura sale por un proveedor cloud;
el personal usa una VPN personal o un relé de privacidad;
un sistema de CI o un script inicia sesión de forma interactiva desde la nube (un hallazgo que merece corregirse en sí mismo).

access.anonymizer lee securityContext.isProxy y los datos tunnels de debugData. Desde el punto de vista de Okta, las VPN comerciales son anonimizadores.

Ajuste: enumera las IP y ASN de salida de tu VPN y tus pasarelas antes del incidente, y contrasta primero cada hallazgo de proveedor de hosting con esa lista. Como prevención, las zonas dinámicas mejoradas de Okta pueden bloquear categorías de anonimizadores y permitir tus redes conocidas.

Una sesión, varias redes o navegadores

session.multi_asn (alta) y session.multi_user_agent (media) agrupan los eventos por externalSessionId durante 12 horas. Causas legítimas:

dispositivos móviles que pasan del wifi a la red del operador (dos ASN, mismo user agent);
conexión a la VPN a mitad de sesión;
actualizaciones automáticas del navegador durante una sesión larga (dos cadenas de user agent que solo difieren en la versión);
conectividad de doble pila IPv4/IPv6 en la que las dos rutas las anuncian ASN distintos.

Ajuste: comprueba si el segundo ASN es un operador móvil o tu VPN, y si los user agents solo difieren en la versión. Un sistema operativo o una familia de navegador distintos en una red de hosting es el caso serio, como se explica en secuestro de sesión. Recuerda además que externalSessionId puede regenerarse tras eventos del ciclo de vida de los factores (Okta Security), así que una sesión reutilizada puede aparecer con un identificador distinto al del inicio de sesión original; pivota sobre authenticationContext.rootSessionId en el JSON original o en tu SIEM.

Fatiga MFA

mfa.push_fatigue cuenta tanto los envíos como los rechazos: cinco push en 15 minutos. Un usuario con varios dispositivos, o que accede a muchas aplicaciones que exigen MFA cada una, puede llegar a ello. Mira los resultados (¿todos aprobados?) y la red de origen de los inicios de sesión que los provocaron. Detalles en detección de la fatiga MFA.

Restablecimiento por el helpdesk y registro de factor

mfa.helpdesk_reset_then_enroll también se dispara con cada ticket real de «he perdido el móvil»; por eso su gravedad base es alta y no crítica. Pasa a crítica cuando el registro llega desde una red que el usuario no había usado antes del restablecimiento, desde un proxy o desde un proveedor de hosting. Un usuario que registra su móvil nuevo desde casa (donde ya había iniciado sesión) se queda en alta. Un usuario de vacaciones en el extranjero se agrava: confírmalo con él. Consulta ingeniería social al helpdesk.

Password spraying y adivinación

access.password_spray necesita 8 o más usuarios distintos con fallos desde una IP en una hora, con una media de 3 fallos o menos por usuario. Un NAT de oficina compartido tras una oleada de caducidad de contraseñas puede acercarse; la tasa de éxito los distingue. access.brute_force (10 fallos de un usuario en 15 minutos) se dispara con scripts con credenciales caducadas, como un cliente de correo antiguo que reintenta.

Cambios de administración, políticas e IdP

Las concesiones de roles, tokens de API, cambios de políticas, IdP y ajustes de seguridad se notifican los haga quien los haga, porque el registro no distingue un cambio planificado de uno malicioso. Las gravedades baja y media lo reflejan. Ajuste: contrasta cada uno con tus tickets de cambio. Una concesión de Super Administrator o un IdP nuevo sin ticket es un incidente hasta que se explique.

Una rutina de verificación para cada hallazgo

Quién es el actor, ¿y es de verdad esa persona? Llama a un número conocido.
Desde dónde: ASN, país y user agent comparados con el historial del usuario.
Qué vino después: los eventos posteriores al hallazgo (acciones de administración, registros de factores, SSO).
¿Hay constancia? Ticket, solicitud de cambio, viaje.
Decide y documenta en el informe, con los uuid de los eventos.

Cuando el veredicto es limpio

Contrasta el periodo, el número de eventos y los usuarios de la fila de estadísticas con lo que esperabas. Si algo parece escaso, corrige la exportación y vuelve a ejecutarla. Si está completa y limpia, es información útil, no una garantía. Conserva la exportación y revisa las recomendaciones de HealthInsight de Okta para tu organización.

FAQ

¿Por qué mi VPN corporativa aparece como proveedor de hosting?

Muchos servicios de VPN y pasarelas web seguras salen por redes cloud o de centros de datos. El nombre de la organización de su ASN coincide con las mismas palabras clave que un proveedor de VPS. Identifica tus ASN de salida y compruébalos primero.

¿Puede el analizador pasar por alto un ataque?

Sí. Solo ve los eventos exportados, usa umbrales fijos y todavía no cubre todas las técnicas. Un veredicto limpio significa que ninguna de sus reglas coincidió, no que no pasara nada.