Add related.entity to okta integration #11589
Conversation
| lang: painless | ||
| source: | | ||
| boolean addValue(Set entities, String value) { | ||
| if (value == null || value == "" || value == "unknown") { |
There was a problem hiding this comment.
@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?
There was a problem hiding this comment.
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.
| TreeSet related = new TreeSet(); | ||
|
|
||
| addValue(related, field("json.actor.id").get(null)); | ||
| addValue(related, field("json.actor.alternateId").get(null)); |
There was a problem hiding this comment.
Do we also capture alternateId? I deemed it relevant because it's where we have the email present, which should be able to pivot on. But I also kept the id because it's the Okta id.
Any thoughts on if I should capture both indeed? Or maybe just one of the two? Same goes for target.
There was a problem hiding this comment.
Im in favor of both. Specifically for directory sync purposes. The Id does capture what Okta has registered as an IdP, but when acting as an IdP on behalf of other SaaS applications, alternateId is often pulled by syncing directory services. For example, if an environment sync'd Okta directory services with an Active Directory forest in a Windows Server, the Alternate ID will be more reliable than the Okta ID based on the functionality of the Universal Directory in Okta.
🚀 Benchmarks reportTo see the full report comment with |
andrewkroh
added
Integration:okta
|
Pinging @elastic/security-service-integrations (Team:Security-Service Integrations) |
|
cc @efd6 --> Adding Dan here who has been making some Okta adjustments requested by TRADE where we have discussed |
| addValue(related, field("json.actor.id").get(null)); | ||
| addValue(related, field("json.actor.alternateId").get(null)); | ||
|
|
||
| field("json.target").get(new ArrayList()).stream().forEach(target -> { |
There was a problem hiding this comment.
I've seen okta.target as an array of JSON objects but also a single JSON object. Just want to confirm that the code here addresses that or maybe that is inherit regardless.
There was a problem hiding this comment.
Good catch! I covered it in the painless script.
Interesting, once I tried to test with it we got a different error. The event is generated, but if an error. I wonder if that happens on pro.
Anyway it seems to work. Also with what I tested
💚 Build Succeeded
History
|
|
tldr; Adding
related.entityto 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.entityPRBackground
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.entityWith 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
relateddescription:To add a broad
related.entityfield that can hold any needed identifier to pivot data on seems to be well fitted. This would enable customers to simply runrelated.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. Althoughip,userandhostscan 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