Loading...

Automated Detection and Response for Azure Firewall with the New Logic App Connector and Playbooks

Automated Detection and Response for Azure Firewall with the New Logic App Connector and Playbooks

 

Written in partnership with  (Program Manager, Azure Sentinel Product Team)

 

 

Introduction

 

In the current threat landscape, success of security operations depends on the ability to respond quickly to threats in the environment.  A key part of the agility needed to respond to the volume of threats detected by many systems, is automation in both detection and response processes.  To implement security monitoring, detection, and response at scale from a networking perspective, in addition to having visibility into the traffic traversing through your network devices and detection logic to identify malicious patterns in the network traffic, you also need automation to surface threats to SOCs/security analysts and allow them to take swift response/remediation actions to mitigate the threats.

 

Readers of this post will hopefully be familiar with both Azure Firewall which provides protection against network-based threats, and Azure Sentinel which provides SEIM (Security Information and Event Management) and SOAR (security orchestration, automation, and response) capabilities.  In this blog, we will discuss the new Azure Firewall Logic App Connector and Playbook Templates which provide deeper integration for Azure Firewall with Azure Sentinel.  With this integration, you can automate response to Azure Sentinel incidents which contains IP addresses (IP entity), in Azure Firewall.  The new Connector and Playbook templates allow security teams to get threat detection alerts directly in a Microsoft Teams Channel when one of the Playbooks attached to an Automation Rule triggers based on a Sentinel detection rule.  Security incident response teams can then triage, perform one click response and remediation in Azure Firewall to block or allow IP address sources and destinations based on these alerts. 

 

 

 

Scenario

 

In case of an attack or a compromise, a malicious adversary or malware may employ a variety of techniques to discover, infiltrate into and exfiltrate data from a target environment.  The traffic representing these malicious activities will flow in and out through the network ingress and egress points where it will be processed and logged, ideally by a firewall controlling internet access.  The data logged by firewalls processing internet egress traffic can be analyzed to detect traffic patterns suggesting/representing malicious activity.  Azure Sentinel provides many such in-built rules to detect malicious traffic patterns through Azure Firewall logs.    

 

The new Azure Firewall Connector and Playbooks can be added on to this workflow, whereby the Automation feature in Azure Sentinel can be used to trigger one of the Firewall Playbooks when an incident with an IP entity is created (by an Analytic rule-based detection), to take desired action.  When the Azure Sentinel detection rule criteria is met, the attached Playbook is triggered which sends an adaptive notification to a Teams Channel defined in the configuration.  The adaptive notification allows the SOC team to triage the notification and either act on the alert by blocking specific IP sources or destinations or to ignore the detection as false positive, as defined in the Playbook.

 

 

 

What’s New

 

Up until now, customers could create their own Logic App Connector for Azure Firewall and Playbooks.  We are excited to announce availability of the Custom Logic App Connector along with three new Playbooks Templates for Azure Firewall which can be used with Azure Sentinel Automation feature and Analytic Rules to take a variety of desired actions, in case of a detection.  The solution package contains four components:

 

  1. Azure Firewall Connector:  The connector allows you to take many different actions against Azure Firewall, Firewall Policy, and IP Groups.  A full list of actions supported by the connector is available here
  2. AzureFirewall-BlockIP-addToIPGroup:  This playbook allows you to block IP addresses in Azure Firewall by adding them to IP Groups based on analyst decision.  It allows you to make changes on IP Groups, which are attached to firewall rules, instead of making changes directly to the Azure Firewall.  The target IP Group could be associated with policy/rules used in one or more firewalls
  3. AzureFirewall-AddIPtoTIAllowList:  This playbook allows the SOC to automatically respond to Azure Sentinel incidents which includes a destination IP address, by adding the specific IP to the Threat Intelligence (TI) Allow list in Azure Firewall
  4. AzureFirewall-BlockIP-addNewRule:  This playbook allows you to block an IP address by adding a new network rule with the specific IP to an existing Deny Network Rule Collection in Azure Firewall

 

All three playbooks add VirusTotal enrichment and send adaptive notification to the specified Teams Channel.  Whether you’re using Azure Firewall Standard with Classic Rules, Firewall Manager Standard Policies or Firewall Premium with Firewall manager Premium Policies, the different playbook templates provide coverage for these different configuration scenarios. 

 

The table below summarizes playbook support for the Firewall Standard and Premium policy types:

 

Playbook Name

Premium Policy

Standard Policy

Classic Rules

AzureFirewall-BlockIP-addToIPGroup

Yes

Yes

Yes

AzureFirewall-AddIPtoTIAllowList

No

Yes

No

AzureFirewall-BlockIP-addNewRule

No

No

Yes

 

 

 

How Azure Firewall Logic App Connector and Playbooks Work

 

The steps below provide an overview of the end-to-end Playbook and Connector workflow:

 

  1. A new Azure Sentinel incident is created with an IP entity which triggers one of the three playbooks attached to the Automation Rule
  2. An adaptive card is sent to the SOC Teams channel providing IP address, VirusTotal report, showing list of existing firewalls in the Resource group and depending on the playbook in use, providing an option to add the specific source or destination IP address to an IP Group, TI Allow List, a new rule to be added to an existing Deny Network Rule Collection.  The analyst can also choose to either close the incident using one of the classifications provided in the adaptive card, change the incident severity or to completely ignore the incident

    Teams Adaptive Notification CardTeams Adaptive Notification Card

  3. If the SOC analyst decides to act on the incident by clicking the action button depending on the playbook in use (Add this IP Address to the IP Group, Add IP address to threat intel allow list or Add IP address to Network Rules Collection buttons), the Firewall Connector uses the Service Principal to authenticate against and make changes to the respective targets; IP Group, Threat Intel Allow List, or the Network Rule Collection.  Additionally, incident gets updated with endpoint information, summary of the action taken and virus total scan report
  4. If ignored, the incident gets updated with endpoint information and summary of the action taken

 

All three playbooks work in a similar fashion, the only difference being the action performed by the specific playbook.  To learn more about the end to end workflow of each workbook, please visit the Azure Sentinel GitHub repo page for Azure Firewall here.  You can click on the Connector and Playbook links to get more details.

 

 

 

What Customizations Can be Done

 

You can also customize the playbook templates to your preference.  Existing playbook logic can be modified or removed, and new logic can be added to the playbooks to meet your specific requirements.  Below are a couple of examples of the customization that can be made:

 

  1. You can replace the VirusTotal TI with your own custom TI provider
  2. You can remove the Teams notification steps in the playbook to remove any human decision/intervention and allow a playbook to make changes directly in the Firewall

 

It is important to note that the playbook templates and examples above are merely a source of reference and inspiration.  While you can choose to use the available playbook templates as is, you can also customize them heavily to the extent needed.

 

 

 

How to Deploy

 

The Azure Firewall Logic App Connector and Playbooks can be deployed directly from the Azure Sentinel GitHub repo page by clicking the Deploy to Azure button.

 

  • Notes:
    1. The Azure Firewall Logic App Connector and Playbooks are also available in the Azure Firewall Solution for Azure Sentinel
    2. The Azure Firewall Solution for Azure Sentinel is available and can be deployed from the Azure Marketplace (search for “Azure Firewall Solution”) or from the Solution (Preview) gallery in Azure Sentinel
    3. The Azure Sentinel Solution gallery is currently in preview and available via the Azure Sentinel blade in the left pane under the Configuration node

 

In this post, we will discuss how to deploy from the Azure Sentinel GitHub repo.  We will discuss the Azure Firewall Solution for Azure Sentinel in a separate post.

 

Please review the deployment prerequisites (pre-deployment configuration) and the post-deployment steps below to successfully deploy, configure, and start using the automation.

 

 

Deployment Prerequisites

 

You must have an existing Azure Firewall Standard or Azure Firewall Premium, Firewall Policy and IP Group deployed in the environment.  The following dependencies should be understood, and prerequisites must be completed before you begin deploying the Firewall Connector and Playbooks.  You should have the required permissions to make these changes.

 

  1. The Firewall Connector uses an Azure AD application and service principal to authenticate and make changes to the Firewall, Firewall Policy, and IP Group configuration when a Playbook is triggered.  To enable this, you must complete the following steps 
    1. Register an application with Azure AD and create a Service Principal using these instructions Create an Azure AD app & service principal in the portal
      • You will use this application credential when deploying the Firewall Connector and Playbooks.  To retrieve it, go to the Azure Active Directory --> App registrations blade and find the following
        • Tenant Id (Directory ID in Overview blade)
        • Client ID (Application ID in Overview blade)
        • Client secret (Client secret Value in Certificates & secrets blade)Get AAD SecretGet AAD Secret
    2. Assign the Azure AD application and service principal “Contributor” permission to the Azure Firewall, Firewall Policy, and IP Groups.  Use the IAM panel of these resources to assign the permission
      • For each Firewall, Firewall Policy, and IP Group resource that you want to be updated when a Playbook is triggered
        1. Go to Settings à Access control (IAM)
        2. Click Add and then click Add role assignment
        3. Select Contributor role
        4. Search for the name of your Azure AD application and service principal created in the previous step (1a), select it, and then click Save
          • Note: By default, Azure AD applications aren't displayed in the available options. To find your application, search for the name and select it

 

  1. When a Playbook is triggered, it first posts an adaptive notification action card to the Teams Channel you specify in the configuration.  This allows the SOC analyst to take desired action directly from Teams using the options available in the adaptive card.  To enable this, you must complete the following steps
    1. Create a Team and a Channel in Microsoft Teams (if it does not exist)
    2. You will need the Teams and Channel id when deploying Firewall Connector and Playbooks.  To obtain Teams id and Channel id, please follow the below instructions
      • Copy the URL of the Teams Channel where you would like to get Playbook notifications
      • Click on the ellipses next to the Teams Channel and click Get link to the channel

Get Teams URLGet Teams URL

      • The URL will be in the following format - https://teams.microsoft.com/l/channel/10%3a3xxxxx3302eaxxxxx790xxxxxx21xx78%40thread.skype/General?groupId=axxx61xx-2xx8-xx45-a0xx-53xx476xxx0x&tenantId=1xxxx7xx-1xxb-3xx9-xx8b-87xxxxx1xx60
        • The Teams Group id is in the groupId= parameter in the URL
          • From above example, Teams Group id: axxx61xx-2xx8-xx45-a0xx-53xx476xxx0x
        • The Teams Channel id is in the URI after /channel/ in the URL.  You will need to replace the parts marked in blue, in the URL with " : " and " @ " to get a valid Channel id
          •  From above example, Teams Channel id: 10:3xxxxx3302eaxxxxx790xxxxxx21xx78@thread.skype
            • Notes:
              1. You can also skip the Teams Group id and Teams Channel id during the initial deployment by adding N/A to the fields and configure them directly in all three playbooks using the drop-down menu after deploying and authorizing the Teams APIs successfully (see post deployment steps for more details on authorizing the APIs)
              2. You can also get Teams Channel id using the Microsoft Teams PowerShell module with these instructions Get-TeamChannel

 

  1. The Playbooks leverage VirusTotal service for notification enrichment with IP details and reputation.  To use this VirusTotal capabilities, you will need to generate a VirusTotal API key 
    1. Create a VirusTotal API key using this link how to generate the API Key
    2. You will use the API key to authorize the VirusTotal APIs in the post deployment steps below

 

 

Deploying the Firewall Connector and Playbooks

 

After completing the deployment prerequisites, you are now ready to deploy the Firewall Connector and Playbooks.  To deploy, please use the following instructions

 

  1. Browse over to the Azure Sentinel GitHub repo page and click the Deploy to Azure button
  2. In the Custom deployment page, select the Subscription and Resource Group where you want to deploy the components
  3. Add the Teams; Group id and Channel id along with Service Principal; Client id and Client Secret
    • Note: You can also skip the Teams Group id and Teams Channel id during the initial deployment by adding N/A (or some other text) to the fields and configure them directly in all three playbooks using the drop-down menu after deploying and authorizing the Teams APIs successfully (see post deployment steps for more details on authorizing the APIs)
  4. Click Review + Create button and then click the Create button on next page to start deployment

 

Deploying Firewall Connector and PlaybooksDeploying Firewall Connector and Playbooks

 

 

Post Deployment Configuration and Validation

 

After the deployment of Firewall Connector and Playbooks is complete, you should see a total of sixteen new resources in the target Resource Group.  The new resources will include a Logic App Connector for Firewall, three Logic App Playbooks, and twelve API connections (three APIs each for OAuth, VirusTotal, Azure Sentinel, and Teams).  Please follow the below steps before the Playbooks can be used.

 

  1. Authorize API Connections:  All APIs for the solution must be authorized before the connector and playbooks can be used.  Please complete the following steps to authorize the APIs:
    1. Click an API to open the API Connection settings page
    2. Click the Edit API Connection node in the left pane
    3. Click the Authorize button in the blade, sign-in and Save to authorize the API
    4. Repeat steps a, b & c for all twelve APIs in the same manner, one at a time
      1. For authorizing the three Virus Total APIs, you will need to add API key in the x-api_key and click Save
      2. For authorizing the three Teams APIs, you will need to sign-on with the same identity you use to logon to Teams

 

  1. Validate/update playbook configuration:  Validate or optionally update the playbook configuration to ensure that all components are setup correctly and ready to be used.  Please complete the following steps to validate/update configuration of the playbooks:
    1. Click on one of the playbooks to open Settings
    2. Click on the Logic app designer in the Development tools node
    3. Check to ensure that all steps are showing up without the exclamation icon which indicates an issue with the configuration

Playbook Validation - errorPlaybook Validation - error

    1.  
       
      Optionally, if you had skipped adding the Teams Group and Channel ids during initial deployment by adding N/A (or some other text) to the fields, you can configure it now by opening Teams Connections under the For each Malicious IP Address Entity present in the Incident step and then selecting the appropriate Teams Group and Channel using the drop-down selection

Playbook Validation - Configure Teams SettingsPlaybook Validation - Configure Teams Settings

 

  1. Configure playbook permissions:  In order to allow Azure Sentinel to run Firewall playbooks based on a detection rule, you must give Azure Sentinel permission to run them.  Please complete the following steps to add permissions:
    1. Open the Azure Sentinel blade and click Automation under the Configuration node
    2. Click on Configure permissions button under Give Sentinel permissions to run playbooks
    3. In the Manage permissions blade, search for, and then click to select the resource group which contains the firewall playbooks
    4. After selecting the appropriate resource group, click Apply

 

Congratulations!  You are now ready to use the Azure Firewall playbooks with Azure Sentinel rules.

 

 

 

Playbooks in Action

 

To see how the playbooks and the connector work together, please use the following instructions:

 

  1. Open the Azure Sentinel blade and click Analytics under the Configuration node
  2. Click on Rule templates tab and filter Data Sources to Azure Firewall.  This will show all the built-in Analytic Rule templates for Azure Firewall
  3. Select one of the rules and create an Analytic Rule for Azure Firewall
    • Alternately, you could also use a custom rule that you have created for testing
      • Note: The Analytic Rule must be one which generates alerts/creates incidents with an IP address (IP entity)
  1. Once the rule is created and active, click on the Automation node
  2. In the Automation blade, click Create à Add new rule
  3. In the Create new automation rule blade, provide a name for your automation rule
  4. Observe that the Trigger is preset to When incident is created
  5. Under Conditions, select If Analytic rule name Contains <name of the rule you created in step 3>
  6. Under Actions, select Run Playbook and then select one of the Firewall playbooks you have deployed
  7. Add Rule expiration date or time (default is indefinite) and value for Order (in which rule should be processed)
  8. Click Apply to enable the rule

 

Creating Sentinel Analytic and Automation RulesCreating Sentinel Analytic and Automation Rules

 

Now that the Automation rule has been created and is enabled, when the condition defined in the Analytic Rule is met, Azure Sentinel will trigger the playbook attached to the Automation rule.  This will send you an adaptive notification card in the Team Channel you have specified in the configuration.  You can then click on the different options available in the Teams adaptive card to make changes to the target IP Groups, TI allow list or the Network Rule Collections.

 

For testing the playbook workflow, you could create a custom Analytic Rule and then generate the traffic to trigger the playbooks.

 

 

 

Summary

 

Azure Firewall logs can help identify patterns of malicious activity in your network.  Azure Firewall Connector and Playbook templates can help expedite SOC triage with Teams notification and rapid mitigation with on-click response/remediation in case of threat detections.  We encourage all customers to utilize these new automation capabilities to help improve your overall security posture.

 

You can also contribute new connectors, playbooks, detections, workbooks, analytics and more for Azure Firewall in Azure Sentinel. Get started now by joining the Azure Network Security plus Azure Sentinel Threat Hunters communities on GitHub and following the guidance.

 

 

 

Additional Resources

 

 

 

Published on:

Learn more
Azure Network Security Blog articles
Azure Network Security Blog articles

Azure Network Security Blog articles

Share post:

Related posts

Announcing the General Availability of Managed DevOps Pools (MDP) for Azure DevOps

We are thrilled to announce that Managed DevOps Pools for Azure DevOps is now generally available! This milestone marks a significant advancem...

9 hours ago

Azure Developer CLI (azd) – November 2024

This post announces the November release of the Azure Developer CLI (`azd`). The post Azure Developer CLI (azd) – November 2024 appeared...

4 days ago

Microsoft Purview | Information Protection: Auto-labeling for Microsoft Azure Storage and Azure SQL

Microsoft Purview | Information Protection will soon offer Auto-labeling for Microsoft Azure Storage and Azure SQL, providing automatic l...

4 days ago

5 Proven Benefits of Moving Legacy Platforms to Azure Databricks

With evolving data demands, many organizations are finding that legacy platforms like Teradata, Hadoop, and Exadata no longer meet their needs...

6 days ago

November Patches for Azure DevOps Server

Today we are releasing patches that impact our self-hosted product, Azure DevOps Server. We strongly encourage and recommend that all customer...

6 days ago

Elevate Your Skills with Azure Cosmos DB: Must-Attend Sessions at Ignite 2024

Calling all Azure Cosmos DB enthusiasts: Join us at Microsoft Ignite 2024 to learn all about how we’re empowering the next wave of AI innovati...

6 days ago

Getting Started with Bicep: Simplifying Infrastructure as Code on Azure

Bicep is an Infrastructure as Code (IaC) language that allows you to declaratively define Azure resources, enabling automated and repeatable d...

7 days ago
Stay up to date with latest Microsoft Dynamics 365 and Power Platform news!
* Yes, I agree to the privacy policy