search

mbegan / Okta-Identity-Cloud-for-Splunk

Public REPO for splunkbase app
https://splunkbase.splunk.com/app/3682/
Other
19 stars 13 forks source link

system@okta.com being tagged as authentication #22

Open kylegbakker opened 3 years ago

kylegbakker commented 3 years ago

Good afternoon,

Our team uses your TA for ingesting Okta logs into Splunk and have noted an issue in that for certain Okta events (Connect AD agent to Okta, Authenticate user with AD agent etc), the actor.alternateId is "system@okta.com" and these events are tagged as authentication.

I am working with a number of large clients that have also noted this.

Upon a fair amount of investigating, these events are not exactly "authentication" events and are more so events generated on the backend based on conditions like authenticating users via the AD connector, changing group membership in the Okta console etc.

The Microsoft Azure Splunk app had similar issues with src_ip from authentication events originating from Microsoft ASN when in fact the events were various internal azure operations on user accounts like updating group memberships etc. Using the newest Microsoft Graph API fixes this issue as these events originating from the Microsoft ASN are now split into a separate audit sourcetype.

I am proposing that these events where the actor.alternateId=system@okta.com are split into their own sourcetype (OktaIM2:audit, for example) and stripped of their authentication tags as the events aren't truly authentication events.

I have made the proposed changes to my own fork of this repo and in testing it solves the problem. Wondering what your thoughts are on this proposed feature or what reasoning you might have to keep it the way it is?

Kind regards, Kyle.

simonsigre commented 3 years ago

@kylegbakker yup.. we see this also

mbegan commented 3 years ago

So... my ignorance is on full display.

I copied a bunch of the things that Splunk had done when they built the original add-on for Okta sometimes even without really understanding what or why.

I agree with the misclassification what i'm interested in is what is the best / right way to do this?

the [eventType] (https://developer.okta.com/docs/reference/api/system-log/#attributes) [catalog] (https://developer.okta.com/docs/reference/api/event-types/)from Okta is ever expanding

There is some hierarchical to the eventType that might be useful here.

Is sourcetype really the right place to tweak this? did you have to add logic to the collector to override that?

Would you be open to a meeting to dig deeper?

simonsigre commented 3 years ago

@mbegan no problems at all... so just to confirm is this project the one that feeds Okta Identity Cloud Add-on for Splunk ( https://splunkbase.splunk.com/app/3682/ ) ?

kylegbakker commented 3 years ago

More than happy to meet and explore options. I'll admit my solution is hacky and simply involved a check right before setting eventsourcetype in the collector and then hard coding system@okta.com events to the audit sourcetype.

simonsigre commented 3 years ago

@mbegan re: Would you be open to a meeting to dig deeper? .. yeah for sure. Can you confirm that this is this project that feeds Okta Identity Cloud Add-on for Splunk ( https://splunkbase.splunk.com/app/3682/ ) ?

mbegan commented 3 years ago

Yes this project is the one that feeds the Okta Identity Cloud Add-on for Splunk

simonsigre commented 3 years ago

@mbegan we are going to submit a pull request for this in a moment and am also tracking (just because its easy for us) our changes here also; https://gitlab.com/enosysau_socgroup-public/TA-Okta_Identity_Cloud_for_Splunk/-/issues Reach out direct if you'd like to offload any of this to us to assist with :)