Microsoft Sentinel - Create a new automation rule
Andrew Posted on 7:04 am

Responding to Incidents with Microsoft Sentinel – Part 2 – Optimize What You See

In this article we will explore some enhancements to your Microsoft Sentinel environment. Today we will take a look at optimizing our ticket queue and working to prevent ticket overload. If you missed it, the previous article is here. Let’s explore how we can work towards reducing false positives and overloading our SOC Analysts watching the Incident queue.

In the constantly evolving landscape of cybersecurity, organizations face an incessant onslaught of threats that require prompt and efficient response. Microsoft Sentinel, Microsoft’s cloud-native security information and event management (SIEM & SOAR) solution, has emerged as a powerful tool to bolster security operations. Leveraging the capabilities of Sentinel automation rules to add comments and close incidents with low fidelity has proven to be a game-changer for security teams.

By automating routine tasks and augmenting the decision-making process, Sentinel automation rules enable security analysts to focus their expertise on more critical and complex security incidents. The ability to add comments to incidents allows analysts to provide contextual information, share insights, and collaborate effectively within the security operations center (SOC). This real-time exchange of information enhances situational awareness, facilitates knowledge sharing, and fosters a collaborative work environment.

Let’s run through a few options that we have to help reduce some ‘noise’ in our queue:

Analytics Rules

Our first step is to simply not create incidents when they are not needed or helpful. Sometimes, default values can sneak into our deployments, or things have evolved in our organization and we need to tune-up a rule.

Let’s start in the Azure portal by opening up our Microsoft Sentinel enabled workspace. Navigate in the Azure Portal https://portal.azure.com and Navigate to Microsoft Sentinel, open your workspace, then choose Analytics.

Select the Analytics Rule you would like to examine.

A blade will open on the right-side of your portal. Select Edit near the bottom.

Browse using the tabs across the top of this blade and head over to Incident Settings.

You can choose to create incidents here, on the previous tab Set rule logic, you can tune the KQL query to trigger for the exact events that you wish to target. This is my most frequently used method to tune rules.

Next, go the Automated Response tab.

Here you can configure and ADD Automation Rules targeted directly at taking automation steps for incidents in this Analytics Rule. This is a great way to trigger a playbook or other automated investigation steps to help reduce incidents in your Sentinel queue.

Automation Rules

First, let’s open up our Microsoft Sentinel enabled workspace. Navigate in the Azure Portal https://portal.azure.com and Navigate to Microsoft Sentinel, open your workspace, then choose Automation:

Next, you will see the Automation blade.

Note the 3 tabs that we can take actions on: Automation rules, Active playbooks, and Playbook Templates.

For our demonstration purposes today, we will create a new Automation rule:

Choose the +Create button then select Automation rule.

A new blade will open on the right ‘Create new automation rule’. Let’s explore what we can do here and how this can help clean up the queue for us.

Conditions

  1. Name – Enter a title for your rule. Be descriptive and say what the rule does here.
  2. Trigger – Select when you want this automation rule to be triggered. Depending on the problem you are trying to solve, you may choose different options. Today, we will select ‘when an incident is created’. I find this is the most common scenario.
  3. Conditions – Here is where you build some logic. This can be tricky as this is where we can get very detailed building conditional logic for the rule to match as the trigger.
    • Note in the example above we selected ALL incident providers, specified a single Analytic Rule name using the ‘contains’ operator to ensure that we capture all the words specified in the rule name, and we specified a ‘title’ phrase as ‘Sales User’. This means that the title of the incident MUST contain the words ‘Sales User’ with the incident generated by the Analytics Rule specified.
    • Otherwise if these conditions are not met, this rule will not trigger.
  4. Actions – Choose your actions – you can trigger a playbook, change the status of the incident, change severity, assign an owner, add tags, and add a task (Task is in preview as of publishing date).
    • Today we will change the incident status from Open to Closed and add some descriptions.
    • Select why we are closing the incident. My reason is ‘Benign Positive’ because it’s a valid incident, but we don’t need to know about new Sales Users accounts not being reset at the 2 day mark. Other users may be required to reset their password after less days or other reasons.
    • Something that is really important is to add the COMMENT.
    • In the COMMENT field > always add the same text (copy / paste) such as ‘Closed by automation rule – ‘ so that when you build reports or investigate post-incident, there is a note on the incident that can be used to understand WHY it was closed and the automation handled the incident.
  5. Rule Expiration – can be used to make a rule time-bound. This is useful when solving a problem or process outside our control will be done in 2 months, but for today we need to take an automation step on these incidents. I also use this to expire rules I am testing.
  6. Order – This is the trigger order of all your Automation Rules in Microsoft Sentinel. You can change the running order so that rules follow a logical order of importance for your needs.
    • Yes > You can have 3 #7 rules that all trigger in the same slot. The numbering is not distinct at this time.
Actions

Remember to click APPLY to save your automation rule once you are ready.

The other tip with Automation rules is that you are able to Disable / Enable the rules dynamically in the blade.

You can disable a rule that is not configured correctly, or have a rule written and sitting in your blade but disabled, waiting to be used when needed. I have done this step before to address outage incidents that made my queue far too messy. Another way listed above, is to simply not create incidents for certain conditions right at the source data connector or analytics rule.

Conclusion

The capability to close incidents with low fidelity through automation rules empowers organizations to streamline their incident response process. Low-fidelity incidents are typically less severe or require minimal intervention, making them ideal candidates for automated closure. By configuring rules that accurately identify such incidents based on predefined criteria, security teams can reduce the burden on analysts, optimize resource allocation, and focus their attention on higher-priority threats.

The benefits of leveraging Sentinel automation rules to add comments and close incidents with low fidelity extend beyond efficiency gains. The automated comments provide an audit trail, documenting the actions taken and decisions made during the incident response process. This documentation proves invaluable for compliance purposes, internal investigations, and post-incident analysis. By adding a standardized comment, this further supports a mechanism to build accurate reports and additional automation layers in the future.

Organizations must exercise caution and adopt a measured approach when implementing automation rules. While automation brings numerous advantages, it should not replace human judgment entirely. Continuous monitoring, fine-tuning of rules, and periodic reassessment of thresholds are necessary to ensure the accuracy and effectiveness of automation processes. Striking the right balance between automation and human intervention is crucial to maintaining a robust and adaptive security posture.

Sentinel automation rules provide a compelling solution for organizations seeking to enhance their security operations. By leveraging these rules to add comments and close low-fidelity incidents, security teams can improve efficiency, foster collaboration, and optimize resource allocation. However, it is essential to remember that automation is a complement to human expertise, and a well-defined strategy is necessary to achieve the desired outcomes. With the right approach, organizations can leverage the power of Sentinel automation rules to strengthen their defenses in the face of an ever-evolving threat landscape.