Using Conditional Access to enable Azure Active Directory Identity Protection risk polices
Picking up from my previous post on configuring and enabling MFA through registration campaign and conditional access policies, it is now time to address the requirement of configuring risk policies as part of over all implementation of Azure AD Identity protection feature.
So what is a risk?
Any suspicious action related to user accounts in the directory may be considered as a risk in Azure AD Identity protection. Identity Protection identifies risks under the following categories:
- Anonymous IP address
- Atypical travel
- Malware linked IP address
- Unfamiliar sign-in properties
- Leaked credentials
- Password spray
Identity protection also supports automated remediation actions which can be tiggered in form of requiring users to perform Azure AD Multi-Factor Authentication, reset their password, self-service password reset, or blocking until an administrator takes action.
There are some licensing requirements which need to be taken into consideration as not all features within Identity protection are available straight away.
Source: Microsoft
Ways to configure risk policies
There are 2 ways to configure risk policies. Either enable directly in Identity protection in Azure AD or use Conditional Access policies. It is recommended to enable using CA policy as one can make use of signals from conditions like risk, device platform, or location to expand the policy parameters.
Conditional Access policies for user risk and sign-in risk
With CA, you can configure both user risk and sign-in risk.
User risk represents the probability that a given identity or account is compromised. This risk detection type indicates that either the user's valid credentials have been leaked or the user's activity has been found to be unusual. It can also raise flags if found consistent with known attack patterns based on Microsoft's internal and external threat intelligence sources.
Sign-in risk on the other hand represents the probability that a given authentication request isn't authorized by the identity owner.
We will be creating a CA policy for each.
User risk Policy Medium or higher
The first one is User risk policy which will enforce remediation measure like requiring user to change password if the risk is evaluated as Medium or High. To configure, follow the steps below:
1. Sign in to the Azure portal or MEM Admin portal and browse to Conditional Access.
2. Select new policy and give a name.
3. Under Assignments, select Users and groups to add either All users or specific list of users\groups.
Note: If you have any emergency or break-glass accounts then it will be a good option to exclude them.
4. Under Cloud apps or actions > Include, select All cloud apps. Note: For the requirement against change of password, the CA policy requires All cloud apps to be selected.
5. Under Conditions > User risk set to Yes and select risk levels Medium and High.
6. Under Access controls > Grant, select Grant access and then Require password change. Notice the little message in the bottom which says that All cloud apps need to be selected for Require password change to work? Well in addition to that MFA is also needed and will automatically get selected when you select Require password change.
7. Deploy in Report-only mode to assess the impact. In case you have already simulated risk detections and ready to test the CA policy, then enable the policy.
Sign in risk Medium or High
The second policy is for Sign in risk which will enforce a remediation measure like requiring user to complete the MFA authentication process if the risk is evaluated as Medium or High.
1. Sign in to the Azure portal or MEM Admin portal and browse to Conditional Access.
2. Select new policy and give a name.
3. Under Assignments, select Users and groups to add either All users or specific list of users\groups.
Note: If you have any emergency or break-glass accounts then it will be a good option to exclude them.
4. Under Cloud apps or actions > Include, select All cloud apps. Note: You have the option to use individual apps if needed. However, it is recommended to select All cloud apps to ensure maximum reachability.
5. Under Conditions > Sign-in risk, set Configure to Yes and then Select the sign-in risk level as High and Medium.
7. Deploy in Report-only mode to assess the impact. If you have already simulated risk detections and are ready to test the CA policy, then enable the policy.
End user experience & validation
When threat actors try to authenticate using credentials of an Azure AD user protected by Identity risk policies through CA, the credentials will be identified as compromised and the user's risk level will automatically elevate to medium or high. At this stage the CA policy targeting the user against the user's risk level, will get enforced and the user will be required to accept MFA and reset the password.
Similarly, when the sign-in is dectected from an anonymous IP, unknown location, or other supported sign-in detection types, then the risk level of the sign-in will elevate. If the risk level is elevated to medium or high, then the CA policy for enforcing MFA will kick in.
The sign-in logs in Azure can be checked for the enforcing of the CA policies.
Clicking on the cards will take you to the drilled down report of risky users. Once remediated, the risk state will change from active to remediated automatically.
Administrators have the option to change the status of the user account to 'Compromised' which will increase the user risk level to 'High', inturn resulting in the CA policy to kick in requiring the user to go through MFA authentication and change the password again.
Bonus Tip: Make sure to enable the Weekly digest and set the 'User at risks detected alerts' to get real time alerts. By default both are enabled for Global Administrators, Security Administrators and Security Reader roles.
Conclusion
Organizations must decide the level of risk they are willing to accept in order to balance between end user experience and security posture. It is recommended to simulate the sign-in attacks in order to gather risk detection data first. Post which using the Identity security risk users and sign-in reports, an assessment should be carried out to identify areas that may need to be addressed immediately and make necessary adjustments in existing Azure configuration settings as needed. For example, you may need to modify trusted locations in order to address false positives arising against risky users and sign-ins. The Identity protection risk policies can be restrictive so it is important to carry out a data gathering exercise first before enabling the policies to mitigate the risks.
References:
Comments
Post a Comment