Playbooks & Watchlists Part 2: Automate incident response for Deny-list/Allow-list

Great Thanks to @Julian Gonzalez  for working together on the playbooks templates!

In the previous article, Playbooks & Watchlists Part 1: Inform the subscription owner I have presented one scenario of using Watchlists in Playbooks. I also presented some best practices: how to query a watchlist using Azure Monitor Logs connector, and also how to use the output data.

In this blogpost I’ll present another interesting use case and some new ways to work with the Watchlists data.

Allow-listing is a strategy for allowing certain identities or sources to access sensitive resources or to exclude them from security protections. An example for such scenario can be a set of IP addresses which might trigger new alerts, but known to the SOC as coming from approved sources. In a case where a new alert consists only approved IPs as its entities, we might want to save the analysts time and auto close the incident.

Of course, more steps and actions can be taken and added to this playbook for other steps taken in this case by the SOC. Also, the same practice can be adopted for Deny-list scenarios.

Quick access to the playbook in Azure Sentinel Github repository

This blogpost includes:

• Solution summary
• Prerequisites
• Playbook steps explained
• Setup instructions
  • Create and upload your watchlist
  • ARM Template deployment
  • Playbook configurations
  • Set automated response
• Documentation reference

Solution summary

• An Azure Sentinel Watchlist lists all approved IP addresses.
• Watchlist-CloseIncidentKnownIPs Playbook is attached to an analytic rule that attaches IPs to the outcome alerts.
• Everytime a new alert of this analytic rule is created, the playbook is triggered, receiving the alert with the contained alerts as an input.
• For each IP entity in this alert, the playbook queries the Watchlist includes it.
  • In case the IP is in the Watchlist, it will be added to “Safe IPs” array.
  • Else, it will be added to “Not Safe IPs” array.
• A informative HTML comment will be written to the incident that contains this alert, to inform about the IPs in each category.
• If all IPs were found safe, the incident will be closed with Benign Positive classification reason.

Prerequisites

A user or registered application with Azure Sentinel Contributor role to be used with the Azure Sentinel connector to Logic Apps.

Playbook steps explained

When a response to an Azure Sentinel alert is triggered

Azure Sentinel alert was created. The playbook receives the alert as the input.

Initialize variables

This actions stores values to be used later in the playbook:

• Watchlist name is a variable of type string, will be used for the Log Analytics query
• Safe/not safe IPs are variables of type array, will be used to store the found IPs

Entities – Get IPs

This action takes all the entities found in the alert and parses only the IPs with their special fields ready to be used as dynamic values in later actions.

For Each IP

Iterates on the IPs found in this alert and performs the following:

• Run query and list results – Get Watchlist
  In this step we ask Log Analytics (Azure Monitor Logs connector) to get the items of the Watchlist. Subscription, Resource Group and Resource Name are the Azure Sentinel workspace details where the watchlist is located.
  I used the following query:
  _GetWatchlist(@{variables(‘WatchlistName’)})
  | extend IpAddress = tostring(parse_json(WatchlistItem).IpAddress)
  | where IpAddress == ”@{items(‘For_each’)?[‘Address’]}”
  
• Condition
  In this step I check the length of the response array from the query, using the Logic apps expression length(collection). If it is greater then 0, we have found the IP in the watchlist.
  Therefor, we will add this IP to the Safe array; otherwise, to the not safe.

Add a comment to the incident
In this step we audit the information collected so far: a list of safe IPs found in the Watchlist, a side to a list of unknown IPs.

Condition

Finally, we want to check if there is any IP which found as not safe. This step checks if our “not safe” array is empty. If so, we will close the incident.

Change Incident Status
Closes the incident with Benign Positive classification reason.

Setup instructions

Create and Upload your watchlist

1. Create your input CSV table
   In this use case I have created a simple table, where each row represents an ip address.
   I created the table using Office 365 Excel, and then saved it as a CSV file (save as).
2. Upload your table
   
   1. In Azure Sentinel, go to Watchlists.
      
   2. Click on Add new

1. Fill in the required details.
   Note that the Alias will be used to query this watchlist in the playbook query step.
2. Add the CSV file
3. Review and create.

Playbook deployment instructions

1. Open the link to the playbook.  Scroll down on the page and Click on “Deploy to Azure” or “Deploy to Azure Gov” button depending on your need.
2. Fill the parameters:
   1. Basics
      Fill the subscription, resource group and location Sentinel workspace is under.
   2. Settings
      1. Playbook name – this is how you’ll find the playbook in your subscription
      2. User name (will affect the names of the API connections resources)
   3. Check the terms and conditions and click purchase.
   4. The ARM template, contains the Logic App workflow (playbook) and API connections is now deploying to Azure. When finished, you will be taken to the Azure ARM Template summary page.
   5. Click on the Logic Apps name. you will be taken to the Logic Apps resource of this playbook.

Confirm API connections

On the left menu, click on API connections.
For each product being used in this playbook, click on the connection name – in our case, it is only the Azure Sentinel connection.
Click on Authorize to log in with your user, and don’t forget to save.

Documentation Reference

• Azure Sentinel Logic Apps connector