Activating a Microsoft Sentinel’s Solution’s analytic rules

Introduction

One of the great new features in Microsoft Sentinel is the Content hub which allows you to search for, and activate, solutions. A solution is a self-contained offering inside of Microsoft Sentinel that can contain Data connectors, Analytic rules, Hunting Queries, Parsers, Playbooks, Workbooks, and/or Watchlists.

I really hope that sometime in the future, when you create a new Microsoft Sentinel instance, there won’t be any Data connectors listed. Everything will be part of a solution. Microsoft may be moving towards this goal since I noticed there are now solutions for Azure Active Directory, Azure Active Directory Identity Protection, Azure Activity, and other out of the box data connectors.

While this is great, I have noticed that these new solutions will create Analytic rule templates but not the actual rules. As anyone who has worked with Microsoft Sentinel for any amount of time will know, it can be a pain to create rules from templates as you can only create a single rule at a time.

There are ways around this. I have written a blog post around creating rules from templates using PowerShell and the official Microsoft Sentinel PowerShell module also allows you to do this. There is also an entry in the Microsoft Sentinel uservoice community to allow for the creation of multiple rules from templates using the UI!

But how do we know what rule templates are created by a solution and how to we create the rules from these templates? The Microsoft Sentinel REST APIs can help with that.

Getting a list of installed solutions

First of all, you need to know the name of the solution that has been installed. This may or may not be what you see in the UI. For example, the “Continuous Threat Monitoring for GitHub” solution’s internal name is just “Github”. It is also worth mentioning that this solution will automatically create the rules but does not create the template. I think this is the older way of doing this since the Azure AD solutions are new and they don’t work this way.

If you do not know how to setup PowerShell to call the Microsoft Sentinel REST APIs, refer back to Your first Azure Sentinel REST API call – Yet Another Security Blog (garybushey.com)

The URL to call to get the installed solutions is

https://management.azure.com/subscriptions/<subscription>/resourceGroups/<resourceGroup>/providers/Microsoft.OperationalInsights/workspaces/<workspace>/providers/Microsoft.SecurityInsights/metadata/?api-version=2022-01-01-preview&%24filter=properties%2Fkind+eq+%27Solution%27

This URL format should look familiar to anyone who has worked with Microsoft Sentinel REST APIs before. The big different is

  1. We are calling the “metadata” command, which may be new to some readers.
  2. We are filtering the data in the call. This MUST use the URL encoding for it to work correctly

The call to “metadata” will return more than just the solutions that have been installed. It will return Data Connectors, Analytic Rules, as well as other information. Since we only care about the solutions in this case, we will look at the “kind” field located under “properties” to make sure we just want to see solutions.

We could do this filtering inside of PowerShell but then we would get more information returned than we care about and that would increase network traffic, so we let the REST API do the filtering before it sends the data back.

Getting the data for a single solution

We have already downloaded all the information for all the installed solutions but if we want to download just a single solution, we can have the REST API filter on the solution’s ID. This is located in the “sourceId” field which is under “source” which is itself under “properties”. If we wanted to filter to see just the Azure Active Directory solution, we would call

https://management.azure.com/subscriptions/<subscription>/resourceGroups/<resourceGroup>/providers/Microsoft.OperationalInsights/workspaces/<workspace>/providers/Microsoft.SecurityInsights/metadata/?api-version=2022-01-01-preview&%24filter=properties%2Fkind+eq+%27Solution%27+and+properties%2Fsource%2FsourceId+eq+%27azuresentinel.azure-sentinel-solution-azureactivedirectory%27

We just add an additional filter. We could probably get rid of the first filter and just look at the “sourceId” but this seems to be more efficient.

Getting a list of analytic rules

The listing of what the solution will install is hidden a bit. There is an array under the “properties” array (not sure if that is the correct JSON terminology) called “dependencies”. Under that is another array called “criteria” which holds all the Microsoft Sentinel features that will be installed. If I look at the Azure AD solution, it will look like

Figure 1 – Azure AD solutions’ dependencies.

As you can see, everything is listed. By looking at just those entries whose “kind” is “AnalyticsRule”, you will see all the rule templates that are created. You can then iterate through this list and, using your favorite tool to create the rule from a template, create the needed analytic rules.

Summary

This post showed you how to look at Solutions and determine those analytic rule templates that a solution creates. By accessing this list you can then create a way to automatically create the rules from those templates.

Leave a Reply

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.