Section 13 – Mitigate threats using Microsoft Sentinel – Configure Security Orchestration, Automation, and Response (SOAR)

13th section starting and this time were are learning on automation, alerts and remediation.

Configure automation rules

By centrally managing automation rules for event management, users may streamline complicated incident orchestration procedures.

Automation rules are triggered by the creation of incidents. Action execution can be controlled by conditions. Actions enable launching a playbook or updating incident configurations directly: adding a tag, changing the severity, or changing the status. The sequence of events and the rule’s expiration period can both be customized by users.

You can access Automation rules under Sentinel -> Automation

From here you can modify the current automation rules and write new ones. Additionally, you may move automation rules around to reorder their execution and toggle their on/off status.

You can view every rule that has been defined on the workspace, together with its status (Enabled/Disabled), and the analytics rules it applies to, in the Automation blade.

Create an automation rule directly in the Automation blade whenever you need one that will apply to several analytics rules.

Automation rules are made up of several components:

• Triggers that define what kind of incident event will cause the rule to run, subject to…
• Conditions that will determine the exact circumstances under which the rule will run and perform…
• Actions to change the incident in some way or call a playbook.

But you can also find use Automation rules from Sentinel -> Analytics

You may examine, update, and create automation rules that relate to the specific analytics rule being created or changed in the analytics rule wizard under the Automated response tab of the analytics rule wizard.

And the third place is Incidents

You can also use the Incidents blade to define an automation rule to respond to a single, reoccurring occurrence. This is important for designing a suppression rule to close “noisy” instances automatically.

Create and configure Microsoft Sentinel playbooks

To better understand the concept Workflows created in Azure Logic Apps serve as the basis for the playbooks in Microsoft Sentinel.

Define what you need, Microsoft has some use cases for them.

And create the Playbook from Automation pane a blank Playbook or from templates.

Playbook templates are not active playbooks until a playbook (an editable copy of the template) is created from them.

Or open GitHub repo https://github.com/Azure/Azure-Sentinel/tree/master/Playbooks and deploy a Playbook directly from there

Microsoft Sentinel supports the following logic app resource types:

• Consumption, which runs in multi-tenant Azure Logic Apps and uses the classic, original Azure Logic Apps engine.
• Standard, which runs in single-tenant Azure Logic Apps and uses a redesigned Azure Logic Apps engine.

But standard workflows do not presently support Playbook templates, thus you cannot create a playbook based on a Standard process directly in Microsoft Sentinel. You must instead develop the workflow in Azure Logic Apps. After you’ve established the workflow, it displays in Microsoft Sentinel as a playbook.

Playbooks can be run either manually or automatically.

To run them automatically you can create a Automated response rule

Or an Automation rule that triggers the Playbook

Select the resource group that you want to allow Sentinel to access

And permissions will be provisioned

And you can select the Playbook you have

And manually by triggering the Logic app Workflow

Or from Sentinel and under the Incident you create and attached the Playbook

And click Run

See more on Playbook from Learn.

Configure alerts and incidents to trigger automation

Maybe you don’t have incidents in Sentinel, not to worry. You can easily integrate Defender For Cloud and deploy those sample alerts for your use.

First add Sentinel Data connector

Switch Connected on and choose automatically create Incidents from below the page.

Once done, create those Alerts and see the magic happen.

And Magic!

Now we can create a automation based on the Incident.

When you create an Automation rule based on the Incident, you can choose the following.

And you can also trigger Automation based on the alert is created by Analytics rule

Use automation to remediate threats

Automation on threats is an essential part on stopping the possible attack. We covered in this section Automation rules and Playbooks earlier and those are the key components on achieving the automation.

Let’s try this one with Identity protection.

What you need for it:

1. Azure AD P2 license for using riskyUsers API
2. Have a user with Identity Protection API rights.
3. (Optional) In Azure AD Identity protection, create policies to run when users are proven to be hacked.

It will connect to Teams, Sentinel and Identity protection to create information for SOC-team to analyze

You can connect to Sentinel with Service principal (App registration) or with Managed identities

But you have to enable it first and then authorize the connections

First create a Managed Identity for the Playbook

And yes, we are sure.

And then Authorize the APIs

Like this

And you will see the Workflow of the Playbook in the Logic apps designed (this is the preview one, that you can try)

As you can see, I’m mixing up the Playbook and Logic apps in purpose. Microsoft will use Logic apps for automation in many different places because the native API connections and completely customizable workflows.

If you want to create your own Playbook, you can use the Blank one under Automation.

And you will find an familiar creation screen.

Use automation to manage incidents

Incident-triggered automation is the best method for the majority of use cases. An incident is a “case file” in Microsoft Sentinel, which is a compilation of all the pertinent data for a given inquiry. It serves as a container for additional artifacts, such as entities, comments, and collaboration notifications.

Instead of being isolated bits of evidence like alerts are, incidents may be enhanced with comments, tags, and bookmarks. They also have the most recent status.

And if you want to combine both, you can in example create an Playbook to add related Alerts to Incidents.

This could be done with Automation rules. See more from Learn.

Closure

What you need to remember for the exam:

Automation rules:

• By centrally managing automation rules for event management, users may streamline complicated incident orchestration procedures.
• Automation rules are triggered by the creation of incidents. Action execution can be controlled by conditions.

Automation rules are made up of several components:

• Triggers that define what kind of incident event will cause the rule to run, subject to…
• Conditions that will determine the exact circumstances under which the rule will run and perform…
• Actions to change the incident in some way or call a playbook.

Playbooks:

To better understand the concept Workflows created in Azure Logic Apps serve as the basis for the playbooks in Microsoft Sentinel.

Playbooks can be run either manually or automatically.

How you can deploy Playbooks, what you need to do for them to work?

Incidents:

What are alerts and incidents? What is the difference?

How to automate remediation and others tasks?

As we can see Microsoft Sentinel is a Security Orchestration, Automation, and Response (SOAR) platform in addition to a Security Information and Event Management (SIEM) system.

Automating any recurrent and predictable enrichment, response, and remediation tasks that fall under the purview of your Security Operations Center is one of its main goals.

Link to main post