type
status
date
summary
tags
category
URL
password
slug
icon
Monitor Risk on an Ongoing Basis or Prepare for Surprises
The Microsoft Entra ID Protection features included with Microsoft Entra ID P2 subscriptions are a very powerful way to combat identity-based attacks. ID Protection allows admins to use the risk status (as determined by Microsoft) generated in real-time for sign-ins and through behavioral analysis by Microsoft Entra to automatically block sign-ins or force password resets if connections exceed a configurable risk threshold.
Blocking sign-ins automatically is great for tenants with the right licenses but doesn’t help everybody. Putting aside any conversations about gating security features behind top-tier licensing SKUs, all is not lost for organizations without premium subscriptions. While premium licensing is required for some of the enhanced detail and automated remediation features, the risky users, sign-ins, and risk detection reports are available to tenants with Entra ID P1 or Entra ID Free (Entra ID Free tenants do not get risk detection reports) in a limited capacity as detailed in Microsoft documentation.
Risk events in Microsoft Entra can often be overlooked by busy administrators, particularly in smaller environments where there may not be a dedicated security operations team responsible for monitoring risk. As with many things in Microsoft 365, a little automation can go a long way to bridge some of these gaps. In this article, I explain how to create an Azure Automation runbook (code available on GitHub) to report risk detections in a tenant and email the report to administrators daily.
Getting Started
The first requirement is an Azure Automation account. Azure Automation is a great way to manage automated reporting such as monitoring Unified Audit log events and performing repetitive tasks such as provisioning Microsoft Teams based on templates.
To keep things simple, the script uses a managed identity to connect to the Microsoft Graph SDK. As the script uses a managed identity, the Automation account should be associated with the tenant Entra ID directory the script will run against.
Next, the service principal of the automation account needs the following Graph permissions to run the script:
- “IdentityRiskyUser.Read.All” – This permission is required to retrieve the Risky User data.
- “IdentityRiskEvent.Read.All” – This permission is required to retrieve the Risk Event data.
- “IdentityRiskyServicePrincipal.Read.All” – This permission is required to retrieve the Risky Service Principal data.
- “Mail.Send” – This permission is required to send out the report via email at the end of the script
Assigning the permissions required to the service principal is done using the Microsoft Graph PowerShell SDK using the steps described in the article about Using Power Automate and Azure Automation to Manage the Lifecycle of SharePoint Sites.
This code shows how to assign the permissions by:
- Defining the required permissions in an array.
- Getting the service principal of the Microsoft Graph app.
- Getting the identifier of the Automation account service principal.
- Getting the Role IDs for each of the required permissions.
- Looping through each role and assigning the role to the Automation account service principal
All you need to do is replace the name of the automation account (aa-EntraRiskReport’ in my example).
Next, the following Microsoft Graph PowerShell SDK modules must be installed as resources for the Azure automation account:
- Microsoft.Graph.Authentication.
- Microsoft.Graph.Identity.SignIns.
- Microsoft.Graph.Users.Actions.
The Microsoft Graph SDK modules receive regular updates so it’s important to ensure they are up to date. For more information on updating the modules in Azure Automation, check out this article on how to keep your Microsoft Graph PowerShell Modules for Azure Automation updated.
Adding the Code
The script for this task is available on GitHub. At a high level, the script performs the following tasks:
- Declares variables for the sender address, recipient address, and subject of the report email.
- Connects to the Microsoft Graph using the PowerShell SDK.
- Gathers the risk detections, risky users, and risky service principals from the tenant, only including the entries that have an “at risk” status.
- Parses the data into collections containing the information that should be contained in the report.
- Converts the data to HTML format for the report.
- Adds some basic HTML formatting to the output.
- Adds the HTML report to the body of a new mail along with the subject and recipient parameters.
- Sends the report using the Send-MgUserMail cmdlet specifying the sender address variable.
To run in your environment, the sender and recipient variables on lines 20 and 21 of the script should be updated with valid sender and recipient addresses from your tenant.
Review the Report
The report includes three tables, Risk Detections, Risky Users and Risky Service Principals. The Risk Detections table, shown in Figure 1, lists the risk events that have occurred in the tenant that are at the Risk State “at Risk.” This means an admin hasn’t updated the status of the triggering event, which usually implies that it hasn’t been reviewed yet.
Figure 1: The Risk Detections Report Table
The second and third tables contain the list of users (Figure 2) and service principals where the Risk State is “at Risk.” Generally, if a user or service principal has a risk status listed, it will have one or more risk detections contributing to that status. The Risk Detections table can be used to provide context to identities listed in the user and service principal tables.
Figure 2: The Risky Users Report Table
When an administrator actions a Risk within the Microsoft Entra admin center, the Risk State is updated, and the risk no longer appears in the report.
Schedule the Report
A key benefit of running scripts like this in Azure Automation is the scheduling functionality. To run script every morning, create a daily schedule in the automation account like the one shown in Figure 3.
Figure 3: Creating a schedule in an Azure Automation account
Next, from the runbook, link the schedule to the runbook (Figure 4) to schedule the script to run each morning.
Simple, but Effective
The Automation account will run the script based on the schedule and deliver the report each morning via email. It’s important to not just read the report but to make sure that you action the risk status in your environment and update the status of risks as they are mitigated. While this information is available from the Entra admin center, delivering it in a daily report is a good way to ensure the information is visible to the people who need it easily. There’s nothing particularly complicated in the script but it does what it needs to by connecting to the tenant, gathering data, formatting it, and then sending it out via email. I’m sure there are improvements that can be made, particularly on the formatting of the report, but I’ll leave that to someone with a better eye for design than me.
上一篇
11款轻量、简洁、可用于内网穿透的免费隧道工具与平台 » 老E的博客
下一篇
10 cybersecurity frameworks you need to know about - Help Net Security
- Author:NetSec
- URL:https://blog.51sec.org/article/4e694083-f5c2-4275-89c0-91a45396bb6b
- Copyright:All articles in this blog, except for special statements, adopt BY-NC-SA agreement. Please indicate the source!
