Unleash the power of Sentinel - SOAR

Introduction

In this blog we will dig into the capabilities of automation using Sentinel referred to as SOAR. SOAR (Security Orchestration, Automation, and Response) platforms are designed to streamline and enhance security operations by automating and orchestrating various tasks and processes.

Sentinel brings multiple possibilities to automatically react to incidents, and alerts. Everything starts with automation rules. With automation rules, we can perform a wide range of automated actions, including alerting, remediation, enrichment, and orchestration. For example, when a specific event or alert matches the conditions defined in an automation rule, the system can trigger the following action types:

• Run playbook
• Change status
• Change severity
• Assign owner
• Add tags
• Add task

Those action can be supportive to streamline the process of incident analysis and response. You can use the actions to assign an incident of a special category to the right analyst and add a couple of predefined action items as well to support your first level analyst.

Integrating Logic apps

Using the Run playbook action, we can integrate another Azure service called Azure Logic apps.

Azure Logic Apps is a cloud-based service that allows us to automate workflows and integrate various systems, applications, and services. It leverages a wide range of connectors to interact with popular software-as-a-service (SaaS) applications, on-premises systems, and cloud services. These connectors enable seamless integration and data exchange between different endpoints, such as Microsoft Office 365, Dynamics 365, Salesforce, SharePoint, Azure services, and many others.

With Logic apps we can automatically interact with API based systems. For Sentinel being able to trigger your logic app you must ensure it has the needed permissions. Those can be configured directly in Sentinel by navigating to the Settings blade and choose Playbook permissions:

In the upcoming wizard select the location where you plan to deploy your logic apps and hit Apply. In the background Azure will assign the role Microsoft Sentinel Automation Contributor to the principal Azure Security Insights. You can locate this principal within your Enterprise Applications. If you have multiple instances of Sentinel, they will share this service principal. Therefore, they will also share access to the logic app location.

It is important to understand under which circumstances an analyst will see playbooks to trigger them manually. In this case it depends on the permissions of the analyst himself. They need to be able to read the logic app to trigger it using Sentinel. If you plan to have a larger set of automations, which is likely once you understand the power, it might be useful to plan different location for your logic app. There should be one resource group for logic apps that are only used fully automatic by Sentinel and one resource group for logic apps that are meant to be triggered manually. This will help improve the user experience of analysts as they will only see playbooks meant for usage during their investigation flow.

Authentication

Logic apps needs to be able to authenticate against other Azure resources like Sentinel. Resource-to-resource authentication in Azure with managed identities enables secure communication between Azure services without manually managing credentials. It utilizes Entra ID to automatically create, rotate, and delete credentials for resources. Two types exist: system assigned (tied to resource lifecycle) and user assigned (standalone, assignable to multiple resources) managed identities.

While having a dedicated system assigned managed identity for each logic app follows the principle of least privilege, it also brings some challenges to the processes in an organization. You need to be able to manage many managed identities with fine granular permissions for your automations to work properly.

Furthermore, when integrating APIs like Microsoft Graph or Defender for Endpoint API you need to delegate permissions per managed identity as well in Entra ID like the following example. Usually, organization struggle to deliver such fluent permission processes and get them running in an acceptable time from a SOC point of view.

Thats why building clusters of similar logic apps and combine each cluster with a single user assigned managed identity can be beneficial. In this scenario you can group similar logic apps like the following:

• Identity: Logic apps that need to do privileged stuff in Entra ID
• Defender: Logic apps that need to do stuff via Defender API
• 3rd party system 1
• 3rd party system n
• Using this grouping will allow your organization having only to manage a couple of managed identities instead of dozens. You need to be aware that this may end up in some apps being overprivileged which means you need strong controls to ensure only necessary people can modify the apps.

When integrating third party apps there might be several other ways of authentication. Usually, APIs will use some kind of key or user credential.

Connectors could also need the usage of a user sign-in or an app registration. If possible, you should always try to use a managed identity for resource-to-resource authentication.

Playbook templates

To get things started it is worth to have a look at the playbook templates. Microsoft provides a set of logic apps available for direct usage. To view available templates, navigate to the Content hub blade and filter for Content type: Playbook:

Once you found a set of templates to start with mark them and hit Install/Update:

After adding the desired playbooks from the Content hub, you can explore them in the Automation blade under Playbook templates (Preview):

To deploy a template select it from the list and hit Create playbook:

This will lead you into the well-known deployment wizard. In my case I’m planning to create a playbook meant for analyst usage and will place it in the resource group rg-sentinelPlaybooksManually. After you successfully deployed the template, you will see the logic app designer:

Before you can start using the new playbook you have to alter all the connections that are included in the logic app. The needed input for the connections depends on the connector it is using and may need third party access credentials.

There is a complete list of built-in connectors available:

List of all Logic Apps connectors | Microsoft Learn

Common Use cases

Logic apps are often used to make response actions available to the analyst without the need of extensive privileges for the user account. Furthermore, the analyst does not need to leave Sentinel for certain actions and can focus on his core responsibility. Those response actions commonly include but are not limited to the following:

• Isolate a compromised device
• Block file-based threats in EDR systems
• Run a full AV scan
• Reset a users password
• Revoke users access tokens
• Block malicious IPs and URLs
• Remove malicious mails from a user mailbox
• Restrict the execution of executables

The set of possible response actions heavily relies on the set of tools your organization is using. Additionally, Logic apps can be used for data enrichment. Data enrichment helps your analyst to gather the needed data during incident investigation and will improve the time an analyst needs to spend to conclude. Enrichment can include many different actions. Here is just a set of possible enrichments:

• Reputation check of IPs and URLs against tools like VirusTotal
• On demand loading of data out of log management solutions like Elastic or Splunk
• Query existing logs for related entity activities
• Check for peers of a potentially compromised user or device
• Gather details on used Mitre Att&ck tactics and techniques

On top of that Logic apps help you to integrate your incident response process to already existing ticketing systems like Jira or ServiceNow. It may also be useful to streamline the needed communication to impacted users or responsible asset owners. Therefore, you can use Teams or mail integration to send automated messages. Those Teams messages may also be interactive using adaptive cards to ask for additional information or confirmation and take actions based on the response like in the selected template above.

All those use cases are meant to save the analysts time and get the maximum value out of your SOC.

Building your app from scratch

Now that we know how to setup the integration of Sentinel and Logic apps and have an idea about use cases, we can start implementing our own process. In this example we will build a response action that will be able to revoke a user’s token in Entra ID using Microsoft Graph API. Token revocation is a crucial ability to fight token replay attacks and is nearly free of risk as the impact to the user’s productivity is limited to a full reauthentication. Therefore, this is a must have for your use case library.

First, we need to create the logic app resource. Therefore, we navigate to the Automation blade in Sentinel and hit create. In the dropdown we choose Playbook with entity trigger. This will give us a preconfigured flow with a Sentinel entity trigger and the needed connection:

The Entity trigger needs to be configured to the needed entity type. The playbooks will only be visible if an analyst choose the right type of entity:

Before we can safely revoke the token, we should first check if the provided account exists in Entra ID. We going to use the Azure AD (renaming will not happen shortly) connector to verify the user account:

After connecting using an account with the needed permissions we going to fill the parameters using dynamic content from the entity trigger:

Next, we need to check if the user was found. Therefore, we use the condition action:

If we found a user account, we going to revoke the access. As we do not want to use a user sign in for authentication this time, we will not use the built-in connector but rather directly talk to the API endpoint using the HTTP action:

Afterwards and in the false path we going to add the relevant information to the incident:

At the end the flow will look something like this:

Before we can start using this logic app, we need to ensure the app has the right permissions. To add comments to a Sentinel incident it will need an appropriate Azure RBAC role to do so. We can achieve that by navigating to the Identity blade and hit Azure role assignments. Choose the resource group of Sentinel as a scope and select the role Microsoft Sentinel Responder:

As we used the HTTP action to call the graph API our managed identity will need some permissions to Graph API as well. This is a more complicated task to achieve as there is no UI available. There are scripts available to achieve this like the following:

Function Grant-GraphAdminConsent
{
    [CmdletBinding()]
    param (
        [Parameter(mandatory=$true)]
        [string]
        $TenantID,

        [Parameter(mandatory=$true)]
        [string]
        $ServicePrincipalId,

        [Parameter(mandatory=$true)]
        [string[]]
        $PermissionName
    )
    If (-not(Get-Module "AzureAD" -ListAvailable))
    {
        Install-Module AzureAD -Scope CurrentUser
    }

    Import-Module AzureAD

    Connect-AzureAD -TenantId $TenantID

    $GraphServicePrincipal = Get-AzureAdServicePrincipal -SearchString "Microsoft Graph" | Select-Object -first 1
    Foreach ($permission in $PermissionName)
    {
        $AppRole = $GraphServicePrincipal.AppRoles | Where-Object {$_.Value -eq $permission -and $_.AllowedMemberTypes -contains "Application"}
        New-AzureAdServiceAppRoleAssignment -ObjectId $ServicePrincipalId -PrincipalId $ServicePrincipalId -ResourceId $GraphServicePrincipal.ObjectId -Id $AppRole.Id
    }
}

The script currently depends on the Azure AD PowerShell module which is subject of deprecation for March 30, 2024. Nevertheless, we will need some information for the script to work. You should grab your Tenant ID and the Object ID of the managed identity. You can find this in Entra ID in the Enterprise Applications blade. Filter for Application type == Managed Identities and search for the name of your logic app:

Next, we need to know the needed permissions. These can be found in the API reference in this example case
user: revokeSignInSessions - Microsoft Graph v1.0 | Microsoft Learn
the following permissions are needed:

Now we can use the information and the script to grant the needed app roles of the Graph API application to the managed identity. After you run the script, you should get the following:

Analyst point of view

As an analyst there are different entry points to use playbooks manually. All starts by viewing an existing incident. In my case I have a demo incident involving an account entity:

As we created a playbook with the entity trigger it is only visible by selecting the correct type of entity:

By clicking Run playbook the analyst will be able to see all playbooks with the entity trigger of type account in the fly-out menu:

You can also use the Incident actions button to run playbooks with the incident trigger:

Or select an alert to run playbooks with the alert trigger:

We select the earlier created playbook by clicking run and have a look at the response as a comment:

The end user will experience the following screen after the sessions were revoked:

We can also review the details of the last run by opening the logic app and check the Runs history tab in the Overview blade:

Conclusion

Although Azure Logic apps comes with its challenges regarding authentication and authorization it is a great and easy-to-use tool for process automation.

In our example we used an HTTP call to invoke the Microsoft Graph API as there is no built-in connector yet. You’re very likely not willing to write this HTTP call every time you need it from the beginning. Therefore, in the next blog we will cover Logic app custom connectors and make our API call reusable.

Still there will be challenges that won’t be solvable easily using Logic apps as you are limited to the available set of actions and functions. For example, dealing with dynamic data input or building more complex evaluations will bring you in situations where you might need additional capabilities. We will discover how to leverage Azure Function Apps to invoke custom code from your playbook soon.