Liste des eventTypes Okta utiles en réponse à incident
Les eventTypes du System Log Okta qui comptent en incident, classés par étape d'attaque, avec les champs à lire et les différences Classic / Identity Engine.
TL;DR. Le catalogue d'Okta compte largement plus d'un millier d'eventTypes ; une enquête d'identité en utilise une quarantaine. Connexions (user.session.start, user.authentication.auth_via_mfa), notifications push (system.push.send_factor_verify_push, user.mfa.okta_verify.deny_push), changements de facteurs (user.mfa.factor.reset_all, user.mfa.factor.activate), octrois d'admin (user.account.privilege.grant), jetons (system.api_token.create), fédération (system.idp.lifecycle.create, user.authentication.auth_via_IDP) et accès aux applications (user.authentication.sso). Lisez chacun avec ses champs outcome, client, securityContext et authenticationContext, jamais l'eventType seul.
Chaque eventType ci-dessous a été vérifié dans le catalogue des event types publié par Okta (également téléchargeable en CSV). Les descriptions sont mes propres résumés ; le catalogue reste la référence.
Les champs à lire sur chaque événement
Un eventType dit ce qui s'est passé. Le reste du LogEvent dit si c'était bien l'utilisateur :
| Champ | Pourquoi c'est important |
|---|---|
published | horodatage UTC ; la colonne vertébrale de votre chronologie |
actor.alternateId, actor.type | qui a agi (un utilisateur, le propriétaire d'un jeton d'API, le système) |
target[] | sur qui ou quoi : utilisateur, application, IdP, politique, authentificateur |
outcome.result, outcome.reason | SUCCESS, FAILURE, ALLOW, DENY… et pourquoi |
client.ipAddress, client.userAgent.rawUserAgent | source et navigateur |
securityContext.asNumber, asOrg, isp, isProxy | propriétaire du réseau (ASN), indicateur de proxy |
authenticationContext.externalSessionId | la session (externalSessionId) |
authenticationContext.rootSessionId | la racine d'une session interactive, qui survit aux changements de facteur |
debugContext.debugData | privilegeGranted, factor, behaviors, risk, threatSuspected, tunnels, requestUri |
transaction.id, uuid | regrouper les événements liés ; citer l'événement exact |
Une mise en garde sur debugData : c'est un contexte de diagnostic, pas un contrat stable, et ses clés varient selon les organisations et les versions. Traitez-le comme un indice fort, pas comme un schéma.
Côté sessions, Okta Security note que externalSessionId peut changer après des événements du cycle de vie des facteurs, alors que rootSessionId suit toute la session interactive (Okta Security : rootSessionId). Pivotez sur les deux.
Connexion et MFA
| eventType | Ce qu'il enregistre | À lire avec |
|---|---|---|
user.session.start | connexion à Okta (succès ou échec) | outcome.reason, IP, ASN, user agent |
user.authentication.verify | vérification de l'identité de l'utilisateur | résultat, IP |
user.authentication.auth_via_mfa | vérification MFA | debugData.factor, résultat |
policy.evaluate_sign_on | évaluation de la politique de connexion | debugData.behaviors, risk |
system.push.send_factor_verify_push | une notification Okta Verify a été envoyée | nombre par utilisateur et par minute |
user.mfa.okta_verify.deny_push | l'utilisateur a refusé un push (Classic Engine) | rafale, puis un push accepté |
user.mfa.okta_verify | vérification Okta Verify | résultat |
user.mfa.attempt_bypass | tentative de contournement d'un facteur | acteur, IP |
user.account.lock | compte verrouillé après des échecs | échecs précédents |
L'entrée du catalogue pour user.mfa.okta_verify.deny_push précise qu'elle est émise par les flux API de Classic Engine ; dans Okta Identity Engine, un push refusé apparaît comme un user.authentication.auth_via_mfa en échec. Une détection de fatigue MFA qui ne surveille que deny_push est aveugle sur les organisations OIE. Plus de détails dans détection de la fatigue MFA.
Facteurs et mots de passe
| eventType | Ce qu'il enregistre | Pourquoi c'est important |
|---|---|---|
user.mfa.factor.reset_all | tous les facteurs d'un utilisateur réinitialisés | le pivot de l'ingénierie sociale du helpdesk |
user.mfa.factor.deactivate | un facteur supprimé | idem, quand l'acteur n'est pas l'utilisateur |
user.mfa.factor.activate | un nouveau facteur enrôlé | l'appareil de l'attaquant après une réinitialisation |
user.account.reset_password | mot de passe réinitialisé par un admin | acteur ≠ cible, c'est le signal |
user.account.update_password | mot de passe modifié | qui l'a changé, d'où |
device.enrollment.create | nouvel appareil Okta Verify enregistré | nouvel appareil juste après une réinitialisation |
La séquence réinitialisation par quelqu'un d'autre → nouveau facteur depuis un nouveau réseau est traitée dans ingénierie sociale du helpdesk et réinitialisations de facteurs.
Sessions et signaux de menace
| eventType | Ce qu'il enregistre |
|---|---|
security.session.detect_client_roaming | Okta a détecté une session en itinérance |
user.session.context.change | le contexte de la session a assez changé pour justifier une réévaluation des politiques |
policy.auth_reevaluate.fail | l'évaluation continue des accès a constaté une violation de politique |
user.session.clear | un admin a supprimé les sessions d'un utilisateur |
user.session.end | déconnexion |
security.threat.detected | requête depuis une IP classée malveillante par ThreatInsight |
security.attack.start | ThreatInsight a détecté que l'organisation est attaquée |
security.breached_credential.detected | un identifiant associé à une fuite connue a été utilisé |
user.account.report_suspicious_activity_by_enduser | l'utilisateur a cliqué sur « signaler une activité suspecte » |
user.risk.detect, user.risk.change | risque utilisateur détecté ou modifié |
Voir détection du détournement de session et détection du password spraying.
Administration et persistance
| eventType | Ce qu'il enregistre | Détail clé |
|---|---|---|
user.session.access_admin_app | ouverture de l'Admin Console | premier accès admin après une réinitialisation |
user.account.privilege.grant | privilèges d'admin accordés à un utilisateur | debugData.privilegeGranted |
group.privilege.grant | privilèges d'admin accordés à un groupe | puis regarder les membres du groupe |
user.account.privilege.revoke | tous les privilèges d'admin retirés | le nettoyage : par qui ? |
system.api_token.create | nouveau jeton d'API | porte les droits de son créateur |
system.api_token.revoke | jeton révoqué | |
user.session.impersonation.grant / .initiate | accès d'usurpation du support activé / démarré | demandé par votre équipe ? |
user.lifecycle.create | nouvel utilisateur créé | nouveau compte puis octroi d'admin |
policy.lifecycle.update, policy.rule.update | politique ou règle modifiée | MFA retiré d'une règle ? |
policy.lifecycle.deactivate, policy.rule.deactivate | politique ou règle désactivée | |
security.authenticator.lifecycle.deactivate | authentificateur désactivé pour toute l'organisation | |
zone.update, security.threat.configuration.update | zone réseau ou ThreatInsight modifiés | liste de blocage retirée ? |
Détails dans abus de rôles d'admin et de jetons d'API.
Fédération
| eventType | Ce qu'il enregistre |
|---|---|
system.idp.lifecycle.create / .activate | fournisseur d'identité créé / activé |
system.idp.lifecycle.update | fournisseur d'identité modifié |
system.idp.key.create | clé de signature d'IdP ajoutée |
system.idp.lifecycle.read_client_secret | secret client d'IdP consulté |
user.authentication.auth_via_IDP | utilisateur connecté via un IdP externe |
user.authentication.auth_via_inbound_SAML | authentification SAML entrante |
Okta Security cite system.idp.lifecycle.create et user.authentication.auth_via_IDP parmi les événements à surveiller contre la cross-tenant impersonation (Okta Security).
Accès aux applications
| eventType | Ce qu'il enregistre |
|---|---|
user.authentication.sso | SSO vers une application (target contient l'application) |
app.oauth2.token.grant, app.oauth2.as.token.grant | jeton OAuth émis |
Le SSO dit quelle application a été ouverte, pas ce qui y a été fait ; poursuivez dans les journaux propres à cette application.
Comment l'analyseur les utilise
L'analyseur regroupe ces eventTypes en catégories de filtrage (authentification, MFA, sessions, admin et IdP, politiques et sécurité, accès aux applications, utilisateurs et comptes), et ses 25 règles de détection sont écrites à partir d'eux : seuils (rafales de push ou d'échecs), séquences (une réinitialisation puis un enrôlement) et suivis (SSO vers une application sensible après un constat de sévérité élevée). Les règles sont des données, visibles sur la page d'accueil : vous pouvez vérifier exactement quels eventTypes et quels champs chacune lit.