Playbooks

Overview

Our new Playbooks feature helps security analysts automate common incident response tasks, and also guide them in their incident response workflow. Using Playbooks, analysts can define custom flows for selected events. When new events are recorded, the playbook engine checks for matches and executes predefined activities. A Playbook can be created in the workspace side-panel and partner menus. Once created, these can be stored in a user-defined order. This feature is available in the Emsisoft Enterprise Security +EDR plan.

How does it work?

The main idea of playbooks is to be able to overwrite the built-in default processing flows with customized sequences. Once an incident is created, it attempts to match the incident against the Playbook triggers sequentially until a match is found. It will then execute the pre-defined activities designed within that playbook, until it reaches its defined end (complete remediation).

Together with the general description, we have listed here the essential elements that define this feature, with its intended use, functionalities and caveat. We recommend familiarizing yourself with these elements before deep-diving into its use.

Create, edit and share Playbooks

A Playbook can be created in the workspace side-panel and partner menus. Once created, these can be stored in a user-defined order.

They are inherently bound to the threat type that they’re designed for, with different features being available based on the type (file, host, or payload based).

Partners and workspace members can edit their own playbooks, any other user can enable, disable, or clone the playbooks that Emsisoft or our Partners made available to them.
When a playbook is cloned, it is detached from the original playbook and any future updates made in the original will not be reflected on the cloned version.

By default, the Partners’ defined Playbooks are not visible to the user. This is to provide the ability to protect partner intellectual property where needed. Based on their needs, a Partner can make a Playbook Visible, or Cloneable to their relative workspaces.

Security analysts can manually select and (re-)run any playbooks for incidents, even if another playbook was assigned before. This allows testing a newly created or updated playbook for a specific threat, when necessary. Please note that each incident can only have one playbook running at a time to avoid conflicting or loop actions.
Also, to avoid potentially endless execution loops, the nested playbooks cannot invoke playbooks that they have been invoked by.

Execution

Once an incident is created it will try and match the incident against the Playbook triggers one by one, until a match is found. It will first look at the Partner-specific Playbooks and then the ones that are specific to that workspace.
This allows creating a match even before the Emsisoft’s default ones.

Only the first matching playbook executes for each incident, all following playbooks are ignored, for this reason we recommend to sort the playbooks from the most detail-specific to the most generic. Incidents keep records of which playbook has automatically matched or manually been assigned, and the current step or breakpoint within the playbook.

Playbooks run until they meet one of these conditions:

• Reach one of the defined ends (i.e. remediation complete).
• Reach a manual-action breakpoint that requires a human action to proceed (i.e. False Positive confirmation, custom remediation action, etc.).
• Reach an invalid element in a playbook. Execution is paused similarly to manual-action breakpoints. UI signals the error in red and the user can jump to the error element to fix it.
• Invoke a nested playbook: The current playbook is paused until the nested playbook finishes.

Elements and their functionalities

The Playbook panel displays the following Elements on the left side:

• Custom note
• Alert
• Incident update
• Manual action
• Remediation
• Notification
• Condition
• Policy update
• Delay
• Threat intelligence source

You will also find the Debugger button in the top-right corner of the Playbook window.
Each of the Elements panels can be drag-and-dropped on the Playbook window, so it can be arranged and linked with the others. By double-clicking on any of the Elements placed, it will display a series of common fields, that you can modify to better match your needs.

• Name field: to label the element placed on the board, to easily recognize it;
• Description field: to provide an in-depth explanation of its purpose
• Enabled: Allows disabling the Element without removing it from the Playbook flow;
• Skip on test: useful to isolate certain elements while testing your own Playbook;
• Error action menu: to specify if the element should pause the flow or simply be skipped leaving the rest of the Playbook run.
• Save button: to save the changes to that element.

Once placed on the board, each element can be clicked on to reveal also the Remove and the Connect button. The Remove button (displayed as “X“) sits at the top right corner of the Element. You can click on it to delete the Element (and its defined settings) from the board. On the right side of the Element, you will also find the Connect button (displayed as “>“). You can drag the connect arrow to link one Element to another, in your desired order of execution.

Let’s see in detail the functionality of each element in order to build your own automation.

Custom note

Whenever you want to leave a note on the Playbook board, you can simply drag and drop a custom note element on the board. Double click to apply your comments in the description field.
It is particularly useful to better organize and document the playbook.

Alert

This Element is used to add a new custom alert to an incident.
It allows you to define a name for the threat, as well as assign a different severity. When you click on “Add custom field“, the Alert element will also display one input field for name and another for the value (use single value or regex).
You can click on highlighted text in blue between them to change the operator as follows:

• For strings: you can choose between Assign, and Add to array;
• For numbers: you can choose between Assign, Add to array, Increment, Subtract.

Incident update

You can use this element to update the severity level of the trigger incident, its verdict and extra notes. Once you click on a data field, you will be able to choose which part of the incident to update, by choosing between Severity, Verdict, and Notes. Each of those selections will turn the “assign” field into a drop menu with the relevant options.

Like the “Alert” element, “Incident update” also offers the option to add a custom field.

Manual action

Use this Element to introduce a breakpoint in execution that requires the user action in order to resume the execution of the playbook.
The typical use case is when you require the user to review an incident before its remediation is automatically applied; or when the user needs to confirm a threat being a false positive
The required action is shown on the Incident Details page of the workspace.
We recommend adding a notification element before the manual action element to automatically notify the user on the required action.

Remediation

This element executes one or more remediation actions.It is available only in file-based incidents (eg: no Web Protection incidents) and offers the following options:

• Device isolation.
• End device isolation.
• Quarantine threat.
• Rollback threat.

Please note that when Rollback is enabled and available, the Isolation and Quarantine parts of remediation will finish first, then pause the playbook for manual approval.

Notification

This Element triggers a custom notification to a specified target, using the Email or the Webhook option. You can then customize those notifications directly within the Email body field.
You can also use double brackets “{{” to open a list of autocomplete options with all possible execution context fields and integrations schemes.

Regarding the Recipient, you can use a comma separated list of email addresses, although a target email must have a role within the workspace in order to be able to receive notifications.

Please note that if a playbook with this element was cloned from an upper context (e.g. workspace user cloned partner’s playbook), the notification settings stay the same, but webhook header value and syslog certs are not accessible for the user and they must change it.

Condition

This element is what allows you to design the logic upon which your Playbook behaves, by testing some conditions against some logic blocks. This element presents a Condition box, an Operator selector highlighted in blue in the middle, and a Value box on its right side.

By clicking on the first field, the Condition box will present you all the possible selections. As soon as you select one of those options, it will automatically change their relative Operator and the Value to reflect that option.

Policy update

This element allows you to modify both your Monitoring and Scanning exclusions, at either Device, Workspace or Partner policy root level.
A classic example of the use of this Element comes when a Security Analyst investigates a program that was alerted by Behavior Blocker and confirms it as false positive.
They can use this Element to add the file path to the monitoring exclusions, in order to avoid future false positives coming from the same source.

Delay

This Element introduces an intentional processing delay, useful when it is necessary to wait until certain conditions to change. A classic example is when a playbook must wait for more data to become available to make useful decisions; or when a long-term playbook framework is used to execute a series of nested playbooks over a longer period of time.
You can set the amount of the delay and choose its value in seconds, minutes, hours, days.

Threat intelligence source

This element sends Incident data fields to an external web API and adds selected response fields to the incident. This is particularly useful to add more insights over Incidents with additional Indicators Of Compromised data feed, blocklists and enrichment sources alike. The analysts can directly extract data from API responses for further decision making and processing of the incident.

You can select the relevant Method by choosing among GET/POST/PUT.
The Source field offers a comprehensive list of autocomplete option, use the double brackets “{{” to access it. The same autocomplete functionality is available for the Body field, made available for the POST and PUT methods.
You can choose between Basic and HTTP Auth type in its dedicated field.
Finally, this elements offers the possibility to add custom Headers, Data Mapping, and Query.

Debugger

On the right side of the Playbook field you will find the Debugger button. Click to open the debugging panel, then select an incident as the starting point for debugging the playbook.
The panel will also display the incident context and logs from the debugging sessions, highlighting any errors in the flow.