Communication tasks in playbooks enable you to send surveys and collect data. Ask task, data collection task.
Communication tasks enable you to send surveys to users, both internal and external, to collect data for an alert. The collected data can be used for alert analysis, and also as input for subsequent playbook tasks. For example, you can send a scheduled survey requesting analysts to send specific incident updates or send a single (stand-alone) question survey to determine how an issue was handled.
An ask task is a type of conditional task that sends a single question survey, the answer to which determines how a playbook proceeds. If you send the survey to multiple users, the first answer received is used, and subsequent responses are disregarded. For more information about ask task settings, see Create a conditional task.
Because this is a conditional task, you need to create a condition for each of the answers. For example, if the survey answers include, Yes, No, and Maybe
, there should be a corresponding condition (path) in the playbook for each of these answers.
Users interact with the survey directly from the message, meaning the question appears in the message and they click an answer from the message.
The survey question and the first response is recorded in the alert context data. This enables you to use this response as the input for subsequent playbook tasks.
For all ask conditional tasks, a link is generated for each possible answer the recipient can select. If the survey is sent to more than one user, a unique link is created for each possible answer for each individual recipient. These links are visible in the context data of the incident's Work Plan. The links appear under Ask.Links in the context data.
In this example, the message and survey will be sent to recipients every hour for six hours, until a reply is received (it is repeated every 60 minutes, 6 times). The SLA is six hours. If the SLA is breached, the playbook will proceed according to the Yes condition.
In this example, a message and survey are sent by email to all users with the Analyst role. We are not including a message body because the message subject is the survey question we want recipients to answer. There are three reply options, Yes, No, and Not sure. In the playbook, we will only add conditions for the Yes and No replies. We require recipient authentication, which first involves setting up authentication.
The data collection task is a multi-question survey (form) that survey recipients access from a link in the message. Users do not need to log in to access the survey, which is located on a separate site.
All responses are collected and recorded in the alert context data, whether you receive responses from a single user or multiple users. This enables you to use the survey questions and answers as input for subsequent playbook tasks. If responses are received from multiple users, data for multi-select fields and grid fields are aggregated. For all other field types, the response received most recently will override previous responses as it displays in the field. All responses are always available in the context data.
For all data collection tasks, a single link is generated for each recipient of the survey. These links are visible in the context data of the incident's Work Plan. The links appear in the context data under the Links section of that survey.
You can include the following types of questions in the survey.
Stand alone questions. These are presented to users directly in the message, and from which users answer directly in the message (not an external survey).
Field-based questions. These are based on a specific alert field (either system or custom), for example, an Asset ID field. The response (data) received for these fields automatically populates the field for this alert. For single-select field based questions, the default option is taken from the field’s defined default.
In a playbook, click + to create a new task.
Select the Data Collection option.
Enter a meaningful name in the Task Name field for the task that corresponds to the data you are collecting.
Select the communication options you want to use to collect the data.
Tab
Configuration fields in the tab
Message
Ask by: The method for sending the message and survey. Options are:
Task (can always be completed directly in the Workplan)
Generated link (appears in the context data): A link to the data collection survey is available in the context data of the task.
Email: If you select this option, enter below the subject and message of the email and the email addresses of the users who should receive this message or survey.
To: The message and survey recipients. You can define by:
Selecting from a predefined drop down list.
Manually typing email addresses for users and/or external users.
Clicking the context icon to define recipients from a context data source.
CC of the email: A CC email address.
Subject of the email: The message subject that displays to message recipients. You can write the survey question in the subject field or in the message body field.
Message body: The message question body to be used in the notification sent to the given users along with the reply options.
Require users to authenticate: Enable this option to have your SAML or AD authenticate the recipient before allowing them to answer. You must first set up an authentication integration instance and check Use this instance for external users authentication only in the integration instance settings.
Questions
Web Survey Title: The title displayed for the web survey.
Short Description: A description displayed above the questions on the web survey. Click Preview to see how it displays.
Question: A question to ask recipients.
Answer Type: The field type for the answer field. Options are:
Short text
Long text
Number
Single Select (requires you to define a reply option)
Multi select/Array (requires you to define a reply option)
Date picker
Attachments
Mandatory: If this checkbox is selected for a question, survey recipients will not be able to submit the survey until they answer this question.
Help Message: The message that displays when users hover over the question mark help button for the survey question.
Placeholder: A sample value displayed until a real value is entered.
Note
You can drag questions to rearrange the order in which they display in the survey.
Timing
Retry interval (minutes): Determines the wait time between each execution of a command. For example, the frequency (in minutes) that a message and survey are resent to recipients before the response is received.
Number of retries: Determines how many times a command attempts to run before generating an error. For example, the maximum number of times a message is sent. If a reply is received, no additional retry messages will be sent.
Task SLA: Set the SLA in granularity of weeks, days, and hours.
Set task Reminder at: Set a task reminder in granularity of weeks, days, and hours.
Complete automatically if:
Reached task SLA (with or without a reply): This option is grayed out.
Received <enter a number> reply
Details
Tag the result with: Add a tag to the task result. You can use the tag to filter entries in the War Room.
Task description (Markdown supported): Provide a description of what this task does. You can enter objects from the context data in the description. For example, in a communication task, you can use the recipient’s email address. The value for the object is based on what appears in the context every time the task runs.
Advanced
Using: Choose which integration instance will execute the command, or leave empty to use all integration instances.
Extend context: Append the extracted results of the action to the context. For example, "newContextKey1=path1::newContextKey2=path2" returns "\[path1:'aaa',path2: 'bbb', newContexKey1: 'aaa',newContextKey2:'bbb'\]"
Ignore outputs: If set to true, will not store outputs into the context (besides the extended outputs).
Execution timeout (seconds): Sets the command execution timeout in seconds.
Indicator Extraction mode: Choose when to extract indicators:
None: Do not perform indicator extraction
Inline: Before other playbook tasks
Out of band: While other tasks are running
Mark results as note
Mark results as evidence
Run without a worker
Skip this branch if this script/playbook is unavailable
Quiet Mode: When in quiet mode, tasks do not display inputs and outputs or extract indicators. Errors and warnings are still documented. You can turn quiet mode on or off at the task or playbook level.
(Optional) To customize the look and feel of your email message, click Preview.
You can determine the color scheme and how the text in the message header and body appear, as well as the appearance and text of the button the user clicks to submit the survey.
In this example, we create a stand-alone question, with a single-select answer. This question is not mandatory. If we selected the First option is default checkbox, the reply option "0" is the default value in the answer field.
In this example, we create a question based on a custom alert field that is marked as mandatory. You can add a question based on a field. To add a field, click the Add Question based on field.
When sending a form in a communication task, you can configure user authentication to ensure only authorized users gain access to the form.
The authorized users are usually external users not in Cortex XSIAM, and they will not be able to access anything else in Cortex XSIAM.
Set up your SSO if it is not already configured. See Authenticate users using SSO for more details.
In the Task details of your playbook communication task, check Require users to authenticate to have your SAML or AD authenticate the recipient before allowing them access to the form.
If you are using NGINX as a reverse proxy with SSL termination, configure the NGINX configuration file to enable accessing data collection links in emails.
Navigate to
/etc/nginx/sites-available/
and open the NGINX configuration file.Update the file with the following configurations:
server { listen 443 ssl; server_name <PROXY DOMAIN>; ssl_certificate <path to CRT file>; ssl_certificate_key <path to KEY file>; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384'; ssl_prefer_server_ciphers on; location / { proxy_pass https://<XSOAR DOMAIN>; proxy_cookie_domain <XSOAR DOMAIN> <PROXY DOMAIN>; proxy_pass_header Set-Cookie; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }