Playbooks

Open Single Management Platform uses playbooks that allow you to automate workflows and reduce the time it takes to process alerts and incidents.

Playbooks respond to alerts or incidents according to the specified algorithm. Playbook launches an algorithm that includes a sequence of response actions that help analyze and handle alerts or incidents. You can launch the playbook manually or configure the automatic launch of the playbook you need.

The automatic launch of playbooks is performed according to the trigger that you configure when creating a playbook. A trigger defines the conditions that an alert or incident must meet to launch this playbook automatically.

One playbook scope is limited to only alerts or only incidents.

Note that the playbook can only belong to one tenant and it is automatically inherited by all child tenants of the parent tenant, including child tenants that will be added after the playbook is created. You can disable playbook inheritance by child tenants when creating or editing a playbook.

In Open Single Management Platform, there are two types of playbooks:

• Predefined playbooks

  Predefined playbooks are created by Kaspersky experts. These playbooks are marked with the [KL] prefix in the name and cannot be edited or deleted.

  By default, predefined playbooks operate in the Training operation mode. For more information, refer to the Predefined playbooks section.

• Custom playbooks

  You can create and configure playbooks yourself. When creating a custom playbook, you need to specify a playbook scope (alert or incident), a trigger for launching the playbook automatically, and an algorithm for responding to threats. For details about creating a playbook, see Creating playbooks.

Operation modes

You can configure both automatic and manual launch of playbooks. The way to launch the playbook depends on the selected operation mode.

These are the following types of operation modes:

• Auto. A playbook in this operation mode automatically launches when corresponding alerts or incidents are detected.
• Training. When corresponding alerts or incidents are detected, a playbook in this operation mode requests the user's approval to launch.
• Manual. A playbook in this operation mode can only be launched manually.

User roles

You grant user rights to manage playbooks by assigning user roles to the users.

The table below shows access rights for managing playbooks and performing the user actions.

Viewing the playbooks table

The playbooks table is displayed in the Monitoring & reporting → Playbooks section. By default, the table displays the playbooks related to all of the tenants to which you have access rights.

The playbooks table displays all existing playbooks, except for playbooks with the Deleted operation mode.

To configure the playbooks table, do any of the following:

• Apply tenant filter:
  1. Click the link next to the Tenant filter setting.
  2. The tenant filter opens.
  3. Select the check boxes next to the required tenants.
• Filter the data of the playbooks table:
  1. Click the Filter button.
  2. On the Filters tab, specify and apply the filter criterion in the invoked menu.
• If you want to hide or display a column, click the settings icon (), and then select the necessary column.

The playbooks table is configured and displays the data you need.

The playbooks table contains the following information:

• Name. Name of the custom or predefined playbooks.

  The predefined playbooks are marked with the [KL] prefix in the name and cannot be edited or deleted.

• Operation mode. Playbook operation mode that defines the way to launch the playbook. For more details on operation modes, see the Playbooks section.
• Tags. Tags that are assigned to a playbook. You can filter playbooks by using the assigned tags.
• Response actions. Actions that are launched within playbooks.
• Launches. Total number of playbook launches.
• Modified. Date and time of the last edit of the playbook.
• Created. Date and time the playbook was created.
• Availability. Playbook launch availability. Possible values:
  • Available. All response actions within the playbook are available to the user.
  • Unavailable. There are response actions that cannot be launched by the user.
• Parent tenant. Name of the tenant to which the playbook belongs.
• Description. Playbook description or a comment. By default, this column is hidden.
• Scope. Playbook scope. Possible values: Alert or Incident. By default, this column is hidden.
• Created by. Name of the playbook's creator. By default, this column is hidden.
• Updated by. Name of the user who edited the playbook. By default, this column is hidden.

Creating playbooks

You can create a playbook to automate threat analysis and threat response.

To create a playbook, you must have one of the following roles: Main administrator, SOC administrator, Tier 1 analyst, Tier 2 analyst, Tenant administrator.

Kaspersky Next XDR Expert also allows you to create a new playbook that will meet your needs, based on an existing one. For details, refer to Customizing playbooks.

To create a new playbook:

1. In the main menu, go to Monitoring & reporting → Playbooks.
2. Click the Create playbook button.

   The Create playbook window opens.

3. In the Tenant field, select a parent tenant and child tenants for which the playbook should be launched.

   All child tenants of the selected parent tenant will automatically inherit this playbook. To disable the playbook inheritance, clear the check box next to any child tenants. The playbook inheritance will be disabled for all child tenants.

   If you select a child tenant, all parent tenants will be selected automatically.

4. In the Name field, enter the playbook name.

   Note that the playbook name must be unique and cannot be more than 255 characters long.

   The playbook name must not contain the following special characters: < > ".

5. If necessary, in the Tags field, specify up to 30 tags. You can filter playbooks by using the assigned tags.

   Note that the maximum tag length is 50 characters.

6. If necessary, in the Description field, enter a playbook description or a comment.
7. In the Scope list, select one of the following options:
   • Alert. The playbook will be launched only for alerts.
   • Incident. The playbook will be launched only for incidents.
8. In the Operation mode list, select one of the following options:
   • Auto. A playbook in this operation mode automatically launches when corresponding alerts or incidents are detected.
   • Training. When corresponding alerts or incidents are detected, a playbook in this operation mode requests the user's approval to launch.
   • Manual. A playbook in this operation mode can only be launched manually.
9. In the Launching rule list, choose an action to perform if two or more playbook instances are launching at the same time:
   • Add new playbook instances to the queue. A new playbook instance will be launched after the current one is completed. By default, this action is selected.
   • Terminate current execution and launch a new instance. The execution of the current playbook instance will be terminated. After that, a new playbook instance is launched.
   • Do not launch new playbook instances. A new playbook instance will not be launched. The execution of the current playbook instance will continue.

   The Launching rule list is displayed only if the Auto operation mode is selected.

10. In the Trigger section, specify the condition for the automatic launch of the playbook.

    To describe the trigger condition, use jq expressions. For more information about jq expressions, refer to jq Manual.

    Depending on the option you select in the Scope list when creating or editing a playbook, alert data model or incident data model is used.

    For example, to filter alerts or incidents by critical severity, specify the following expression:

    .Severity == "critical"

    You can also specify complex expressions to filter alerts or incidents.

    For example, to filter critical alerts or incidents by rule name, specify the following expression:

    [(.Severity == "critical") and (.Rules[] |.Name | contains("Rule_1"))]

    where Rules[] |.Name defines the name of the triggered rule.

    Validation of jq expressions is configured. If you specify an incorrect expression in the Trigger section, the error is marked in red. If you want to view the details, hover the mouse cursor over the error.

    If you select the Manual operation mode, the Trigger section is unavailable.

11. To view alerts or incidents that match the playbook trigger, in the Trigger matching section, click the Find button.

    You can also request a full list of alerts or incidents. To do this, in the Trigger section, enter true, and then click the Find button.

    The full list of alerts or incidents is displayed.

12. In the Algorithm section, specify the sequence of responses to alerts or incidents in the JSON format. For details, refer to the Playbook algorithm section.

    If necessary, you can copy an algorithm from another playbook. To do this, do the following:

    1. Click the Copy from another playbook button.

       The Copy from another playbook window opens.

    2. In the list of playbooks, select a playbook from which to copy the algorithm, and then click the Add button.

       The algorithm of the selected playbook is added to the Algorithm section.

    Validation of jq expressions and JSON syntax is configured. If you specify an incorrect expression in the Algorithm section, the error is marked in red. If you want to view the details, hover the mouse cursor over the error.

13. By default, the playbook will only be launched for new alerts or incidents that match the trigger.

    If you want to launch a new playbook for existing alerts or incidents that match the trigger, select the Launch the playbook for all matching alerts or incidents. Note that the system may be overloaded check box.

14. Click the Create button.

A new playbook is created and displayed in the list of playbooks.

Editing playbooks

To edit a playbook, you must have one of the following roles: Main administrator, SOC administrator, Tier 1 analyst, Tier 2 analyst, Tenant administrator.

For predefined playbooks, you can only change the playbook mode and launching rule. You can also view alerts or incidents that match the predefined playbook.

To edit a playbook:

1. In the main menu, go to Monitoring & reporting → Playbooks.
2. Do one of the following:
   • Click the name of the playbook that you want to edit. In the Playbook details window that opens, click the Edit button.
   • Select the playbook from the list, and then click the Edit button.

   The Edit playbook window opens.

3. Edit the playbook's properties. For more details on the playbook properties that you can edit, see Creating playbooks.
4. If you changed the operation mode to Auto or Training, in the Running instances list, choose an action to apply to launching playbook instances:
   • Terminate instances that are in progress or awaiting approval.
   • Terminate only the instances that are awaiting approval.
   • Execute all instances that are in progress or awaiting approval.
5. Click the Save button.

The playbook's properties are modified and saved.

Customizing playbooks

You can customize any playbook to your needs.

To customize playbooks:

1. In the main menu, go to Monitoring & reporting → Playbooks.
2. Open the playbook for editing by doing one of the following:
   • Click the name of the playbook that you want to customize. In the playbook details window that opens, click the Duplicate and edit button.
   • Select the playbook from the list, and then click the Duplicate and edit button.

   The Edit playbook window opens.

3. Configure the playbook's properties according to your needs.

   For more details on the playbook's properties that you can edit, refer to Creating playbooks.

   If you want to customize the playbook algorithm parameters, refer to Playbook algorithm.

   The name of the customized playbook must be unique.

4. Click the Save button.

The customized playbook is modified and saved.

Viewing playbook properties

Playbooks allow you to automate workflows and reduce the time it takes to process alerts and incidents.

To view a playbook, you must have one of the following roles: Main administrator, SOC administrator, Junior analyst, Tier 1 analyst, Tier 2 analyst, SOC manager, Approver, Observer, Tenant administrator.

To view a playbook's properties:

1. In the main menu, go to Monitoring & reporting → Playbooks.
2. In the list of playbooks, click the name of the playbook that you want to view.

   The Playbook details window opens.

3. Switch between tabs to get information about the playbook.

General

The General tab contains the following information about the playbook:

• Tenant. Name of the tenant to which the playbook belongs.
• Tags. Tags assigned to the playbook.
• Description. Playbook description.
• Scope. Playbook scope. Possible values: Alert or Incident.
• Created. Date and time the playbook was created.
• Modified. Date and time of the last edit of the playbook.
• Trigger. Description of alerts or incidents that trigger the playbook. The trigger is described by using jq expressions.
• Algorithm. Description of response actions that are launched during the playbook execution. The algorithm is described by using JSON.

You can edit the playbook's properties by clicking the Edit button.

History

The History tab contains a table that lists all playbooks or response actions launched within the playbook. On this tab, you can view response history and terminate the launched playbooks or response actions by clicking the Terminate button. You can also view response history from the Response history section or from alert or incident details.

You can group and filter the data in the table as follows:

• Click the settings icon (), and then select the columns to be displayed in the table.
• Click the filter icon (), and then specify and apply the filter criterion in the invoked menu.

  The filtered table of devices is displayed.

The table contains the following columns:

• Actions. Response action name.
• Response parameters. Response action parameters that are specified in the playbook algorithm.
• Start. Date and time the playbook or response action was launched.
• End. Date and time the playbook or response action was completed.
• Alert ID or Incident ID. ID that contains a link to the alert or incident details.
• Launched by. Name of the user who launched the playbook or response action.
• Approver. Name of the user who approved the launch of the playbook or response action.

  By default, this column is hidden. To display the column, click the settings icon (), and then select the Approver column.

• Approval time. Date and time when the user confirmed or rejected the launch of the playbook or response action.

  By default, this column is hidden. To display the column, click the settings icon (), and then select the Approval time column.

• Action status. Execution status of the playbook or response action. The following values can be shown in this column:
  • Awaiting approval—Response action or playbook awaiting approval for launch.
  • In progress—Response action or playbook is in progress.
  • Success—Response action or playbook is completed without errors or warnings.
  • Warning—Response action or playbook is completed with warnings.
  • Error—Response action or playbook is completed with errors.
  • Terminated—Response action or playbook is completed because the user interrupted the execution.
  • Approval time expired—Response action or playbook is completed because the approval time for the launch has expired.
  • Rejected—Response action or playbook is completed because the user rejected the launch.
• Assets. Number of the assets for which the playbook or response action is launched. You can click the link with the number of the assets to view the asset details.
• Asset type. Type of the asset for which the response action or playbook is lauched. Possible values: Device or User.

Changelog

The Changelog tab contains the history of playbook editing, including time, author, and description.

Terminating playbooks

You can forcibly terminate the launched playbook. In this case, the uncompleted response actions will be terminated. The completed response actions will not be canceled after the termination of the playbook.

To terminate a playbook, you must have one of the following roles: Main administrator, Junior analyst, Tier 1 analyst, Tier 2 analyst, Tenant administrator.

To terminate a playbook:

1. In the main menu, go to Monitoring & reporting → Playbooks.
2. In the Playbook details window that opens, go to the History tab.
3. In the list of the launched playbook instances, select one or several instances that you want to terminate, and then click the Terminate button.
4. In the window that opens, click Terminate.

The playbook is terminated.

Deleting playbooks

Predefined playbooks cannot be deleted.

To delete a custom playbook, you must have one of the following roles: Main administrator, SOC administrator, Tier 1 analyst, Tier 2 analyst, Tenant administrator.

To delete a custom playbook:

1. In the main menu, go to Monitoring & reporting → Playbooks.
2. Do one of the following:
   • Click the name of the playbook that you want to delete. In the Playbook details window that opens, click the Delete button.
   • Select the playbook from the list, and then click the Delete button.
3. In the confirmation dialog box, click Delete.

   The playbook cannot be deleted if there are launched playbook instances. In this case, terminate all launched instances before deleting the playbook.

Deleted playbooks will only be available for viewing and copying in the Playbooks section.

Launching playbooks and response actions

Launching playbooks

Depending on your needs, you can configure the way to launch the playbook. You can select one of the following operation modes during the playbook creation:

• Auto. Select this operation mode if you want to automate the launch of playbook and response actions.

  Playbooks in this mode help automate threat response, and also reduce the time it takes to analyze alerts and incidents.

• Training. Select this operation mode if you want to check if the playbook is configured correctly.

  Playbooks in this mode will not be launched automatically when a corresponding alert or incident is detected. Instead, the playbook requests the user's approval to launch.

• Manual. Select this operation mode if you want to launch the playbook manually only.

  Playbooks in this mode have no trigger, so you can launch such playbooks for any alert or incident, depending on the selected playbook scope. For more details, see Launching playbooks manually.

You can also change the operation mode of the existing playbook. For more details, see Editing playbooks.

Launching response actions

Response actions can be launched manually, automatically within a playbook, or can be configured to request the user's approval before launching within the playbook. By default, manual approval of the response action is disabled.

For more details on how to configure the manual approval of a response action launched within the playbook, see Configuring manual approval of response actions.

Launching playbooks manually

Kaspersky Next XDR Expert allows you to manually launch all playbooks that match all alerts or incidents you want to respond to.

To launch a playbook manually, you must have one of the following roles: Main administrator, Junior analyst, Tier 1 analyst, Tier 2 analyst, Tenant administrator.

To launch a playbook manually for an alert:

1. In the main menu, go to Monitoring & reporting → Alerts.
2. In the table of alerts, click the link with the ID of the alert for which you want to launch the playbook.
3. In the Alert details window that opens, click the Select playbook button.

   The Select playbook window opens.

4. In the list of playbooks that match the alert, select the playbook you want to launch, and then click the Launch button.

   If the selected playbook is already running for this alert, in the Monitoring & reporting window that appears, do one of the following:

   • If you want to wait until the current playbook instance is completed, click the Wait and launch button.

     The new playbook instance will be launched after the current one is completed.

   • If you want to launch a new playbook instance immediately, click the Terminate and launch a new one button.

     The current playbook instance will be terminated and the new one will be launched.

   • If you want to cancel the new playbook launch, click the Close button ().

   If the selected playbook already has the status Awaiting approval, after manual launch, the playbook status will change to In progress.

The playbook is launched for the selected alert. After the playbook is completed, you will receive a notification.

To launch a playbook manually for an incident:

1. In the main menu, go to Monitoring & reporting → Incidents, and then select the XDR incidents tab.
2. In the table of incidents, click the link with the ID of the incident for which you want to launch the playbook.
3. In the Incident details window that opens, click the Select playbook button.

   The Select playbook window opens.

4. In the list of playbooks that match the incident, select the playbook you want to launch, and then click the Launch button.

   If the selected playbook is already running for this incident, in the Monitoring & reporting window that appears, do one of the following:

   • If you want to wait until the current playbook instance is completed, click the Wait and launch button.

     The new playbook instance will be launched after the current one is completed.

   • If you want to launch a new playbook instance immediately, click the Terminate and launch a new one button.

     The current playbook instance will be terminated and the new one will be launched.

   • If you want to cancel the new playbook launch, click the Close button ().

   If the selected playbook already has the status Awaiting approval, after manual launch, the playbook status will change to In progress.

The playbook is launched for the selected incident. After the playbook is completed, you will receive a notification.

Launching playbooks for objects specified by users

You can specify observables and assets for which a playbook must run. You have to create a playbook with the following settings:

• In the Scope list, select Alert or Incident.
• In the Operation mode list, select Manual.
• In the Algorithm section, when setting a response action, use jq expressions to specify the objects (observables or assets) for which you want the playbook to launch. These objects will be the input to the playbook when it is launched.

If you do not specify the objects in the playbook algorithm and only select them before launching the playbook, these objects will be ignored.

After the playbook is created, you can launch it for the selected objects.

To do this, you must have one of the following XDR roles: Main administrator, Junior analyst, Tier 1 analyst, Tier 2 analyst, or Tenant administrator.

To launch a playbook for the selected objects:

1. In the main menu, go to the Monitoring & reporting section, and then in the Alerts or Incidents section, click the ID of the alert or incident from which you want to launch the playbook.
2. In the details window that opens, click the Select playbook button.

   The Select playbook window opens.

3. Select the Select target objects before launching the playbook option, and then click the Launch button.
4. In the Target objects window that opens, select the objects from the Observables and Assets tabs for which you want to launch the playbook, and then click the Apply and launch button.

   The playbook is launched for the objects you selected.

You can view the result of the playbook from the History tab in the alert or incident details, from the playbook History tab, and from the Response history section.

For example, you write a script that is called during the executeCustomScript response action. When creating a playbook, in the Algorithm section, you write the executeCustomScript response action with the playbook input data. Then, you have to run the script for an observable with an IP type that you select when launching the playbook. The script uses the IP address that you selected as a parameter:

{

"dslSpecVersion": "1.0.0",

"version": "1",

"responseActionsSpecVersion": "1",

"executionFlow": [

{

"responseAction": {

"function": {

"type": "executeCustomScript",

"params": {

"commandLine": "./script.py",

"commandLineParameters": "${ \"-ip \" + ([.input.observables[] | select(.type == \"ip\")] | map(.value) | join(\",\")) }",

"workingDirectory": "/folder/with/script"

}

},

"onError": "stop"

}

},

{

"responseAction": {

"function": {

"type": "updateBases",

"params": {

"wait": false

},

"assets": "${ [.input.assets[] | select(.Type == \"host\") | .ID] }"

}

}

}

]

}

Several objects will be an input to the playbook, and the list of IP addresses separated with commas must be an input to the script:

{

"input": {

"observables": [

{

"type": "ip",

"value": "127.0.0.1"

},

{

"type": "ip",

"value": "127.0.0.2"

},

{

"type": "md5",

"value": "29f975b01f762f1a6d2fe1b33b8e3e6e"

}

],

"assets":[

{

"AttackerOrVictim": "unknown",

"ID": "c13a6983-0c40-4986-ab30-e85e49f98114",

"InternalID": "6d831b04-00c2-44f4-b9e3-f7a720643fb7",

"KSCServer": "E5DE6B73D962B18E849DC0BF5A2BA72D",

"Name": "VIM-W10-64-01",

"Type": "host"

}

]

}

After jq expressions perform calculations on the playbook operational data, the following information is passed as command line parameters:

-ip 127.0.0.1,127.0.0.2

For a playbook expecting input data, if you specified different types of objects when creating the playbook and when launching it, or if you did not select the Select target objects before launching the playbook option, the playbook will finish with one of the following results:

• An error will occur because the playbook did not receive input data.
• The action will not be performed because the playbook contains a condition or a loop that is based on the input data.
• The result will depend on the response of the application, or service, or script that performs the action.

Launching playbooks in the Training operation mode

The Training operation mode allows you to check if the playbook is configured correctly. This can be helpful if you are planning to change the playbook operation mode to Auto.

All playbooks in the Training operation mode request the user's approval to launch.

To launch a playbook in the Training operation mode, you must have one of the following roles: Main administrator, Junior analyst, Tier 1 analyst, Tier 2 analyst, Tenant administrator.

The playbook in the Training operation mode cannot be launched automatically when a triggering alert or incident is detected. You can test launching the playbook in the Training operation mode in one of the following ways:

• Create an alert or incident that matches the playbook trigger.
• Edit an alert or incident that matches the playbook trigger. The alert or incident must be in a status other than Closed.

When one of the above actions is completed, the playbook requests the user's approval to launch. For more information on how to approve the playbook, see Approving playbooks or response actions.

Configuring manual approval of response actions

Kaspersky Next XDR Expert allows you to configure manual approval of a response action launched within a custom playbook. By default, manual approval of the response action is disabled.

Before configuring manual approval, make sure that email notifications for tenants are configured and the email address of the approver is specified.

We recommend that you configure manual approval of the following response actions: moving devices to another administration group, moving files to quarantine, enabling and disabling network isolation, responding on accounts through Active Directory, and data enrichment.

To configure manual approval of a response action:

1. In the main menu, go to Monitoring & reporting → Playbooks.
2. Open the playbook for editing by doing one of the following:
   • Click the name of the playbook that you want to edit. In the Playbook details window that opens, click the Edit button.
   • Select the playbook from the list, and then click the Edit button.

     If you select more than one playbook, the Edit button will be disabled.

   The Edit playbook window opens.

3. In the Algorithm section, specify one of the following parameters for the response action for which you want to enable the manual approval:
   • To enable the manual approval of a response action with the default approval time, specify the following parameter:
     "manualApprove": true

     By default, the approval time is 60 minutes.

   • To enable the manual approval of a response action with an adjustable approval time, specify the following parameter:
     "manualApprove": {"timeout": "period"}

     where "period" is an adjustable approval time.

     You can configure the approval time in hours (h) and/or minutes (m), for example:

     "manualApprove": {"timeout": "20h"} "manualApprove": {"timeout": "2h30m"}
   • To enable the manual approval of a response action with notifications sent to the email address of the approver, specify the following parameter:
     "emailNotifications": { "enabled":true }
   • To enable the manual approval of a response action with a notification that is sent to the email address of the approver after a certain period, specify the following parameter:
     "manualApprove": { "emailNotifications": { "enabled": true, "delay": "period" }

     where "period" is an adjustable sending time.

     You can configure the sending time in minutes (m), for example:

     "delay": "20m"
4. Click the Save button.

Manual approval of a response action is configured. Email notifications with a request to approve the response action will be sent to the email specified in the user account properties.

You can view requests for approval of response actions in the Approval requests section.

Approving playbooks or response actions

All playbooks in the Training operation mode require a user's approval. You can also configure manual approval of response actions launched within the playbook.

To approve or reject a playbook launch, you must have one of the following roles: Main administrator, Junior analyst, Tier 1 analyst, Tier 2 analyst, Tenant administrator.

To approve or reject a response action launch, you must have one of the following roles: Main administrator, Approver, Tenant administrator.

If there are playbooks or response actions that are awaiting a user's approval, a notification appears at the top of the Open Single Management Platform Console. Additionally, if the user's approval is required for the response action launch, an email notification is sent to the email address within the time period specified in the algorithm of the playbook.

Viewing the list of playbooks and response actions

To view the list of playbooks and response actions that are awaiting approval, do one of the following:

• Click the View approval requests link at the top of the Open Single Management Platform Console.
• Follow the link in the notification that is sent to your email address.

The Approval requests pane with the table that contains the full list of approval requests opens.

The Approval requests table contains the following columns:

• Time. Date and time when a playbook or a response action requested a user's approval.
• Approval due date. Date and time by which the user must approve or reject the playbook or the response action. If the user has not approved the playbook or the response action by this time, the launch is canceled.
• Playbook. Name of a custom or predefined playbook that requests a user's approval.
• Response action. Actions that are launched within playbooks.
• Assets. Number of the assets for which the playbook or response action is launched. You can view the list of assets for which the user's approval is requested by clicking the link with the number of the assets.
• Response parameters. Response action parameters that are specified in the response action or playbook algorithm.
• Alert or incident ID. ID that contains a link to the alert or incident details.

Approving and rejecting playbooks

To approve or reject playbooks:

1. In the notification at the top of Open Single Management Platform Console, click the View approval requests link.

   A notification with the View approval requests link is displayed only if there is a playbook that is waiting for a user's approval.

2. In the Approval requests pane that opens, select one or more playbooks, and then do one of the following:
   • To approve the launching of a playbook, click the Approve button.

     After that, the playbook is launched. The action status in the Response history sections changes to In progress.

   • To decline the launching of a playbook, click the Reject button.

     After that, the launching of the playbook is canceled. The action status in the Response history sections changes to Rejected.

3. Click the Close button () to close the Approval requests pane.

After approving or rejecting playbooks, you can view their statuses in the Response history section.

Approving and rejecting response actions

To approve or reject response actions:

1. In the notification at the top of Open Single Management Platform Console, click the View approval requests link.

   A notification with the View approval requests link is displayed only if there is a response action that is waiting for a user's approval.

   The Approval requests pane opens.

2. In the Approval requests pane that opens, in the Assets column, click the link with the number of assets.

   The Assets to approve pane that contains the full list of assets opens.

3. Check the list of assets for which the manual approval is required, and then do one of the following:
   • To approve the launch of a response action for assets, select one or more assets you need, and then click the Approve button. After that, the response action for the selected assets is launched.
   • To decline the launch of a response action for assets, select one or more assets you need, and then click the Reject button. After that, the launch of the response action for the selected assets is canceled.
4. Click the Close button () to close the Assets to approve pane.
5. Click the Close button () to close the Approval requests pane.

After approving or rejecting response actions, you can view their statuses in the Response history section.

Enrichment from playbook

After you configure integration between Kaspersky Next XDR Expert and Kaspersky TIP, you can obtain information about the reputation of observables related to an alert or incident from Kaspersky TIP or Kaspersky OpenTIP, and then enrich the obtained data.

You can obtain information only for observables with the following types: domain, URL, IP, MD5, SHA256.

You can configure data enrichment to run automatically. To do this, when creating or editing a playbook, in the Algorithm section you must specify the following:

1. Data source.

   You can specify one of the following services:

   • TIP—Kaspersky Threat Intelligence Portal (General access)
   • OpenTIP—Kaspersky Threat Intelligence Portal (Premium access)
2. Limit for data returned by Kaspersky TIP or Kaspersky OpenTIP, if necessary.

   You can specify one of the following values:

   • All records
   • Top100

     This value is set by default.

3. Observable for which the playbook requests data from Kaspersky TIP or Kaspersky OpenTIP.

In the playbook algorithm, you can use the output enrichment parameters that are displayed in the fields that Kaspersky TIP returns.

You can view the enrichment result for all observables related to an alert or incident in one of the following ways:

• From the alert or incident details
• From a response history
• From a playbook

To view an enrichment result:

1. In the main menu, go to the Monitoring & reporting section, and then do one of the following:
   • If you want to view the result from an alert or incident details, go to the Alerts or Incidents section, and then click the ID of the alert or incident for which the enrichment was performed. In the window that opens, go to the History tab, and then select the Response history tab.
   • If you want to view the result from a response history, go to the Response history section.
   • If you want to view the result from a playbook, go to the Playbooks section, and then click the name of the playbook for which the enrichment was performed. In the window that opens, go to the History tab.
2. In the Action status column, click the status of the playbook for which you want to view the enrichment result.

You can also obtain the information from Kaspersky TIP, and then enrich data manually on the Observables tab in alert or incident details.

Viewing response history

The Response history section allows you to view the detailed response history for all detected alerts and incidents. Note that if an alert or incident is deleted, the response history for this alert or incident is not displayed.

To view a response history, you must have one of the following roles: Main administrator, Junior analyst, Tier 1 analyst, Tier 2 analyst, SOC manager, Approver, Observer, Tenant administrator.

To view a response history, in the main menu, go to Monitoring & reporting → Response history. The table that contains the response history for all alerts and incidents opens.

To filter the data in the table,

Click the Filter button, and then, on the Filters tab, specify and apply the filter criterion in the invoked menu.

The table contains the following columns:

• Actions. Response action or playbook name.
• Response parameters. Response action parameters that are specified in the response action or playbook algorithm.
• Start. Date and time the playbook or response action was launched.
• End. Date and time the playbook or response action was completed.
• Alert or incident ID. ID that contains a link to the alert or incident details.
• Launched by. Name of the user who launched the playbook or response action.
• Action status. Execution status of the playbook or response action. The following values can be shown in this column:
  • Awaiting approval—Response action or playbook awaiting approval for launch.
  • In progress—Response action or playbook is in progress.
  • Success—Response action or playbook is completed without errors or warnings.
  • Warning—Response action or playbook is completed with warnings.
  • Error—Response action or playbook is completed with errors.
  • Terminated—Response action or playbook is completed because the user interrupted the execution.
  • Approval time expired—Response action or playbook is completed because the approval time for the launch has expired.
  • Rejected—Response action or playbook is completed because the user rejected the launch.
• Assets. Number of the assets for which the playbook or response action is launched. You can click the link with the number of the assets to view the asset details.
• Asset type. Type of asset for which the response action or playbook is launched. Possible values: Device or User.
• Tenant. Name of the tenant to which the playbook belongs.

Predefined playbooks

Kaspersky Next XDR Expert provides ready-to-use predefined playbooks that are created by Kaspersky experts. Predefined playbooks are based on KUMA correlation rules. For more information on the KUMA correlation rules included in the distribution kit, see Correlation rules.

You can find predefined playbooks in the Playbooks section. Such playbooks are marked with the tag "Predefined" and the [KL] prefix in the name.

Note that you cannot edit the parameters of a predefined playbook, except for the Operation mode and the Running instances fields. If you want to edit other parameters of a predefined playbook, you need to duplicate the playbook, and then use it as a template to create a custom playbook. For details, refer to Customizing playbooks.

Before using the predefines playbooks, you must do the following in KUMA:

• Configure the enrichment rule settings for the event enrichment with the Event type selected as the Source kind setting. Specify the VictimUserID and AttackerUserID values in the Target field.
• Configure enrichment in KUMA to get Windows Event Log.

Predefined playbooks cannot be deleted.

Predefined playbooks belong to the parent tenant and are inherited by all child tenants.

[KL] P001 "Creation of executable files by office applications"

This playbook contains the Responding through KASAP response action, and can be used only as a template. If you want to launch the playbook, click the Duplicate and edit button. In the Edit playbook window that opens, in the Algorithm section, specify the KASAP group ID for the groupId parameter.

Before using the playbook, you must configure enrichment in KUMA to get Windows Event Log.

By default, the playbook launches the response actions for all users in the alert. If you want the playbook to launch the response actions only for the victim account, you can do the following:

1. In KUMA, configure the enrichment rule settings. For the event enrichment that has the Event type selected as the Source kind setting, specify the VictimUserID value in the Target field.
2. In the Algorithm section of the playbook, specify and .IsVictim in the assets parameter, as shown below:

   "assets": "${[ alert.Assets[] | select(.Type == \"user\" and .IsVictim) | .ID]}".

The [KL] P001 "Creation of executable files by office applications" predefined playbook allows you to prevent an attacker from using office applications, for example, to perform a phishing attack when a user opens an infected document, and then the document creates an executable file and executes it.

The alert that triggers the playbook is created according to the Creation of executable files by office applications correlation rule. This rule helps to detect the creation of files with suspicious extensions such as scripts and executable files on behalf of office applications.

The Trigger section of the playbook contains the following expression:

[.OriginalEvents[] | .ExternalID == "R350"] | any

During execution, this playbook launches the following response actions:

1. Responding through Active Directory, and then resetting the passwords of both the attacker and the victim accounts.

   If an error occurs during the execution of the response action, the playbook is terminated.

2. Responding through KASAP, and then assigning an information security course to the account.

   If an error occurs during the execution of the response action, the execution of the playbook will continue.

The Algorithm section of the playbook contains the following sequence of response actions:

{

"dslSpecVersion": "1.0.0",

"version": "1",

"responseActionsSpecVersion": "1",

"executionFlow": [

{

"responseAction": {

"function": {

"type": "resetLDAPPassword",

"assets": "${[ alert.Assets[] | select(.Type == \"user\") | .ID]}"

},

"onError": "stop"

}

},

{

"responseAction": {

"function": {

"type": "assignKasapGroup",

"assets": "${[ alert.Assets[] | select(.Type == \"user\") | .ID]}",

"params": {

"groupId": "SET KASAP GROUP ID"

}

},

"onError": "continue"

}

}

]

}

[KL] P002 "Windows Event Log was cleared"

By default, this playbook operates in the Manual operation mode. We do not recommend switching this playbook to the Auto or the Training operation mode.

Before using the playbook, you must do the following in KUMA:

• Configure the enrichment rule settings for the event enrichment that has the Event type selected as the Source kind setting. Specify the AttackerUserID value in the Target field.
• Configure enrichment in KUMA to get Windows Event Log.

The [KL] P002 "Windows Event Log was cleared" predefined playbook allows you to prevent an attacker from clearing the Windows Event Log, because the log contains sufficient telemetry for an investigation of the attacker's malicious activity.

The incident that triggers the playbook contains one or several alerts created according to the Windows Event Log was cleared correlation rule. This rule helps to detect when Windows logs are cleared or deleted by using the wevutil utility, the user interface, or PowerShell commands. To enable the creation of the incident, you have to configure segmentation rules.

The Trigger section of the playbook contains the following expression:

[.Alerts[] | .OriginalEvents[] | .ExternalID == "R050"] | any

During execution, this playbook launches the Responding through Active Directory response action, and then blocks the account of the attacker.

If an error occurs during the execution of the response action, the playbook is terminated.

If one or several alerts in the incident are generated by another correlation rule, the playbook does not apply to those alerts.

The Algorithm section of the playbook contains the following sequence of response actions:

{

"dslSpecVersion": "1.0.0",

"version": "1",

"responseActionsSpecVersion": "1",

"executionFlow": [

{

"responseAction": {

"function": {

"type": "blockLDAPAccount",

"assets": "${[ incident.Alerts[] | select(.OriginalEvents[] | .ExternalID == \"R050\") | .Assets[] | select(.Type == \"user\" and .IsAttacker) | .ID]}"

},

"onError": "stop"

}

}

]

}

[KL] P003 "Suspicious child process from wmiprvse.exe"

Before using the playbook, you must do the following in KUMA:

• Configure the enrichment rule settings for the event enrichment that has the Event type selected as the Source kind setting. Specify the AttackerUserID value in the Target field.
• Configure enrichment in KUMA to get Windows Event Log.

The [KL] P003 "Suspicious child process from wmiprvse.exe" predefined playbook allows you detect pairs of parent and child processes that deviate from the norm and must be viewed as suspicious.

The alert that triggers the playbook is created according to the R297_Suspicious child process from wmiprvse.exe correlation rule. This rule helps to detect the launch of suspicious processes on behalf of wmiprvse.exe.

The Trigger section of the playbook contains the following expression:

[.OriginalEvents[] | .ExternalID == "R297"] | any

During execution, this playbook launches the following response actions:

1. Responding through Active Directory, and then blocks the account of the attacker.
2. Terminating the process on the device that is registered in the alert.
3. Running a malware scan, and then a full scan is performed on the device where the alert is detected.

   By default, network drives are not scanned, to avoid overloading the system. If you want to scan the network drives, you have to duplicate this playbook, and then set the allowScanNetworkDrives parameter to true in the Algorithm section.

The Algorithm section of the playbook contains the following sequence of response actions:

{

"dslSpecVersion": "1.0.0",

"version": "1",

"responseActionsSpecVersion": "1",

"executionFlow": [

{

"responseAction": {

"function": {

"type": "blockLDAPAccount",

"assets": "${[ alert.Assets[] | select(.Type == \"user\" and .IsAttacker) | .ID]}"

},

"onError": "stop"

}

},

{

"split": {

"input": "${ [alert.OriginalEvents[] | [select(.DestinationProcessName != null and .DestinationProcessName != \"\")][] | .DestinationProcessName] }",

"onError": "stop",

"steps": [

{

"responseAction": {

"function": {

"type": "killProcess",

"params": {

"path": "${ .[0] }"

},

"assets": "${[ alert.Assets[] | select(.Type == \"host\") | .ID]}"

}

}

}

]

}

},

{

"responseAction": {

"function": {

"type": "avScan",

"params": {

"scope": {

"area": "full",

"allowScanNetworkDrives": false

},

"wait": false

},

"assets": "${[ alert.Assets[] | select(.Type == \"host\") | .ID]}"

},

"onError": "stop"

}

}

]

}

If an error occurs during the execution of any response action, the playbook is terminated.

Playbook trigger

The playbook trigger is a filter that allows you to select alerts or incidents for which a playbook must be launched. The filter (trigger) is applied to each object (alert or incident) individually and takes a single value: either true or false. A trigger consists of expressions in the jq language that processes structured data in the JSON format. For more information about jq expressions, refer to jq Manual.

In Kaspersky Next XDR Expert, gojq is used. It is an implementation of jq written in the go language, which has the following differences from jq:

• Mathematical functions are implemented in a more convenient way.
• Errors messages have a clear indication of where to fix your query.
• Integer calculations are more accurate.
• Functions that work incorrectly in jq are improved in gojq.

For more information about the differences between gojq and jq, refer to GitHub.

How to write a trigger

You can write a trigger in the Trigger section when creating or editing a playbook.

The following suggestions can be displayed:

• Names of functions.
• Special values.
• Fields that are specified as object identifiers in accordance with the data model.

The suitable values are filtered and displayed in the list of suggestions when you start writing.

The jq language also provides syntax highlighting and validation of jq expressions. If the trigger has invalid expressions, you cannot save the playbook.

Depending on the option you select in the Scope list when creating or editing a playbook, alert data model or incident data model is used.

The names of parameters in a playbook trigger must be the same as in the data model. Note that elements of jq expressions are case-sensitive.

To avoid overloading the system, it is not recommended to specify OriginalEvents, Observables, Extra, and Alerts data in the trigger.

When writing a trigger, basic syntax rules are used.

To refer to structure properties, you must use dot "." and specify the attribute, for example:

• .MITRETactics[]—To view the array of MITRE tactics associated with all triggered IOA rules in the alert.
• .MITRETactics[0]—To view the first element from the MITRE tactics array.

To refer to child properties, you can either use the pipe (|) or the same combination without the pipe, for example:

• .Assignee[0].Name or Assignee[0] | .Name—The expression outputs the name of the user to whom the alert is assigned.
• .MITRETactics[0].ID or .MITRETactics[0] | .ID—The expression outputs the ID of the first MITRE tactic.

To get a value, you have to use the following operators: ==, >, <, >=, <=, !=, for example:

• .Assignee[0] | .Name == "user"—The expression returns true if the alert is assigned to the user.
• (.Serverity == "high") and (.DetectSource == "KES")—The expression returns true if the alert severity level is high and the source of data is Kaspersky Endpoint Security.
• [ .DetectionTechnologies[] | . == "IOC" ] | any —The expression returns true if the IOC detection technology is triggered.
• .DetectionTechnologies | length > 1—The expression returns true if more than one detection technology is triggered.

To enumerate values in an array of objects, you can use the any method, for example:

• [.Assets[] | .Name == "W21H2-X64-3160"] | any—The expression filters the alert where any element of the Assets array has the W21H2-X64-3160 value in the Name field.
• [.Observables[] | .Value == "127.0.0.1"] | any—The expression filters the alert where any element of the Observables array has the 127.0.0.1 value in the Value field.
• [.Assets[].ID]—To output the array of IDs.
• [.Assets[] | select(.AttackerOrVictim=="attacker") | .ID]—To display an array of IDs for the assets filtered by the AttackerOrVictim field.

If you want to reuse calculations, specify a variable with $. For example, the expression event.manual != true as $not_manual | [ .DetectionTechnologies[] | . == "IOC" ] | any and $not_manual defines and uses the $not_manual variable that contains a flag that shows if the change is manual or not.

To work with dates, you can use the following functions:

• now—To get the current Unix time in seconds, for example, now == 1690541520.537496.
• todate—To get the current Unix time in seconds, for example, now | todate == "2023-07-28T10:47:36Z".
• fromdate—To convert the date to seconds, for example:
  • .CreatedAt | split(".")[0] + "Z"—This command removes milliseconds and converts the string to the 2023-07-15T07:49:51Z format.
  • (.CreatedAt | split(".")[0] + "Z") | fromdate == 1689407391—The conversion to seconds is finished.

Jq uses iterators—an interface that provides access to elements of a collection, for example, an array, and allows you to navigate through them. Iterators are always the result of calculation. The difference is in the number of elements that the iterator contains. In Kaspersky Next XDR Expert, an iterator must have only one element; the other cases are considered an error.

To write a correct trigger, you have to wrap an iterator into square brackets ([ ... ]). For example, the .DetectionTechnologies[] == "IOC" trigger will cause an error because it returns an iterator with two elements. The correct trigger must have the following form: [ .DetectionTechnologies == "IOC" ] | any, where first you have to use [] to wrap the result of the comparison into an array, and then process it with the any method that returns true if at least one element of the array is true. Otherwise, false is returned.

When the trigger runs

The search for a suitable playbook starts when one of the following triggering events occurs:

• New alert/incident is created.
• Any field of an active alert/incident is changed.
• When creating or editing a playbook, the user selected the Launch the playbook for all matching alerts or incidents. Note that the system may be overloaded check box.

The following types of alert change events are supported:

• Assigning or removing an analyst.
• Changing an alert status.
• Changing basic events.
• Linking or unlinking an alert to or from an incident.
• Changing the value in the ExternalReference field.

The following types of incident change events are supported:

• Assigning or removing an analyst.
• Changing an incident status.
• Changing basic events.
• Linking or unlinking an alert to or from an incident.
• Changing an incident name.
• Changing an incident description.
• Changing an incident priority.
• Changing the value in the ExternalReference field.
• Merging incidents.

The alert/incident structure does not contain any data about the alert/incident changes. This data is transferred in additional information. If in a playbook trigger you want to refer to the changes, use the event function without arguments.

By default, manual changes to an alert or incident details are ignored. If you want a playbook to launch for manual changes, you have to use the event.manual function in the trigger, for example:

• event.manual and ([ event.updateOperations[] | . == "alertReopened" ] | any)—The trigger works only if the alert is manually reopened.
• [ event.updateOperations[] | . == "alertLinkedWithIncidentBySystem" ] | any—The trigger works only if the alert is automatically linked to an incident.
• event.manual != null and (([ event.updateOperations[] | . == "alertChangedToNew" ] | any) | not)—The trigger works if the alert status is changed to any status other than New, either manually or automatically.
• event == null and .Status == "inIncident"—The trigger works for all alerts with the In incident status, but only when the playbook is changed, not the alert.

If necessary, you can test examples of jq expressions, apply filters, and then view the results in the Jq playground service.

Playbook algorithm

Expand all | Collapse all

Kaspersky Next XDR Expert allows you to respond to alerts and incidents manually or automatically by using playbooks. Responding to alerts or incidents may consist not of a single action, but of a whole set of steps and parameters. These steps depend on the specified conditions, the alert or incident data, and the results of previous response actions.

The playbook algorithm allows you to specify the sequence of response actions, the necessary conditions and the required impact on the target objects in the JSON format. The playbook algorithm steps are performed sequentially, one step after another. You can specify the playbook algorithm when creating or editing a playbook.

After launch, the playbook obtains all the alert or incident data and places them in global data. The playbook uses the following data:

• Global data.

  Global data is readable at any step of the playbook. Global data contains information about the alert or incident for which the playbook was launched.

  You cannot edit global data by using a playbook, or by changing alert or incident data. Global data remains unchanged for the entire lifetime of the playbook instance.

• Operational data.

  Operational data is transferred between the steps of the playbook. You can manage operational data by using jq expressions, which are specified in the input and output parameters.

• Local data.

  Local data is limited to a specific step. You can manage local data by using the input (local data generation) and output (generation of operational data from local data) parameters.

How to write an algorithm

The playbook algorithm is written in JSON format and consists of two main parts:

• General information on playbook:
  • Name (name)
  • Description (description)
  • Scope (inputType)
  • Transformation of the input data of the playbook (input)
  • Transformation of the output data of the playbook (output)
  • Playbook execution timeout (playbookRunTimeout)
  • Timeout policies that can be applied at specific steps (timeouts)
  • Playbook version (version)
  • DSL schema version (dslSpecVersion)
  • Response action schema version (responseActionsSpecVersion)
• Playbook execution steps (executionFlow).

The following parameters are required when writing the algorithm:

• name
• inputType
• dslSpecVersion. The required value: 1.0.0.
• responseActionsSpecVersion
• version
• executionFlow (at least one execution step)

  Each execution step has its own required fields.

If you try to save a playbook without filling in the required fields, an error will appear.

The playbook algorithm is case sensitive. To use the asset data of the alert, you need to capitalize the Assets parameter. For example: alert.Assets[]. However, to use asset data in the input data when manually launching the playbook for target objects, do not capitalize the assets parameter. For example: .input.assets[].

Depending on the scope you selected when creating or editing a playbook, you can use alert data model or incident data model in the algorithm. To do that, write expressions in the jq language with an alert or incident value (do not use dot "." at the beginning of the value). For example:

"${[ alert.Assets[] | select(.Type == \"user\" and .IsAttacker) | .ID]}"

You can use alert or incident data in a jq expression at any execution step. The alert or incident data is only available in read mode. This data does not change during the operation of the playbook. If alert or incident data has changed after launching the playbook, it will not affect the playbook execution.

You also can use the jq expressions when use the playbook data in the algorithm. For more information about jq expressions, refer to jq Manual.

If you use quotation marks in the jq expression, you need to escape these marks with backslashes. For example: "${[ alert.Assets[] | select(.Type == \"user\" and .IsAttacker) | .ID]}".

Backslashes that are not used to escape quotation marks must also be escaped by other backslashes. For example: ${\"add_firewall_rule --ip_address=\" + ([.input.observables[] | select(.type == \"ip\") | select(.value | test(\"^(10\\\\.|172\\\\.(1[6-9]|2[0-9]|3[01])\\\\.|192\\\\.168\\\\.|127\\\\.).*\") | not) | .value] | join(\",\"))}.

If you want to launch the playbook for the specific object (observables or assets), use the .input parameter in the algorithm. These objects will be the input to the playbook when it is launched. For example:

"assets": "${ [.input.assets[] | select(.Type == \"host\") | .ID] }"

For details, refer to Launching playbooks for objects specified by users.

How to call hints

If you need a hint on the available fields when writing the algorithm, use quotation marks (""). A list of available fields appears.

To display hints on the alert or incident data, write alert or incident in the jq expression with a dot "." at the end.

The correct hint appears if there are no errors in the above expressions. Otherwise, the list of available fields may be incorrect.

Example of the playbook algorithm

Playbook parameters

Execution step parameters

The array of execution step elements describes a playbook's logic. The execution steps are performed in the order described in the playbook. There are several types of execution steps:

• ResponseAction
• Split
• Scatter-gather
• Switch
• UpdateData

ResponseAction parameters

The Response action parameters call the response function.

Timeout policy

The timeout policy of execution steps. The system automatically determines the default timeout policy.

The default timeout policy can be reconfigured by using the default policy name. In this case, the new policy will be automatically applied to all execution steps.

Output

The output parameter generates operational data at the end of a step, which will then be transferred to the next step. Specify the output parameter if you want to use the results of the current step of the playbook in the next step.

To avoid overloading the system, it is recommended to limit the data placed in the playbook data (local or operational).

Manual approve

Email notification settings

Split

Before specifying the split parameter, make sure that the aggregate parameter is also specified in the playbook algorithm.

The split parameters are used to split the array of incoming data by elements and to perform various actions on the elements.

Scatter-gather

Before specifying the scatter-gather parameter, make sure that the aggregate parameter is also specified in the playbook algorithm.

The Scatter-gather parameters are used to perform several actions on the data at the same time. Unlike Split, Scatter-gather transmits the same input data to different execution branches.

Branch

Switch

An execution step that allows you to perform a step or set of steps according to a condition. Note that only the first verified condition will be executed.

Condition

UpdateData

The UpdateData parameter can be described either as a jq script with state change logic, or as an Output object.

ResponseFunction parameters

Response action parameters