Just recently, Microsoft released their long awaited implementation of risk based authentication/authorization control. Personally, we’re very excited about this announcement. Hold your horses, as it’s still in public preview …. for now…
Let’s have a little background on the subject. What’s so interesting about this component and why should you be interested in it?
For starters, in the contemporary cloud, we’re relying on Identity & Access Management frameworks to provide our subscribers with secure and manageable paths to authentication and authorization of their resources. By secure we mean we are able to provide our subscribers with a corporate identity in the current framework, but there are limitations. For example, how are we to know if it’s really that subscriber using the resource at a given moment ? Sure, we know that the credentials are valid, but what if the account has been compromised? How does one tell? Cue Azure AD Identity Protection: a big step in the right direction for helping establish a risk posture and applying it during the authentication process, particular when combined with other mechanisms, such as Multi-Factor Authentication (MFA).. (something we’ll cover in a later blog post).
Azure Active Directory Identity Protection is a security service within Microsoft Azure that provides a consolidated view into risk events and potential vulnerabilities affecting the organization’s identities. Identity Protection leverages existing Azure AD’s anomaly detection capabilities (available through Azure AD’s Anomalous Activity Reports), and introduces new risk event types that can detect anomalies in real-time.
The vast majority of security breaches take place when attackers gain access to an environment by stealing a user’s identity. Attackers have become increasingly effective at leveraging third party breaches, and using sophisticated phishing attacks. Once an attacker gains access to even a low privileged user account, it is relatively straightforward for them to gain access to important company resources through lateral movements/traversal attacks. It is essential, therefore, to protect all identities and, when an identity is compromised, proactively prevent the compromised identity from being abused.
Discovering compromised identities is no easy task. Identity Protection uses adaptive machine learning algorithms and heuristics to detect anomalies and risk events that may indicate that an identity has been compromised.
Using this data, Identity Protection generates reports and alerts that enables the administrator to investigate these risk events and take appropriate remediation or mitigation action.
Azure Active Directory Identity Protection is more than simply a monitoring and reporting tool. Based on risk events, Identity Protection calculates a user risk level for each user, enabling the security professional to configure risk-based policies to automatically protect the identities of the organization. These risk-based policies, in addition to other conditional access controls provided by Azure Active Directory and EMS, can automatically block or offer adaptive remediation actions, including password resets and enforcement of multi-factor authentication.
Now, let’s have a look at the delivered functionality here.
In the reporting module of the Azure Active Directory Identity Protection service, we’re now able to view some important security related events within our environment (tenant):
Detecting risk events and risky accounts:
- Detecting 6 risk event types using machine learning and heuristic rules
- Calculating user risk levels
- Providing custom recommendations to improve overall security posture by highlighting vulnerabilities
Investigating risk events:
- Sending notifications for risk events
- Investigating risk events using relevant and contextual information
- Providing basic workflows to track investigations
- Providing easy access to remediation actions such as password reset
Very useful additions for incident and event management. The real-time evaluation and mitigation are also very interesting.
Risk-based conditional access policies:
- Policy to mitigate perceived “risky” sign-ins by blocking sign-ins or requiring multi-factor authentication challenges.
- Policy to block or secure “risky” user accounts
- Policy to require users to register for multi-factor authentication
The Risk level for a risk event is an indication (High, Medium, or Low) of the severity of the risk event. The risk level helps Identity Protection users prioritize the actions they must take to reduce the risk to their organization. The severity of the risk event represents the strength of the signal as a predictor of identity compromise, combined with the amount of noise that it typically introduces.
- High: High confidence and high severity risk event. These events are strong indicators that the user’s identity has been compromised, and any user accounts impacted should be remediated immediately.
- Medium: High severity, but lower confidence risk event, or vice versa. These events are potentially risky, and any user accounts impacted should be remediated.
- Low: Low confidence and low severity risk event. This event may not require an immediate action, but when combined with other risk events, may provide a strong indication that the identity is compromised
Given we’re able to classify the risk level of any authentication attempt, using the classification within the context of the authentication process, we still need to look at how the information is collected. Let’s have a look under the hood of the Azure Active Directory Identity Protection service a little further…
Leaked credentials are found posted publicly in the dark web by Microsoft security researchers. These credentials are usually found in plain text. They are checked against Azure AD credentials, and if there is a match, they are reported as “Leaked credentials” in Identity Protection. Leaked credentials risk events are classified as a “High” severity risk event, because they provide a clear indication that the user name and password are available to an attacker.
This risk event type identifies two sign-ins originating from geographically distant locations, where at least one of the locations may also be atypical for the user, given past behavior. In addition, the time between the two sign-ins is shorter than the time it would have taken the user to travel from the first location to the second, indicating that a different user is using the same credentials.
This machine learning algorithm ignores obvious “false positives” contributing to the impossible travel condition, such as VPNs and locations regularly used by other users in the organization. The system has an initial learning period of 14 days during which it learns a new user’s sign-in behavior.
Impossible travel is usually a good indicator that a hacker was able to successfully sign-in. However, false-positives may occur when a user is traveling using a new device or using a VPN that is typically not used by other users in the organization. Another source of false-positives is applications that incorrectly pass server IPs as client IPs, which may purport sign-ins taking place from the data center where that application’s back-end is hosted (often these are Microsoft datacenters, which may give the appearance of sign-ins taking place from Microsoft owned IP addresses). As a result of these false-positives, the risk level for this risk event is “Medium”.
This risk event type identifies sign-ins from devices infected with malware, that are known to actively communicate with a bot server. This is determined by correlating IP addresses of the user’s device against IP addresses that were in contact with a bot server. Be aware; this risk event identifies IP addresses, not user devices ! If several devices are behind a single IP address, and only some are controlled by a bot network, sign-ins from other devices my trigger this event unnecessarily, which is the reason for classifying this risk event as “Low”.
This risk event type identifies users who have successfully signed in from an IP address that has been identified as an anonymous proxy IP address. These proxies are used by people who want to hide their device’s IP address, and may be used for malicious intent. The risk level for this risk event type is “Medium” because in itself an anonymous IP is not a strong indication of an account compromise.
This risk event type identifies IP addresses from which a high number of failed sign-in attempts were seen, across multiple user accounts, over a short period of time. This matches traffic patterns of IP addresses used by attackers, and is a strong indicator that accounts are either already or are about to be compromised. This is a machine learning algorithm that ignores obvious “false-positives“, such as IP addresses that are regularly used by other users in the organization. The system has an initial learning period of 14 days where it learns the sign-in behavior of a new user and new tenant.
The risk level for this event type is “Medium” because several devices may be behind the same IP address, while only some may be responsible for the suspicious activity.
This risk event type is a real-time sign-in evaluation mechanism that considers past sign-in locations (IP, Latitude / Longitude) to determine new / unfamiliar locations. The system stores information about previous locations used by a user, and considers these “familiar” locations. The risk even is triggered when the sign-in occurs from a location that’s not already in the list of familiar locations. The system has an initial learning period of 14 days, during which it does not flag any new locations as unfamiliar locations. The system also ignores sign-ins from familiar devices, and locations that are geographically close to a familiar location.
Unfamiliar locations can provide a strong indication that an attacker is able attempting to use a stolen identity. False-positives may occur when a user is traveling, trying out a new device or uses a new VPN. As a result of these false positives, the risk level for this event type is “Medium”.
There’s a nice looking management style console as a collation point for gathering all events, but the real ingredients or “special sauce” lie beneath 🙂
We’re still some steps away from the desired end-state, where we’re able to influence or even determine the level of authorization next to the level of authentication, but let’s not be too pessimistic 🙂 This is really a big step forward as a building block within the (Microsoft) Access Management framework!
In the meantime, if you’d like to know more on how you are able to use this functionality within your corporate environment, please contact us and let us know how we can assist you.