[Integration Update] Add Sessions, Policy, Factors and Devices data to Okta Entity Analytics

[terrancedejesus]

Summary

The Okta Entity Analytics integration is great for contextual IdP data on users. Often this data can be helpful when writing threat detection rules alongside Okta system logs.

However, according to the documentation, the integration only pulls data from the Users API, which is a great start but does not contain enough contextual information to write high fidelity threat detection rules on. Adding data from the Sessions, Policy, Factors and Devices APIs will add much more enrichment. Below are examples:

• Login failed behind proxy (Okta system logs), where MFA is disabled (Policy data)
• Multiple MFA denied (Okta system logs), where device registered is < 14 days for user (Device data)

Additionally, this contextual and relational data may prove beneficial for ML and LLM initiatives.

cc @tinnytintin10 @jmcarlock

[elasticmachine]

Pinging @elastic/security-service-integrations (Team:Security-Service Integrations)

[Mikaayenson]

cc. @joedatlive

[joedatlive]

Thanks Mika! I agree this would be great data to add and we can use it to enrich our Privileged User Monitoring capability in 8.17. For example, we can show disabled and denied MFA for Privileged Users.

Here is a sub-task we created for integrations. https://github.com/elastic/security-team/issues/10420

@cpascale43 let's discuss in our sync tomorrow and see if we can get this on the 8.17 list.

[terrancedejesus]

Update 09-19-2024

@sodhikirti07 reached out asking for insight into Okta system logs related to https://github.com/elastic/security-team/issues/10420 linked by @joedatlive in a previous comment.

From my understanding, the goal is to leverage ML to identify scenario's (priv esc) similar to the following:

Scenario

• Alice was assigned admin by Bob (System Logs - Okta)
• Bob is a member of an overly permissive group with several admin roles (EA Logs - User/Groups API)
• Bob typically does not assign user roles (System Logs - Okta)
• Bob is also authenticated from an unusual location based on client data (captured in system logs) (System Logs - Okta)
• Bob also does not have MFA enabled, making his account more susceptible to abuse if creds are compromised ( EA Logs - User Factors API)

To accomplish this, an algorithm would need access to both "activity-based" and "context-based" data for Okta. For example, what did Bob do and tell me about Bob's user profile. This seems to be accomplishable, but will require some updates to the Entity Analytics integration with the minimum being done.

• User's API (data already being pulled) - Include List all User Role Assignments data for each user. This will capture any roles, including administrative, that are assigned to the user. In this instance, capturing context about Bob's roles.
  • Ref: https://developer.okta.com/docs/api/openapi/okta-management/management/tag/RoleAssignmentAUser/#tag/RoleAssignmentAUser/operation/listAssignedRolesForUser
• Group's API (data not being pulled yet) - Add data from this API endpoint, specifically List all Group Role Assignments. This will help correlate if Bob is part of a group and what the role assignments to that group are.
  • Ref: https://developer.okta.com/docs/api/openapi/okta-management/management/tag/RoleAssignmentBGroup/#tag/RoleAssignmentBGroup/operation/listGroupAssignedRoles
• User Factors API (data not being pulled yet) - Add data from this API endpoint, specifically List all Enrolled Factors. This will help identify the factors that Bob's account has, 2FA, MFA, etc.
  • Ref: https://developer.okta.com/docs/api/openapi/okta-management/management/tag/UserFactor/#tag/UserFactor/operation/listFactors
  • Note that while the Core Okta APIs list's this as a separate API, the URI path points to Users, so not entirely sure 🤷🏽

I believe Session data would be beneficial as well but not entirely necessary for this or priv esc scenarios based on the sample data given by Okta. It would however, allow us to start leaning into session-hijacking anomalies and detection.

I have given Kirti access to TRADE's Okta dev environment and a stack with data from both integrations actively ingesting. Happy to share access as need be and helping with threat emulation.

cc @tinnytintin10 @Mikaayenson

@tinnytintin10 - It may be very beneficial for you and @joedatlive to sync on this, if not already. When we discussed node visualization for CDR, the contextual information reported by these APIs would be extremely helpful with each node or edge if user's wanted to understand more about that entity.

[susan-shu-c]

Hi, in relation to [Epic] Using ML to detect abusing the Privileged access of an admin account elastic/security-team#10421: Can we confirm if this ticket will update the Okta fields that we need for developing anomaly detections:

Field	Description	Notes
okta.assignmentType	Type of the assignment	e.g. USER, GROUP or CLIENT
okta.type	Standard role type	Examples are ORG_ADMIN, HELP_DESK_ADMIN and more
okta.label	Label for the Role Assignment	Examples are "Help Desk Administrator" and "Organization Administrator"

More info:
https://docs.google.com/spreadsheets/d/1grG6KiM_3IQJg1qAPIK-tt5nThaXezvVF2QqbIncJG0/edit?gid=0#gid=0

[efd6]

I have a PR that adds role and factor collection to the internal client. Session data is not viable since it requires a cookie and only deals with a single, logged in (or with this state fabricated via cookie) user.

I am concerned about the impact of adding all these additional calls. Already we make O(paginations+users) calls to the API since all users have their group membership queried by the client. With the addition of roles, we will have O(paginations+3×users) (abusing O-notation). In the current set-up we are already in a position where a large organisation will be rate-limited to the extent that a full sync may take on the order of 24 hours. Really, Okta should have used graphQL for this set of APIs, but we live in the universe that we do.

[efd6]

@susan-shu-c The roles API endpoints include those fields. If they are needed as fields under octa.* we can do that mapping.

[
    {
        "id": "REDACTEDROLE",
        "label": "Super Administrator",
        "type": "SUPER_ADMIN",
        "status": "ACTIVE",
        "created": "REDACTEDDATE",
        "lastUpdated": "2024-05-13T20:57:13Z",
        "assignmentType": "USER",
        "_links": {
            "assignee": {
                "href": "https://REDACTEDDOMAIN.okta.com/api/v1/users/REDACTEDUSER"
            }
        }
    }
]

[susan-shu-c]

@efd6 those fields look great, let's add them, thank you!

#10426 (comment)

[andrewkroh]

I share the concerns about rate-limiting. I think we should document a formula to estimate the length of time a full sync will take given the number of accounts in your org. Do we also want to consider making some of the enrichment optional (e.g. making it possible to opt-out of "factors") in the integration config?

Originally I was thinking that if we used the SCIM we might be able to mitigate rate-limits because the API works a little different, but it doesn't expose things like sessions or factors so this isn't an option.