Azure AD Identity Protection
With all the news about cyber-attacks and data leakage and stolen credentials, it's important that a multilayered security approach is in place no matter how small or large the organization. Even as individuals, implementing a multilayered security approach for our personal accounts is beneficial (e.g. two-factor authentication).
I've posted in the past about Microsoft Advanced Threat Analytics (ATA) and Cloud App Security and how both solutions provide insight, alerts, and governance across on premises and cloud applications. Identities are the new control plane and securing them beyond just a password is a priority among many organizations I work with. If an identity is stolen, the person or even company is at risk for losing precious personal info and intellectual property which can have devastating financial implications that are difficult to recover from.
What keeps me up at night is that my customers may be at risk for leaked identities and other security vulnerabilities, so I do my best every day to educate them about threats and solutions Microsoft provides to assist with detection and remediation of these types of vulnerabilities and attacks.
Now I understand that there is no single fix or silver bullet to prevent attacks from happening. Security is typically implemented in a layered approach which is why Microsoft has invested significantly in multiple security oriented organizations over the past few years as well as ramped up their own solutions. See details here: https://www.microsoft.com/en-us/cloud-platform/enterprise-mobility-products
In my opinion, every organization should assume compromise, whether it’s a legitimate employee accessing information they shouldn’t by accident or a hacker that’s been sitting quietly monitoring network traffic for clear text passwords or by using a user name password acquired by social engineering. No matter what the scenario, it’s important to be notified of such occurrences. In my previous posts you’ll find Microsoft ATA and Cloud App Security look for user and entity behavior analytics (UEBA) as well allow for direct API access into well know services such as Office 365, Salesforce, Box, and so on. But what happens when credentials are leaked? How do you know when a user signs in from another part of the globe if it’s really them?
To combat against stolen credentials, Microsoft has released a solution called Azure AD Identity Protection that will assist with protecting user identities from being utilized in an unsecure manner. Based on the risk level, Azure AD Identity Protection will take appropriate action (based on a risk profile) such as requiring a user the change their password or by forcing multi-factor authentication.
First we need to define the types of risks events Azure AD Identity Protection detects today:
| Leaked credentials | Typically, when a breach occurs, credentials are sold or accessed on the dark web and used in attempt to access services. |
| Impossible travel to atypical locations | Multiple sign-in’s from different locations across the globe. |
| Sign-ins from infected devices | Device infected with malware that communicate with a bot server. |
| Sign-ins from anonymous IP addresses | Typically done by proxying, for example using Tor browser. |
| Sign-ins from IP addresses with suspicious activity | IPs which a high number of failed sign-in attempts occurred. |
| Sign-ins from unfamiliar locations | Uses past sign-in locations to determine unfamiliar location. |
| Lockout events (not in public preview) |
Read more about risk events here: https://azure.microsoft.com/en-us/documentation/articles/active-directory-identityprotection-risk-events-types/
Setting the risk detection levels
Now that we have an understanding of the type of risks detected, we need to set the risk level. Risk levels can be set as High, Medium, or Low.
There are two types of risk levels, User risk and Sign-in risk:
- User risk indicates the likelihood that the user’s identity has been compromised.
- Sign-in risk indicates the likelihood that someone other than the account owner is attempting to sign-on using the identity.
To set the risk detection levels navigate to https://portal.azure.com and sign-in with your administrator credentials (you have MFA enabled for all Azure admins right? :-) ).
Quick Tip: To further protect azure administrator accounts further see Privileged Identity Management.
To add Azure AD Identity Protection, select “New” on the left hand navigation bar, then type in “identity” then select “Azure AD Identity Protection” from the search results. 
This will open a new blade, select “Create” at the bottom of the blade: 
On the next blade, select “Create” again: 
Once created you’ll see the following blade: 
From here we’ll need to configure Azure AD Identity Protection so the service can start detection. Under “CONFIGURE” on the left hand side, select “User risk policy”. There are multiple options on the new blade to configure, mainly what users the policy will assigned to, the risk condition (High, Medium, Low), controls (require MFA or password change or both), and enforcing the policy by turning on or off.
Note: I recommend starting with a small subset of users to learn more about the user experience when an account is at risk. 
For example, in my environment I have my user risk policy configured as follows:
Note: My sign-in risk policy is identical to my user risk policy.
For MFA, I require my users to register for MFA.
Analyzing the results
As the service begins to monitor it will begin to detect risks as shown below. I used a Tor browser to kick off events because the Tor browser will proxy through different parts of the globe. So it will simulate impossible travel and so on. 
When I investigate by selecting the options below “INVESTIGATE” is see I have a couple users at risk and users that I’ve remediated. For these particular users who are flagged for risk, I can allow them through if I think their sign on is legitimate. 
Here are the risk events that Azure AD Identity Protection has found: 
Here are the Vulnerabilities Azure AD Identity Protection has found: 
Clearly I need to go in and remove a few administrators from my demo environment, however with Azure AD Identity Protection, I’m made aware of these issues and vulnerabilities and I can take action.
End user experience
When an end user signs into Office 365 using a Tor browser they’ll have the following experience: 
Here is shows additional details about the app, device, and user: 
Accessing Azure AD Identity Protection via Microsoft Graph API
For those who are interested in pulling the raw data out to import into their SIEM or BI you’ll want to look at the APIs for Azure AD Identity protection in Microsoft Graph: https://blogs.technet.microsoft.com/enterprisemobility/2016/08/02/apis-for-azuread-identity-protection-are-now-available-in-the-microsoft-graph/
Here I log into my MSOL account via PowerShell: 
Then I ran a PowerShell script (example) to list all the risk events as shown below: 
For a more readable format you can change the formatting of the raw output: 
Or group by “location” for example…and so on:
To learn more about Azure AD Identity Protection, please visit: https://azure.microsoft.com/en-us/documentation/articles/active-directory-identityprotection/