Duplicate alerts creating a "Correlate Unfamiliar sign-in properties and atypical travel alerts" necessary?

Brandon Early 1 Reputation point

We're performing our SOC review in Sentinel and found a new incident called "Correlate Unfamiliar sign-in properties and atypical travel alerts". We found that this incident is being generated by an unfamiliar sign-in property and an atypical travel alert, both of which come from Azure Identity Protection.

Trouble is, both of the incidents coming from Azure Identity protection are picking up on an employee travelling for work and signing in from a location other than their home office, its the unfamiliar IP that's creating both incidents. We have a rule to close out these incidents based on successful MFA, but we don't have anything for the new Correlate incident.

We are thinking of just creating an automation rule to close these new "Correlate" incidents when both underlying incidents close, but can the community think of any reason for why we might want to keep these open?

And also, any suggestions on the best way to automate closing this incident based on both underlying incidents closing?

Microsoft Sentinel
Microsoft Sentinel
A scalable, cloud-native solution for security information event management and security orchestration automated response. Previously known as Azure Sentinel.
968 questions
Microsoft Entra ID
Microsoft Entra ID
A Microsoft Entra identity service that provides identity management and access control capabilities. Replaces Azure Active Directory.
19,293 questions
0 comments No comments
{count} votes

1 answer

Sort by: Most helpful
  1. Marilee Turscak-MSFT 33,621 Reputation points Microsoft Employee

    Hi @Brandon Early ,

    The solution you described sounds like a great option since the accounts would still be protected by MFA and need to meet the MFA requirements to close the Correlate incident. I don't see any reason to keep the false positive incidents open and based on your description can't think of any concern with that strategy.

    Another option if you want to grant access to specific users traveling to specific countries is to create a universal "exclude" group in your Conditional Access policies and add the users to that group when they are traveling. Then if you have MFA enforced for untrusted locations and have those users added as an exemption to your "block international countries" policies, any attempts to access those accounts outside of your trusted locations will still be prompted for MFA.

    But the method you suggested with MFA enforced is definitely a more secure option and a better long-term strategy.

    As for suggestions to automate closing the incident based on underlying incidents closing, the feature is still in preview right now but you should be able to define the action of closing out the related incident based on the condition of the other incidents being closed. Based on what currently exists in the portal you could create the automation conditions based on the rule itself, the IP address, incident tags, or any of the other defining properties.



    You can combine playbooks with automation rules to customize further.

    Let me know if this helps and if you run into any issues with this. I haven't tested the preview feature yet so I will try to create a proof-of-concept for this in my lab as well.


    If the information helped you, please Accept the answer. This will help us and other community members as well.

    0 comments No comments