Configure risk-based access rules

- [Instructor] Let's talk about risk-based configuration in our Azure AD conditional access strategy. Risk-based analysis is delivered via the Azure AD Identity Protection feature, which comes in the P2 or plan two level of Azure AD Premium. This can be incorporated as an additional condition within our conditional access policies and enables response based on the level of risk associated with a sign-in. Risk is a machine learning driven feature, so this really adds another layer of intelligence to the evaluation of conditions surrounding an authentication request.

Azure AD identity protection enables us to detect potential vulnerabilities affecting our organization's identities, to configure automated responses to detected suspicious actions that are related to those identities, and to view reports to investigate suspicious incidents and take appropriate action to resolve them. To protect your organization's identity, you can configure risk-based policies that automatically respond to detected issues when a specified risk level has been reached.

These policies, in addition to other conditional access controls, can either automatically block access or initiate adaptive remediation actions, including password resets. This is conditional access as you know it with an additional element of context for us to evaluate. Azure AD Identity Protection will detect the following vulnerabilities, which weaken your security posture and increase your attack surface. First, multi-factor authentication registration not configured, too many global administrators in your Azure AD tenet, unmanaged cloud apps as a point of access, and security alerts from privileged identity management.

Currently, Azure AD Identity Protection detects six types of risk events, users with leaked credentials, sign-ins from anonymous IP addresses, which identifies logins from behind anonymous proxies, hiding device IP, signaling potentially malicious intent, impossible travel to atypical locations where logins from two locations are too far to travel in between the login times. Note that the machine learning behind this feature should ignore sign-ins from remote corporate locations as when you connect to a remote server based on other sign-in locations of users within your corporate organization.

Sign-ins from unfamiliar locations based on past, familiar sign-in locations, and trusted locations you define. Sign-ins from infected devices infected with malware or actively communicating with a bot server, for example. And sign-ins from IP addresses with suspicious activity representing the possibility of a threat actor. There are currently two types of detection, real time and offline. Currently, not all detections are happening in real time.

And by real time, I mean within five to 10 minutes. Offline detections typically take two to four hours. The machine learning in the intelligent security graph needs a bit of a time to crunch the data to surface some of these risks. Expect to see the real time capability to improve over time. The risk level property of a risk event is an indicator, high, medium, or low, for the severity and the confidence surrounding a risk event. This property helps us prioritize actions that we should take.

Severity of the risk represents the strength of the signal as a predictor of identity compromise. Confidence is an indicator of the possibility of false positive detection. Response guidance is based on the level, which is determined through confidence and severity. High risk requires immediate and stronger action. This means remediate immediately. I might configure conditional access to trigger a password reset or simply block access in these situations.

Medium might mean high severity but with lower confidence, or vice versa. At this level, I might configure identity protection to trigger an MFA challenge. And low confidence and low severity are low priority. How are these threats rated? Leaked credentials are classified as high, because they provide a clear indication that a username and password are available to an attacker. Sign-ins from anonymous IP addresses are a medium risk, because an anonymous IP is not a strong indication of account compromise, although Microsoft recommends that you immediately contact the user to verify that they were intentionally using an anonymous IP address.

Impossible travel, unfamiliar locations, and suspicious IPs also fall into that medium category. If several devices are behind a single IP address, and only some are controlled by a bot network, sign-ins from other devices may trigger this event unnecessarily, which is the reason for classifying this risk event as low. There are two places where you can view reported risk events, in Azure AD reporting, or the Azure AD Identity Protection Center in the Azure portal.

While automated response is one line of defense, manual review to apply human perspective and identify patterns is a best practice. With Azure AD Identity Protection, we get the best of both worlds.