Advanced Customization of Microsoft Sentinel Analytics Rules

AzureTracks - Microsoft Sentinel Logo
Andrew Posted on 7:00 am

Advanced Customization of Microsoft Sentinel Analytics Rules

Join me as we walk through creating a custom Microsoft Sentinel Analytics Rule using KQL to identify suspicious login patterns based on failed attempts. We will explore the different components of creating these custom rules, what tuning looks like, and creating incidents from the rules.

Before we jump in, there are a few things that you should know about being ready for this walk-through:

Prerequisites:

  • Access to Azure & Microsoft Sentinel.
  • Knowledge of Kusto Query Language (KQL).
  • Basic understanding of incident creation in Microsoft Sentinel.
  • Windows SecurityEvent logs available to use the KQL query example provided in this post.

Let’s Begin! Ensure you’re logged into the Azure portal at https://portal.azure.com with the necessary permissions.

You will need Sentinel Contributor role to make the changes we are working through today.

Open Your Microsoft Sentinel Workspace:
Navigate to the specific Microsoft Sentinel workspace where you want to create or edit an Analytics rule.
Remember to use a testing or non-production instance for doing tests like this one today!

Create or Edit an Analytics Rule:

  • To create a new rule, click “Configuration” in the left sidebar and then select “Analytics” under Configuration. Click the “+ Add” button to start creating a new rule.
  • To edit an existing rule, locate the rule in the list and click on it to access its settings.

Define Rule Logic with KQL:
In the rule settings, use a KQL query that addresses your specific use case.

Here’s an example:
We make an assumption here that there are Windows security logs available in Log Analytics Workspace. This can be done a few different ways, but we will stick with this as a baseline example today. 

// KQL query for detecting suspicious login patterns
let threshold = 5; // Set the threshold for suspicious login attempts
SecurityEvent
| where EventID == 4625 // Filter for failed login attempts
| summarize LoginAttempts = count() by AccountName, Computer
| where LoginAttempts >= threshold // Filter for accounts with suspicious login attempts
| project-rename IncidentName = strcat("Suspicious Login Attempts - ", AccountName, " on ", Computer), Description = strcat("Multiple failed login attempts detected for account ", AccountName, " on computer ", Computer)
  • In this example, we are detecting multiple failed login attempts on Windows systems (Windows EventID 4625) and customizing the incident name and description.
  • Adjust the threshold variable to define what constitutes a suspicious number of login attempts for your environment. Common settings are 3 and 5, but this will vary in many cases.

Configure Rule Triggering Logic:
Below the query, configure the rule triggering settings, including frequency, severity level, and other criteria based on your organization’s requirements.

Define Incident Settings:
In the same rule settings, specify incident settings such as title, description, severity, and tags. Make sure these details provide clear context when incidents are generated.

Save and Enable the Rule:
After configuring the rule and incident settings, click “Save” to save your changes. Then, enable the rule to start monitoring your data.

Monitor and Refine:

  • Once the rule is enabled, Microsoft Sentinel will continuously evaluate your data against the KQL query.
  • Regularly review generated incidents and fine-tune the query and incident settings as needed to reduce false positives and accurately capture specific events. This is a key step here –continuous improvements– to update and tune the KQL so that the events being examined are relevant to your current environment. Ensure that your team calendar or ticket system triggers a ticket or reminder to review your Analytics Rules at least quarterly to stay aligned with business and SOC team goals.

Stay Informed:
Keep updated on new features and best practices in Microsoft Sentinel to continuously enhance your security monitoring and incident detection capabilities.


Check out: https://learn.microsoft.com/en-us/azure/sentinel/whats-new to stay up to date!

Conclusion:
Creating KQL queries requires an understanding of your data and the security events you want to monitor. It may take a few iterations to develop the most effective rules for your unique use case. Be diligent in reviewing and refining your rules to ensure optimal incident detection and keep your Sentinel incident queue relevant.