Okta System Log: what to ingest
The Okta System Log emits every authentication, authorisation, user lifecycle, policy, and admin action. ManySignal's Okta connector ingests via the System Log API with a configurable polling interval (default 30 seconds) and full backfill on first run. All events are normalised to OCSF before landing in the entity graph.
Do not filter Okta events before ingestion. The volume is manageable (most orgs under 10M events/day), and the cross-event correlations — authentication followed by user lifecycle change followed by app assignment — are what make Okta detections powerful. Filtering breaks correlation.
Critical Okta event types for detection
Authentication: user.authentication.auth_via_mfa_challenge_failed (brute force), user.authentication.sso (track app assignment usage), policy.evaluate_sign_on (conditional access policy match). Admin actions: user.account.update_password_by_admin (credential reset without user initiation), group.user_membership.add for privileged groups, application.lifecycle.activate for new apps.
MFA events are the most critical: user.mfa.factor.deactivate (MFA removed, T1556.006), user.mfa.factor.suspend, and user.mfa.factor.update. Any MFA change on a privileged account should generate a high-severity finding immediately — this is the primary persistence indicator in Okta-targeted attacks.
# detections/okta/mfa_deactivated_admin.yaml
key: okta.mfa_deactivated_admin
domain: identity
severity: critical
type: streaming
where:
class_uid: 3006
source: okta_system_log
event_type: "user.mfa.factor.deactivate"
graph:
condition: target_user_is_member_of_admin_group
attck:
tactic: TA0003
techniques: [T1556.006]
stage: activeImpossible travel and session anomaly
Impossible travel detection requires comparing sequential authentications from the same identity against the physical travel constraint. ManySignal's graph computes geographic velocity between consecutive authentications and flags pairs where the implied speed exceeds the configurable threshold (default 900 km/h — fast jet, not concord).
Concurrent session anomaly is distinct from impossible travel: the same identity with active sessions from two different countries simultaneously, regardless of velocity. Both can fire independently; the combination is high-confidence credential compromise.
Okta admin actions monitoring
Okta admin actions are the highest-blast-radius category of events. Monitor: new Okta admin created (application.lifecycle.activate for admin console), MFA policy changed to allow weaker factors, network zone modified to expand trusted IPs, and SAML IdP added (new authentication path, T1556.007).
The network zone expansion is particularly important: adding a broad IP range to a trusted zone can effectively bypass conditional access policies for identities that sign in from those IPs. It is silent, instant, and effective — exactly what an attacker with admin access would do.
Behavioural baselines for Okta identities
Every Okta identity in the entity graph has a rolling 90-day baseline: typical sign-in hours, typical client IP ranges, typical device fingerprints, typical app access patterns, and typical geographic regions. Deviations from any dimension lower the confidence score; deviations from multiple dimensions simultaneously trigger the behavioural detection.
Per-entity baselines are what separate ManySignal's Okta monitoring from standard SIEM rules. A static rule fires on 'login from a new country' for everyone — generating hundreds of FPs from legitimate travel. A behavioural rule fires on 'login from a country and device this identity has never used in 90 days, outside their normal hours, with no prior corporate VPN usage' — generating a handful of high-precision findings.
Key takeaways
- Do not filter Okta events before ingestion — cross-event correlation requires the full log.
- MFA deactivation on any privileged account is a critical detection regardless of other context.
- Impossible travel and concurrent session anomaly are distinct detections that compound when combined.
- Admin actions — policy changes, network zone expansion, new SAML IdP — are highest blast radius.
- API token creation events are high-severity and invisible to MFA policies.
- Per-entity baselines are what distinguish precise identity anomaly detection from high-FP static rules.