Registros del proveedor de identidad

El registro del sistema de un proveedor de identidad como Okta guarda una ventana deslizante de 90 días: lo anterior no se devuelve, y una consulta con un rango mayor falla en la consola de administración. Quien necesite más historia tiene que descargarla o enviarla a otro almacén antes de que salga de la ventana.

Eso hace de la exportación continua a un SIEM una decisión previa al incidente. Cuando llega el caso, ya no se puede decidir.

Tres tipos de evento arman la mayor parte de una investigación de identidad. user.session.start es un inicio de sesión: la persona se autentica y el proveedor le abre una sesión. user.authentication.auth_via_mfa registra la verificación con segundo factor. system.api_token.create registra que se generó un token de API nuevo, con el identificador del token y la cuenta que lo creó.

Cada evento trae el resultado (SUCCESS o FAILURE), el cliente (con su dirección IP) y detalles del motivo. En la tabla sistema_idp esos campos son las columnas tipo_evento, resultado, ip, pais y detalle.

Una secuencia de fallos seguida de un éxito es una de las formas más viejas de leer un acceso no autorizado: alguien probó hasta acertar. Pero también es lo que parece cuando una persona olvida su contraseña. Lo que cambia el peso del patrón es el contexto: el país, la dirección y si esa dirección ya había aparecido antes en la cuenta.

La consulta de los inicios de sesión exitosos permite comparar el éxito de la madrugada del 17 de septiembre con los habituales de la misma cuenta.

Después de entrar, lo que hace la cuenta dice más que la entrada. Un token de API es una credencial de larga vida que no pasa por el segundo factor cada vez que se usa; que una sesión recién abierta lo cree de inmediato es un dato que se resalta, aunque tampoco prueba nada por sí solo.

Mide el tiempo entre el primer intento fallido de la secuencia y la creación del token. Responde en minutos completos.

En la secuencia hay cinco fallos desde un país donde la cuenta no suele entrar, un inicio exitoso, una verificación de segundo factor aprobada y un token nuevo. Lo que el registro permite afirmar es la secuencia, con horas y direcciones. Quién estaba al teclado y si la persona dueña aprobó la notificación del segundo factor no consta en esas filas.

Un informe sólido describe la secuencia, nombra lo que falta por confirmar y pide la acción que lo confirma: hablar con la persona por otro canal y revisar el dispositivo que aprobó.