Microsoft Sentinel Automation Tips & Tricks – Part 1: Automation rules

In addition to being a Security Information and Event Management (SIEM) system, Microsoft Sentinel is a security orchestration, Automation, and Response (SOAR) platform. One of its primary purposes is to automate any recurring and predictable enrichment, response, and remediation tasks that are the responsibility of your Security Operations Center and personnel (SOC/SecOps). With this, we can free up time and resources for more in-depth investigation and hunting for advanced threats. Automation takes a few different forms in Microsoft Sentinel, from automation rules that centrally manage the automation of incident handling and response to playbooks that run predetermined sequences of actions to provide robust and flexible advanced automation to your threat response tasks.

 

This blog is part of a multi-series

Part 1: Automation rules – this blog

Part 2: Playbooks

Part 3: Send email notification options

Part 4: Dynamic content and expressions – coming soon

 

Automation rules

Automation rules (now generally available!) allow users to manage the automation of incident handling centrally. Besides letting you assign playbooks to incidents (not just to alerts as before), automation rules also allow you to automate responses for multiple analytics rules at once, automatically tag, assign, or close incidents without needing playbooks and control the order of actions that are executed.

 

Here are some tips & tricks that can be helpful when creating automation rules:

 

Order of automation rules

Order of automation rules is important because they will be executed per order number. And for each incident, all automation rules will be executed.

 

The important thing is that you don’t create redundant tasks in automation rules for the same incident. A common one is that you auto-close specific incidents in the automation rule with order 1. Then in the automation rule with order 2 (or 5, 10, etc.), you configure that the same incident will have the status Active.

In these cases, auto-close of incidents should be with a lower-order number so these situations wouldn’t happen if not expected behavior.

 

Also, the important thing is to make sure that essential playbooks go in the automation rule with a lower-order number. This is important if you have playbooks that have a long-run period or we need to wait for input from the user/analyst. It can take a few minutes to run all automation rules. Playbooks are run one by one, not simultaneously. The second playbook will run either after the first playbook is finished or 2 minutes after the first playbook starts. The third playbook will run either after the second playbook finished its run or 2 minutes after the second playbook started the run. And so on. So, if you have ten playbooks to run with automation rules, it can pass 18 minutes before you run playbook number 10.

 

Run playbooks on Microsoft 365 Defender or Microsoft Defender for Cloud incidents

Before introducing automation rules, we could only run alert trigger playbooks on Microsoft 365 Defender and Microsoft Defender for Cloud.

 

Automation rules allow us to utilize a more powerful incident trigger that can be configured to run on all incidents (including Microsoft 365 Defender and Microsoft Defender for Cloud) or specifically on incidents that are created in Microsoft 365 Defender or Microsoft Defender for Cloud.

 

Run playbooks on incident update

The latest addition to Microsoft Sentinel automation is an option to run playbooks and automation when the incident is updated. It is done using automation rules, where we need to change the trigger to “When incident is updated” and add update conditions (state or severity changed, comment, tag, alert, tactics, the owner added).

 

More about this new addition on this blog:

What’s new: Automate full incident lifecycle with incident update triggers - Microsoft Tech Community

 

Rule expiration

Automation rules can also be used to auto-close false-positive incidents or auto-close expected incidents because the organization is performing pen-testing. Suppose we know those incidents are expected in the next five days until pen-texting is over. In that case, we can create an automation rule to auto-close those incidents until a specific date and time, after which the automation rule will be disabled.

 

Part 2: Playbooks >