Splunk ES Integration- field mapping to a choice value on sn_si_incident

Adam43 · ‎09-01-2023

Hey all-

we have a working Splunk ES integration configured previously by ServiceNow implementers- but the 'source' field is currently populating to the SNow form default of 'phone', and the secops folks want it adjusted to SIEM. instead of changing the default on the form, I'd like to do this in the Event Profile mapping. I've added the source field on the right side and just typed SIEM in string form for the input expression. It populates to the resulting SIR, put it appears to actually be creating a new choice value rather than using the referenced choice option. It also shows up as "SIEM | SIEM" instead of just "SIEM".

Am I in the right place to try to do this? or do I just need to do an after business rule? kinda prefer to keep all the config in one place for later maintenance. There is no actual 'source' value coming from Splunk itself- they just want all the values to default to SNow's choice value of SIEM.

andy_ojha · ‎09-01-2023

Hey there,

You are on the right track - the Source (contact_type) on the SIR, is a Choice field and in this case you can hardcode the value you want to set on the profile using the actual "choice value" here -- which should be "siem".

Can you verify on your 'sys_choice' for the SIR table, and field 'contact_type' - what the corresponding label is for the value 'siem' ... that label is what will appear on the target SIRs being created when you use that choice value.

Also for the setting the Alert Sensor, that is a bit tricky as it is a reference field - you will need to put the SYS_ID of the value you want to use - should you want to map that as well.

Reference:

Adam43 · ‎09-04-2023

thanks,

guess I was using the Label instead of the value as my input expression- all caps instead of lowercase- probably cause of the odd result? i'll give it a try at switching and see what results. Not sure if they're using the Alert Sensor, but I appreciate the KT.

Adam43 · ‎10-10-2023

Andy- that use case worked out great. since I only had the static value to populate.

Now they've come back and want to populate the 'assigned to' value, with the string value they send us from Splunk. Is it possible to somehow configure a lookup for the reference sysid based on the string value of userid that they send via the API? asking about inside the Splunk Event Mapping.

My other thought- is maybe on the provided Splunk Event Imports table that came with the plugin- I could do an insert business rule that looks up the value- but that would only work if the record is hitting that import table BEFORE the event mapping takes place- and I'm not sure on that aspect since it contains both all the columns/fields and the raw data chunk.

andy_ojha · ‎10-10-2023

Hey there - glad you got a win with that mapping.

------------------------------------------------------------------------------------------

I suppose, technically speaking, it could be possible to set the `SIR Assigned to` value in the Splunk Profile Mapping, based on a string value Splunk sends over (ideally a User ID, Email - or even better ServiceNow User SYS_ID)...

My question would be why though?

Is the process, that the SIR Analyst ack's the Notable on the Splunk ES Incident Review page, and then they will go to SIR and work the case from there?
Why not have the Analyst pick up the SIRs as they flow into ServiceNow (and let that be the true queue)?
Is this a temporary process as we transition from primarily working out of Splunk ES and into SerivceNow SecOps - any way to just move the triage and ack process directly into ServiceNow?

Could see some challenges around timing - what happens if the Splunk Notables, are picked up (scraped by ServiceNow) prior to an Analyst ack'ing it on the ES Incident Review page?

------------------------------------------------------------------------------------------

Would certainly re-evaluate that use-case - but if you are absolutely in a corner and want to investigate how to do proceed with it:

Keep in mind the Assigned to field on the SIR, is dependent and tied to the SIR's Assignment Group (in other words, you have to pick a User that belongs to the SIR Assignment Group) - you can't set the Assigned to value user to a person that is not a member of the current Assignment Group - so we have to iron out the Assignment Rules
There is a setting that needs to be disabled, as it will cause the Assigned to, on the SIR to be set automatically (SIR > Administration > Configuration > Assignment) - technically you'd want it to be "Manual"
Will need to have a good object from Splunk that has a unique string to identify a User in ServiceNow -> ideally something like email, user id, SYS_ID for the user in ServiceNow, etc.
You will create a new config record under Splunk Field Translations, for the 'Assigned to' value - based on that string that is sent from Splunk... You will query the 'sys_user' table in ServiceNow to return the SYS_ID of the user you want (and attempt set the value of the SIR Assigned to)

This is really one of those "just because you can, should you..." type scenarios.

Would strongly suggest against this and try to have the SIR Analysts start triaging and ack'ing the Security Incidents in ServiceNow...

Reference: