XSOAR Engineer - Part 6: Playbook Essentials

Summary

This video guides XOR engineers through the essential elements of building playbooks. It covers key topics such as integration, automation, and built-in commands, as well as how to manage inputs, outputs, and context within tasks. The script provides detailed insights on utilizing different task types, configuring advanced options like retries and auto-extraction, and executing integration commands from specific instances. Engineers will learn how to leverage incident data dynamically, and gain a deeper understanding of how context and outputs work to drive playbook actions. This knowledge enhances efficiency in automating security workflows.

Takeaways

• 😀 Integration commands are used to interact with external products, formatted as lowercase with dashes (e.g., adget-user).
• 😀 Automation scripts are internal tasks that perform operations like data transformation, written in title case (e.g., GeneratePassword).
• 😀 Built-in commands (camel case) are used to manage XOR incidents, indicators, and threat intelligence (e.g., setIncident).
• 😀 Inputs for tasks can come from incident fields, labels, or outputs of previous tasks. These are necessary for executing automation or integration commands.
• 😀 Outputs from tasks are stored in incident context, making them available for use in downstream tasks within the playbook.
• 😀 Context stores outputs of integration and automation tasks, which can be referenced as inputs for further tasks in the playbook.
• 😀 When selecting integration commands, those with brackets specify a particular integration, while those without execute across all enabled integrations.
• 😀 Advanced task options include setting retries for failed tasks, specifying auto-extraction of indicators, and using quiet mode to suppress non-error outputs.
• 😀 The 'Using' parameter allows selecting a specific integration instance for executing commands, ensuring precise control over task execution.
• 😀 Quiet mode disables auto-extraction and suppresses non-critical outputs, useful for tasks that should not interrupt the playbook flow.
• 😀 The playbook editor allows dynamic mapping of incident fields to task inputs, ensuring playbooks can adapt to different data contexts without hardcoding.

Q & A

What is the key difference between integration commands, automation scripts, and built-in commands in XOR playbooks?

Integration commands are typically in lowercase with dashes and are used to interact with external systems (e.g., Active Directory). Automation scripts are in title case and are used to transform or process data within XOR. Built-in commands are in camel case and are used to manipulate XOR-specific objects such as incidents or indicators.

How do you add tasks to a playbook in XOR?

Tasks can be added by using the task library, which includes automation scripts, integration commands, and manual tasks. Alternatively, tasks can be created by dragging and dropping from the task editor or by linking them to previous tasks using the half-circle icon.

What does the curly brace format signify in XOR playbooks?

The curly brace format (e.g., {source_username}) is used to dynamically pass inputs into tasks in a playbook. It allows the playbook to extract data from the incident context and use it as inputs for automation or integration commands.

What is the role of outputs in XOR playbooks?

Outputs are the results returned by automation scripts or integration commands. They are stored in the incident context and can be used as inputs for subsequent tasks in the playbook, enabling the playbook to take further actions based on the results.

How does the 'using' parameter function in advanced task options?

The 'using' parameter allows you to specify which instance of an integration to execute a command from when multiple instances are available. This ensures the playbook runs the task against the correct integration.

What are the available retry options in XOR playbooks, and when should they be used?

Retry options allow a task to be retried in case of failure. The retry interval specifies how long to wait between retries. This is useful for integrations that may fail intermittently due to network issues or other instability.

What is the purpose of the quiet mode in XOR playbooks?

Quiet mode suppresses auto extraction, prevents enrichment of task results, and stops automatic updates to the war room. It allows for more controlled execution of tasks without cluttering the war room with excessive information.

How can outputs be extracted and associated with incidents in XOR?

Outputs from tasks can be extracted using the 'auto extract' feature, which allows for automatic enrichment and association of indicators with the incident. This can be set to 'inline' (extraction occurs immediately) or 'out of band' (happens concurrently without blocking the task).

What is the difference between selecting a command with and without brackets in XOR playbooks?

Selecting a command with brackets after the command name (e.g., adget_user[active_directory_query_v2]) means the task will be executed only with that specific integration. Choosing a command without brackets executes the task across all enabled integrations that support that command.

How does XOR handle tasks that have no defined outputs?

Tasks that do not produce defined outputs may still return useful information to the war room. However, these results will not be placed in the incident context, and therefore cannot be used as inputs for downstream tasks in the playbook.