Sentinel to ServiceNow (SIR) sync

[joshgbignal]

Hi, 

I have rolled out the first portion of the Microsoft Sentinel Integration (from ServiceNow store). I already have SIR +Secops and have done most of the mapping and config in SNOW. 

The issue I am having is that when polling for say 1m, I am picking up sentinel incidents before any automation has been applied e.g. we have automation to downgrade a high to informational if an alert is in testing/ tuning. Is there a way I can get incidents to only come through after any automations have ran, without having a crazy long polling time..? I could design flows for this; but I am conscious that out of hours a High in sentinel (S2 in ServiceNow), triggers our call-out system. So I want to make sure, that any severity changes are reflected before it polls through, or that an update is sent immediately from sentinel when it’s closed.  Hopefully I’ve explained this well enough and thanks in advance! 

[cp11]

Hey Josh,

Not sure I fully followed the ask, but does the filtering capabilities provided as part of the profile not meet the need?

Thanks

[AJ_UK]

Hi @joshgbignal ,

I've not seen this behavior - if anything the opposite, where the incident is not actually available to be read by API in Sentinel at the time it shows as being was created.

You would almost need to add an offset to the ingestion API call 'last modified time' to achieve what you are describing - which would in effect delay ingestion of ALL incidents by a number of minutes. There is no default option to implement this - it's possible, but you would have to custom script it. I can't say I'd recommend it, as it would delay ingestion of all incidents. 
A couple of options you could look at (and a lot depends on whether you can cleanly identify the subset of testing/tuning alerts):

1.  Test whether you can use the the filtering as mentioned by @cp11 e.g. a relative time filter on lastModifiedTime AND alert/title contains xxx value (or however you can identify the testing/tuning subset) so that SIR only triggers on those alerts after a length of time to allow them to 'settle'.

2.  Have your automations finish by adding a tag in Sentinel, which then allows 'pickup' by SIR (using the filtering as mentioned by @cp11 ) - where you only create SIRs from incidents with this tag. This way they could not be 'picked up' before an automation had run. (You would need at least 2 automations - one that triggers on your testing incidents, and one that triggers on everything else). A tag being added would count as an incident update, which would trigger another ingestion by the integration.  The only danger of this route is the scope for a subset of incidents to miss an automation and thus a tag and thus triggering an SIR.

3.  Alternatively set your Severity field mapping to use the Update - so that if it is changed in Sentinel, that change is reflected through into SIR, then potentially add a delay to your automation in ServiceNow so that it only triggers on S2s after the incident has existed for say more than 5 mins at S2 level. This wouldn't delay all incident ingestions, but would potentially delay triggering call out of a 'real' S2 by a few mins.

4. Potentially explore the Overlaps functionality an see if that can do anything for you, however from memory it looks backwards in time, and is there to make sure that no incidents are missed. There are similarities in the concepts that you are talking about.
Hope that helps,

AJ