[Quick Tip] How to share information between playbooks

[ylandovskyy]

Sometimes, you might be in a situation, where you want to share information between multiple playbooks, even across different alerts.

For example, if you have a an ITSM integration and you want to only create 1 ticket per case. If there are multiple alerts, you want to just update the existing ticket with a comment that new Alert was grouped under the same case.

There are 2 ways to achieve this:

• Using Context Values
• Using Custom Fields

Context Values vs Custom Fields

If you need to share huge JSONs between playbooks and it's not information that you want to collect for metrics in the future, then Context Values are more suitable.

If you need to share simple information like "ticket_id", then custom fields is best practice for this use case.

Eventually, both context values and custom fields are just variables that you are appending to the Case/Alert.

Playbook

Let's create a simple playbook, where we are creating a ServiceNow ticket per case. If the ticket was already created, instead of creating another ticket we are going to add a note to the existing ticket. The playbook needs to be protected from race conditions. To determine, if the ticket was already created, we are going to check if there is a context value/custom field "ticket_id" with valid value (eq INC1010101).

Using Context Values

If you are using a context value, then you will need to work with action "Set Scope Context Value" from Siemplify integration. Considering that ticket needs to be created per Case -> we will work with Case Context Values. We will have a variable called "ticket_id", so our configuration will need to look like this:

Next,  we need to build the Flow condition correctly. Considering that we have Case Context Value called ticket_id, then we can use [Case.ticket_id] placeholder to validate, if it has any value. The structure of the ticket name is "INC{number}", so that means we can create the following condition:

This ensures that if we don't have a "ticket_id" value that contains "INC" inside of it -> new ticket will be created, as it means that no ticket was created for the case, yet.

To prevent potential race conditions we will put an Tools powerup action "Lock Playbook" before this condition. Lock playbook makes it so that the current playbook will wait until the playbook from other alert will finish execution. It allows us to transform chaotic execution inside case into a sequential one.

The last step is to define the action, when we are updating the existing ticket with new comment. Again, here we can rely on the placeholder from context value to automate the whole process.

The final playbook will look like this:

I've attached the same playbook to 2 alerts within 1 Case and as you can see, it worked in the expected way (I've first attached it to Alert 2 accidentally, that's why this playbook was used to create the ticket):

Using Custom Fields

Eventually the idea is almost identical, the only difference is that first you will need to create a Case Custom Field under "SOAR Settings -> Case Data -> Custom Fields" page, use action "Set Custom Fields" and the placeholder will look slightly different -> [CaseCustom.ticket_id].

Everything else is the same.

And here is an example execution that shows that it also works as expected:

[donkos]

What about storing data as an entity highlight, case description or some other case metadata field?

[ylandovskyy]

Hey @donkos ,

Can you elaborate what you mean? You definitely can add information to entities/case description, but it depends on the use case.

[donkos]

Of course I have two examples:

• I want to store a set of essential email headers in each suspicious email case - this allows me to run a separate scheduled playbook that collects this header data, aggregates it and sends a report - I store the header data as a json in the case description
• In each suspicious email case, there may be multiple reporters who report the exact same email - I want an auto response email sent to each reporter (each reporter ends up as a separate alert in this case), so for each new alert, I have the same sus mail playbook create an entity insight that contains that reporter's email address - these entity insights are available in the action results of the "Get Case Data" which i can ran after an analyst triggers the autoresponse part of the playbook.

[ylandovskyy]

Hey @donkos ,

Thanks for sharing. You can definitely do it like that. The same use case can be solved with both context values and custom fields. You can create a dedicated variable "email_headers", where you would store information about the suspicious headers and you can also have another variable called "affected_reporters", which will contain a comma-separated list of emails.

This way they will still be accessible via playbook, but done in a more structured way. Still, if the current implementation solves all of the pain points, then there is no reason to re-do anything.