Playbooks are at the heart of the Cortex XSOAR system. They enable you to automate many of your security processes, including, but not limited to handling your investigations and managing your tickets. You can structure and automate security responses that were previously handled manually. For example, you can use playbook tasks to parse the information in the incident, whether it be 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 3rd party integration.
Playbooks have different task types for each of the actions you want to take along the way. There are manual tasks where an analyst might have to confirm information or escalate an incident, and there are conditional tasks with a loop to check if certain information is present so you can proceed with your investigation. The playbook tasks can open tickets in a ticketing system, such as Jira, detonate a file using a sandbox.
As you are building your playbook, keep in mind the following:
- What actions do you need to take?
- Which conditions might apply 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?
The answers to the above questions will determine what kind of task you will need to create. Playbooks support the following task types:
- Standard tasksrange from manual tasks like creating an incident or escalating an existing incident, to automated tasks such as parsing a file, or enriching indicators. Automated tasks are based on scripts that exist in the system. These scripts can be something that was created by you, the user, or come pre-packaged as part of an integration. For example, the!filecommand enables you to enrich a file using any number of integrations that you have installed in your system. Alternatively,!ADGetUsercommand is specific to the Active Directory integration.
- Conditional tasksare used as decision trees in your flow chart. For example, were indicators found. If yes, you can have a task to enrich them, and if not you can proceed to determine that the incident is not malicious. Or, you can use conditional tasks to check if a certain integration is available and enabled in your system. If it is, you can use that integration to perform an action, and if not, you can continue to a different branch in the decision tree.
Conditional tasks can also be used to communicate with users through a single question survey, the answer to which determines how a playbook will proceed.
- Data collectiontasks are used to interact with users through a survey. The survey resides on an external site that does not require authentication, thereby allowing survey recipients to respond without restriction.
All responses are collected and recorded in the incident's context data, whether you receive responses from a single user or multiple users. This enables you to use the survey questions and answers as input for subsequent playbook tasks.
You can collect responses in custom fields, for example, a Grid field.
- Section headerstasks are used to manage the flow of your playbook and help you organize your tasks efficiently. You create a Section Header task to group a number of related tasks under the Section Header, as you would items in a warehouse or topics in a book.
For example, in a phishing playbook, you would have different sections for the investigative aspect of the playbook, such as indicator enrichment, and the tasks for communication with the user who reported the phishing.
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. To learn more about inputs and outputs, see Playbook Inputs and Outputs.
You can map output from a playbook task directly to an incident field. This means that the value for an output key populates the specified field per incident. This is a good alternative to using a task with a set incident command.
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. While it is detached, the playbook is not updated by the Content Pack. This may be useful when you want to update the playbook without breaking customization. If you want to update the playbook type through Content Pack updates, you need to reattach the playbook but any changes are overridden by the Content Pack on upgrade.
If you want to keep the changes, duplicate the playbook before reattaching it.
Recommended For You
Recommended videos not found.