Respond to Advanced Threats with Risk Based Policies and Monitoring Azure Active Directory Identity Protection Azure Active Directory Identity Protection is a security service that provides a consolidated view into risk events and potential vulnerabilities affecting your organization’s identities. Microsoft has been securing cloud-based identities for over a decade, and with Azure AD Identity Protection, Microsoft is making these same protection systems available to enterprise customers. Identity Protection leverages existing Azure AD’s anomaly detection capabilities, and introduces new risk event types that can detect anomalies in real-time. Today, we will be covering both Admin and End user experiences. To start things off, let’s begin with the Admin experience. CLICK STEP(S). Click anywhere on the slide to begin

Here, the dashboard gives you access to: Reports such as Users flagged for risk, Risk events and Vulnerabilities And also settings such as the configuration of your Security Policies, Notifications and multi-factor authentication registration Click Step(s): Click scroll bar to scroll down.

To show you power of Azure AD Identity Protection and it’s user friendly interface, let’s investigate a discovered Risky Event. Click Step(s): Click Risk Events tile.

Risk events are events that were flagged as suspicious by Identity Protection, and indicate that an identity may have been compromised. Microsoft is continuing to invest in this space, and plans to continuously improve the detection accuracy of existing risk events and add new risk event types on an ongoing basis. For today, let’s further investigate the Impossible travels risk event. Click Step(s): Click Impossible travels to atypical locations.

Within the Impossible travel blade, all flagged incidents are displayed by 1st and 2nd login locations and time of each login occurred. Click Step(s): On Jennifer Davis incident, click on 3 instances.

Identity Protection does not just provide you the visibility over suspicious activity such as Impossible Travel but also allows you to take immediate action if necessary. Click Step(s): Under the User column, click on Jennifer Davis.

Here, you have the option to choose from resetting the password, enabling MFA or dismissing all events. Point Out: Top bar under Jennifer’s name, the 3 types of actions that can be taken (Reset password, Enable MFA and Dismiss all events). Aside from addressing incidents on an individual basis, Azure AD Identity Protection gives you the capability to address possible issues through a proactive approach by configuring a User risk remediation policy. Click Step(s): On the bottom of the browsing session, click the horizontal scroll bar to navigate back to the landing page.

But before moving on to creating User risk policies, let’s first take a look at Users flagged for risk in order to gain a better understanding of the criteria User risk policies base their actions on. Click Step(s): Click Users flagged for risk tile.

Within the Users (flagged for risk) blade, users who demonstrate “suspicious” activity are: assigned the appropriate Risk Levels, the total number of risk events are tracked and also displays the current status of that user. A user Risk Level is an indication (High, Medium, or Low) of the likelihood that the user’s identity has been compromised. It is calculated based on the user risk events that are associated with the user's identity, such as: Active risk events impacting the user Risk level of these events Whether any remediation actions have been taken User risk policies base their actions off a user’s Risk Level. Click Step(s): Click Apply a user risk policy… (anywhere on the blue bar).

A User risk remediation policy is a conditional access policy that evaluates the risk level to a specific user and applies remediation/mitigation action based on predefined conditions and rules. However, this policy is currently not enforced. Point Out: Enforce Policy is Off. Before enabling this policy, let’s be sure it is set up properly. Click Step(s): Under the Assignments section, click Conditions: User risk.

The recommended default for most organizations is to configure a rule for a Medium threshold to strike a balance between usability and security. As you can see, the current policy meets the recommended guidelines but let’s also see what other options are available to choose from. Click Step(s): In the Conditions blade, click User risk: Medium and above.

It seems that there are quite a few more options to choose from. Depending on your current situation, you have the option of lowering or raising the conditions to trigger this policy. Now moving on to the type of action to be taken if and when this policy is triggered. Click Step(s): In the User risk remediation policy blade, under Controls, click Granting access: Block access.

Lastly, you have the option of either blocking access entirely or allowing access with the requirement(s) of: Multi-factor authentication Azure MFA registration A password change. By default, the setting of this policy is set up to block access entirely, which is the appropriate action desired for the identified Risk level. Click Step(s): In the User risk remediation policy blade, under Enforce Policy, click On.

Now, to save and deploy this policy to my environment. Click Step(s): In the User risk remediation policy blade, click Save.

Now that the policy has been saved and deployed. All users who possess a User Risk Level of medium or above will be blocked from gaining access to any corporate assets using his/her corporate credentials. Moving on to the End User’s experience. Click Step(s): (If you wish to continue to the End User Experience section) In the upper right corner of the browsing session, click the Minimize button to minimize the window.

To test the User risk remediation policy currently in place, an InPrivate Edge browser and Tor browser will be used. Point Out: “In Private” Edge browser on the Left and Tor browser on the Right. As presented, both browsers are using the same set of credentials. To start things off, let’s see the specific hops the request will take when using the Tor browser. Click Step(s): Within the Tor browser (Right side), click on Tor icon (located to the left of the Back button).

As seen here, it seems that the request will take 3 random hops to the Netherlands, then to Canada, and finally Romania before it hits the internet. If you aren’t already familiar with Tor, Tor is a free software for enabling anonymous communication and is a browser often used by hackers on the “dark web”. Tor directs Internet traffic through a free, worldwide, volunteer network consisting of more than seven thousand relays to conceal a user's location and usage from anyone conducting network surveillance or traffic analysis. Now, let’s see what happens to the request when sent through the Tor browser. Click Step(s): Click Sign In.

As you can see, the request sent through the Tor browser was immediately blocked, not allowing any type of anonymous sign ins to occur. Now to see what happens from the Edge browser. Click Step(s): Within the Edge browser, click Sign In.

As expected, since the request was sent through a legitimate source, the login attempt was successful moments after being blocked in Tor. Closing Statement: In a world of increasing identity theft incidents, persistent bad actors and frequent security breaches, Azure Active Directory Identity Protection is a must-have.