In this series, I’ll be covering the Microsoft Secure Score improvement actions. Although Microsoft does a great job on telling you what to do, some actions have a much bigger impact and need to be balanced against business needs. Some actions might not even have value for your organization. In the end, Microsoft Secure Score is meant to strengthen your security, not a contest to reach the highest score possible. In this series, I’ll pick out random actions and try to make it as simple as possible, backed with notes from the field.
Articles in this series can be read separately since they are written at random order. The articles vary in case of impact and complexity and cover multiple categories. Here is a list of all the articles in this series:
01 – What is Microsoft Secure Score?
02 – Require MFA for administrative roles
03 – Enable Password Hash Sync if hybrid
04 – Ensure all users can complete multi-factor authentication for secure access
05 – Enable self-service password reset
06 – Enable policy to block legacy authentication
07 – Turn on sign-in risk policy
08 – Use Cloud App Security to detect anomalous behavior
09 – Do not allow users to grant consent to unmanaged applications
10 – Discover trends in shadow IT application usage
12 – Turn on customer lockbox feature
13 – Set automated notifications for new and trending cloud applications in your organization
14 – Designate more than one global admin
Turn on user risk policy
With the user risk policy turned on, Azure AD detects the probability that a user account has been compromised. As an administrator, you can configure a user risk conditional access policy to automatically respond to a specific user risk level. For example, you can block access to your resources or require a password change to get a user account back into a clean state.
Today, we take a look at Azure AD Identity Protection. More specifically, the ability to take automatic action on your risky users. Risky users can be blocked or forced to reset their passwords.
What are risky users?
User risk is a calculation of the probability that an identity has been compromised. This is based on the “normal” behavior of the users. Identity Protection can detect leaked credentials and uses Azure AD threat intelligence to detect whether a user account is likely breached. Administrators can set up a policy so that users can self-remediate this risk. Risks are detected both in realtime and offline.
Azure Identity Protection can detect (among other things):
- Anonymous IP address (mostly TOR browsers and anonymous VPN)
- Unfamiliar sign-in properties (new device, location or behavior that is new to the given user)
- Malware linked IP address (malware-infected devices can be detected, as they send data to malicious servers)
- Atypical travel (sign-ins from locations that are different from other recent sign-ins)
- Malicious IP address (IP addresses that have bad reputations, mostly caused by a large amount of failed sign-ins)
Some of the detections are discovered by Microsoft Cloud App Security:
- Suspicious inbox manipulation rules (dubious inbox rules that are created to intentionally hide messages)
- Impossible travel (sign-ins are compared geographically, to detect breached accounts)
You can check for risky sign-ins and risky users in the Azure portal.
Using this feature requires an Azure AD Premium P2 license. Self Service Password Reset is part of the Azure AD Premium P1 license.
TIP: you can easily activate a trial license. This gives you 100 Azure AD Premium P2 licenses for 30 days. During this trial, you can check out your risky users and see if any of those users have leaked credentials.
When you have Identity Protection running, you can go through the list of risky sign-ins yourself to invest and block users manually. With the use of the risk policy, you can automate this very easily. Configuring this policy takes only minutes and is very powerful.
Simply pick the user risk level and the controls to be enforced.
It is recommended to enable this for all your (licensed) users, but you should exclude your break glass accounts. Your policy would look something like this:
User experience – Block access
When you have configured your policy to block access, the user will get prompted with the following screen during sign-in:
User experience – Require password change
NOTE: Users that triggers the policy must have registered for password reset before. Otherwise, the access get's blocked. If you have not implemented SSPR, I suggest you read this and this blog first.
When users have registered before and triggered the policy, they get prompted for password change. The actual flow will depend on your SSPR configuration.
Test your policy
To test your policy, you can use a TOR browser. Sign-in a few times and refresh your identity each time. Because you are using a TOR browser, each sign-in will be risky. You can easily pick a new identity using this button:
The result is a few sessions from different locations that will trigger risky sign-in policies.
Setting up a user risk policy will take the heat of your service desk and IT admins. Risky users can self-remediate without the help of someone else. With the use of Identity Protection, your users will have an extra layer of security. It is recommended to enable this feature for you privileged users like administrators, C(E)(O)(T)O’s, and accounts that are an obvious target for spear phishing. Even better; enable for all your users when your budget allows it.
You can only configure one user risk policy per tenant. The sign-in risk policy, on the other hand, can be integrated with Conditional Access to have more granular control.
For more information, I suggest you take a look at this page. And don’t forget to check out the other articles in the Secure Score Series.
Pingback: Close the gap. Azure AD Identity Protection & Conditional Access. - JanBakker.tech
Pingback: Control access from unmanaged devices with Cloud App Security - JanBakker.tech
Pingback: 10 tips to secure your identities in Microsoft 365 - JanBakker.tech
We are in an annoying position where we’ve set up Conditional Access policies to allow for granular control of User Risk (e.g. one policy for High risk and another for Medium risk) but Secure Score still shows this as unconfigured. I assume this is because it is only looking at the dedicated Identity Protection policy rather than the overall tenant config 🙁
Is there a way you know of to make the Secure Score understand that it has been configured?
Hi there! Good one. I assume that Microsoft is indeed looking at the Identity Protection policies and not to the CA rules. For now, you could change the status to “Alternate mitigation”. You can add the details of your steps in the action plan. I’m sure Microsoft is analyzing this data as well. It will also gets you your well-deserved points.
After thinking about it for a few minutes we’ve come up with an alterative approach that I think will satisfy everything.
We are setting the Identity Protection policy to block high risk, then we have an additional CA policy to manage Medium risk.
I’m still hoping Microsoft update their scoring system as their own docs state using the granular CA policies is best practice!