Working with Analytics rules Part 3 – Create Fusion / ML Rule

Introduction

In the previous posts I spoke about the Azure Sentinel Analytics rule templates. You may be wondering why I did that. The reason is that in this post, I will be discussing creating new Fusion and ML rules and in order to do that you need to have a rule template’s ID. You will also need to know how to format the URL to work with a specific Analytic rule which was covered in Working with Analytics rules Part 2 – The rules

Rule Template Rule Types

Refer back to PowerShell Objects post to setup the $results variable from the listing of Analytic rules templates. the If you run this command again

$results.kind

You will see there are 4 different entries that correspond to the 4 different rule types. Microsoft has set the rule type to the kind field. There is also a type field but that is always set to Microsoft.SecurityInsights/AlertRuleTemplates.

For now, the ones we care about are Fusion and MLBehaviorAnalytics. We will be using MicrosoftSecurityIncidentCreation in a later post so write it down somewhere handy.

We will need to know what value to set for the kind variable when we create the body of the REST call to create a new Analytic Rule.

Create a new Fusion rule

When creating a new rule there are 3 things we need to do differently than when listing rules

We will need to create GUID that will be part of the URL we use to make the REST call
We will be using the PUT method when making the REST calls
Because of this we need something to PUT. We will be setting up a variable that contains all the needed data.

For item #1, we will need to create a GUID, store it in a variable, and use that variable in the URL. First, to create a GUID and store it in a variable, use

$guid = (New-Guid).Guid

We then use that to state which alertRule we are looking at. So, in this case, the URL would be

https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}/providers/Microsoft.SecurityInsights/alertrules/$($guid)?api-version=2019-01-01-preview

making all the needed replacements for {subscriptionId}, {resourceGroupName}, and {workspaceName}. Notice the $($guid) which is needed to translate the variable inside quotes (which are not shown in the code segment above but when you set the URL to a variable you will need to use them. See the full listing below)

Item #2 is easy enough. When we make the call to Invoke-RestMethod we change the Method parameter to Put.

For item #3, we will need to create a variable that holds the information to pass into the body of the REST call and pass that in. To pass it in, we will use the Body parameters and pass in the variable after converting it to JSON (see the code below).

We are going to be really creative and use $body as the variable for the body. There are 3 fields that we need to have in the body; kind, enabled, and alertRuleTemplateName and the last two are part of the properties variable. It is pretty easy to create the variable as shown below:

$body = @{
    "kind"       = "Fusion"
    "properties" = @{
        "enabled"               = "true"
        "alertRuleTemplateName" = "f71aba3d-28fb-450b-b192-4e76a83015c8"
    }
}

In this case we are creating a new Fusion rule based on the Advanced Multistage Attack Detection rule template (which is currently the only Fusion based rule template) and you get its ID from the listing of the rule templates. Now we call the PowerShell command to use the REST API:

Invoke-RestMethod -Uri $uri -Method Put -Headers $authHeader -Body ($body | ConvertTo-Json -EnumsAsStrings)

making sure to translate the $body string to JSON. The full listing would be like below. This was taken from VSCode which is the editor I usually use for PowerShell.

$context = Get-AzContext
$profile = [Microsoft.Azure.Commands.Common.Authentication.Abstractions.AzureRmProfileProvider]::Instance.Profile
$profileClient = New-Object -TypeName Microsoft.Azure.Commands.ResourceManager.Common.RMProfileClient -ArgumentList ($profile)
$token = $profileClient.AcquireAccessToken($context.Subscription.TenantId)
$authHeader = @{
'Content-Type' = 'application/json' 
'Authorization' = 'Bearer ' + $token.AccessToken 
}
# FUSION
$body = @{
  "kind" = "Fusion"
  "properties" = @{
    "enabled" = "true"
    "alertRuleTemplateName" = "f71aba3d-28fb-450b-b192-4e76a83015c8"
   }
}
$guid = (New-Guid).Guid
$uri = "https://management.azure.com/subscriptions/xxxxxx-xxxx-xxxx-xxx-xxxxxxxxxxxx/resourceGroups/rg-sentinel-beta/providers/Microsoft.OperationalInsights/workspaces/la-sentinel-beta/providers/Microsoft.SecurityInsights/alertRules/($guid)?api-version=2019-01-01-preview"
try {
  $result = Invoke-RestMethod -Uri $uri -Method Put -Headers $authHeader -Body ($body | ConvertTo-Json -EnumsAsStrings)
  Write-Output "Successfully updated rule with status: $($result.StatusDescription)"
  Write-Output ($body.Properties | Format-List | Format-Table | Out-String)
}
catch {
  $errorReturn = $_
  Write-Error $errorReturn
}

One thing to remember is that you can only have 1 instance of a rule based on the Fusion template so if you run this code twice without deleting the rule that was created, the second time it will throw an error.

Create a new ML rule

It is very easy to create a new Machine Language Analytic rule as it is identical to how you create a new Fusion rule. In the $body variable, change the kind field to MLBehaviorAnalytics and make sure you use the ML rule template’s ID. Currently there is only one ML rule template called (Preview) Anomalous SSH Login Detection so it should be easy to find it.

Conclusion

It is fairly simple to add a new Fusion or Machine Language Analytic rule in Azure Sentinel. You just need to know the ID of the template you want to use and the rest falls into place. In the next posting, we will look at creating a Microsoft Security Analytic rule.

Yet Another Security Blog