Add related.entity to okta integration

[romulets]

tldr; Adding related.entity to okta is part of the initial steps of CDR (epic overview). That enables our customers to better correlate events based on entities and enhances the investigation workflows for the Cloud Security use case.

ECS related.entity PR

Background

Elastic Cloud Security Team has been focusing, this past year, on Cloud Detection and Response (CDR). One of the first steps towards the CDR vision is to enhance investigation workflows for the Cloud Security use-case in SIEM.

As part of enhancing investigation workflows it's necessary to be able to correlate events and entities. Meaning, if an alert is triggered on the user [email protected], it is of great value to easily be able to search all the events related to that entity, across multiple indices, with one query. Therefore we are working on extracting entities and enabling them to be correlated.

Why related.entity

With this background, we've researched a few options on what would be the best approach to enable such feature (discussions https://github.com/elastic/security-team/issues/10026 and https://github.com/elastic/security-team/issues/9798, and outcomes https://github.com/elastic/security-team/issues/10152), and arrived at the ecs field related.

Based on the related description:

This field set is meant to facilitate pivoting around a piece of data.

Some pieces of information can be seen in many places in an ECS event.
To facilitate searching for them, store an array of all seen values to their
corresponding field in related..

To add a broad related.entity field that can hold any needed identifier to pivot data on seems to be well fitted. This would enable customers to simply run related.entity: "i-000000000" and get all the hits to that specific cloud resource.

What is an entity?

An "entity" in our context refers to any discrete component within an IT environment that can be uniquely identified and monitored. This broad term encompasses both managed and unmanaged elements.

The term "entity" is broader than the current set of available fields under related. Although ip, user and hosts can be identities, there is a lack of space to represent messaging queues, load balancers, storage systems, databases and others. Therefore the proposal to add a new field.

Related issues

• Closes https://github.com/elastic/security-team/issues/10393

[romulets]

@tinnytintin10 I'm ignoring the value unknown because if the alternative id is unknown to okta, the value in the event is unknown, e.g.

Do you agree with that decision?

[terrancedejesus]

I'd caution on ignoring unknown for Display Name and Alternate ID, specifically when it comes to custom client's that use Okta's API. Typically any custom client that uses the API will not be recognized by Okta and thus be considered unknown. In your example, the authentication enrollment is user specific. As long as we favor the existing Alternate ID over unknown, then we should be fine here.

When testing Okta, I'd test via 3 ways to have a good showcase of the workflows:

• Console Admin --> You logging in and doing stuff
• Custom Client --> Create App integration > API Services and then use the API key and client secret to interact with Okta's API.
• Third-Party App --> Register a third-party application that is available via Browse App Catalog and setup auth workflows. Then assign this to an existing user or yourself and interact with your registered applications via your Okta portal or browser plugin.

Each of these will have different workflows and potentially different related entities, targets, etc. From what I have found from past research is okta.actor.alternate_id (source), okta.target (target) and okta.debug_context.debug_data (context) will be your go to for most of this.

[romulets]

I'm getting:

• okta.actor.id
• okta.actor.alternate_id
• okta.target.id
• okta.target.alternate_id

And ignoring if any of those values is empty or contains the string unknown. Does that make sense?

[elastic-vault-github-plugin-prod]

🚀 Benchmarks report

To see the full report comment with /test benchmark fullreport

[elasticmachine]

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

[terrancedejesus]

cc @efd6 --> Adding Dan here who has been making some Okta adjustments requested by TRADE where we have discussed okta.target and a few other fields as well. Want to make sure we are all in sync here.

[efd6]

I think this is putting the cart before the horse. There is no related.entity field defined in the ECS. That should be proposed and worked through before we add a field use here that will prevent a proper exploration of how the semantics of this should be best represented. That is elastic/ecs#2360 noted in the PR description. I think that change is well posed, but let's wait until it's merged.

[romulets]

Hey @efd6 given you approved the related.entity implementation in GCP, without the need of ECS, could you have a look on this one again?

[efd6]

Well played. What is the progress of the ECS change?

[romulets]

The status of the ECS is awaiting product discussions. @tinnytintin10 is the best one to give context. On that

[elastic-sonarqube]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 969fa23

History

• 💚 Build #17729 succeeded 3c0dda2
• 💚 Build #17721 succeeded 689f771

[botelastic]

Hi! We just realized that we haven't looked into this PR in a while. We're sorry! We're labeling this issue as Stale to make it hit our filters and make sure we get back to it as soon as possible. In the meantime, it'd be extremely helpful if you could take a look at it as well and confirm its relevance. A simple comment with a nice emoji will be enough :+1. Thank you for your contribution!