Working with Playbooks
Select .
A playbook defines the automation and orchestration capability. After a case is dispatched, playbook performs the response procedure. The system can execute a fully automated playbook as well as a semi-automated playbook.
A completely automated playbook does not require any decision making from the agents. A semi-automatic model requires agent intervention for decision making or providing some extra information to the automation. So during a semi-automation procedure, SOAR handles the case resolution automatically till some point and then the control is passed to agents for decision making task and again after the decision is made, the control is handled by automation. If needed, SOAR automation can again assign the task to agent for some decision making or extra information requirement. So basically, SOAR performs orchestration and then finally makes a Response.
You can specify the execution priority of playbooks by setting the Rank values for each playbook, the smaller the rank, the higher is the priority.
Playbooks are processed from top to bottom and when a case matches, all of the playbooks with matching conditions are executed.
While designing any playbook, you must set conditions to ensure if multiple playbooks can run on the same case or not. As the playbooks running on the same case are not aware of each other, they must be designed independently such that one playbook does not interfere with another. If possible, it is recommended that a case matches with only one playbook.
Searching a Playbook
You can search a specific Playbook, through the Search option. Click the 
button next to search, to view search results based on the following attributes:
-
ID
-
Scenario Name
-
Type
-
Last Modified by
-
Modification Date
-
Rank
-
Actions
-
Disabled
Creating an Advanced Playbook
The Advanced Playbook allows you to write your own playbook scripts.
-
Click button.
-
In the Advanced Playbook Editor window, specify the details for following fields:
Value
Description
Name
Display name of the playbook.
Matching Mode
All Conditions means playbook will be executed if all the conditions are true. Any Conditions means playbook will be executed if any of the conditions is true.
Rollback Mode
Set if the action will be permanent or will be rolled back after a period of time.
case auto-close
From the combo box, you can select in which conditions the playbook will close the cases.
Conditions
Click to add a condition to this playbook. You can define multiple conditions.
- In the black console area, you can write your playbook scripts in Python programming language.
- To test your playbook, use the option:
- Select a defined alert source from the combo box.
- For , enter a value to test your script.
The option can be any parameter depending on your script, such as IP or email address.
- Click .
Your test result is displayed on the same console.
Creating Workflow Playbook
Workflow Playbooks run automatically and follows the visual process definition. You can specify the a name to the playbook in .
While creating a Workflow Playbook, you can drag and drop elements from the right side of the page. You must enter appropriate and valid values depending on the element in the tab. Each element must be connected to another except the last one.
When a case is created, a playbook with matching condition is executed. The match conditions of the Workflow Playbook are defined in the element of the playbook.
Executing Workflow Playbooks
Workflow Playbooks are run automatically when:
-
A new case is created: cases are created by the Alert Rule Name Filter configuration.
-
A new alert is received: Alerts are added to the cases by the Consolidation rules.
-
Rules of the case is updated: Some alert sources update an existing alert for example, QRadar Offences and these can trigger an execution.
Workflow Playbook Elements
To create a visual process definition, you must map the executable instructions through the predefined workflow playbook elements. You can drag and drop following elements to create the workflow:
-
Automation Bit Usage: Automation Bits are custom code created by the users to execute custom business logic. A detailed explanation for Automation Bit’s can be found in Automation Bit section of this guide. While using bits, scope will be supplied from the Start from here element if Scope Filter variable is not used.
-
Actions Usage: There are two kinds of actions:
-
Actions coming from the SOAR itself, and these actions act on cases to change it appropriately, for example, Status, Severity.
-
The action capabilities coming from integrations. There are different capabilities depending on the target device and all of them takes some input regarding their role in the workflow.
Action elements are named as <Integration Name> - <Capability Name>. For example, Active Directory - Lock User.
Actions usage have several standard properties including:
Properties Descriptions Title Visible name of the element in the visual editor. Continue on Error In some cases an action on a device can return an error for example, network problems. In such cases , SOAR will stop the execution of the workflow entirely. If this option is selected, SOAR will continue execution even if the action has failed. Rollback Mode SOAR can undo the action after a set time if needed. In many devices there are limits to how many items can be blocked and most of these artifacts usefulness drops over time. Rollback future gives the SOAR users a way to control their actions and the health of the target device.
Scope Filter The scope filter name can be changed from capability to capability but in essence filter will define which scope items from the alert will be included in the execution.
Some actions also have other fields and these are populated from data that resides on the target device. Such as tag’s or group names.
Actions are synchronous Therefore when a workflow processes an action element, it queues this action and after successful queueing of this action workflow will resume processing the next element. This means in an ideal SOAR, processing actions will not create a performance issue for the workflow execution. There however some edge cases that when SOAR is under heavy load or an unexpected error is present, actions might be queued but different elements are executed before these actions are finished.
-
-
Enrichment: Enrichments are data gathering capabilities that will assist in case response procedures and decision making.
Enrichments have several standard properties including:
Properties Descriptions Title Visible name of the element in the visual editor. Continue on Error In some cases an enrichment on a device can return an error e.g network problems. In such cases SOAR will stop the execution of the workflow entirely. If this option is selected SOAR will continue execution even if the enrichment is failed. Integration On which integration this capability will be executed.
Scope Filter This part’s name can be changed from capability to capability but in essence filter will define which scope items from the alert will be included in the execution.
Do not use cache When a workflow processes an action element, it queues this action. After successful queueing workflow resumes processing the next element. This means in an ideal SOAR, processing actions does not create a performance issue for the workflow execution. However some when SOAR is under heavy load or an unexpected error is present, actions might be queued but different elements are executed before these actions are finished. Enrichments are synchronous When executed they will start immediately and hold the workflow execution on this state until a result is returned. It is important to note that not every enrichment works as fast as you expect and in some cases rate limits might apply affecting the execution time of the overall workflow. Some enrichments execute and then wait for the process to be completed in the target device. These are also called asynchronous for their update part but for workflow execution they are treated as synchronous as well and will stop the execution until the response is returned.
-
Tasks: Tasks are elements that does not have an automatic component. These elements are dependent on SOC analysts for completion. Task properties are dependant on the configuration of the task. So one or more of these properties might not appear in Properties tab..
Tasks have several standard properties including:
Properties Descriptions Title Visible name of the element in the visual editor. Scope Filter The name can be changed from task to task but in essence filter will define which scope items from the alert will be included in the execution. Filters can occur more than once and they are restricted to the Scope Item Type defined for them. So a Network Address type filter only works on Network Address type scope items. Timeout Span It is when the task is due, it will be defined by this property. Task will be timed out when it is due and execution will continue. If left empty, this value will be taken from the Configuration Parameter WorkflowTimeout as a global value. -
Analyst's Decision: This is the logic element and provides true/false options to the analyst.
Analyst's decision have several standard properties including:
Properties Descriptions Title Visible name of the element in the visual editor. Description Description of the decision.
Timeout span This property is defined when the task will be due. When the task is due will be defined by this property. Task will be timed out when it is due and execution will continue. If left empty, this value will be taken from the Configuration Parameter WorkflowTimeout as a global value. Send Additional Email for Approva When this is checked, SOAR will send an additional email for out of SOAR interaction to the selected Analyst. Analyst Recipient of the approval Email. -
Utilities: There are three types of utility elements:
-
Notification:This element supports sending notifications to different users.
Notifications can be sent from different channels and currently on-screen, SMS, email and windows type messages are supported. Notifications use free-form subject and a pre-defined template for the message.
-
Decision: Decision are standard logic element of the workflow. For a given predicate group in the property section, SOAR checks the alert scope and the workflow scope. If both of the scopes match, the automation returns a true value and the playbook is executed.
The alert scope is defined at the Start from here element and workflow scope is the enrichment data that is specific to the workflow execution gathered till this point.
-
User Decision: User decisions are true/false type checkpoints and they are sent to a recipient for gathering inputs.
The difference in the Task Decision and User Decisions can be explained as, the user decision sends the decision message to a variety of recipients. It can send the notification to a free-text e-mail address, to a user, or to an the case scope.
User decision takes a template to form the message and expects the recipient to reply with an APPROVE or DENY option. You can create more than one template to send different set of data and messages to the relevant recipients. You can find the User Decision Notification Email Template as a built-in template in the Customization Library.
You can also define scope restricted parameters that can be filled on the fly.
Using a scope restricted parameter in the e-mail subject shows only the first item in the parameter. Rest of the items are appended in the body of the message. The decision must appear in the body of the reply message.
-
Types of Connectors in the Workflow Playbook
Every element in workflow has a pre-defined connector type. There can be one, two or three output connectors.
-
Single connector: All actions and most other types of elements, fall into this category and after the element executes workflow continue to the next element.
-
Double connector: Elements that contain a timeout falls into this category. First connector will lead to a successful completion of the element within the given time, these are named then and second connector will lead to timeout.
-
Triple connector: User and Analyst Decision falls into this category. First two connectors will lead to true and false respectively in a successful execution and third connector will lead to timeout.
Importing and Exporting a Workflow
You can import a pre-designed workflow by clicking the Import Workflow tab. In Workflow Import Editor window, navigate to the template file, add a suitable name for the template and then click Save to import a a workflow.
To export a workflow playbook, click Export option under the Actions tab.
Editing Rank of a Playbook
You can define the order of execution for different playbooks by assigning a rank to it. Click Edit Rank option under the Actions tab and then modify the rank of the playbook in the respective Rank column.
Editing and Deleting a Playbook
To edit the previously created playbooks click Edit option under the Actions tab. In the Workflow Playbook Editor window, modify the visual process flow to suit you requirements.
To remove a playbook from the automation, click Delete option under the Actions tab.