Read Azure Sentinel Playbooks Like A Pro
Understand Azure Sentinel automation by breaking it down into parts.
When an Azure user opens a logic app like Azure Sentinel Playbooks for the first time it may be intimidating seeing large chains of branched boxes with esoteric symbols. Fortunately, if the user understands what the primary types of action pieces do, they should be able to figure out what the automation does without issue.
In this blog, we show how an Azure user can go through a logic app like a playbook and determine what it does based on its components. Once they understand how the components work, they will be able to come up with ideas about how to make their own automations.
The trigger piece is always the first piece that starts the automation. In the logic app designer menu, use the top search bar to find a trigger type piece. Sentinel commonly uses a trigger that is a response to an alert (run manually by analysts) or a trigger that responds to an incident (automatically run in response to an incident).
Sentinel Action Pieces
The first set of action pieces playbook users will need to know about are Sentinel action pieces because they allow the automation to make Sentinel-specific changes. Some common tasks that Sentinel action pieces do include gathering information about an incident, leaving comments, and updating information about incidents.
Application Action Pieces
Since playbooks are built on Azure Logic Apps, there are hundreds of other action pieces that playbook users could potentially use. These pieces can include taking actions with Office apps, Azure resources, or third-party applications that are compatible with Azure Logic Apps.
Control Action Pieces
The control action pieces behave like conventional programming statements that control how a program behaves. These can include logical operations like condition statements, for each statements, and switching based on conditions set by the playbook creator.
If a playbook user does not have a variable that they would like to use available in their current data, they can initialize their own variable. If they want to edit a variable, they can use one of the variable operations like appending or incrementing action pieces.
If a playbook creator needs to take data and transform it into a different form of that data, they can use data operations. Some common uses for data operations include getting data out of (parsing) JSON files and turning existing data into tables.
We will continue to share best practices and lessons learned in future posts on creating playbook automations. CyberMSI is constantly coming out with new playbook automations to help with making security operations more effective and efficient.
In closing, consider these three questions when using playbooks in your organization:
- Should we activate our automations manually or automatically in response to an incident?
- What aspects of our organization’s security can we enhance by using playbook automations?
- What skills do we need to develop for producing security automations in Azure?