Azure AD Identity Protection Overview Part 1
Today I want to talk about Azure AD Identity Protection, in the first part of this blog I’m going to talk give an overview of what Azure Identity Protection does and cover 2 of the 3 policies it provides. I’ll cover the 3rd in a follow up post.
Azure AD Identity Protection can calculate risk associated with suspicious actions of your users. This could be when they sign-in or carry out actions that seem abnormal when compared with their usual behaviour.
Identity protection looks at 2 risk types:
This is calculated offline using Microsoft's internal and external threat intelligence sources. So, this can be retrospective in a sense, say if intelligence sources flag an IP address this could lead to user(s) who signed in from this IP recently as being risky.
This is calculated both in real-time and offline depending on the risk detected. An example of real time would if a user attempted to sign-in from a Tor browser, an offline detection might be two sign-ins originating from geographically distant locations, where AI analyses the sign-in times and whether the distance between them made two sign-in sessions like to be different users using the same account.
More information on risk types and user risk vs sign-in risk can be found here: https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/concept-identity-protection-risks
Identity Protection policies
Aligned with the risk types, Identity Protection provids 3 policies to help protect your users. All 3 policies can be assigned to all users with optional exclusions or selected users and groups with optional exclusions. This provides an easy way to introduce the policies in a phased manner and the exclusion option should be used for break-glass accounts.
One thing to keep in mind is that right now you can only have one instance of each policy, so you cannot mix levels of sign-in risk and assignment. Maybe this will come in the future?
MFA registration policy
As much of the protection and remediation capabilities rely on MFA, the MFA registration policy will aid in making Identity Protection successful from both a security and end user UX perspective. As the name suggests the policy will require users register for Azure MFA at sign-in.
The policy is super simple; select assignment targets, optionally exclusions and apply the control to require Azure MFA registration. That is it, you don’t actually have the choice of other controls, so this is a bit of redundant option.
When the policy is setup, users in scope will be prompted to setup thier accounts for MFA when they sign-in. They are given a 14 day grace period when they can skip this, at the end of the grace period they won’t be able to sign-in without completing the self-service registration process.
If the user has already previously setup Azure MFA or an administrator has registered a hard token for them then they will not need to carry out these steps. So, if you already use hard tokens with Azure MFA then you could pre-stage your users and they would not be prompted.
MFA options will be driven by your Azure MFA setup but out of the box you will have the option of using the Microsoft Authenticator app or SMS text message. After clicking Next on the screen above the user will need to complete registration as shown below.
To summarise, the MFA registration policy will make sure your users register for MFA, it can be entirely self-service and you don’t need to do anything other than license your users for them to be able to utilise this policy.
Sign-in risk policy
This policy dictates the action that should be taken when user sign-in occurs and it is deemed at or above the risk level you’ve set in the policy, you’ve two options:
Allow access and require MFA
You also have the option of the risk level this should apply to, low and above, medium and above and high. Medium and especially low are going to be noisy, you probably should start at high and then increase the sensitivity level if you feel there is the need.
In the screenshot below we can see a user sign-in occurred from an anonymous IP address and the risk level is medium, you can also see this was a real-time detection. This is the view from Azure AD Identity Protection in the portal that the admin will get.
For the end user they will be see something similar to that shown below:
Now they need to complete MFA in order to sign-in.
Once they have completed MFA, they will be able to complete sign-in and access the resources they were attempting to access.
By completing MFA the user is also going to mitigate the sign-in risk. The thinking here is, that given the user knows their password and can complete an MFA sign-in, then its highly probable that this one of your genuine users.
So, a key thing I want to point out, sign-in risk policy is NOT enforcing MFA for every sign-in, only for those that meet or exceed the risk level you have stated in the policy. In my opinion this makes for a better user experience, users are not constantly having to carry out MFA, only when there is risk associated with the sign-in.
Of course, you do have the option to block sign-in instead of going the MFA route. You could do this if you do not use Azure MFA for example, perhaps you already have a 3rd party MFA solution and do not want to switch, but still want to take action on risky sign-in events.
You still achieve the added security offered by Azure AD Identity Protection but without the ability for users to remediate the sign-in. It is worth keeping in mind that this particular sign-in was blocked, but if the user can sign-in from a device/location that falls under the risk threshold then they’ll be able to successfully sign-in even if they’ve not remediated the blocked sign-in.
If you leverage Azure AD for sign-in and if you have Premium P2 licensing, then you should seriously consider enabling Azure Identity Protection sign-in policies to enhance the security of your users' sign-in events. You can phase the introduction by targeting only specific groups of users and start at a high-risk level. If you already have Azure MFA or plan to use it, then you can let users remediate sign-ins seen as risky and minimise the impact to users and your Service Desk by making the process largely self-service.
The second key thing I want you think about, as Azure AD supports OpenID Connect and OAuth and SAML SSO you can easily setup SSO using Azure AD with 3rd party SaaS applications that will be able to leverage the same sign-in protection as say Office 365. So, SaaS applications like ServiceNow, Salesforce and Workday immediately begin to benefit from the protection that Azure AD Identity Protection brings.
In the screenshot below you can see a sign-in requiring MFA when I logged into SurveyMonkey using my Azure AD account:
That just about covers it for Part 1, in Part 2 I will cover User risk policy.