Ignore Okta internal admin console accesses in stolen session rule

[JosiahOne]

Background

Okta may include events in the system log that make it look like an Okta (admin) user suddenly changed user agent and IP: https://support.okta.com/help/s/article/okta-integrations-showing-as-rawuseragent-with-okta-ips?language=en_US

Prior to February 7, the externalSessionId was "unknown" which meant this Panther rule ignored the problematic events. However, starting February 7th this seems to have changed and Okta has started generating session ids corresponding to these Okta-owned, internal events.

The result is that we (a customer of Panther's) started getting hit with alerts making it seem like sessions were hijacked when in fact it's just that these internal Okta user agent/ip events were causing alerts to fire.

Changes

To fix this, note that the client.id field contains a unique ID associated with internal Okta applications. You can find some of these IDs documented as part of the following Okta API: https://developer.okta.com/docs/api/openapi/okta-myaccount/myaccount/tag/OktaApplications/

To mitigate the noise, I've started by checking for the "Admin Console" application and ignore events associated with that.

Testing

• pat test
• We are running this variant in our company's panther instance without issue.

[skottler]

We're seeing the same events generated from the browser plugin and dashboard itself too. It might be worth including all four app IDs?

[JosiahOne]

Some bad news is I don't think this solution totally works. At least, it won't work if you make use of "Okta Access Requests" which aren't okta. prefixed. I'm assuming the client id is unique per customer.

Instead, I think we might need to change the keys themselves. Instead of relying purely on the externalSessionId, perhaps concatenating that value with the actor.id would be more robust. It seems that these "app" events always have a different actor id. A truly stolen session would use the same actor presumably, so it should be safe to update.

I'm going to try that internally and will update this PR later if that seems to work.

[egibs]

@JosiahOne -- that might be a good approach and one we were looking at internally as well. Feel free to include the change in this PR 👍🏻

[skottler]

@JosiahOne @egibs I think the most complete solution is something like comparing client.id with the list of non-user actors. If there is a target outside the user with a matching client ID then it should be permitted?

[JosiahOne]

@egibs @skottler

Hmm. After looking further, handling the Access Requests case robustly is non-trivial. I was wrong and it is not the case that the actor.id always differs (with respect to user actions and Access Request actions).

Worse, it also looks like client.id doesn't always exist so using that as part of the key won't always work either.

It might be preferable to merge this PR as-is (or, perhaps, with the few additional okta. prefixed IDs) to solve most cases. A followup will need to be thought of for the access requests situation.

[JosiahOne]

Also, regarding the other okta. app ids. It doesn't look like they would have to be added to this PR. At least in my data, the other Okta apps properly re-use the user agent of the real user. It's only the admin console (and now Access Requests) that rewrites it.

[egibs]

It might be preferable to merge this PR as-is (or, perhaps, with the few additional okta. prefixed IDs) to solve most cases.

I think this makes sense for now; addressing the prevalent cases frees up cycles to work on the remaining gaps.

[skottler]

I've applied the okta.* ignore change here in our environment.

The more broad change I made is a modification to the rule that set the previous_session. When there's more than one target and one of the targets has a signOnModeType of OPENID_CONNECT, the pieces that write the session metadata via put_string_set get skipped so the behavioral information about the internal session doesn't get recorded.

Let me know if that'd be a useful change to propose in this repo and I'd be happy to submit a pull request.

[egibs]

@skottler -- go for it! We'd be more than happy to look at it.

I was working on a change to track the dtHash value via put_string_set but didn't get a chance to test it much.