Incident Playbooks

LAST UPDATED: OCT 15, 2024

Overview

Incident Playbook is the main Playbook type you will use in the system. SOC Engineers, Senior Analysts and MSSPs can configure workflows for day-to-day operations within the SOAR platform within the Incident Playbook. These Playbooks should be configured to respond to different Incident types, and the complexity of these Playbooks can vary depending on your organization’s needs. In this section, we will outline and explain the unique features of an Incident Playbook.

Life Cycle

The life cycle of the Incident Playbook starts when an Event escalates into an Incident. A sample life cycle of the Incident Playbook is:

1. Event is escalated into an Incident with a default Incident Playbook attached

2. Tasks run in sequence according to data flow

3. End of Incident Playbook

UI Elements

The incident playbook UI contains the following components:

Action Bar

Back Button: Navigate to the previous level.

Breadcrumbs: Displays your location relative to other modules/pages.

Concurrent Users: All the current users viewing/editing this playbook are displayed here in their initials.

Playbook Features: View the current state of the Playbook (Live/Draft), and perform actions like Save Draft, Submit, Permissions, and Version History on the Playbook you’re working on.

More Actions :

• Clone Playbook: Make a copy of the current incident Playbook.

• Replace Playbook: Import a Playbook to replace the existing one (only in Draft mode).

• Delete Playbook: Remove the Playbook from the system.

• Command References: View all commands used in the Playbook.

Playbook Details

Playbook Name: This Playbook’s name; it can only be changed in edit mode.

Description: A short description of this Playbook.

New Task: The tab displays a list of Playbook Tasks, Integration, and Utility Commands for configuring your Playbook.

Main Editor

The Main Editor shows an overview of all the Tasks being used and how they are related to each other.

Within this view, there is a secondary Action Bar with the following actions:

• Search: Searches for any tasks in the Playbook.

• Show/Hide Overview: This feature can be activated when the playbook view is larger than the frame.

• Zoom in: Zooms in to view a task in a larger size.

• Zoom out: Zooms out to view more tasks and task flows in the frame.

• Fit to screen: Fits the entire Playbook into the size of the frame.

• Export: Downloads the current playbook view as a .PNG file.

• Refresh: Refreshes the Playbook to the most recent update.

• Run test: Test runs the Playbook.

• Stop test: Stops the running Playbook test.

Starting from the source node, Tasks are run from left to right. You can choose to have different types of flow between nodes, including looping and conditional tasks. For more details on data flow, refer to Data Flow in Playbooks.

Task Editor

You can configure details of a Task such as Task Name, Input, Assigned To, etc

Features

Triggers

In an incident playbook, task chains can be connected to a trigger. In this case, each task chain is only run when the trigger condition is satisfied. Currently, incident playbooks have four triggers:

1. On Incident Change – Tasks connected to this trigger run when the incident is changed.

2. On Incident Status Change – Tasks connected to this trigger run when the incident status is changed.

3. On Incident Close – Tasks connected to this trigger run when the incident is closed.

4. On Incident Reopen – Tasks connected to this trigger run when the incident is reopened.

5. On Incident External Action – Tasks connected to this trigger run when the "Trigger Incident External Action" is run as a remote command.

You should use these triggers to help you classify which workflows to run depending on the stage of the incident life cycle an incident is currently in.

Draft/Live Modes

There are two Playbook modes in the incident playbook:

By default, all newly created Playbooks are in Draft mode. Once a Playbook is fully configured, you can switch the Playbook mode from Draft to Live by pressing the Submit button to solidify the changes.

Collaboration and Concurrent Users

When collaborating with other users on a playbook, it’s essential to know if you are on the same playbook and what changes each of you is making. Seeing concurrent users is also important when working independently on a playbook so that you are aware of where other users are, and no crucial data is unknowingly overridden.

Concurrent Users at Playbook Level

Every user currently working on the same playbook will appear on the toolbar as coloured circles with their initials. When you hover over a specific user, you can see their name. The toolbar can display up to five users’ initials. However, if the total number of concurrent users exceeds five, the 5th circle will show you how many more people are here on this playbook. When you hover over that number, you will see a list of their names.

Concurrent Users at Task Level

When a user is on a specific playbook task, whether they’re viewing or editing it, you will see an outline in their colour around the task they're on. When you hover over the task, it tells you exactly who the user is.

In the case of multiple users on one task, you can hover over the task to see everyone’s name.

Concurrent Users at Field Level

To view a specific field that a user is editing, click on the task to open up the task configuration panel. The field being edited will be outlined in the editor's colour. When you hover over the field, you will see the editor's full name at the bottom right corner. However, concurrent users at field level can only be seen when the playbook is in draft mode.

In the case of multiple users on the same field, you can hover over the field to see everyone’s name. Fields are automatically saved when you click away from the input box.

Concurrent Editing and Saving

View Draft / View Live

As mentioned in the above section, a playbook can have two modes, a live mode, and a draft mode. When another user clicks on the Edit button while you are viewing a playbook, a draft mode is created for the other user to edit. You will remain on the live mode so that your viewing is not interrupted. If you want to edit or view the changes made by the other user, you can do so by clicking on the View Draft button. You can exit the the draft mode at any time by clicking on the View Live button.

Submit Changes with Concurrent Editors

When you’ve finished editing and want to make the changes go live, the system will notify you if another user is still editing a field. You can choose to cancel your submission or submit it anyway. However, doing the latter may cause data loss or overridden changes on the fields they were editing.

In the event that other users submit their edits to go live while you are still editing a field, you will see the following notification:

You can then choose to see the newest live view or open a draft view of the most recent live view to continue your edits.

Version History

A version of the playbook is saved every time it goes live. Each version contains the DateTime the playbook went live and the user who performed this action. You can access all previous versions of this playbook by clicking on the More button located in the top right and clicking on Version History.

To restore to a previous version of a playbook

1. Make sure this playbook has gone Live at least once

2. Click on Version History

3. Click on Restore on the version to be restored to, overwriting the current draft.

More Actions

These actions are accessible by clicking on the ⋮ button in the Action Bar.

Local Shared Data

The local shared data allows you to store data in JSON format for tasks to reuse in a playbook. This storage area is local – data stored here is only accessible by this playbook and this playbook only. This feature may be helpful in situations where there are data (e.g. URL reputations) you want to be accessible by any tasks regardless of their playbook path.

There are four utility commands in D3 SOAR to help you manipulate data in the local shared data:

To add and retrieve data from local shared data

In this example, we want to save URL reputation data from a task to the local shared data and add this data to a global list in the system.

1. Drag the command task Add Root Key for Local Shared Data and drop it right after the Check URL Reputation task

2. In the command input area of Add Root Key for Local Shared Data:

   1. Input
      Select the path of the output of the Check URL Reputation task

   2. JSON Path
      Enter $.URLReputationData

3. In Add to Global List command task, make sure Dynamic input is enabled and click on …

4. Select Local Shared Data from the data source dropdown

5. Select the path $.URLReputationData

6. Test the playbook

Playbook List

The Playbook List shows all the Incident Playbooks you have in the system. Clicking on any Playbook from the List will open up the Playbook Editor where you can configure the specific Incident Playbook.

Access Control

D3's SOAR platform incorporates a combination of role-based and predefined access controls that can be executed at the Incident, Stage, or Task level. Through this model, you can determine access control rules for five types of assignees: Users, Groups, Role, Owner, and Investigators. The following diagram describes the access control hierarchy within the SOAR platform:

Level 1 - Incident Type/Dynamic Sections

Level 2 - Incident Stage

Level 3 - Playbook

You can define who can edit or have access to a connection. By default, the creator of the connection will be marked as the owner and be the only person that can use the connection. In order for other users to have access to the connection, the creator will have to provide a Viewer, Editor, or Owner role. Below are the permissions granted for each role:

Level 4 - Playbook Task

The access controls at this level are applied to a specific Task within a specific Playbook Type. Within each Playbook Task, you can assign different Users, Groups, Roles, Owners, and Investigators from the Assigned To dropdown to action the Task.

Publishing

To use an Incident Playbook, you have to publish it to one or more Site(s). Only Live Playbooks can be Published to other sites for members of the Site to use.

To publish an Incident Playbook:

A dropdown list of all published Playbooks will be available when you escalate an event to an incident. You can also assign multiple Playbooks to an Incident within the Incident Workspace.

Playbook Test

The incident playbooks allows you to test your workflow while you are editing it in Draft mode. You can use this feature to test the usability of your Playbook while you are building it. The Playbook editor offers testing at three different levels of your workflow, allowing you to locate and fix bugs in your workflow more easily and accurately.

You can test on these three levels:

1. Playbook Level

2. Task Level

3. Input Level

Playbook Level

You can test your entire incident playbook workflow to see if everything is working as intended by clicking on the ▶ Test Playbook button in the action bar. You then need to choose a site and an incident to run the test on in the pop-up window. The Playbook runs according to the control flow, from the source node on the left all the way to the rightmost node.

After your first test run, you might see various icon(s) appear in each Task card. These icons represent the current status of the Playbook task, and you can click on the icon(s) to view the Playbook Task Details in the pop-up window.

You can click on the icons to view the task details and status. Within the pop-up window, the top panel highlights the Task Type, Assignee, Due Date, Status, Run Mode and action buttons of the playbook task. If not run, the first tab within this window presents the Input tab. You can review the contextual data in the Input tab, and update the input fields before running or skipping the Playbook Action. To run the task, click on the "Run/Done" button.

When you choose to skip a task, you can skip to the next task in the flow without having to run the previous task. After a Task has successfully run, additional tabs such as Task Details, Key Fields, Context Data, Return Data, Raw Data and Result will be available in the Playbook Task Details window. The information presented in these tabs will vary depending on the Task Type selected.

To test an incident playbook

1. Click on ▶ Test Playbook.

2. Select an incident for which to test your playbook.

3. Click on ▶ Run Test.

Task Level

On the task level, you can test a single task with specified input parameters and view the resulting output. Before testing at the task level, you will have to test the entire playbook at least once first to ensure there is data to test with. This can be done by clicking on ▶ Test Playbook button in the action bar. Testing a task can help you ensure that it is well configured before moving on to creating the next step of your workflow.

To test a task

Input Level

On the Input level, you can test your inputs to make sure it satisfies the command parameters. Before testing at the input level, you will have to test the Playbook at least once first to ensure there is data to test with. Testing an input is especially useful when you are configuring a dynamic input - testing here can ensure the correct JSON path has been picked, or the correct data transformation has been applied.

To test an Input in a Command Task

To test an Input in a Data Formatter Task

Tasks

Playbook Tasks are the building blocks of a playbook. Tasks take in input data, perform data processing, and return output data. These tasks are connected to each other using control flow, and data flows from left to right starting from the source node. There are 13 Playbook Tasks with which you can use to build or edit an Incident Playbook:

1. Command Task

2. Nested Playbook Task

3. Conditional Task

4. Data Formatter Task

5. Interaction Task

6. Stage Task

7. Universal API Task

8. REST API Task

9. SLA Task

10. Ongoing Surveillance Task

11. Unwind Task

12. Merge Task

13. Lock Task

14. Unlock Task

To use a playbook task, simply drag and drop the task you want to use from the playbook side panel into the Main Editor. A new node will be created and connected to the preceding node via a line.

Task Data Flow

Each Task can take in input data, perform data processing, and return output data. You can link Tasks together in the Main Editor with arrows that represent data Control Flow. The following section will explain the data flow of Tasks.

Input

A Task can take in both static and dynamic inputs.

A static input means that the input is fixed and will not change. For example, in a Fetch Event Command Task, you can set a fixed start/end date for the Events you are fetching for. However, if your workflow requires a moving time window for the Fetch Event command to fetch from, you will need to use a dynamic input.

There are 5 types of dynamic input methods for a Task. They are:

1. Dynamic Input

2. Data Formatter

3. HTML Editor / Data Formatter

4. DateTime / Data Formatter

5. Dropdown

Dynamic Input

Dynamic Input is the most common input type in a Playbook - it allows for both static and dynamic data to be used as an input for a Task. This feature can help you transfer data from one Task to another in a Playbook and chain Tasks together.

Static Data: Enter in the values that match the data type into the text area

Dynamic Data: Enable the dynamic toggle and enter the corresponding JSON Path of the dynamic data. This JSON Path should point to a data source that is dynamically updated in the Playbook. Optionally, you can apply regular expressions on this data through the Regex Filter tab to filter the JSON data.

Data Formatter

Data Formatter input allows you to use formatted dynamic data as an input for a Task. It is similar to Dynamic Input - but in addition, the Data Formatter allows you to perform complex data transformation on the data with our library of Jinja filters. With this, you can customize and create very specific dynamic inputs for a Task. The Quick Start guide in the Data Formatter contains more information on how to use this feature.

HTML Editor / Data Formatter

As the name suggests, this input method is the combination of HTML and Data Formatter. This input type is the same as Data Formatter, with the added ability to switch between the Data Formatter editor and a HTML editor. This allows you to build customized HTML templates that contain formatted dynamic fields that update automatically.

Date / Time Input

Date / Time input allows you to select a specific Date and Time as a static input for a Task. If your workflow requires a dynamic Date/Time input, you have the option to use the Data Formatter to select and format a dynamic input as the Date/Time input for a Task.

Dropdown Input

Static Data: Dropdown input allows you to select a value from a predefined list as an input for a Task.

Dynamic Data: You can define a JSON path or formatted data that outputs a value corresponding to one of the dropdown options. The playbook will dynamically select the matching value (from the JSON path or formatted data) in the dropdown when run.

Control Flow

All playbook tasks have an order of execution that determines which playbook task runs first, how often they run, whether they loop, etc. You can set a task to run if a condition is satisfied, thus creating branching flows; tasks can also run in a loop. The order of execution of playbook tasks is called a Control Flow.

There are a few types of Control Flow used in D3: sequencing, conditional branching, looping, wait for all, wait for any, and nesting.

Control Flows are represented by a directional line within the playbook. A playbook task will be triggered to run after the directly preceding task finished running. All playbook tasks can only be triggered and run once, except for when you set tasks to run in a loop.

There are a few examples of different types of Control Flow that are often used in D3:

Task Options

Every task has a few options for its run, to ensure the smooth configuration of the playbook. This can include: Active, Auto Run, Required, Stop on Error, and Long Run.

Output

There are five types of task output. The output of each task in runtime is yielded in the formats: Output Data, Context Data, Result, Return, and Raw Data. If the playbook task encounters an error, there will also be an Error tab. After running a playbook, you can click on each task to view the task output details.

Task Types

Command Task

Command task is one of the most important task types in D3 SOAR. The command task allows you to utilize D3’s library of built-in commands and 2000+ integration commands to perform tasks including data processing, data transformation, system actions and much more. It is essential to every playbook as it connects our system with third-party integrations.

Our system has four different types of commands:

1. Third-party integration commands

2. System Commands

3. Utility Commands

4. Cyber Commands

In addition to the built-in commands, you can build your own custom commands with Python or D3’s Codeless Playbook Editor.

All Command Tasks have the following basic elements:

Types of Commands

Nested Playbook Task

A playbook functioning as a custom command with inputs and outputs which can be used in one or many other playbooks is called a nested playbook. It is very common that many playbooks share one or more the same small segments of the workflow. In order to reduce the repetitive configuration of the workflows, nested playbooks can be configured to accommodate the need for reusability of playbooks. One of these use cases is IP enrichment across multiple threat intelligence tools.

Creating a Nested Playbook

The following steps demonstrate the process of creating a sample nested playbook for IP enrichment:

Step 1: Create a New Utility Command

Step 2: Configure Command Setting, Inputs and Outputs

Step 3: Configure Playbook

Step 4: Publish and use the Playbook

Data Formatter Task

The Data Formatter Task lets you perform complex data transformations to playbook data. You can use D3’s built-in data filter to format and select specific playbook data and view the resulting output. The resulting reformatted output can be used as inputs for subsequent playbook tasks.

The example below demonstrates how you can add a data formatter to an event playbook to clean up URL data output from a preceding task. We will create a script in data formatter that removes duplicate URLs and ensures each URL is in a standardized format.

1. Give the task a relevant name that indicates what it does. In this example, we will name the task "URL Data Cleansing".

2. Input a custom Jinja script to select and format data. You can use the format builder to help you build a script by selecting the data source and filters you would like to use. Refer to the Quick Start guide for in-depth documentation on the available filters. In the following example, the script that cleanses the raw data and parses it into a JSON array:

   JSON

   {% set urlString = PlaybookData | jsonpath('$.DataSource.incident.Artifacts[*].URLAddress[*].Url') %}
   {% set result%}
   [
   {% for urlString in PlaybookData | jsonpath('$.["Extract URLs"].contextData') %}
       {% if urlString | last | equals("/") %}
       "{{result | plus (urlString[0:-1]) }}",
       {% else %}
       "{{result | plus (urlString)}}",
       {% endif %}
   {% endfor %}
   ]
   {% endset %}
   {{result | unique}}

   You can click Test to run and view your script’s output. The Data Formatter Output pop-up displays a bug log to help you troubleshoot if necessary. For our example, the output data was:

   CODE

   [
     "http://amazon.com",
     "http://google.com",
     "http://abc.com",
     "http://xmr.pool.minergate.com"
   ]

3. Configure the control flow for the command task. Use the tick boxes to configure if the command task is active, if it will auto run, and if it will stop when an error occurs. The dropdown menu lets you select the control flow for the task. Refer to Task Data Flow for more details. The configurations in this example ensure the command task is active, and will always auto-run when its preceding tasks have been completed.

4. Include a description for the data formatter task for future playbook editing reference if desired. We have not included one for this example.

5. Click the gray check mark button to confirm and create the command task.

6. Done!

Stage Task

The Stage Task lets you create checkpoints into a playbook’s workflow to organize playbooks. Stage tasks split the playbooks into different stages for easier management of workflows. Analysts can also use stage tasks to assign investigators to the incident.

In this example, we will create a stage task in an incident playbook to signify the data enrichment stage of the playbook workflow.

1. Give the stage task a relevant name that indicates the corresponding stage of your playbook’s workflow. In this example, we will name the stage task "Data Enrichment".

2. Configure the control flow for the stage task. Use the tick boxes to configure if the stage task is active and if it will autorun. The dropdown menu lets you select the control flow for the task. Refer to Task Data Flow for more details. The configurations in this example ensure the command task is active, and will always auto-run when its preceding tasks have been completed.

3. Include a description for the stage task for future playbook editing reference if desired. We have not included one for this example.

4. Click the gray check mark button to confirm and create the command task.

5. Done!

SLA Task

The SLA Task lets you set precise service-level agreement (SLA) for all tasks in the incident response lifecycle. This task facilitates the reporting and monitoring of your team’s compliance with SLA guidelines. Click here for a short how-to video on creating an SLA task.

In this example, we use an SLA Task to measure how long it takes the playbook to complete the escalation stage. This functionality is commonly used by SOC teams to ensure incidents are resolved and handled within a reasonable time frame per SLAs.

1. Give the task a relevant name that indicates the SLA agreement. In this example, we will name the task "Escalation SLA Start".

2. Select the SLA agreement for this task using the dropdown menu. Configured SLAs will be available to select. You can add custom SLAs in the settings module of D3 SOAR. For this example, we will select Incident Closed in 1 Hour. This means that the time limit to respond to an incident is one hour.

3. Define the SLA tracking stage for the task. With this configuration, you can select whether you want to start, pause, resume, stop or reset the SLA tracking task. For this particular SLA task in the example, we are adding the SLA task to start tracking when an escalation has started. We would need to add a Stop SLA task in the playbook to define when the SLA tracking will stop.

4. Select who should be notified when the SLA is breached using the dropdown menu. Investigation teams, groups, users, and roles will be available to select. For our example, we will notify the Owner of the task.

5. Configure the control flow for the SLA task. Use the tick boxes to configure if the stage task is active and if it will autorun. The dropdown menu lets you select the control flow for the task. Refer to Task Data Flow for more details. The configurations in this example ensure the SLA task is active, and will always auto-run when its preceding tasks have been completed.

6. Include a description for the SLA task for future playbook editing reference if desired. A brief description of the SLA is included in the example shown.

7. Click on the check mark button to confirm and create the command task.

8. Done!

Conditional Task

The Conditional Task allows you to set up different possible paths a playbook workflow may go through depending on how the output of a preceding task runs through a logical test.

In this example, the Conditional Task checks which option a user has selected in an automated email sent by the D3 SOAR system inquiring if he/she has clicked on any malicious links.

1. Give the task a relevant name that describes the conditional task. In this example, we will name the task "Did the User click on the Link?".

2. Use the tick boxes to set whether the task is active and automated. Both boxes are checked in this example so that the task is active and will auto-run.

3. Select the condition type for the task (i.e. input or command). For the input condition type, you can build a custom Python script with the built-in data formatter to define the workflow for the conditionals. You can also select the command condition type, which allows you to use D3’s library of built-in and integration commands to define the workflow for the conditionals.

4. Configure the control flow for the conditional task. The dropdown menu lets you select the control flow for the task. Refer to Task Data Flow for more details. The configurations in this example ensure the conditional task will always auto-run when its preceding tasks have been completed.

5. Include a description for the conditional task for future playbook editing reference if desired. We have not included one for this example.

6. Add conditionals for the task. Conditionals correspond to the output data of the preceding playbook task. You can also change the order of the conditional options you have added. A common set of conditions is true and false, which we have used in this example.

7. Click the gray check mark button to confirm and create the command task.

8. Done!

Interaction Task

The Interaction Task is typically used to add a point of manual human processing into your playbook. With the Interaction Task, you can incorporate questions, prompts or notes to guide your SOC team’s decision-making process throughout an incident response. Unlike other playbook tasks, an interaction task cannot be automated, as its purpose is to facilitate manual response in incident response.

In this example, we will create an interaction task to prompt the investigator to manually select from a list of potentially malicious IP addresses from the dynamic output data of a preceding playbook task to block.

1. Give the task a relevant name that describes the interaction task. In this example, we will name the task "Which of the following IP addresses do you want to block?".

2. Add questions, prompts, information etc. that will guide the investigator’s manual processing of the task. You can use the JSON path picker to select output data and use the Regex filter to filter the JSON data. For this example, we added a question asking the investigator which IP address to manually block from the preceding playbook task’s output dynamic data of some potentially malicious IP.

3. Configure whether the interaction task is active and a required task. Both tick boxes are checked in our example so that the interaction task is both active and required.

4. Assign the group, user or role responsible for processing the interaction task. We have assigned the task to the investigator for this example.

5. Set the time constraint for the assignee to process the task. This setting can be used to align with any SLA requirements of your organization or use case. Here, we have set the time limit to process the interaction task to one hour.

6. Configure the control flow for the interaction task. The dropdown menu lets you select the control flow for the task. Refer to Task Data Flow for more details. The configurations in this example ensure the interaction task will always auto-run when its preceding tasks have been completed.

7. Include a description for the command task for future playbook editing reference if desired. We have not included one for this example.

8. Click on the check mark button to confirm and create the command task.

9. Done!

Merge Task

The Merge Task lets you gather data from all preceding connected playbook tasks and combine them based on specified conditions. Tasks downstream of the merge task can then use the combined data. Often, a Merge Task is used downstream of an Unwind Task. The Unwind Task plays a role in breaking down arrays into manageable units, which can then be individually used for processing and enrichment, and potentially consolidated. The Unwind Task plays a role in breaking down arrays into manageable units, which can then be used for processing, retrieving data from third parties, or enriching other components before potentially being consolidated.

1. Give the task a display name. In this example, we will name the task "Merge".

2. Set the condition to control how the data is combined. There are four conditions you can configure to control how data is combined: by playbook instance, by task name, by task instance, or by a specified JSON path. For this example, we will combine the data by task name.

3. Use the tick boxes to configure if the task is active, if it is automated, and if it will stop on error. Active and Auto Run are selected for this example.

4. Configure the control flow for the merge task. The dropdown menu lets you select the control flow for the task. Refer to Task Data Flow for more details. The configurations in this example ensure the interaction task will always auto-run when its preceding tasks have been completed.

5. Include a description for the command task for future playbook editing reference if desired. We have not included one for this example.

6. Click the check mark button to confirm and create the command task.

REST API Task

The REST API Task lets you use REST APIs to send a request to a web service to retrieve or modify data in your playbooks. You can use the five HTTP methods for CRUD (create, retrieve, update and delete) operations.

In this example, we will create a REST API task to send a webhook event to D3 SOAR with the POST method in order to create a new event entry.

1. Give the task a relevant name that describes the REST API task. In this example, we will name the task "Send Webhook Event".

2. Configure the input parameters to use the REST API. This includes the request URL, the HTTP method, the request header and the body data for the request. In this example, the following values for the input parameters were configured:

   1. URL:

      CODE

      {{PlaybookData | jsonpath('$.["Construct Webhook URL"].returnData')|trim}}

      The request URL is selected using the format builder to select the data from a previous playbook task.

   2. Method:
      POST
      We will use the POST request method to perform a create operation for a new event.

   3. Header:

      CODE

      {"d3key":"d3test"}

      The key-value pair is used for the API authorization.

   4. Body:

      JSON

      {% set result %}
      {
      "eventtype":"Suspicious Email",
        "username": "user1",
        "sourceip": "192.168.87.104",
        "hostname": "D3cyber7ce",
        "email": "demo@d3soar.com",
        "domain": "www.google.com",
        "destinationip": "8.8.8.8",
        "sha256": "8b2e701e91101955c73865589a4c72999aeabc11043f712e05fdb1c17c4ab19a",
        "timestamp": "{{'today' | date('YYYY/MM/DD HH:mm:ss')}}"
      }
      
      {%endset%}{{result|trim}}

      The body contains the JSON object data we want to POST into D3 SOAR.

3. Use the tick boxes to configure if the task is active, if it is automated, and if it will stop on error. Active and Auto Run are selected for this example.

4. Use the tick boxes to set whether the task is active and automated. Both boxes are checked in this example so that the task is active and will auto-run.

5. Include a description for the command task for future playbook editing reference if desired. We have not included one for this example.

6. Click the gray check mark button to confirm and create the command task.

7. Done!

Ongoing Surveillance Task

You can set up additional conditions and correlations in the Ongoing Surveillance Task to conduct a deeper analysis and ingest Events on a periodical basis.

Unwind Task

The Unwind Task deconstructs an array of JSON object(s) into individual objects. More specifically, it deconstructs an array field from the specified JSON data and creates output(s) for each object of the array. Each returned object contains two parts: the root fields of the original JSON data and one object from the array. An instance is created for each returned object. 

In most use cases, if a command input can only accept one item at a time, we use the unwind task to repeat the command task to handle the loop of an array. The unwind task is often used in conjunction with a merge task to re-combine the data based on specified conditions.