SOAR playbook toolkit

The Playbook manager displays all the playbooks and their status. The Playbooks page is the initial page that is shown when you click Playbooks in the menu bar. You can create or edit playbooks.

For each incident, there is a Playbook progress link to show the status of the playbook instance for this incident.

See the following topics for detailed descriptions of the Playbook designer features.

To create and manage playbooks, see Build and manage playbooks.

Review your organization’s policies for responding to events then determine the basic categories of events. As a simple example, you might have three categories: Malware, Intrusion, and Loss of Personal Information. You can create an incident type for each category. Furthermore, you can create subcategories by creating a parent incident type with child incident types. For example, you might have three subcategories of Loss of Personal Information: Executive, HR, and Other.

Define incident types that are relevant and meaningful to the full lifecycle of the incident handling and response actions, specifically, pre, intra, and post incident.

Use Phases to define each stage of an incident response, essentially capturing the general intent of the response action. Phases logically and visually organize tasks within a playbook, which also helps leadership and management to be able to identify the current work state of the incident.

Like incident types, the phases you need for your environment are largely dependent on your organization’s response approach and tracking methods.

Tasks can be in the form of a set of instructions or advisories. It can also take the form of an action that a responder selects, which you configure by using the Rule feature. When the responder finishes the task, it can be marked and recorded as completed. As you define the tasks, keep in mind your organization’s policies as to responding to a particular situation. Make sure to have these tasks specific and repeatable to the incident or situation at hand.

Tasks also play a vital role as a system of record and as a method of training. Analysts new to your organization can quickly learn specific processes by following the playbooks.

You create and manage the pool of tasks in the Phases & Tasks tab under Customization Settings, where you also assign the task to a phase.

You can dynamically add these tasks to a specific incident through playbooks, workflows and the configurations of rules, their conditions and activities. The conditions for adding tasks can be based on the field values of the following objects: incident, tasks, notes, milestones, artifacts, attachments, and data tables.

Within each layout, you can organize information by fields and data tables.

You can use fields as data capture points for analysis review and to produce metrics. Features, such as rules, reports, and analytic dashboards, can access the values in fields. Make sure to have the fields be distinct, specific, and purposeful.

You can use data tables to capture and organize field values in a spreadsheet table format. Features, such as rules and reports, can access the values in data tables. Data tables can also be used in apps, where the information that is escalated from another security program populates the data table with values. Depending on the app, a user might be able to access limited capabilities of that security program directly from the data table.

You create and manage fields and data tables from the Layouts tab where you can add them to the various incident tabs.

You can also create fields and data tables for other features, such as tasks and functions. Creating fields within tasks allows users to spend more time to perform actions and capture information directly in the tasks and less time to switch between the incident tabs. When possible, add relevant fields to each task for more efficient data capture AND the layout of the appropriate incident tabs to allow ease of review and reporting.

For users familiar with writing Python scripts, you can write scripts to access incident data (same data as accessed by rules) then run activities more complex than can be handled by rules. Scripts can be triggered by playbooks, rules, or workflows.

Functions use scripts to provide input values. In Playbook designer, it is called a function input script. In workflows, it is a pre-process script.

Playbooks have local scripts, which apply only to the playbook where it was created. These scripts have extra operations to access the output of functions in the playbook.

Workflows allow simpler scripts to be used as conditions for inclusive and exclusive gateways.

A function is an object that sends data to a remote app through a message destination. The app runs an activity then returns the results. Functions can be triggered by playbooks and workflows.

A function has one or more inputs and provides a result in JSON. You can provide static values for inputs manually or variable inputs programmatically by a script. When triggered, the function sends the input values to the remote app by way of a post to a message destination and waits for a result. You use the result as a decision point in the playbook or workflow.

When you use a script to set the input value of one or more of the function’s input fields, you can use the script to retrieve the current value of a property then provide that value to the function. However, the script cannot run such activities as changing incident values or adding artifacts.

You can have script take as input the function’s result. The script can change incident values, add artifacts, add rows to a data table, and more. You can also save the function’s result for use by functions later in the playbook workflow path.

You can create and manage functions in the Functions tab. Typically, app developers create functions to use with an app that can then be installed in multiple SOAR Platform instances.

Workflows are triggered by rules and provide more complex decision-making processes. You design each workflow to represent a specific business process. As a simple example, you can use a workflow to determine the geographic location of an event then implement a specific set of activities based on that location.

When you design rules and workflows, generally use workflows to define any conditional logic, sequencing, and orchestration of human tasks and automated activities. Use rules for implementing general, higher-level business logic, such as “include the privacy team on the incident when a data breach occurs.”

For complex processes, you can simplify your design by creating smaller, repeatable workflows that can be called by other workflows.

You create workflows in the Workflows tab, which has a graphics editor, making it easy to design workflows.

You cannot use workflows in a playbook that was created by the Playbook designer tool.

An activity is an operation that the rule runs when the appropriate conditions are satisfied. The activity can be as simple as adding a task to the incident or setting incident values, or more sophisticated such as starting scripts, workflows, and sending data to external programs.

Each condition is statement that includes a field, an equation, and a value. The condition is met when the statement evaluates to true. Conditions can be combined by using Boolean “AND/OR” logic.

You can add conditions, order those conditions, add activities, provide the rule’s results to an external program, and more.

When you use rules, the term “playbook” is not shown in the user interface.

Simulations allow users to create incidents for testing to see how each component of your playbook responds. You can use it to verify that your playbook responds as you expect, and to fine-tune it for more efficient responses.

Simulated risk assessments allow users to test the implications of a data breach situation without keeping it in your organization’s record. The wizard collects basic information about a hypothetical data breach event. It ends with an assessment that includes a summary of the recommended steps to be taken and the estimated fine liability.

To run a simulation, click Create incident menu and select Create simulation then complete the incident entry wizard. You can use the same actions on simulations as you can on incidents, as described in the Introduction to incident response. Simulated scenarios are distinguished within the system by a SIM icon. The process of working with simulated items is identical to working with real incidents.

To close an active simulated incident, click Close Incident within the appropriate incident.

If your organization is using workspaces, consider which workspace is appropriate for incidents when you add conditions to rules or layouts. For example, you can send incidents to specific workspaces or identify which workspace contains a specific incident.

For more information about workspaces, see SOAR platform workspaces.

Playbook components can include functions, rules, workflows, Python scripts, custom fields, data tables, and message destinations. Code can access and return external data, interact or integrate with other security systems, or be a utility that runs a specific action.

An app is available in two formats. One format requires the App Host Kubernetes-based container environments. The other format, called an extension, requires an integration server.

You can download existing app packages from the IBM® X-Force® Community App Exchange. You must have an account to download packages.

You can download apps that support the container environment directly to the SOAR Platform, as described in the Apps section of the System Administrator Guide.

You download function and custom action Python apps in the extension format to an integration server. See the Integration Server Guide for details.

App developers can also create their own apps. For function-based apps in either format, see the App Developer's Guide.

For other types of apps, see the SOAR Developer web site. The Reference page on the website provides pointers to various developer documents, such as the Custom Action Developer's Guide.

A condition is a statement that includes a field, an equation, and a value. When the condition statement evaluates to true, it triggers its playbook or rule.

Both playbooks and rules require at least one condition to be triggered. Rules have a default condition. Playbooks do not.

The condition is based on the object type, which determines the fields that are available to be used as conditions. With some object types, you can select fields from their parent object; for example, you can select incident fields for a Task or Note object type.