Okta-eventType-Liste für die Incident Response
Die eventTypes im Okta System Log, die bei Vorfällen zählen, nach Angriffsphase gruppiert, mit wichtigen Feldern und Classic/Identity-Engine-Unterschieden.
TL;DR. Oktas Katalog umfasst weit über tausend eventTypes; eine Identitätsuntersuchung stützt sich auf etwa vierzig davon. Anmeldungen (user.session.start, user.authentication.auth_via_mfa), Push-Anfragen (system.push.send_factor_verify_push, user.mfa.okta_verify.deny_push), Faktoränderungen (user.mfa.factor.reset_all, user.mfa.factor.activate), Admin-Vergaben (user.account.privilege.grant), Tokens (system.api_token.create), Föderation (system.idp.lifecycle.create, user.authentication.auth_via_IDP) und App-Zugriff (user.authentication.sso). Lesen Sie jeden mit seinen Feldern outcome, client, securityContext und authenticationContext, nie den eventType allein.
Jeder unten genannte eventType wurde gegen Oktas veröffentlichten Katalog der Event Types geprüft (auch als CSV herunterladbar). Die Beschreibungen sind meine eigenen Zusammenfassungen; maßgeblich bleibt der Katalog.
Die Felder, die Sie bei jedem Ereignis lesen
Ein eventType sagt, was passiert ist. Der Rest des LogEvent sagt, ob es der echte Benutzer war:
| Feld | Warum es wichtig ist |
|---|---|
published | UTC-Zeitstempel; das Rückgrat Ihrer Zeitleiste |
actor.alternateId, actor.type | wer es getan hat (ein Benutzer, der Inhaber eines API-Tokens, das System) |
target[] | an wem oder was: Benutzer, App, IdP, Richtlinie, Authenticator |
outcome.result, outcome.reason | SUCCESS, FAILURE, ALLOW, DENY … und warum |
client.ipAddress, client.userAgent.rawUserAgent | Quelle und Browser |
securityContext.asNumber, asOrg, isp, isProxy | Netzbetreiber (ASN), Proxy-Kennzeichen |
authenticationContext.externalSessionId | die Sitzung (externalSessionId) |
authenticationContext.rootSessionId | die Wurzel einer interaktiven Sitzung, übersteht Faktoränderungen |
debugContext.debugData | privilegeGranted, factor, behaviors, risk, threatSuspected, tunnels, requestUri |
transaction.id, uuid | zusammengehörige Ereignisse gruppieren; das genaue Ereignis zitieren |
Ein Hinweis zu debugData: Es handelt sich um Diagnosekontext, keinen stabilen Vertrag, und die Schlüssel unterscheiden sich zwischen Organisationen und Releases. Behandeln Sie es als starken Hinweis, nicht als Schema.
Zu Sitzungen merkt Okta Security an, dass sich externalSessionId nach Faktor-Lifecycle-Ereignissen ändern kann, während rootSessionId der gesamten interaktiven Sitzung folgt (Okta Security: rootSessionId). Pivotieren Sie auf beide.
Anmeldung und MFA
| eventType | Was er protokolliert | Lesen zusammen mit |
|---|---|---|
user.session.start | Anmeldung bei Okta (Erfolg oder Fehlschlag) | outcome.reason, IP, ASN, User-Agent |
user.authentication.verify | Überprüfung der Benutzeridentität | Ergebnis, IP |
user.authentication.auth_via_mfa | MFA-Überprüfung | debugData.factor, Ergebnis |
policy.evaluate_sign_on | Auswertung der Anmelderichtlinie | debugData.behaviors, risk |
system.push.send_factor_verify_push | ein Okta-Verify-Push wurde gesendet | Anzahl pro Benutzer und Minute |
user.mfa.okta_verify.deny_push | der Benutzer hat einen Push abgelehnt (Classic Engine) | Serie, dann ein akzeptierter Push |
user.mfa.okta_verify | Überprüfung mit Okta Verify | Ergebnis |
user.mfa.attempt_bypass | Versuch, einen Faktor zu umgehen | Akteur, IP |
user.account.lock | Konto nach Fehlschlägen gesperrt | vorangehende Fehlschläge |
Der Katalogeintrag zu user.mfa.okta_verify.deny_push vermerkt, dass er von API-Abläufen der Classic Engine erzeugt wird; in der Okta Identity Engine erscheint ein abgelehnter Push als fehlgeschlagenes user.authentication.auth_via_mfa. Eine MFA-Fatigue-Erkennung, die nur deny_push beobachtet, ist in OIE-Organisationen blind. Mehr dazu unter MFA-Fatigue erkennen.
Faktoren und Passwörter
| eventType | Was er protokolliert | Warum er für Responder zählt |
|---|---|---|
user.mfa.factor.reset_all | alle Faktoren eines Benutzers zurückgesetzt | der Dreh- und Angelpunkt des Helpdesk-Social-Engineering |
user.mfa.factor.deactivate | ein Faktor entfernt | ebenso, wenn der Akteur nicht der Benutzer ist |
user.mfa.factor.activate | neuer Faktor registriert | das Gerät des Angreifers nach einem Zurücksetzen |
user.account.reset_password | Passwort von einem Admin zurückgesetzt | Akteur ≠ Ziel ist das Signal |
user.account.update_password | Passwort geändert | wer es geändert hat, von wo |
device.enrollment.create | neues Okta-Verify-Gerät registriert | neues Gerät direkt nach einem Zurücksetzen |
Die Abfolge Zurücksetzen durch jemand anderen → neuer Faktor aus einem neuen Netz wird in Social Engineering am Helpdesk und Faktor-Zurücksetzungen behandelt.
Sitzungen und Bedrohungssignale
| eventType | Was er protokolliert |
|---|---|
security.session.detect_client_roaming | Okta hat eine Roaming-Sitzung erkannt |
user.session.context.change | der Sitzungskontext hat sich so stark geändert, dass Richtlinien neu bewertet werden sollten |
policy.auth_reevaluate.fail | die kontinuierliche Zugriffsbewertung hat einen Richtlinienverstoß festgestellt |
user.session.clear | ein Admin hat die Sitzungen eines Benutzers beendet |
user.session.end | Abmeldung |
security.threat.detected | Anfrage von einer IP, die ThreatInsight als bösartig eingestuft hat |
security.attack.start | ThreatInsight hat erkannt, dass die Organisation angegriffen wird |
security.breached_credential.detected | ein Zugangsdatum aus einem bekannten Datenleck wurde verwendet |
user.account.report_suspicious_activity_by_enduser | der Benutzer hat „verdächtige Aktivität melden“ angeklickt |
user.risk.detect, user.risk.change | Benutzerrisiko erkannt oder geändert |
Siehe Session Hijacking erkennen und Password Spraying erkennen.
Administration und Persistenz
| eventType | Was er protokolliert | Wichtiges Detail |
|---|---|---|
user.session.access_admin_app | Admin Console geöffnet | erster Admin-Zugriff nach einem Zurücksetzen |
user.account.privilege.grant | einem Benutzer wurden Admin-Rechte gegeben | debugData.privilegeGranted |
group.privilege.grant | einer Gruppe wurden Admin-Rechte gegeben | danach die Gruppenmitglieder prüfen |
user.account.privilege.revoke | alle Admin-Rechte eines Benutzers entzogen | wer aufgeräumt hat und wann |
system.api_token.create | neues API-Token | trägt die Rechte seines Erstellers |
system.api_token.revoke | Token widerrufen | |
user.session.impersonation.grant / .initiate | Support-Impersonation aktiviert / gestartet | hat Ihr Team das angefordert? |
user.lifecycle.create | neuer Benutzer angelegt | neues Konto, dann Admin-Vergabe |
policy.lifecycle.update, policy.rule.update | Richtlinie oder Regel geändert | MFA aus einer Regel entfernt? |
policy.lifecycle.deactivate, policy.rule.deactivate | Richtlinie oder Regel deaktiviert | |
security.authenticator.lifecycle.deactivate | Authenticator für die gesamte Organisation deaktiviert | |
zone.update, security.threat.configuration.update | Netzwerkzone oder ThreatInsight geändert | Sperrliste entfernt? |
Details unter Missbrauch von Admin-Rollen und API-Tokens.
Föderation
| eventType | Was er protokolliert |
|---|---|
system.idp.lifecycle.create / .activate | Identity Provider angelegt / aktiviert |
system.idp.lifecycle.update | Identity Provider geändert |
system.idp.key.create | IdP-Signaturschlüssel hinzugefügt |
system.idp.lifecycle.read_client_secret | Client-Secret des IdP gelesen |
user.authentication.auth_via_IDP | Benutzer über einen externen IdP angemeldet |
user.authentication.auth_via_inbound_SAML | eingehende SAML-Authentifizierung |
Okta Security zählt system.idp.lifecycle.create und user.authentication.auth_via_IDP zu den Ereignissen, die gegen Cross-Tenant Impersonation überwacht werden sollten (Okta Security).
Anwendungszugriff
| eventType | Was er protokolliert |
|---|---|
user.authentication.sso | SSO in eine Anwendung (target enthält die App) |
app.oauth2.token.grant, app.oauth2.as.token.grant | OAuth-Token ausgestellt |
SSO verrät, welche Anwendung geöffnet wurde, nicht was dort geschah; machen Sie in den Logs der jeweiligen Anwendung weiter.
Wie der Analyzer sie nutzt
Der Analyzer gruppiert diese eventTypes in Filterkategorien (Authentifizierung, MFA, Sitzungen, Admin und IdP, Richtlinien und Sicherheit, App-Zugriff, Benutzer und Konten), und seine 25 Erkennungsregeln bauen auf ihnen auf: Schwellenwerte (Serien von Pushes oder Fehlschlägen), Sequenzen (ein Zurücksetzen, dann eine Registrierung) und Folgebedingungen (SSO in eine sensible App nach einem hohen Befund). Die Regeln sind Daten und auf der Startseite sichtbar, sodass Sie genau prüfen können, welche eventTypes und Felder jede liest.