Playbook
IBM Security
Objectives
1. What is a Playbook?
2. Accessing the Playbooks
a. From IBM QRadar SOAR Software
b. From IBM QRadar Suite
3. Main Interface
4. Conditions to run A Playbook
a. Automatically
b. On-demand
5. Work with Objects
a. Tasks
b. Scripts
c. Integrations
d. Decision points
e. Sub-playbooks
6. Validate a Playbook
7. Export and import a playbook.
What is a Playbook?
1. Definition:
• A Playbook in IBM SOAR (Security Orchestration,
Automation, and Response) is a pre-defined set of
procedures, tasks, and automated actions
designed to manage a process.
2. Functionality:
• Parallel or Sequential Use: Multiple playbooks can
be used in parallel or in sequence to resolve
cybersecurity incidents.
3. Key Components:
• Automated Workflows: Streamlines incident
response processes.
• Decision Points: Conditional logic to determine
next steps.
• Integration Points: Connects with various security
tools and databases.
• Tasks: Specific actions to be performed.
• Scripts: Automated sequences for efficiency.
• Sub-Playbooks: Smaller, specialized playbooks for
complex processes.
4. Benefits:
• Streamlined Processes: Ensures efficient and
systematic incident handling.
• Flexibility: Adaptable to various incident
types and response strategies.
• Enhanced Coordination: Facilitates
synchronized actions across different teams
and tools.
5. Purpose:
• Ideal for managing diverse and complex
cybersecurity incidents.
• Customizable to fit unique organizational
needs and policies.
6. Reusability:
• Security use cases are solved using multiple
playbooks to adapt the solution to the
complexity of the problem
Accessing the Playbooks
From IBM QRadar SOAR Software
Accessing the Playbooks
From IBM QRadar Suite SaaS or Software
What if you do not see it?
Verify the permissions!
“Ability to view and Modify” includes the Playbooks.
In SOAR:
In QRadar Suite:
From the Main menu under your name and
organisation,
Administrator Setting > Roles > Ability to view and
Modify is including Playbooks
From the Main menu
Application settings > Case Management >
Permissions and access > Roles > Ability to view
and Modify is including Playbooks
Playbooks main page – list view
Creating a Playbook
- Use descriptive name
- API name is auto-populated
- In description explain any setup or triggering points for
automatically executed playbooks
Define the Activation details
Activation type
How the playbook is triggered
Object type
Activation Form –
manual playbooks
Uses to process additional input form the analyst when the playbook is activated.
Automatic Cancelation
When used, the playbook will stop running, stopping also all functions in progress.
Activation Key Points
L1
L2
Note
Task
Incident
Artifact
Attachment
Data Table
Milestone
Task Note
Conditions (to show or to run a playbook)
Playbook interface
Adding elements
Cascading
Elements
All elements must be
connected to activate
and run the playbook.
Tasks
Task are global tasks, editing one may affect other playbook using the same task.
Decision Points
• Wait points:
A Wait point requires that all incoming paths must be complete
before the playbook proceeds to the next step.
• Condition points:
The condition point evaluates the incoming data by using Boolean
operators, and uses the result to determine which outgoing path
to activate in the playbook.
• End points:
An end point signifies the completion of the entire playbook or of
a specific path within it.
A playbook can have multiple end points that each terminate an
individual path, but all paths in the playbook must lead to a single
endpoint.
Wait Point example
Condition
Points
Condition Points - example
Functions
Function configuration example
Function output definition used to Create post-process scripts
This part is composed of 3 sections:
1. The description. You can describe the function usage
and also how to test a positive value
2. A JSON output example
3. A JSON output schema that will be used by the
schema definition when accessing data schema.
Scripts
Example: create a Post Process Script to publish the results
A script can be
• Global - to re-use the script in other
playbook;
you have to set correctly the Type
Level (Incident, Artifact…)
• Local - the script is available in the
playbook only
Post-process - code sample
Script – hint #1
Script – hint #2
Script – testing tips
Test scripts in the edit script UI
using the RUN button!
If the script is using function results, just
simulate the result by commenting the
playbook.result call, replacing it by a local
value for the test.
If the content of the result is a JSON, just
print it in a note.
Use log.info(“message”) or log.info(value) to
present some results of the test.
Sub-playbooks
Use sub-playbooks to define
repeatable activities to use
within other playbooks. You can
access all sub-playbooks from
the playbook library.
You can have multiple levels by
nesting a sub-playbook within a
sub-playbook. However, make
sure to not repeat a subplaybook in the path because it
can cause a loop.
Why using Sub-playbooks?
1. To avoid re-creating a playbook you
frequently use.
Example: open a ticket to ITSM.
2. To avoid the need to change a
playbook when some programatic
element change.
Example: SLA calculation.
3. To use the same Sub-playbook defined
at Incident level, from all sub-levels
(Artifact, Attachement, Note…).
Example: Publication of a JSON result
of integration.
Sub-playbook example
Story:
I want a series of sub-playbook that will publish
integration results from Artifacts, Attachements,
Incidents, Notes.
The source content is a JSON from the integration
The results can be published:
• Artifact:
✓ Description
✓ Tag
• All:
✓ Note
✓ Custom Task
✓ Full JSON humanly readable excluding values
Build:
I need 2 sub playbooks
1. Publication Artifact
• Level: Artifact
• Source:
✓ Tag
✓ low_text
2. Publication All
• Level: Incident
• Source:
✓ Full JSON
✓ Low_text
✓ High_text
✓ Task name
Sub-Playbook – hint #1
If a playbook is enabled, and has errors:
If a Sub-playbook is disable, you can’t enable the
main playbook.
The playbook can’t be saved.
You need to disable it it before saving, or correct
the errors if you can.
Until you enable the Sub-playbook
Sub- Playbook – hint #2
You can’t disable a Sub-playbook if the main
playbook is Enabled.
Be carefull with dependencies !
Using Playbook
details, you can
check the
depencies of a
Sub-playbook on
the playbook
details
Note the revision
version of the
playbook is visible
here also.
Playbook
Export
from the playbook list view, by using the
3 dot menu
from the playbook details
Playbook export – application
dependencies
Playbook export – the
other dependencies
Playbook import
Playbook import - example
Playbook
import
Some object
might be ignored
if already there.
Some object will
be new in the
system.
Some objects
might be updated.
Post-import verification