Using Risk-based Multi-Factor Authentication – Reporting

In the last post: Using Risk-based Multi-Factor Authentication, I talked about setting up the risk-based policies, in this post we will look at the reporting and alerting mechanisms that are available.

Within the Azure AD Identity Protection settings within the Azure Portal, there are a couple of locations available. First Investigate, second Settings.

The Investigate option is for identified risks, and vulnerabilities based on users and groups. Clicking Users flagged for risk shows any user accounts that have been identified based on various checks and the automatic checking.

Clicking the individual user displays the specific risks that have been identified.

Clicking into the risk, shows more details about the risk.

You then can either Resolve, Mark as false positive, Ignore the risk or Reactivate a previously closed risk.

Resolve – If after investigating a risk event, you took an appropriate remediation action outside Identity Protection, and you believe that the risk event should be considered closed, mark the event as Resolved. Resolved events will set the risk event’s status to Closed and the risk event will no longer contribute to user risk.

Mark as false-positive – In some cases, you may investigate a risk event and discover that it was incorrectly flagged as a risky. You can help reduce the number of such occurrences by marking the risk event as False-positive. This will help the machine learning algorithms to improve the classification of similar events in the future. The status of false-positive events is set to Closed and they will no longer contribute to user risk.

Ignore – If you have not taken any remediation action, but want the risk event to be removed from the active list, you can mark a risk event Ignore and the event status will be Closed. Ignored events do not contribute to user risk. This option should only be used under unusual circumstances.

Reactivate – Risk events that were manually closed (by choosing Resolve, False positive, or Ignore) can be reactivated, setting the event status back to Active. Reactivated risk events contribute to the user risk level calculation. Risk events closed through remediation (such as a secure password reset) cannot be reactivated.

Clicking Resolve, will then run a process that will force close the event, the re-process the users risk status. It does not however, somehow fix the issue, that is still up to you.

From the same screen of Users flagged for risk, you can click the Apply a user risk policy for automatic mitigation.

Clicking the link loads the User risk remediation policy. From there you can set the policy needed. Which will then automatically remediate the next time the risks are identified.

The next option is Risk events, that will display all events in a list grouped together by type, which when clicked will then display a breakdown of that specific risk type. Risk events are found by using adaptive machine learning algorithms and heuristics to detect suspicious actions that are related to your user identities. The system creates a record for each detected suspicious action.

Clicking any of the items listed will reveal further details, similar-to clicking on the specific user at risk report.

Next, we have the Vulnerabilities option. This simply analyses your configuration and detects vulnerabilities that can have an impact on your user’s identities.

Drilling deeper into the polices, you can then use the Estimated impact of the policies you define for these types of risks.

Though the reporting is great, being notified by email is often a much better approach. This can be achieved by clicking Alerts or Weekly Digest links within the Settings section. Each option allows you to set the alert risk, either Low, Medium or High, followed by the user(s) you want to send the emails too.

The alerts themselves are delivered by email with a link to a detailed report.

Outside of the reporting and alerts within the Azure AD Identity Protection, these can also be found directly within Azure Active Directory, within the Security section.

Now we have Azure AD Identity Protection configured, polices created, notifications set and then the great reports, the next step is to combine that with Azure Active Directory Conditional Access Policies for even more protection. With conditional access control, Azure Active Directory checks the specific conditions you choose when authenticating a user, before allowing access to an application. Once those conditions are met, the user is authenticated and allowed access to the application.