How to Build Custom Microsoft Sentinel Analytics Rules

Today, I wanted to expand a bit on the last couple of articles where we explore rapid Microsoft Sentinel deployment using PowerShell. This model of repeatable, consistent, and fast deployments is a great way to help build our own skills up, and build a resilient and robust deployment method we can count on. Today, I’ll explore building a couple of different Analytics Rules based on KQL queries so that we can start to see how to deploy more rules into our Sentinel environment.

Microsoft Sentinel is a cloud-native security information and event management (SIEM) system that uses machine learning algorithms and rules to identify and respond to security threats. One of the key features of Sentinel is its ability to analyze security logs and other telemetry data from multiple sources, including Azure Active Directory, Microsoft Defender for Endpoint / Advanced Threat Protection, and third-party security tools.

To enable Sentinel analytics rules driven by KQL queries, you’ll need to follow these steps:

Step 1:
Create a new analytics rule in Sentinel To get started, open the Azure portal at https://portal.azure.com and navigate to the Sentinel dashboard, and then navigate to the Analytics section. Click the New button to create a new analytics rule.

Step 2:
Define the rule logic using KQL queries In the Query section of the new rule, you can define the logic of the rule using KQL queries. KQL (Kusto Query Language) is a query language used by Azure Data Explorer, which is the data engine that powers Sentinel. You can use KQL queries to filter, transform, and aggregate data from multiple sources.

For example, you might use a KQL query to identify failed login attempts in Azure Active Directory:

AzureActivity 
| where OperationName == "Sign-in failed" 
| where ActivityStatusValue == "Failure"

Now, be a bit careful there….you will likely find that particular rule to be a bit chatty! Meaning, please do not deploy that simplified KQL based rule into your Production environment. The rest of your SOC team will not be too pleased at the number of incidents created. Let’s finish up in the Azure Portal GUI and then we will jump to take a quick look at the PowerShell side of things!

The above query selects events from the AzureActivity table where the OperationName column equals “Sign-in failed” and the ActivityStatusValue column equals “Failure”.

Step 3:
Define the rule triggers and actions Once you’ve defined the logic of the rule, you can specify when the rule should be triggered and what actions should be taken in response. For example, you might configure the rule to trigger when a certain number of failed login attempts are detected within a specific time period, and to send an alert to a specified email address or webhook.

Step 4:
Save and enable the rule Finally, you can save the rule and enable it to start monitoring your environment for security threats. You can also view the results of the rule in the Analytics section of the Sentinel portal, and use the query editor to refine your KQL queries as needed.

Enabling Microsoft Sentinel analytics rules driven by KQL queries can help you identify and respond to security threats more quickly and effectively. By leveraging the power of KQL queries, you can filter and analyze security data from multiple sources and generate alerts and actions based on specific criteria.

How Does PowerShell Make it Better?

If you’ve hung out on this blog very much, you’ll know that PowerShell makes everything better! Let’s jump right in:

First let’s get connected to Azure:

Connect-AzAccount

This will prompt you to sign in to your Azure account.

Next, you’ll need to select the subscription that contains your Sentinel instance:

$subscription = Get-AzSubscription | Out-GridView -PassThru -Title "Select Azure subscription"
Set-AzContext -Subscription $subscription

Step 2:
Define the rule logic using KQL queries Once you’re connected to Sentinel, you can use PowerShell to define the logic of your analytics rule. This is done by creating a KQL query and assigning it to a variable. Here’s an example query that identifies failed login attempts in Azure Active Directory which is exactly like creating this same logic through the GUI, but because we can script it out — this becomes repeatable:

$query = @"
AzureActivity
| where OperationName == "Sign-in failed"
| where ActivityStatusValue == "Failure"
"@

Step 3:
Define the rule triggers and actions Next, you’ll need to define the triggers and actions for your analytics rule. This is done by creating an instance of the Microsoft.OperationalInsights/scheduledQueryRules resource type and specifying the necessary properties.

Here’s an example script that creates an analytics rule that triggers when there are more than 10 failed login attempts in a 5-minute window:

$resourceGroupName = "YourResourceGroupName"
$workspaceName = "YourWorkspaceName"
$ruleName = "AzureAD_FailedLoginsRule"
$ruleProperties = @{
description = "Alert on 10 Failed Logins within 5 minutes"
query = $query
severity = 2
isEnabled = $true
triggerOperator = "GreaterThan"
triggerThreshold = 10
triggerWindowSize = "00:05:00"
actionGroupId = "/subscriptions/YourSubscriptionId/resourceGroups/YourResourceGroupName/providers/microsoft.insights/actiongroups/YourActionGroupName"
}
New-AzResource -ResourceType "Microsoft.OperationalInsights/scheduledQueryRules" -ResourceGroupName $resourceGroupName -Name $ruleName -Location "canadacentral" -PropertyObject $ruleProperties -WorkspaceName $workspaceName

Now, you can see that we quite easily enhanced this basic rule to now only alert on 10 failed logons within a 5 minute time span. We get some great advantages by scripting this out!

The above script creates a new Microsoft.OperationalInsights/scheduledQueryRules resource in the specified resource group and workspace. It then sets the necessary properties, including the KQL query, the severity level of the alert, and the action group that should be triggered when the alert is raised.

Step 4:
Verify and test the rule Once your analytics rule has been created, you can verify that it’s working correctly by checking the Sentinel Dashboard in the Azure Portal, or by using PowerShell to retrieve the status of the rule:

Get-AzResource -ResourceType “Microsoft.OperationalInsights/scheduledQueryRules” -ResourceGroupName $resourceGroupName -Name $ruleName

This command will return the current status of the rule, including whether it’s enabled and the last time it was triggered. Sometimes it is good to review the environment for all rules enabled and validate that the existing rules are triggering as we expect them to….we can tackle that one another day!

Conclusion

Using PowerShell to automate the process of creating analytics rules in Microsoft Sentinel, you can save time and ensure that your security monitoring is consistent and effective. With just a few lines of code, you can define the logic of your rule, specify the triggers and actions, and test the results out programmatically.

Thanks for joining me for this fun adventure of PowerShell and Microsoft Sentinel Analytics rules! Remember to clean up your test environments and remove unused resources.