[Rule Tuning] credential_access_multiple_auth_events_from_single_device_behind

[BCall-BT]

(https://github.com/elastic/detection-rules/blob/main/rules/integrations/okta/credential_access_multiple_auth_events_from_single_device_behind_proxy.toml)

Description

The absence of 'and event.outcome: "success"' can create a number of false positives as it would count failed logins (including wrong user name, be it typo, auto-fill, etc). Adding this will ensure the rule only triggers successful logins.

On the side, I question the need to have this to be narrowed to be specific to behind proxy only. In my environment, I want to see this action regardless of whether the host system is behind a proxy or not.

[botelastic]

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.

[botelastic]

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]

@BCall-BT - Thank you for taking the time to open this issue. We avoided using event.outcome: success in this rule because of the cardinality between users and device hashes reported, along with the focus being credential stuffing detection. If a single device is having multiple failed attempts against several users behind a proxy, this is a good signal of credential stuffing. Limiting it to only successful authentications, being it a threshold rule, would require a potential credential stuffing attempt to have multiple successful user authentications.

Rather, there is a chance of false-positives with shared devices that leverage Okta as an IdP, such as Kiosks, where multiple failed logins for different users may occur. In these instances, we would suggest adding an exception list for specific values related to okta.debug_context.debug_data.dt_hash as noted in the rule notes:

- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule.
    - This will prevent future occurrences of this event for this device from triggering the rule.

I agree a new rule should be added for potential credential stuffing and/or password spraying against Okta regardless of proxy is a great signal. With ES|QL we have more aggregate functionality to measure data points in authentication. I have created a new pull request with 3 new rules for this. Please feel free to add some insight or suggestions if you'd like!

Ref: #3797