[Rule Tuning] event.action not matching any logs for Okta detection rules

[mavzerburak0]

Link to rule

https://github.com/elastic/detection-rules/tree/main/rules/integrations/okta (except credential_access_okta_brute_force_or_password_spraying.toml)

Description

While using Elastic SIEM for Okta with the system log API, I realized that most of default detection rules for Okta are using the value of the action key (i.e. event.action) to detect suspicious events. However, in the new System Logs API, events are supposed to be identified with the value of eventType key. This leads to no alerts being raised from Okta logs through any of the default detection rules except one (that doesn't use the event.action value). I proceeded to duplicate all default rules and change the query to use the value of eventType key (okta.eventType was what I used since I changed the target from "json" to "okta" in input.yml of the filebeat module) and they all seem to work fine now. For the default Okta module, I believe the queries should be updated with json.eventType : "" instead of event.action. In case there is a need for backward compatibility, event.action : "" can still be kept in query with an OR statement.

I think the main reason for this is that Okta is deprecating the legacy Events API and asks users to migrate to System Log API (More info here: https://developer.okta.com/docs/concepts/events-api-migration/).

"...One of the most important attributes of an event in the Okta system is its "event type" designation. In the Events API, the action.objectType attribute denotes the event type. In the System Log API, the eventType attribute represents the event type. The values in each of these fields are generally different, although there is some overlap for historical purposes. In the interest of easing the transition from the Events API to the System Log API, LogEvent's legacyEventType attribute identifies the equivalent Event action.objectType value. The Event type mapping section of this guide provides a static mapping of Events API event types to System Log API event types..."

Example Data

Example data is taken from the latest Okta System Log API query through curl (rest of the response is omitted as it is irrelevant to this issue):

...
},
        "displayMessage": "User single sign on to app",
        "eventType": "user.authentication.sso",
        "outcome": {
            "result": "SUCCESS",
            "reason": null
},
...

• Screenshot of quick query preview with okta.eventType query

• Screenshot of quick query preview with event.action query

[threat-punter]

@mavzerburak0 - Thank you for reporting this and providing us with so much context and detail. I'll look into this and get back to you.

[threat-punter]

@mavzerburak0 - Can you please confirm how you're retrieving and shipping your Okta System logs to Elasticsearch?

I'm using Filebeat's Okta module to ship my Okta System logs to Elasticsearch and can see the relevant fields and values are being translated to event.action. I was able to trigger a rule consistently (Attempt to Deactivate an Okta Network Zone).

[mavzerburak0]

@threat-punter - Hi. I am also retrieving the logs via Filebeat's Okta module.

Could you confirm if you are using the Events API or the System Log API from Okta? I believe event.action field is only present in the Events API, which will be deprecated eventually (see. issue description). I am retrieving the logs from System Log API and currently I don't see any event.action field.

As I mentioned previously, Events API can still be supported with an OR statement in the query e.g.

Supports both System Log API and Events API

event.dataset:okta.system and (okta.eventType: policy.lifecycle.deactivate OR event.action:policy.lifecycle.deactivate)

Please note that okta is what I used in my module configuration - I think the default is json, so by default, it would be json.eventType.

For references, please see Okta System Log API attributes and Events API attributes.

[threat-punter]

Could you confirm if you are using the Events API or the System Log API from Okta?

@mavzerburak0 - I configured Filebeat's Okta module to use the system log API as follows:

- module: okta
  system:
    var.url: https://yourOktaDomain/api/v1/logs
    var.api_key: 'myapikey'

Please note that okta is what I used in my module configuration - I think the default is json, so by default, it would be json.eventType.

Can you provide more details on how you configured this?

What version of Filebeat are you using?

[mavzerburak0]

@threat-punter - It seems like we are using the same API.

What version of Filebeat are you using?

filebeat version 7.14.0 (amd64)

Can you provide more details on how you configured this?

Only configuration change I made was within the input.yml file within Okta module.

...
processors:
  - decode_json_fields:
      fields:
        - message
      target: json
...

to

...
processors:
  - decode_json_fields:
      fields:
        - message
      target: okta
...

The reason was that the events I received were not easily distinguished with target as json - so only for convenience.

However, I did a little digging into the Okta module and found the following lines in pipeline.yml:

- rename:
      field: json.eventType
      target_field: okta.event_type
      ignore_missing: true
      ignore_failure: true

and

...
 - convert:
      field: okta.event_type
      target_field: event.action
      type: string
      ignore_failure: true
...

That little change I made for convenience broke this flow since there is no json.eventType anymore, it's been renamed to okta.eventType. Also, as ignore_missing and ignore_failure is set to true, this didn't raise any warnings or errors.

Thank you so much for looking into this and my apologies to have wasted your time. I am closing this issue.

[threat-punter]

I'm glad you got it working @mavzerburak0! I don't feel like you wasted my time at all 👍