Best practices - Administrator Guide - Cortex XSIAM - Cortex - Security Operations

Group related input fields.

Grouping inputs organizes the input fields and provides clarity and context to understand which inputs are relevant to which playbook flow.

Use camel case for input names.

Use the CamelCase convention for inputs, keeping in mind that inherently capitalized terms should be kept in upper case. For example, the Entity ID input should be named EntityID and MITRE Technique should be MITRETechnique.

Define outputs properly.

When configuring playbook outputs, configure sub-keys as much as possible, do not limit configuration to only the root keys. For example, instead of outputting File, output File.Name, File.Size, etc. This helps when viewing the outputs of the playbook within another playbook.

Avoid using Cortex XSOAR Transform Language (DT) in the Get input field definition.

If you need to use DT for complex processing and you think a new filter or transformer would provide a better alternative to your DT solution, you can request the feature or contribute it. Consider using DT only if it can drastically simplify the playbook or improve performance.

Avoid race conditions.

Be aware of potential race conditions. When you want to add multiple values to the same key, do not use multiple tasks that run Set, SetAndHandleEmpty, or any other script that sets data in context at the same time, because a race condition can cause your data to be overwritten by the same tasks. This is especially problematic when trying to append data. Instead, run the tasks one after the other or use scripts to append the data instead of setting a new value to the key.

Determine where inputs are coming from.

Verify whether the data you're getting is As value (simple value) or From Previous Tasks (from context).

Filter your inputs correctly so the task runs efficiently.

Tasks take their inputs from the context, not directly from the previous tasks (even if it says from previous tasks). For an example of a task not receiving the right context, see this bug (since fixed) in a playbook:

The playbook begins by classifying the emails as internal or external. It then checks the reputation of external email addresses if any were found. That happens on the right side of the image. We expect that branch to run only if external addresses are found.

However, we did not apply a filter to the last task that gets the reputation on the right side:

This means that if both internal and external email addresses are found, we proceed with both branches (internal and external) of the playbook, and the task that gets the reputation runs without an applied filter, effectively taking all the emails we have in the inputs. The correct task input should have been:

Select Ignore case for input names.

Use ignore-case option where possible, especially when checking Boolean playbook inputs such as True which users may end up configuring as true with a lowercase t:

When working with two lists, if you need multiple items from list A, which are also in list B, use the in filter instead of the equals or contains filters.

Correct Method	Incorrect Method
Get the IP addresses that are in the list of inputs.	Get the IP addresses where the addresses contain the list. This is incorrect because they don't contain the list, they contain individual items from it.

Differentiate between checking if a specific element exists versus checking if an element equals something. This is a common mistake that can lead to tests working in some situations, but not all.

Correct Method	Incorrect Method
Check if any object where the NetworkType is External exists.	Check if the NetworkType of the IP object is External. This is incorrect because the IP object may contain multiple IPs, some internal and some external.

Run one or more tasks based on the object types versus running either one task or the other based on the type of one object.

Correct Method	Incorrect Method
Check the existence of both object types and run tasks for the types found.	Check if there is either an internal or an external IP, and take only one path even if both types exist.

Parent playbooks usually have a closeInvestigation task at the end because they are the main playbook for that incident.

Parent playbooks usually contain inputs that are passed down to sub-playbooks. Certain True/False flags may come from the parent playbook inputs.

Do I need to do this action in multiple tasks?

Can these tasks run in parallel instead of synchronously?

Where applicable, am I setting realistic timeouts, search windows, intervals?

Can I consolidate the API calls into one call? If not, can an integration enhancement solve this by accepting arrays as input instead of running multiple times for each input?

Am I unnecessarily storing the same data twice? Do I have the data I need already stored?

Where applicable, can I run this playbook without a loop?

What extractions are running in my incident?