Conditional Tasks

Assume the implementation of the Others branch:

INFO PANEL

The Others branch handles unhandled cases where a user has not defined a specific branch for the input under evaluation. It serves as a fallback mechanism for branching decisions.

1. Build the following playbook:

   

   INPUT

   TEXT

   Unexpected value

   

   DEMO CONDITIONAL TASK

   CODE

   {% set input = PlaybookData | jsonpath('$.Input.returnData') %}
   
   {% if input == 'A' %}
       Branch A
   {% elif input == 'B' %}
       Branch B
   {% endif %} 

2. Click on to test run the playbook and verify execution follows the Others branch.

   

READER NOTE

Ensure Auto Run is enabled for all tasks.

1. Add an auto-run data formatter task in between the root playbook node and the conditional task node.

   

2. Input the following code snippet into the data formatter task:

   CODE

   {{ ['A', 'B', 'C'] | random }}

   This Jinja expression randomly selects and returns either A, B, or C from the list.

   

3. Input the following code snippet into the conditional task:

   CODE

   {% set letter = PlaybookData | jsonpath('$.["Random Letter (A ,B, or C)"].returnData') %}
   
   {% if letter == 'A' %}
       Branch A
   {% elif letter == 'B' %}
       Branch B
   {% elif letter == 'C' %}
       Branch C
   {% else %}
       Next
   {% endif %}

   This Jinja logic retrieves the randomly generated letter from step 2 and routes execution to the correct branch (Branch A, B, or C). If no match is found, it defaults to the Next branch.

   

4. Test run the playbook, then verify whether execution follows the correct path.

   

Consider the following playbook:

READER NOTE

Ensure Auto Run is enabled for all tasks.

1. Configure the DF Task with the following code:

   JSON

   {
       "demoField1": {
           "demoField1.1": "irrelevantValue",
           "demoField1.2": {
               "demoField1.2.1": "irrelevantValue",
               "target": "A",
               "demoField1.2.2": "irrelevantValue"
           },
           "demoField1.3": "irrelevantValue"
       }
   }

   

2. Configure the Conditional Task with the following code:

   JSON

   {% set inner_object = PlaybookData | jsonpath('$["DF Task"].returnData.demoField1["demoField1.2"]') %}
   {% set items = inner_object | list %}
   
   {% set target_value = inner_object[items[1]] %}
   {% if target_value == "A" %}
       Branch A
   {% else %}
       Branch B 
   {% endif %}

   LOGIC BREAKDOWN
   Line 1: Extracts the demoField1.2 object.

   JSON

   {
       "demoField1.2.1": "irrelevantValue",
       "target": "A",
       "demoField1.2.2": "irrelevantValue"
   }

   Line 2: Converts inner_object into a list of keys.

   JSON

   ["demoField1.2.1", "targetA", "demoField1.2.2"]

   Line 4: Items[1] refers to the second key in ["demoField1.2.1", "target", "demoField1.2.2"], so this line resolves to

   NONE

   {% set target_value = inner_object["target"] %}

   Since inner_object["targetA"] has the value "A", the resulting assignment is:

   NONE

   {% set target_value = "A" %}

   Line 5-9: Evaluates target_value, directing execution to Branch A if it is "A", otherwise to Branch B.

   

3. Click on the button to test run the playbook and verify execution follows Branch A.

   

4. Modify the target field value in the DF Task to "Not A".

   

5. Click on then to confirm execution follows Branch B.

   

READER NOTE

Ensure Auto Run is enabled for all tasks.

1. Drag the output connector of tasks A, B, and C back as inputs for the conditional task.

   

2. Input the following code snippet into the conditional task:

   CODE

   {% set a_return = PlaybookData | jsonpath('$.A.returnData') %}
   {% set b_return = PlaybookData | jsonpath('$.B.returnData') %}
   {% set c_return = PlaybookData | jsonpath('$.C.returnData') %}
   
   {% if not a_return %}
       Branch A
   {% elif not b_return and a_return == 'A' %}
       Branch B
   {% elif not c_return and b_return == 'B' %}
       Branch C
   {% else %}
       Next
   {% endif %}

   LOGIC BREAKDOWN
   Lines 1-3: Extract the return data for tasks A, B, and C.
   Lines 5-13 Conditional Logic:

   • If task A has not yet produced return data (a_return is empty), traverse Branch A.

   • If task A returned "A" and task B has not yet produced return data (b_return is empty), traverse Branch B.

   • If task B returned "B" and task C has not yet produced return data (c_return is empty), traverse Branch C.

   • If none of these conditions apply, traverse Next.

     

3. Test the playbook to observe that execution follows a new conditional branch with each iteration.

   

SCENARIO An analyst seeks to automate incident triage by designing a playbook that evaluates severity. For informational incidents, a note is added indicating they are not urgent. For all others, an email is sent to warrant further action.

Here is how they can design the playbook:

1. Add a conditional task to the On Playbook Start trigger.

   

2. Name the task, (optional) add a description/question, ensure that the Testable option is selected, then click the Next button.

   

3. Select the Auto Run checkbox, then navigate to the Condition Settings tab.

   

4. Select Dynamic Input using the dropdown, paste the if-else statement from the code snippet, then click the button.

   CODE

   {% if "placeholder" == "Informational" %}
       {{"Yes"}}
       {% else %}
       {{"No"}}
   {% endif %}

   

5. In the pop-up window, open the DataSource object, then open the Incident object.

   

6. Select the SeverityName field, click the button, then click the Generate as Variable button.

   

7. Replace "placeholder" in the code with the variable.

   

8. Navigate to the Branch Settings tab, then click on the + Add Branch button.

   

9. Add the Yes and No branches, then click the button to save.

   

10. Add the Set Incident Notes utility command task to the Yes branch to update the incident notes, and the Send Email utility command task to the No branch to send a notification. Configure both tasks accordingly.

    

11. Test the playbook.

    

    1. Click on the Test Playbook button.

    2. Select a site.

    3. Select an incident.
       Testing the playbook on an incident will impact the incident. To avoid unintended effects, perform all testing involving the Test Playbook functionality in a demo instance of vSOC.

    4. Click on the Run Test button.

RESULT

Informational Level Incidents

If the incident's severity is informational, the workflow for the Yes condition executes.

All Others

If the incident's severity is not informational, the workflow for the No condition executes.

Suppose the following playbook is provided:

READER NOTE

Ensure Auto Run is enabled for all tasks.

1. Configure the Input task to return "demo input".

   

2. Configure the Demo Conditional Task to have a true and a false branch.

   

3. Use the Text Equals to utility command to configure the Demo Conditional Task to compare the return value of the Input task with "demo value".

   

4. Click on the button to test run the playbook and verify execution follows the true branch.

   

5. Reconfigure the Input task to return "another value".

   

6. Click on then to confirm execution follows the false branch.

   

SCENARIO An analyst aims to determine whether the body of incoming Office 365 emails contains the keyword "verify" as an indicator of phishing. If detected, they will escalate the incident as phishing. Otherwise, they will assign someone to investigate it further..

Here is how they can design the preprocessing playbook:

READER NOTE

Step 1 involves using the Test Playbook function, which does not impact events in D3 when run on preprocessing playbooks. Testing a preprocessing playbook ensures that fields, including those from the raw data returned by an integration’s fetch event command, are populated and available for selection in the format builder.

Before Testing the Playbook

There is no trigger output data available for selection as input values.

After Testing the Playbook

The trigger output is now fully populated, and its data fields are available for selection as input values.

1. Click the Test Playbook button to create a data source, ensuring the trigger output fields are available for dynamic input selection.

   

   Refer to In-Playbook Data Source Configuration for more information.

2. Add the conditional task’s Boolean template to the On Event Ingestion trigger.

   

   This template includes true and false branches by default, useful when the command task output returns a Boolean value.

3. Name the task, (optional) enter a question/description, ensure that the Testable option is selected, then click the Next button.

   

4. Select the Auto Run checkbox, then navigate to the Condition Settings tab.

   

5. Select Command using the dropdown, then click the icon.

   

6. Select the command driving the conditional logic.

   

   1. Search for the Contains Text utility command.

   2. Select the command.

   3. Click the Select button to save.

7. Click the Dynamic toggle, then click the icon.

   

8. In the pop-up window, open the Trigger object, data object, then the Data object.

   

9. Locate and open the Body object, select the content field, then click the Save button.

   

10. Enter "verify" as the search value, then click the Branch Settings tab.

    

11. Click on the + Add Branch button, add the true and false branches, then click the button to save.

    

12. Add the Escalate task to the true branch to escalate the event as a phishing-type incident and the Assign Investigator utility command task to the false branch to assign an analyst for further investigation. Configure both tasks accordingly.

    

13. Stop the playbook test to restore the Test Playbook button.

    

14. Click the Test Playbook button to test the playbook once more.

    

RESULT

Contains "verify"

If the body of an incoming email contains the word "verify", the workflow for the true condition executes.

All Others

If the body of an incoming email does not contain the word "verify", the workflow for the false condition executes.

Suppose the following playbook is provided:

1. Disable Auto Run for the conditional task to (automatically) enable Manual mode.

   

READER NOTE

Ensure Auto Run is enabled for all other non-conditional tasks.

2. Click on the button to test the playbook, then click on the (pending task) icon.

   

3. Click on the Branch B radio button, then click on the button.

   

4. Close the Task Details popover and verify that execution follows Branch B.

   

The General Settings tab contains fields that allow users to define a question for branch traversal, specify the assignee, and set a due time before the task becomes overdue.

READER NOTE

The location where assignees select the radio buttons to determine branch traversal for the conditional task depends on whether the playbook is a preprocessing or investigation playbook.

CASE 1

If the pending conditional task is in a preprocessing playbook, the assigned user can select the execution path by following these steps:

1. Navigate to the Preprocessing Playbook Viewer module.

   

2. Select the relevant event intake summary card and preprocessing playbook, then click on the conditional task.

   

3. Choose an option, then click the Run button.

   

CASE 2

If the pending conditional task is in an investigation playbook, users can select the execution path from the Pending Tasks tab in either the Investigation Dashboard or the Incident Workspace.

Investigation Dashboard

1. Click on the Pending Tasks accordion, All Pending Tasks item, then the corresponding pending task.

   

2. Choose an option, then click the Run button.

   

Incident Workspace

1. Click the Pending Tasks tab, then select the pending task.

   

2. Choose an option, then click the Run button.

   

SCENARIO An analyst plans to design a playbook for manually verifying whether the incident owner is Admin. If so, they will reassign the incident. Otherwise, the investigation proceeds as usual.

Here is how they can design the playbook:

1. Add an interaction task to the On Playbook Start trigger.

   

2. Configure this task to display the current incident owner to the analyst, then choose the Reply in Pending Task option under Reply Channel.

   

3. Add a conditional task after the interaction task.

   

4. Name the task, enter a question, then click the Next button.

   

5. Navigate to the Branch Settings tab, then click on the + Add Branch button.

   

6. Add the Yes and No branches, then click the button to save.

   

7. Add the Set Incident Field utility command task (named Reassign Owner) to the Yes branch to update the incident owner, and the stage task to the No branch to continue the investigation workflow. Configure both tasks accordingly.

   

8. Test the playbook.

   

   1. Click on the Test Playbook button.

   2. Select a site.

   3. Select an incident.
      Testing the playbook on an incident will impact the incident. To avoid unintended effects, perform all testing involving the Test Playbook functionality in a demo instance of vSOC.

   4. Click on the Run Test button.

9. Click the icon to test the interaction task.

   

10. Note the name of the incident owner, then click the Run button to proceed to the next task.

    

11. Click the icon to test the conditional task.

    

12. Select an option, then click the button.

    

    Test for all execution paths to ensure that they all work as intended

RESULT

Admin-Owned Incidents

If the incident owner is Admin, the workflow for the Yes condition executes.

All Others

If the incident owner is not Admin, then the workflow for the No condition executes.