search

elastic / detection-rules

https://www.elastic.co/guide/en/security/current/detection-engine-overview.html
Other
1.95k stars 497 forks source link

[Rule Tuning] Multiple Okta Client Addresses for a Single User Session #3506

Closed ksavchuk closed 4 months ago

ksavchuk commented 7 months ago

Link to rule

https://github.com/elastic/detection-rules/blob/main/rules/integrations/okta/initial_access_multiple_client_addresses_with_single_okta_session.toml

Description

I would like to propose an improvement to one of your security rules. The rule "Multiple Okta Client Addresses for a Single User Session" produces lots of false positives because of the way how okta generates external_session_id.

So:

When you are trying to log in Okta generates a log with event.action:user.session.start and some session ID. Let's name this ID "111" for example. Then Okta generates log with event.action:policy.evaluate_sign_on and the same session ID "111". But once I get into Okta session ID is no longer the same. All the actions performed by the user after login will have a new session ID. Let's name it "222". Because we have different session IDs during the login process and after finishing the login process we will receive this alert every time someone logs in to Okta. Long story short: okta gives you different session IDs during login and after, even though this is one session.

How to resolve it? You can simply exclude the login process from your query results. For example, you can enhance a query like the following.

event.dataset:okta.system
    and okta.authentication_context.external_session_id:* and okta.debug_context.debug_data.dt_hash:*
    and not (okta.actor.id: okta* or okta.actor.display_name: okta*) and not event.action:policy.evaluate_sign_on and not event.action:user.session.start

As another workaround, you can try to replace the session ID with the IP address, but in this case, there might be some false positives once the user uses the VPN.

botelastic[bot] commented 5 months ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

terrancedejesus commented 4 months ago

Thank you for the recommendations @ksavchuk! I've opened a PR to tune this rule accordingly. If you have further suggestions, please feel free to share. Ref -> https://github.com/elastic/detection-rules/pull/3814