Incorrect creation time for incident creation in Microsoft Sentinel

One of the main benefits of Microsoft Sentinel as a SIEM is the tight integration with other Microsoft products such as Azure Active Directory and Microsoft 365 Defender.

The integration of Microsoft 365 Defender and Microsoft Sentinel offers both bi-directional synchronization of incidents and synchronization of raw advanced hunting.

While implementing a synchronization engine between Microsoft Sentinel and a third party SOAR product, I ran into a timing issue between the two platforms. After checking with the product team, this behavior is by design but can be extremely confusing. With this blog, I want to raise awareness on this ‘problem’ in order for you to know what the expect.

Synchronization of incidents between Microsoft 365 Defender and Microsoft Sentinel has an SLA of 10 minutes as stated in the Microsoft docs. From my experience, this seems correct and the synchronization happens between 2 and 7 minutes.

This means that an incident generated in Microsoft 365 Defender can take up to 10 minutes before it appears in Microsoft Sentinel. This is a long time and it something you need to keep in mind while setting up your SOC. A delay of 10 minutes between when a ransomware incident is created and your SOC sees it in your SIEM is a long time.

Identifying the problem

While this delay can be annoying, it is clearly documented and can be easily work around. The issue is with the ‘creation time’ in Microsoft Sentinel for a Microsoft 365 Defender incident.

The Creation Time property tells you when the incident was created. For incidents coming from Microsoft Sentinel Analytic Rules, this means when it was created in Sentinel but this is not the case for Microsoft 365 Defender incidents.

Let’s take the following scenario:

• An incident is created in Microsoft 365 Defender at 1:50 PM
• Through the Microsoft 365 Defender connector, it arrives in Microsoft Sentinel at 1:55

In this scenario the creation time will be set at ‘1:50’ and not at 1:55, (the time is was actually created). The creation time is the time it was created in Microsoft 365 Defender, not when is showed up in Microsoft Sentinel.

While this is probably a non-issue for SOC analysts, this is an important note when doing automation or writing custom integrations. You need to be aware of this delta and work around it.

Impact on automation rules

The reason I identified this was because of the timing impact it has on automation rules. If you have an automation rule setup to run when an incident is created, you would think they are run immediately after it was created.

When verifying the logs, I noticed the automation rule only ran 7 minutes after the original creation time. This made me think the automation rules were not performant and causing issues.

While investigating this, it came down to the origin of the creation time. An automation rule will only run when the incident is fully created in Microsoft Sentinel. As the creation time is copied from the Microsoft 365 Defender incident, it seems the automation rule has a delay of 7 minutes. But that isn’t the case, in reality it runs immediately after the incident is created in Microsoft Sentinel.

The need for additional insights

While I understand the use case for having the creation time as the creation time for the incident in Microsoft 365 Defender. An additional field called ‘Sentinel creation time’ would go a long way. This would allow us to validate what is happening in the background and how performant incidents are sync’ing and automation rules are being run.