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
(Placeholder) 14 – Designate more than one global admin
(Placeholder) 15 – Secure Score and Graph API
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.
Licenses
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.
Automation
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.
Wrap up
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.
Stay safe!
