Microsoft Secure Score Series – 07 – Turn on sign-in risk policy

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

11 – Turn on user risk policy

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

15 – Do not expire passwords

---

Turn on sign-in risk policy

Turning on the sign-in risk policy ensures that suspicious sign-ins are challenged for multi-factor authentication.

---

Azure AD Identity Protection is powerful in many ways. As discussed in my previous post about Multi-factor Authentication, you can use IdP to onboard your user for MFA. Once you’ve had all your users registered, it’s time to tighten your security by prompting for MFA when a sign-in is risky.

This improvement action wants you to turn on the sign-in risk policy in Azure Identity Protection. By enabling this policy, users will be prompted for MFA every time a suspicious login takes place. To give you a couple of examples, a suspicious sign-in is when:

• a user logs in from an anonymous IP address;
• a user logs in from a malware linked IP address;
• unfamiliar sign-in properties are detected;
• impossible travel happens;
• suspicious inbox manipulation rules are created.

The sign-in risk is calculated at the moment the user logs in and can increase the overall user risk. You can also enable a policy to remediate the overall user risk, but for now, we focus on the sign-in risk policy.

First, let’s talk money

As many great security features, this one requires an Azure AD Premium P2 license for every user that benefits from this feature. You can configure IdP from the Azure Portal.

Configure the policy

To enable the policy, go to Azure Identity Protection and look for the user sign-in policy.

There are 3 settings that needs to be configured:

1. Users. Which users do you want to protect? You can also make exclusions when needed.
2. Sign-in risk. At what sign-in risk level you want your policy to kick in? Low and above, Medium and above or High.
3. Access. What is the action to be taken? You can block access or prompt for MFA.

Last but no least, make sure the policy is enabled.

Conditonal Access

User sign-in risk is also a condition in Conditional Access. This way you can make more polices for specific user groups or scenarios. You can also combine conditions and make use of the named locations. To give you an idea of what you can do:

• Block access for privileged accounts when sign-in risk is high
• Block access from certain locations when sign-in risk is high
• Prompt for MFA when sign-in risk is medium or above, and the device is unmanaged.

Another reason to use Conditional Access is the use of the Report-only feature. This way you can measure the impact first.

User & admin experience

To simulate a suspicious sign-in, I use a TOR browser to access Office 365. This simulates the use of an anonymous IP address, so the sign-in risk is medium. The user is prompted for MFA.

In the Azure portal, you can verify the risky sign-in.

Wrap things up