Essential Azure Sentinel Automations
Boost productivity by automating routine tasks.
One of the ways that Azure Sentinel is attempting to differentiate itself from the competition is by integrating the automation tools available in Azure. A Security Operations Center (SOC) can use a combination of Azure Logic Apps, Azure Runbooks, and Azure DevOps to automate many of the incident management tasks that its cybersecurity analysts perform daily.
Azure Sentinel has a built-in automation system called “Playbooks” that uses Azure Logic Apps to run tasks automatically. These Playbooks can use any of the 100s of action pieces available in Azure Logic Apps in any order. All those actions can be taken in response to an incident or they can be activated manually when a security analyst believes it is necessary.
In this blog, we show some of the automations that we have found the most useful when managing incidents in customer environments. We will also go over important details like what the prerequisites for using them are and when these automations should be used during the incident management lifecycle.
Create a Ticket
Microsoft wanted to make sure that there was a way to integrate Azure Sentinel with common ticketing systems. At the time of writing there are 5 popular ticketing system playbook automations available on the official Sentinel GitHub Playbooks section that SOCs can use. When the playbook triggers, it makes an API call using a user account’s permissions to generate a ticket in the ticketing system. The playbook can take variables from Sentinel and add those details to the ticket so that the information about the incident will be pre-populated in the ticket. This automation requires a service principal with Sentinel Reader permissions and a service connection. This Playbook should be used as an automatic response to a Sentinel incident being generated.
Isolate VM to an NSG
Isolating a device is one of the primary incident response actions that can happen after an incident is confirmed to be a true positive. This automation creates a new Network Security Group (NSG) and adds all affected VMs to that isolated NSG after getting approval. When this playbook triggers, it uses a series of variables, HTTP communications with Azure resources, and “for each” loops to isolate each of the VMs involved with an incident to an isolated NSG. This automation requires a service principal with Sentinel Reader, Network Contributor, and VM Contributor roles. This automation can be run manually with the approval of the systems administrators responsible for the VMs.
Take AAD User Account Actions
Taking actions on user accounts is another common incident response used after confirming an incident is a true positive. The following is a list of publicly available automations that can be implemented using Azure Sentinel playbooks.
1. Reset an AAD User’s Password
2. Revoke an AAD User’s Session
3. Block an AAD User Account
This automation is sensitive because the AAD action piece requires a connection with permissions to automatically make these changes to AAD user accounts. It is up to each organization to decide if they believe having the automation available is worth the risk of having a service principal with these permissions or having an account with those permissions associated with the service principal.
Azure DevOps for Sentinel
There is a continuous integration and continuous deployment (CI/CD) system available for Sentinel that allows analysts to deploy Sentinel features automatically to multiple tenants. In this Microsoft Tech Community Article, a Microsoft security engineer talks about how the deployment system works. Azure Sentinel features like analytic rules, hunting queries, Workbooks, and Playbooks can all be deployed automatically with DevOps. CyberMSI uses this automation to deploy new Azure Sentinel features to customer environments automatically and continuously.
We will continue to share best practices and lessons learned in future posts on using automations in customer environments. Automations may seem complicated, but they are worth the extra effort to automate mundane tasks that would take significantly more effort in the long run.
In closing, consider these three questions when using the Azure Sentinel automations in your organization:
- What repetitive, manual tasks can we automate to become more efficient and accurate in our incident management?
- Do we have anyone with programming experience on staff that could help us build automations?
- What potential business or operational issues will we have if we automate specific incident management activities?