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.
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 type||Detection type||Description|
|Atypical travel||Offline||Sign 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 properties||Real-time||Sign in with properties we‘ve not seen recently for the given user|
|Malware linked IP address||Offline||Sign in from a malware linked IP address|
|Leaked Credentials||Offline – not linked to sign-in||This risk detection indicates that the user’s valid credentials have been leaked|
|Azure AD threat intelligence||Offline – not linked to sign-in||Microsoft’s internal and external threat intelligence sources have identified a known attack pattern|
Picture from Microsoft Ignite Identity Protection presentation
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.
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
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
- Stream Azure AD events to Event Hub for SIEM integration
- 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
- 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:
- identityRiskEvents – this API is deprecated
API’s in action
Following permissions are needed to fetch data from API’s
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).
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.