Automate your SOC – Oh, that user again?

, Azure Active Directory, Azure Sentinel, Microsoft Sentinel, SIEM, SOAR 3 Minutes

Adding user risk to your STAT playbook

Now that you’ve got your first playbook set up, let’s talk about what each module does. We’re going to start with the Azure AD Risks module. This module retrieves several pieces of information to help enrich your incident.

  1. The risk level for the users in the incident as calculated by Azure AD Identity Protection
  2. The number of MFA fraud reports for the specified user account entities
  3. The number of MFA failures (the user denied the MFA request or the MFA request timed out) for the specified user account entities

The module gives you the option to add comments to the incident. This is a great for adding context to an incident. The more information you have the easier it is to decide what steps to take next.

But before we talk about the module, let’s discuss what it means to have Risky Users in Azure AD. Risk detections in Azure AD Identity Protection (which is part of the Azure AD P2 or E5 license) include any identified suspicious actions related to user accounts in the directory. The risk score is calculated by different criteria including things like impossible travel, malicious IP addresses, or unfamiliar sign in properties. For the full list, check out this link.

Identity Protection categorizes risk into tiers: low, medium, and high. Each level of risk brings higher confidence that the user or sign-in is compromised. For example, something like one instance of unfamiliar sign-in properties for a user might not be as threatening as leaked credentials for another user. This will be important when we get to the risk scoring module in a few posts.

Ok. Now back to our previously scheduled module. In the AAD Risks module, you also have the option to decide how far back into the Sentinel SecurityAlert table you want to look for information. You can look back from 1-90 days. I usually set this to seven days, but you can play with this to see what is best in your environment.

Another option you can add is the number of MFA Failures. When you set this to “True”, STAT will query the SigninLogs table for MFA failures for this particular user account entity.

The same option exists for users for MFA Fraud reports. (If you haven’t enabled this in your Azure tenant, you can do so here.) When this is set to “True”, STAT will query the AuditLogs table for the number of MFA Fraud reports submitted by the specific user account.

After the AAD Risk module runs, you will get several pieces of information.

  • AnalyzedEntities will return the number of user account entities that were analyzed from the incident. It will show as 0 if no account entities were found in the incident.
  • HighestRiskLevel will show the highest risk level found in Azure AD for all entities. If no user account entities are found in the incident it will show as “unknown”
  • FailedMFATotalCount will show the total number of failed MFA request in the SigninLogs table for all user account entities. It will show as 0 if no account entities were found in the incident.
  • MFAFraudTotalCount returns the total MFA fraud reports in the AuditLogs table for all the user account entities listed in the incident. It will show as 0 if no account entities were found in the incident.
  • ModuleName returns the internal name of the playbook.
  • DetailedResults  shows an array containing the details for each user account entity.

All right. Now, we’re making some progress. Next time, we’ll talk about the Related Alerts module – a powerful tool for enriching incidents.

Check out our previous posts in this series.

Let’s automate your SOC – Introduction to automating your Microsoft Sentinel

Automate your SOC – Let’s talk about STAT, baby – Introduction and installation of Microsoft STAT Triage

Automate your SOC – Noise is the enemy of speed – How to optimize your incidents

Automate your SOC – Risky Business – Giving your incidents a risk score

Authors

Published