Workarounds for Azure Sentinel SIR Closure

[designitsecure]

Hello,

Has anyone implemented a workaround to have Sentinel close SIR incidents since the integration is not bi-directional in this regard?

Thanks!

[JesseBarath]

I'm wondering the same thing myself. Upon some digging, it seems like the historical integration does close the security incidents, but i need to find a way to have that run more often (seems like you can only trigger it manually) and I'm not sure if that's the best idea performance wise anyways. Please update this post if you find a solution, and likewise if i find a workaround i will let you know too!

Jesse

[AJ_UK]

Yes - I have implemented this, by using a BR to keep refreshing/updating the Historic (One Time Retrieval) functionality so that both open and closed incidents are ingested. That way if an incident that was open in Sentinel is now ingested as closed in Sentinel, it will get closed in SIR automatically.
Note that the default behaviour of the On-Time checkbox is to untick on completion of the retrieval.

It does come with some limitations - an analyst may find that the ticket they are working on gets closed automatically without notice e.g. if Defender auto-investigates it.
There is also a behaviour that we have seen of Sentinel moving/consolidating/aggregating Alerts from a series of individual incidents (e.g. x on One Endpoint) onto one consolidated incident (e.g. of x on Multiple Endpoints) and then auto-closes the previous incidents. Unless closure is enabled in SIR, and Incident Short Description is set to update, then this would potentially be missed in SIR - There is an 'automation activity' that notifies of Alerts being moved, but you wouldn't otherwise be aware of it.

[Pooja P]

Hi @AJ_UK , 

Is it possible to breakdown the Business Rule.

Thank u

[AJ_UK]

Hi @Pooja P ,

I would always recommend updating to the latest version - it looks like v 11.0.24 was released 01 May 2025 and can now do this as per reply from @charankollapudi. It also contains State field mapping which may be equally useful as well as some other fixes. This will remove needing customisation, and will means your solution is SN supported. 

The 'old' way of doing it would be to run a BR on sn_sec_incident_profile before Update, with conditions of active=true and one_time_retrieval CHANGES TO false,

Then script to set one_time_retrieval back to true, and update the historical_pull_start_date:

current.setValue('one_time_retrieval',true);
current.setValue('historical_pull_start_date',current.last_pulled_date);

Regards, AJ