Azure AD Identity protection has changed a lot since I wrote the last blog post related to it. As we all know, the development pace is staggering in the cloud.

Links to older posts if you want to read these through which were written back in 2018 and 2016.

In this blog post, I’m going through new Identity Protection capabilities together with new API’s reporting capabilities. Later in the article Identity Protection is shortened as “IPC” which is its provider name.

Detection Capabilities

Risk Detections

There are two types of risk (descriptions from docs.microsoft.com):

  • User risk – A user risk represents the probability that a given identity or account is compromised (User risk is calculated offline).
  • Sign-in risk – represents the probability that a given authentication request isn’t authorized by the identity owner (Sign-in risk is calculated online or offline).
Risk detection typeDetection typeDescription
Atypical travelOfflineSign in from an atypical location based on the user’s recent sign-ins
Anonymous IP address Real-time Sign in from an anonymous IP address (for example: Tor browser, anonymizer VPNs)
Unfamiliar sign-in propertiesReal-timeSign in with properties we‘ve not seen recently for the given user
Malware linked IP addressOfflineSign in from a malware linked IP address
Leaked CredentialsOffline – not linked to sign-inThis risk detection indicates that the user’s valid credentials have been leaked
Azure AD threat intelligenceOffline – not linked to sign-inMicrosoft’s internal and external threat intelligence sources have identified a known attack pattern

Picture from Microsoft Ignite Identity Protection presentation

Licenses

In earlier days Azure AD Identity Protection reports were totally invisible if you didn’t have a license. Nowadays, the situation is different, which might be quite confusing if you are browsing around the Azure AD portal.

Even you would have Azure AD free, you have some of the IPC reports available and ready to use but with limited information. Here is a summary of the needed license and capabilities included.

Risk Mitigation and Automation

One of the best sides of the IPC is automation. With policy configuration, you can define the needed risk level for “User Risk Policy” and “Sign-in Risk Policy”.

Remember to follow the same best practice than with Conditional Access policies, exclude emergency account(s) from the policies. And hopefully, you have EG accounts created already.

Microsoft recommendation for risk levels is (low, medium & high available):

  • The user risk policy threshold to High 
  • The sign-in risk policy to Medium and above.

User Risk Policy

In the picture below is User Risk policy where the following settings are configured:

  • Risk level: Medium and above
  • Access Control: Allow access – require a password change

This means if medium or high risk is detected IPC enforces users to change the password before access is granted. In some environments, access is blocked which leads calls to the helpdesk on purpose. In such an environment there is an educational curve with this configuration.

Sign-in Risk Policy

Sign-in risk policy is configured with the following settings:

  • Risk level: Medium and above
  • Access Control: Allow access – Require MFA

How it works? If the sign-in risk is medium or above MFA challenge is sent to the user to verify his/her identity.

MFA Registration Policy

Naturally, MFA pre-requirements need to be in place before rolling out IPC. Unfortunately, I see environments on a monthly basis where even baseline security controls (including Modern autH) haven’t been configured.

When configuring the MFA registration policy take into account emergency accounts (which your organization has already created;) ) and service accounts.

Automation

With policies above, the Identity Protection handles alert mitigation with automation. If users are allowed to perform self-remediation by organization security policy they can leverage functionalities from SSPR and MFA to unblock own identity when risk is detected.

As said, I have seen organizations also to configure these policies to block access to the cloud environment which leads to call to the service desk (educational approach).

How It Looks From End-User Perspective?

If automation finds user account suspicious based on IPC policies user is either challenged by MFA or required to change the password for his/her account depending on which risk categories are satisfied.

In my environment user, John Doe needs to verify his identity with MFA and change password, based on IPC policies.

If an admin finds suspicious activity from the identity and marks account as “compromised” the following activities are found from the Azure AD audit log. This can also be seen from the “IPC” APIs which were just published.

When user logins to own laptop all services are requiring password and password change based on the “User Risk” policy in my demo case. Naturally, after the password is changed end-user can access all cloud workloads.

How To Test Scenarios?

Microsoft has a playbook for testing purposes. It can be found here. The playbook covers the most typical scenarios:

  • Anonymous IP address
  • Unfamiliar sign-in properties
  • Atypical travel

Logging & Monitoring

Azure AD Identity Protection blade contains the following reports available (no matter which licenses you are running with):

  • Risky users
  • Risky sign-ins
  • Risk detections
  • Vulnerabilities

Even though, Microsoft documentation says that reports should be available in tenant running free Azure AD version this is what I can see in the free Azure AD tenant. But, these reports are available underneath Azure Active Directory – Security – Reports (see 2nd picture).

There are also alternative possibilities to investigate Identity Protection data:

Log Analytics integration

  • With Azure AD & LA integration IPC data is available for further analysis in the workspace

Event Hub

  • Stream Azure AD events to Event Hub for SIEM integration

Blob storage

  • Stream Azure AD events to storage for long term archive

Microsoft Cloud App Security

  • Events are also populated to MCAS which is the best tool for investigating internal users activity in the cloud

Sentinel

  • The same alert is found from Sentinel where more detailed investigation (including possible lateral movement) can be investigated

New Beta API’s

With new API’s you pull out same information that is visible in the portal. API’s are under “beta” version currently and available ones are:

  • riskDetection
  • riskyUser
  • identityRiskEvents – this API is deprecated

API’s in action

Following permissions are needed to fetch data from API’s

  • IdentityRiskEvent.Read.All
  • IdentityRiskyUser.Read.All

In the first picture, the permission scope is visible. In the second picture, you can see “riskState” attribute highlighted after admin activities. In the last picture, there is information seen from API when the user has automatically remediated the risk (changed password).

Summary

Even Identity Protection is Azure AD P2 capability organizations can leverage some part of it with free and AAD P1 licenses. Definitely worth testing. During the last two years worked deeply with cybersecurity I have seen many environments where Identity Protection has saved identity being compromised. The root cause in those cases has been vulnerabilities in Conditional Access policies or other Azure AD baseline configurations and IPC has been able to identify suspicious activities in these environments.

Worth to mention is that B2B users can be protected with IPC.

The next blog post is about Azure Identity Protection alerts, where those can be found from the cloud ecosystem.