Playbook development - Administrator Guide - Cortex XSIAM - Cortex - Security Operations

Cortex XSIAM Administrator Guide

Product
Cortex XSIAM
Creation date
2024-05-06
Last date published
2024-07-12
Category
Administrator Guide
Abstract

Cortex XSIAM playbooks enable you to structure and automate many of your security processes.

Playbooks enable you to automate many security processes, including handling investigations and managing tickets. You can structure and automate security responses that were previously handled manually. For example, use playbook tasks to parse the information in the incident, whether it is an email or a PDF attachment. You can interact with users in your organization using communication tasks, or remediate an incident by interacting with a third-party integration.

Playbooks have different task types for each of the actions you want to take. Manual tasks can be used where an analyst needs to confirm information or escalate an incident. Conditional tasks can be used with a loop to check if certain information is present, so you can proceed with the investigation. Playbook tasks can open tickets in a ticketing system, such as Jira, detonate a file using a sandbox, etc.

When building your playbook, keep in mind the following:

  • What actions do you need to take?

  • What conditions do you need along the way? Are these conditions manual or automatic?

  • Do you need to include looping?

  • Are there any time-sensitive aspects to the playbook?

  • When is the incident considered remediated?

Note

When creating or updating playbooks, it is recommended to do the following:

  • Update deprecated automations and integration commands used in playbook tasks to an updated version.

  • Remove disconnected playbook tasks.

Playbook tasks

Playbook tasks are the building blocks of playbooks. With tasks, you can run automations and sub-playbooks, communicate with end users, set conditions, and store relevant data. Within each task, you can edit, copy and delete. You can also open a sub-playbook task and click Open sub-playbook and the sub-playbook opens in a new tab.

Note

To open multiple playbooks at the same time, edit the first playbook and then click the + symbol next to the playbook name to create a new tab. You can either create a new playbook, or add an existing one.

Cortex XSIAM supports different task types for the different aspects of the playbook. Each task type requires different information and provides different capabilities. You should choose your task type based on what you want to accomplish in the task. For example, for enrichment, you might want to run an enrichment sub-playbook or a command that returns additional information for an indicator. If you are at a fork in your decision tree, you should use a conditional task to help you determine which path to choose.

Playbooks support the following task types:

  • Standard tasks

  • Conditional tasks

  • Data collection

  • Section headers

Inputs and outputs

Depending on the task type that you select, and the script that you are running, your playbook task has inputs and outputs.

Inputs are data pieces that are present in the playbook or task. The inputs are often manipulated or enriched and they produce outputs. Outputs are objects whose entries will serve the tasks throughout the playbook, and they can be derived from the result of a task or command.

Sub-playbooks

Playbooks can be divided into two categories, depending on their use.

  • Parent playbooks are playbooks that run as the main playbook of an alert.

  • Sub-playbooks are playbooks that are nested under other playbooks. They appear as tasks in the parent playbook flow and can be identified by sub-playbook-task.png. A sub-playbook can also be a parent playbook in a different use case.

Examples of parent playbooks are Phishing - Generic v3 and Process Email- Generic v2 (an alert starts according to these playbooks). Examples of sub-playbooks are Detonate File - Generic or Detonate File - Generic (they are part of a bigger investigation).

As sub-playbooks are building blocks that can be used in other playbooks and use cases, you should define generic inputs for them.

Inputs can be passed to sub-playbooks from the parent playbook, used and processed in the sub-playbook, and sent as output to the parent playbook.

Note

Any change made to a sub-playbook impacts the parent playbook in the next run of the parent playbook.

Field mapping

You can map output from a playbook task directly to an alert field. This means that the value for an output key populates the specified field per alert.

Attach and detach playbooks

When installing a playbook from a content pack, by default, the playbook is attached, which means that it is not editable (apart from some input values).

To edit the playbook, you need to detach or make a duplicate. When detached, the playbook is not updated by the content pack, which may be useful when you want to update the playbook without breaking customization. If you want to update the playbook through content pack updates, you need to reattach the playbook but any changes are overridden by the content pack updates. If you open an attached playbook in a tab, it can be detached from within the editor page.

If you want to keep the changes, duplicate the playbook before reattaching it.

Work plan

When an alert is ingested into a playbook is usually attached and runs automatically. You can see which playbook ran in an incident/alert, if any, by going to Incident ResponseIncidents and selecting the incident. You can view or update the playbook by going to the Alerts & Insights tab, selecting the alert, and then clicking InvestigateWork Plan.

On the left hand side, you can see the name of the playbook. You can select another playbook to run from the dropdown list.