Lista de eventTypes de Okta para respuesta a incidentes
Los eventTypes del System Log de Okta que importan en un incidente, por fase del ataque, con los campos a leer y las diferencias Classic / Identity Engine.
TL;DR. El catálogo de Okta incluye bastante más de mil eventTypes; una investigación de identidad se apoya en unos cuarenta. Inicios de sesión (user.session.start, user.authentication.auth_via_mfa), notificaciones push (system.push.send_factor_verify_push, user.mfa.okta_verify.deny_push), cambios de factores (user.mfa.factor.reset_all, user.mfa.factor.activate), concesiones de administración (user.account.privilege.grant), tokens (system.api_token.create), federación (system.idp.lifecycle.create, user.authentication.auth_via_IDP) y acceso a aplicaciones (user.authentication.sso). Lee cada uno con sus campos outcome, client, securityContext y authenticationContext, nunca el eventType aislado.
Todos los eventTypes de abajo se han comprobado en el catálogo de event types que publica Okta (también descargable en CSV). Las descripciones son resúmenes míos; el catálogo sigue siendo la referencia.
Los campos que lees en cada evento
Un eventType dice qué pasó. El resto del LogEvent dice si fue el usuario real:
| Campo | Por qué importa |
|---|---|
published | marca de tiempo UTC; la columna vertebral de tu cronología |
actor.alternateId, actor.type | quién lo hizo (un usuario, el propietario de un token de API, el sistema) |
target[] | a quién o a qué se le hizo: usuario, aplicación, IdP, política, autenticador |
outcome.result, outcome.reason | SUCCESS, FAILURE, ALLOW, DENY… y por qué |
client.ipAddress, client.userAgent.rawUserAgent | origen y navegador |
securityContext.asNumber, asOrg, isp, isProxy | propietario de la red (ASN), indicador de proxy |
authenticationContext.externalSessionId | la sesión (externalSessionId) |
authenticationContext.rootSessionId | la raíz de una sesión interactiva, sobrevive a los cambios de factor |
debugContext.debugData | privilegeGranted, factor, behaviors, risk, threatSuspected, tunnels, requestUri |
transaction.id, uuid | agrupar eventos relacionados; citar el evento exacto |
Una advertencia sobre debugData: es contexto de diagnóstico, no un contrato estable, y sus claves varían entre organizaciones y versiones. Trátalo como un indicio fuerte, no como un esquema.
En cuanto a las sesiones, Okta Security señala que externalSessionId puede cambiar tras eventos del ciclo de vida de los factores, mientras que rootSessionId sigue toda la sesión interactiva (Okta Security: rootSessionId). Pivota sobre ambos.
Inicio de sesión y MFA
| eventType | Qué registra | Leer junto con |
|---|---|---|
user.session.start | inicio de sesión en Okta (éxito o fallo) | outcome.reason, IP, ASN, user agent |
user.authentication.verify | verificación de la identidad del usuario | resultado, IP |
user.authentication.auth_via_mfa | verificación MFA | debugData.factor, resultado |
policy.evaluate_sign_on | evaluación de la política de inicio de sesión | debugData.behaviors, risk |
system.push.send_factor_verify_push | se envió un push de Okta Verify | número por usuario y minuto |
user.mfa.okta_verify.deny_push | el usuario rechazó un push (Classic Engine) | ráfaga y después un push aceptado |
user.mfa.okta_verify | verificación con Okta Verify | resultado |
user.mfa.attempt_bypass | intento de eludir un factor | actor, IP |
user.account.lock | cuenta bloqueada tras varios fallos | fallos previos |
La entrada del catálogo para user.mfa.okta_verify.deny_push indica que la emiten los flujos de la API de Classic Engine; en Okta Identity Engine, un push rechazado aparece como un user.authentication.auth_via_mfa fallido. Una detección de fatiga MFA que solo vigile deny_push está ciega en organizaciones OIE. Más en detección de la fatiga MFA.
Factores y contraseñas
| eventType | Qué registra | Por qué importa |
|---|---|---|
user.mfa.factor.reset_all | todos los factores de un usuario restablecidos | el eje de la ingeniería social al helpdesk |
user.mfa.factor.deactivate | un factor eliminado | lo mismo, cuando el actor no es el usuario |
user.mfa.factor.activate | nuevo factor registrado | el dispositivo del atacante tras un restablecimiento |
user.account.reset_password | contraseña restablecida por un administrador | actor ≠ objetivo es la señal |
user.account.update_password | contraseña cambiada | quién la cambió y desde dónde |
device.enrollment.create | nuevo dispositivo de Okta Verify registrado | dispositivo nuevo justo después de un restablecimiento |
La secuencia restablecimiento por otra persona → nuevo factor desde una red nueva se trata en ingeniería social al helpdesk y restablecimientos de factores.
Sesiones y señales de amenaza
| eventType | Qué registra |
|---|---|
security.session.detect_client_roaming | Okta detectó una sesión en itinerancia |
user.session.context.change | el contexto de la sesión cambió lo bastante como para reevaluar las políticas |
policy.auth_reevaluate.fail | la evaluación continua de acceso detectó una infracción de política |
user.session.clear | un administrador eliminó las sesiones de un usuario |
user.session.end | cierre de sesión |
security.threat.detected | petición desde una IP que ThreatInsight clasificó como maliciosa |
security.attack.start | ThreatInsight detectó que la organización está bajo ataque |
security.breached_credential.detected | se usó una credencial asociada a una filtración conocida |
user.account.report_suspicious_activity_by_enduser | el usuario pulsó «informar de actividad sospechosa» |
user.risk.detect, user.risk.change | riesgo de usuario detectado o modificado |
Consulta detección del secuestro de sesión y detección del password spraying.
Administración y persistencia
| eventType | Qué registra | Detalle clave |
|---|---|---|
user.session.access_admin_app | apertura de la Admin Console | primer acceso de administración tras un restablecimiento |
user.account.privilege.grant | privilegios de administración concedidos a un usuario | debugData.privilegeGranted |
group.privilege.grant | privilegios de administración concedidos a un grupo | después, revisar quién está en el grupo |
user.account.privilege.revoke | todos los privilegios de administración retirados | quién limpió y cuándo |
system.api_token.create | nuevo token de API | lleva los derechos de quien lo creó |
system.api_token.revoke | token revocado | |
user.session.impersonation.grant / .initiate | suplantación del soporte habilitada / iniciada | ¿la pidió tu equipo? |
user.lifecycle.create | nuevo usuario creado | cuenta nueva y después concesión de administración |
policy.lifecycle.update, policy.rule.update | política o regla modificada | ¿se quitó el MFA de una regla? |
policy.lifecycle.deactivate, policy.rule.deactivate | política o regla desactivada | |
security.authenticator.lifecycle.deactivate | autenticador desactivado en toda la organización | |
zone.update, security.threat.configuration.update | zona de red o ThreatInsight modificados | ¿se quitó una lista de bloqueo? |
Detalles en abuso de roles de administración y tokens de API.
Federación
| eventType | Qué registra |
|---|---|
system.idp.lifecycle.create / .activate | proveedor de identidad creado / activado |
system.idp.lifecycle.update | proveedor de identidad modificado |
system.idp.key.create | clave de firma de IdP añadida |
system.idp.lifecycle.read_client_secret | secreto de cliente del IdP leído |
user.authentication.auth_via_IDP | usuario autenticado mediante un IdP externo |
user.authentication.auth_via_inbound_SAML | autenticación SAML entrante |
Okta Security incluye system.idp.lifecycle.create y user.authentication.auth_via_IDP entre los eventos a vigilar frente a la cross-tenant impersonation (Okta Security).
Acceso a aplicaciones
| eventType | Qué registra |
|---|---|
user.authentication.sso | SSO a una aplicación (target contiene la aplicación) |
app.oauth2.token.grant, app.oauth2.as.token.grant | token OAuth emitido |
El SSO te dice qué aplicación se abrió, no qué se hizo en ella; continúa en los registros propios de esa aplicación.
Cómo los usa el analizador
El analizador agrupa estos eventTypes en categorías para filtrar (autenticación, MFA, sesiones, administración e IdP, políticas y seguridad, acceso a aplicaciones, usuarios y cuentas), y sus 25 reglas de detección están escritas sobre ellos: umbrales (ráfagas de push o de fallos), secuencias (un restablecimiento y después un registro de factor) y seguimientos (SSO a una aplicación sensible tras un hallazgo de gravedad alta). Las reglas son datos, visibles en la página principal, así que puedes comprobar exactamente qué eventTypes y qué campos lee cada una.