I decided to work with Azure Sentinel by adding Azure AD Identity Protection. Why? For one, it was easier than connecting Azure Sentinel to our firewall (which is way beyond my pay grade). More importantly, we know that compromised identities (usernames and passwords) are by far the most common means of hacking into networks. So, it made sense to implement a tool that would help manage identities.

If you want to learn more about Azure Sentinel, check here. And finally, check here to learn more about Azure AD Identity Protection.

Working with Azure Sentinel: Connect Azure AD Identity Protection

The steps to connect Azure AD Identity Protection were pretty easy.

• I purchased a license for Microsoft Enterprise Mobility & Security (EMS) E5. This subscription had the license for Azure AD Identity Protection that I needed (along with some other goodies).
• Then I set up Azure AD Identity Protection. It’s straightforward to do.
• Next, I connected Azure AD Identity Protection to Azure Sentinel. I logged into the Azure portal and went to the Azure Sentinel landing page. Here’s a screenshot of that. You’ll notice that I already connected some other services to Azure Sentinel, and it’s showing me activity on those services (mostly Office 365 activity).

• From there, I clicked on Data Connectors to connect Azure AD Identity Protection.

• I confirmed that I met the prerequisites, added a little more information and clicked on Connect. That was it!

Azure AD Identity Protection Reporting

Let’s look at the results after working with Azure Sentinel to connect in the Identity Protection service. I navigated to the Azure AD Identity Protection landing page. Here’s a screenshot of that.

Without doing anything, Azure AD Identity Protection will tell you about

• Risky users (users that have scored on certain risk factors)
• Risky sign-in’s (sign-in activity that seems weird)
• Risk detections (like it sounds)
• Vulnerabilities (in our case, it noted that not everyone is set up to use Multi-Factor Authentication, or MFA)

For instance, I saw that there were six risky sign-in’s over the last thirty days.

From there, working with Azure Sentinel I was able to “drill down” and see that these risky sign-in’s came from one of our users, signing in from a couple of locations in France. At that point, I could take action. I could also tell the system that this was a risky sign-in or that it was OK. This step is important because it “trains” the machine learning that lies behind determinations of what is or isn’t risky.

Working with Azure Sentinel: Automate with Policies

This is great for reporting on after-the-fact events. I think it’s a good place to start. Once you get comfortable with how Azure AD Identity Protection works, you can work with Azure Sentinel and Identity Protection to begin configuring policies governing risk users and risky sign-in’s. For instance, you can require that users at a certain risk level change their password when they sign in or require them to use MFA.

When you set up these policies, you’re putting the Azure SIEM to work, proactively identifying risk situations and taking action. Now you’re being proactive about security, not just reactive. And that’s going to improve your organization’s security posture.