Threat response

To perform response actions, view the result of an enrichment that you performed from the playbook, and launch playbooks manually, you have to go to the Alerts or Incidents sections.

The Alerts and Incidents sections are displayed in the main menu if the following conditions are met:

• You have a license key for Kaspersky Next XDR Expert.
• You are connected to the root Administration Server in OSMP Console.
• You have one of the following XDR roles: Main administrator, Tenant administrator, Junior analyst, Tier 1 analyst, Tier 2 analyst, SOC manager, Interaction with NCIRCC, Approver, Observer.

After you perform a response action, you can view the response history.

Response actions

The response actions can be launched in one of the following ways:

• Manually, as described in this section.
• Within a playbook.

  In this case, when creating or editing a playbook you can configure the response action to run automatically, or to request the user's manual approval before launching within the playbook. By default, manual approval of response actions is disabled.

Terminating processes

The Terminate process response action allows you to remotely terminate processes on devices. You can run the Terminate process response action for observables or assets.

You can run the Terminate process response action in one of the following ways:

• From alert or incident details
• From a device details
• From an investigation graph

You can also configure the response action to run automatically when creating or editing a playbook.

To run the Terminate process response action, you must have one of the following XDR roles: Main administrator, Junior analyst, Tier 1 analyst, Tier 2 analyst, Tenant administrator.

It might take up to 15 minutes to launch a response action due to the synchronization interval between the managed device and Administration Server.

Running the Terminate process for observables

To run the Terminate process for observables:

1. Do one of the following:
   • In the main menu, go to Monitoring & reporting → Alerts. In the ID column, click the link with the alert ID you need.
   • In the main menu, go to Monitoring & reporting → Incidents. In the ID column, click the link with the incident ID you need.
2. In the window that opens, go to the Observables tab.
3. In the list of observables, select one or several observables for which you want to terminate the process. The observables may include:
   • MD5
   • SHA256
4. Click the Terminate process button.
5. In the Terminate process pane that opens, select assets for which you want to terminate the process.
6. Click the Terminate button.

The process is terminated.

Running the Terminate process for assets

To run the Terminate process for assets:

1. Do one of the following:
   • In the main menu, go to Monitoring & reporting → Alerts. In the ID column, click the link with the alert ID you need.
   • In the main menu, go to Monitoring & reporting → Incidents. In the ID column, click the link with the indent ID you need.
2. In the window that opens, go to the Assets tab.
3. In the list of assets, select one or several devices you need.
4. Click the Select response action button, and then click Terminate process.
5. In the Terminate process pane that opens, specify one of the following parameters:
   • PID. ID of the process.

     For the Terminate process by PID response action with fixed scope, if the assets of the response action belong to the same Administration Server, you can run this response action for only one asset at a time.

     For the Terminate process by PID response action with modifiable scope, you cannot run this response action.

   • Hash (MD5 or SHA256 hash algorithm) and Path to the process file.
6. Click the Terminate button.

The process is terminated.

Running the Terminate process from an investigation graph

The option is available if the investigation graph is built.

To run the Terminate process from an investigation graph:

1. In the main menu, go to Monitoring & reporting → Incidents. In the ID column, click the link with the incident ID you need.
2. In the Incident details window that opens, click the View on graph button.

   The Investigation graph window opens.

3. Click the name of the alert you need, and then click View details.
4. In the window that opens, go to the Observables tab.
5. In the list of observables, select one or several observables for which you want to terminate the process. The observables may include:
   • MD5
   • SHA256
6. Click the Terminate process button.
7. In the Terminate process pane that opens, select assets for which you want to terminate the process.
8. Click the Terminate button.

The process is terminated.

Moving devices to another administration group

As a response action, you can move a device to another administration group of Open Single Management Platform. This may be required when the analysis of an alert or incident shows that the protection level of the device is low. When you move a device to another administration group, the group policies and tasks are applied to the device.

The administration group to which you move the device must belong to the same tenant as the device.

You can move a device to another administration group in one of the following ways:

• From the alert or incident details
• From the device details
• From an investigation graph

You can also configure the response action to run automatically when creating or editing a playbook.

To move a device to another administration group, you must have one of the following XDR roles: Main administrator, Tenant administrator, Junior analyst, Tier 1 analyst, Tier 2 analyst.

It might take up to 15 minutes to launch a response action due to the synchronization interval between the managed device and Administration Server.

Moving a device to another administration group from alert or incident details

To move a device to another administration group from alert or incident details:

1. Do one of the following:
   • In the main menu, go to Monitoring & reporting → Alerts. In the ID column, click the ID of the alert that includes the device to be moved.
   • In the main menu, go to Monitoring & reporting → Incidents section. In the ID column, click the ID of the incident that includes the device to be moved.
2. In the window that opens, go to the Assets tab.
3. Select check box next to the device to be moved to another administration group.

   You can select several devices, if the devices are managed by the same Administration Server: primary, secondary, or virtual.

4. In the Select response actions drop-down list, select Move to group.

   The Move to group window that opens on the right side of the screen displays the administration groups of the Administration Server that manages the selected device.

5. Select the administration group to which you want to move the device, and then click the Move button.

The device will be moved to the selected administration group. An appropriate message is displayed on the screen.

Moving a device to another administration group from the device details

To move a device to another administration group from the device details:

1. Do one of the following:
   • In the main menu, go to Monitoring & reporting → Alerts. In the ID column, click the ID of the alert that includes the device to be moved.
   • In the main menu, go to Monitoring & reporting → Incidents section. In the ID column, click the ID of the incident that includes the device to be moved.
2. In the window that opens, go to the Assets tab.
3. Click the name of the required device, and then in the drop-down list, select View properties.
4. In the Select response actions drop-down list, select Move to group.

   The Move to group window that opens on the right side of the screen displays the administration groups of the Administration Server that manages the selected device.

5. Select the administration group to which you want to move the device, and then click the Move button.

The device will be moved to the selected administration group. An appropriate message is displayed on the screen.

Moving a device to another administration group from an investigation graph

This option is available if the investigation graph is built.

To move a device to another administration group from an investigation graph:

1. In the main menu, go to Monitoring & reporting → Incidents section. In the ID column, click the ID of the incident that includes the device to be moved.
2. Click the View on graph button.
3. In the investigation graph that opens, click the device name to open the device details.
4. In the Select response actions drop-down list, select Move to group.

   The Move to group window that opens on the right side of the screen displays the administration groups of the Administration Server that manages the selected device.

5. Select the administration group to which you want to move the device, and then click the Move button.

The device will be moved to the selected administration group. An appropriate message is displayed on the screen.

Running a malware scan

To prevent a threat distribution on an infected device, you can run a malware scan in one of the following ways:

• From the alert or incident details
• From the device details
• From an investigation graph

You can also configure the response action to run automatically when creating or editing a playbook.

To perform the Malware scan response action, you must have one of the following XDR roles: Main administrator, Tenant administrator, Junior analyst, Tier 1 analyst, Tier 2 analyst.

It might take up to 15 minutes to launch a response action due to the synchronization interval between the managed device and Administration Server.

Running a malware scan from the alert or incident details

To scan a device for malware from the alert or incident details:

1. Do one of the following:
   • In the main menu, go to Monitoring & reporting → Alerts. In the ID column, click the ID of the alert that includes the device to be scanned.
   • In the main menu, go to Monitoring & reporting → Incidents section. In the ID column, click the ID of the incident that includes the device to be scanned.
2. In the window that opens, go to the Assets tab.
3. Select check box next to the device to be scanned.

   You can select several devices, if necessary.

4. In the Select response actions drop-down list, select Run virus scan.

   The Virus scan window opens on the right side of the screen.

5. Select the type of malware scan:
   • Full scan

     You can switch the Network drives toggle button to include network devices into the scan. By default, this option is disabled.

     A full scan can slow down the device due to an increased load on its operation system.

   • Critical areas scan

     The kernel memory, running processes, and disk boot sectors are scanned if you select this type.

   • Custom scan

     In the Specify a path to the file field, specify a path to the file that you want to scan. If you want to set several paths, click the Add path button, and then specify the path.

6. Click the Scan button.

The selected type of malware scan starts.

Running a malware scan from the device details

To scan a device for malware from the device details:

1. Do one of the following:
   • In the main menu, go to Monitoring & reporting → Alerts. In the ID column, click the ID of the alert that includes the device to be scanned.
   • In the main menu, go to Monitoring & reporting → Incidents section. In the ID column, click the ID of the incident that includes the device to be scanned.
2. In the window that opens, go to the Assets tab.
3. Click the name of the required device, and then in the drop-down list, select View properties.

   You can click the Edit in KUMA button to edit parameters of the device in KUMA Console, if necessary.

4. In the Select response actions drop-down list, select Run virus scan.

   The Virus scan window opens on the right side of the screen.

5. Select the type of malware scan. The types are described at step 5 in Running a malware scan from the alert or incident details.
6. Click the Scan button.

The selected type of malware scan starts.

Running a malware scan from an investigation graph

This option is available if the investigation graph is built.

To scan a device for malware from an investigation graph:

1. In the main menu, go to Monitoring & reporting → Incidents section. In the ID column, click the ID of the incident that includes the device to be scanned.
2. Click the View on graph button.
3. In the investigation graph that opens, click the device name to open the device details.
4. In the Select response actions drop-down list, select Run virus scan.

   The Virus scan window opens on the right side of the screen.

5. Select the type of malware scan. The types are described at step 5 in Running a malware scan from the alert or incident details.
6. Click the Scan button.

The selected type of malware scan starts.

If the malware scan is completed successfully, an appropriate message is displayed on the screen, and the alert or incident is displayed in the alert table or incident table with the Success action status. Otherwise, an error message is displayed, and the alert or incident is displayed with the Error action status.

After the malware scan operation is finished, you can view the result.

Viewing the result of the malware scan

After the malware scan is finished, you can view its result in one of the following ways:

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

To view the result of the malware scan:

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 alert or incident details, go to the Alerts or Incidents section, and then click the ID of the alert or incident for which malware scan was performed. In the window that opens, go to the History tab, and then select the Response history tab to display the list of events.
   • If you want to view the result from a response history, go to the Response history section.
   • If you want to view the result of the malware scan from a playbook, go to the Playbooks section, and then click the name of the playbook for which the malware scan was performed. In the window that opens, go to the History tab to display the list of events.
2. In the Action status column, click the status of the event for which you want to view the results of the malware scan.

   In the window that opens, a table of detections is displayed. In the Administration Server field, you can select the Administration Server for which a table of detections is displayed.

   The table contains the following columns:

   • Device. Device name or ID.
   • Path. Path to the file.
   • Hash. SHA256.
   • Detection name. Name of the detection that occurred on the device.
   • Action status. Threat processing result.
   • User. Account of the user who is associated with the detection.

Updating databases

To detect threats quickly and keep the protection level of a client device up to date, you have to regularly update databases and application modules on the device.

You can update databases on a device in one of the following ways:

• From the alert or incident details
• From the device details
• From an investigation graph

You can also configure the response action to run automatically when creating or editing a playbook.

To update databases on a device, you must have one of the following XDR roles: Main administrator, Tenant administrator, Junior analyst, Tier 1 analyst, Tier 2 analyst.

It might take up to 15 minutes to launch a response action due to the synchronization interval between the managed device and Administration Server.

Updating databases from the alert or incident details

To update databases on a device from the alert or incident details:

1. Do one of the following:
   • In the main menu, go to Monitoring & reporting → Alerts. In the ID column, click the ID of the alert that includes the device on which databases are to be updated.
   • In the main menu, go to Monitoring & reporting → Incidents section. In the ID column, click the ID of the incident that includes the device on which databases are to be updated.
2. In the window that opens, go to the Assets tab.
3. Select check box next to the devices on which databases are to be updated.

   You can select several devices, if necessary.

4. In the Select response actions drop-down list, select Update databases.

If the operation is completed successfully, an appropriate message is displayed on the screen. Otherwise, an error message is displayed.

Updating databases from the device details

To update databases on a device from the device details:

1. Do one of the following:
   • In the main menu, go to Monitoring & reporting → Alerts. In the ID column, click the ID of the alert that includes the device on which databases are to be updated.
   • In the main menu, go to Monitoring & reporting → Incidents section. In the ID column, click the ID of the incident that includes the device on which databases are to be updated.
2. In the window that opens, go to the Assets tab.
3. Click the name of the required device, and then in the drop-down list, select View properties.
4. In the Select response actions drop-down list, select Update databases.

If the operation is completed successfully, an appropriate message is displayed on the screen. Otherwise, an error message is displayed.

Updating databases from an investigation graph

This option is available if the investigation graph is built.

To update databases on a device from an investigation graph:

1. In the main menu, go to Monitoring & reporting → Incidents section. In the ID column, click the ID of the incident that includes the device on which databases are to be update.
2. Click the View on graph button.
3. In the investigation graph that opens, click the device name to open the device details.
4. In the Select response actions drop-down list, select Update databases.

If the operation is completed successfully, an appropriate message is displayed on the screen. Otherwise, an error message is displayed.

Moving files to quarantine

To prevent a threat distribution, you can move a device on which the file is located to quarantine in one of the following ways:

• From the alert or incident details
• From the device details
• From a telemetry event
• From an investigation graph

You can also configure the response action to run automatically when creating or editing a playbook.

To move a device on which the file is located to quarantine, you must have one of the following XDR roles: Main administrator, Tenant administrator, Junior analyst, Tier 1 analyst, Tier 2 analyst.

It might take up to 15 minutes to launch a response action due to the synchronization interval between the managed device and Administration Server.

Responding from the alert or incident details

To move a device to quarantine from the alert or incident details:

1. Do one of the following:
   • In the main menu, go to Monitoring & reporting → Alerts. In the ID column, click the ID of the alert that includes the device to be moved.
   • In the main menu, go to Monitoring & reporting → Incidents section. In the ID column, click the ID of the incident that includes the device to be moved.
2. In the window that opens, go to the Assets tab.
3. Select check box next to the device which is to be moved to quarantine.

   You can select several devices, if necessary.

4. In the Select response actions drop-down list, select Move to quarantine.
5. In the window that opens on the right side of the screen, specify the following information in the corresponding fields:
   • File hash.

     You can select either SHA256 or MD5.

   • Path to the file.
6. Click the Move button.

If the operation is completed successfully, an appropriate message is displayed on the screen. Otherwise, an error message is displayed.

Responding from the device details

To move a device to quarantine from the device details:

1. Do one of the following:
   • In the main menu, go to Monitoring & reporting → Alerts. In the ID column, click the ID of the alert that includes the device to be moved.
   • In the main menu, go to Monitoring & reporting → Incidents section. In the ID column, click the ID of the incident that includes the device to be moved.
2. In the window that opens, go to the Assets tab.
3. Click the name of the required device, and then in the drop-down list, select View properties.
4. In the Select response actions drop-down list, select Move to quarantine.
5. In the window that opens on the right side of the screen, specify the following information on the corresponding fields:
   • File hash.

     You can select either SHA256 or MD5.

   • Path to the file.
6. Click the Move button.

If the operation is completed successfully, an appropriate message is displayed on the screen. Otherwise, an error message is displayed.

Responding from a telemetry event

To move a device to quarantine from a telemetry event:

1. In the main menu, go to Monitoring & reporting → Alerts. In the ID column, click the ID of the alert that includes the device to be moved.
2. In the window that opens, go to the Details tab, and do one of the following:
   • Click the name of the required event and select the device.
   • Click the Find in Threat hunting button to go to the Threat hunting section and select the required device.

   You can also go to the Observables tab, select check box next to the file that you want to move to quarantine, and then click the Move to quarantine button.

3. In the Select response actions drop-down list, select Move to quarantine.
4. In the window that opens on the right side of the screen, specify the following information on the corresponding fields:
   • File hash.

     You can select either SHA256 or MD5.

   • Path to the file.
5. Click the Move button.

If the operation is completed successfully, an appropriate message is displayed on the screen. Otherwise, an error message is displayed.

Responding from an investigation graph

This option is available if the investigation graph is built.

To move a device to quarantine from an investigation graph:

1. In the main menu, go to Monitoring & reporting → Incidents section. In the ID column, click the ID of the incident that includes the device to be moved.
2. In the window that opens, click the View on graph button.

   The investigation graph opens.

3. Click the device name to open the device details.
4. In the Select response actions drop-down list, select Move to quarantine.
5. In the window that opens on the right side of the screen, specify the following information on the corresponding fields:
   • File hash.

     You can select either SHA256 or MD5.

   • Path to the file.
6. Click the Move button.

If the operation is completed successfully, an appropriate message is displayed on the screen. Otherwise, an error message is displayed.

Changing authorization status of devices

You can change an authorization status of a device when the analysis of an alert or incident shows that the protection level of the device is low or the device does harm to your infrastructure.

This response action is performed on devices with KICS for Networks installed.

You can change an authorization status of a device in one of the following ways:

• From the alert or incident details
• From the device details
• From a telemetry event
• From an investigation graph

You can also configure the response action to run automatically when creating or editing a playbook.

To change an authorization status of a device, you must have one of the following XDR roles: Main administrator, Tenant administrator, Junior analyst, Tier 1 analyst, Tier 2 analyst.

Changing authorization status of devices from alert or incident details

To change an authorization status of a device from the alert or incident details:

1. Do one of the following:
   • In the main menu, go to Monitoring & reporting → Alerts. In the ID column, click the ID of the alert that includes the device which authorization status is to be changed.
   • In the main menu, go to Monitoring & reporting → Incidents section. In the ID column, click the lD of the incident that includes the device which authorization status is to be changed.
2. In the window that opens, go to the Assets tab.
3. Select check box next to the device which authorization status is to be changed.

   You can select several devices, if necessary.

4. In the Select response actions drop-down list, select Change authorization status.
5. In the window that opens on the right side of the screen, select the new status of the device (authorized or unauthorized), and then click the Change button.

   If the operation is completed successfully, an appropriate message is displayed on the screen. Otherwise, an error message is displayed.

Changing authorization status of devices from the device details

To change an authorization status of a device from the device details:

1. Do one of the following:
   • In the main menu, go to Monitoring & reporting → Alerts. In the ID column, click the ID of the alert that includes the device which authorization status is to be changed.
   • In the main menu, go to Monitoring & reporting → Incidents section. In the ID column, click the ID of the incident that includes the device which authorization status is to be changed.
2. In the window that opens, go to the Assets tab.
3. Click the name of the required device, and then in the drop-down list, select View properties.
4. In the Select response actions drop-down list, select Change authorization status.
5. In the window that opens on the right side of the screen, select the new status of the device (authorized or unauthorized), and then click the Change button.

   If the operation is completed successfully, an appropriate message is displayed on the screen. Otherwise, an error message is displayed.

Changing authorization status of devices from a telemetry event

To change an authorization status of a device from a telemetry event:

1. In the main menu, go to Monitoring & reporting → Alerts. In the ID column, click the ID of the alert that includes the device which authorization status is to be changed.
2. In the window that opens, go to the Details tab, and do one of the following:
   • Click the name of the required event and select the device.
   • Click the Find in Threat hunting button to go to the Threat hunting section and select the required device.
3. In the Select response actions drop-down list, select Change authorization status.
4. In the window that opens on the right side of the screen, select the new status of the device (authorized or unauthorized), and then click the Change button.

   If the operation is completed successfully, an appropriate message is displayed on the screen. Otherwise, an error message is displayed.

Changing authorization status of devices from an investigation graph

This option is available if the investigation graph is built.

To change an authorization status of a device from an investigation graph:

1. In the main menu, go to Monitoring & reporting → Incidents section. In the ID column, click the ID of the incident that includes the device which authorization status is to be changed.
2. In the window that opens, click the View on graph button.

   The investigation graph opens.

3. Click the device name to open the device details.
4. In the Select response actions drop-down list, select Change authorization status.
5. In the window that opens on the right side of the screen, select the new status of the device (authorized or unauthorized), and then click the Change button.

   If the operation is completed successfully, an appropriate message is displayed on the screen. Otherwise, an error message is displayed.

The selected authorization status of the device in displayed in the alert or incident card, on the Assets tab → Authorization status column.

Viewing information about KASAP users and changing learning groups

After configuring the integration between KASAP and KUMA, the following information from KASAP is available in OSMP Console when you view data about users associated with alerts or incidents:

• The learning group to which the user belongs.
• The learning courses completed by the user.
• The planned learning courses and their current progress.

You can view data about the KASAP user. To do this, you have to open a user details in one of the following ways:

• From the alert or incident details.
• From a telemetry event (if you open it from alert details).
• From an investigation graph.

  This option is available if the investigation graph is built.

To open a user details:

1. In the main menu, go to the Monitoring & reporting section, and then select the Alerts or Incidents section.

   If you want to open a user details from a telemetry event, select the Alerts section.

   If you want to open a user details from an investigation graph, select the Incidents section.

2. Click the ID of the required alert or incident.
3. In the window that opens, do one of the following:
   • If you want to open a user details from a telemetry event, go to the Details tab, and either click the name of the required event, and select the user; or click the Find in Threat hunting button to go to the Threat Hunting section, and then select the required user.
   • If you want to open a user details from alert or incident details, go to the Assets tab, and then click the name of the required user.
   • If you want to open a user details from investigation graph, click the View on graph button. In the investigation graph that opens, click the name of the required user.

   The Account details window opens on the right side of the screen.

4. Select the Cybersecurity courses tab.

   The window displays information about the KASAP user.

You can change the learning group of a KASAP user in one of the following ways:

• From the alert or incident details
• From a telemetry event (if you open it from alert details)
• From an investigation graph

  This option is available if the investigation graph is built.

You can also configure the response action to run automatically when creating or editing a playbook. In this case, if you move a user to the group for which the learning is not started, the user is not able to start learning.

To perform the response action, you must have one of the following XDR roles: Main administrator, Tenant administrator, Junior analyst, Tier 1 analyst, Tier 2 analyst.

To change the KASAP user learning group:

1. In the main menu, go to the Monitoring & reporting section, and then select the Alerts or Incidents section.

   If you want to change the KASAP user learning group from a telemetry event, select the Alerts section.

   If you want to change the KASAP user learning group from an investigation graph, select the Incidents section.

2. Click the ID of the required alert or incident.
3. In the window that opens, do one of the following:
   • If you want to respond through a telemetry event, go to the Details tab, and either click the name of the required event, and then select the user; or click the Find in Threat hunting button to go to the Threat hunting section, and then select the required user.
   • If you want to respond through a user details, go to the Assets tab, and then click the name of the user.
   • If you want to respond through an investigation graph, click the View on graph button. In the investigation graph that opens, click the name of the user.

   The Account details window opens on the right side of the screen.

4. In the Assign KASAP group drop-down list, select the KASAP learning group to which you want to assign the user.

   Recalculation of the KASAP user training plan may take up to 30 minutes. It is not advisable to change the KASAP learning group during this period.

The user is moved to the selected KASAP group. The KASAP company administrator receives a notification about the change in the learning group, and the study plan is recalculated for the selected learning group.

For details about learning groups and how to get started, refer to the KASAP documentation.

Responding through Active Directory

You can integrate Kaspersky Next XDR Expert with the Active Directory services that are used in your organization. Active Directory is considered to be integrated with Kaspersky Next XDR Expert after the integration between Active Directory and KUMA is configured.

The process of configuring integration between Kaspersky Next XDR Expert and Active Directory consists of configuring connections to LDAP. You must configure connections to LDAP separately for each tenant.

As a result, if an alert or an incident occurs, you will be able to perform response actions in relation to the associated users of that tenant.

You can perform a response action through Active Directory in one of the following ways:

• From the alert or incident details
• From a telemetry event (if you open it from alert details)
• From an investigation graph

  This option is available if the investigation graph is built.

You can also configure a response action to run automatically when creating or editing a playbook.

To perform a response action through Active Directory, you must have one of the following XDR roles: Main administrator, Tenant administrator, Junior analyst, Tier 1 analyst, Tier 2 analyst.

To perform a response action through Active Directory:

1. In the main menu, go to the Monitoring & reporting section, and then select the Alerts or Incidents section.

   If you want to respond from the telemetry event, select the Alerts section.

   If you respond from an investigation graph, select the Incidents section.

2. Click the ID of the required alert or incident.
3. In the window that opens, do one of the following:
   • If you want to respond through the alert or incident details, go to the Assets tab, and then click the name of the user.
   • If you want to respond through a telemetry event, go to the Details tab, and either click the name of the required event, and then select the user; or click the Find in Threat hunting button to go to the Threat Hunting section, and then select the required user.
   • If you want to respond through an investigation graph, click the View on graph button. In the investigation graph that opens, click the name of the user.

   The Account details window opens on the right side of the screen.

4. In the Response through Active Directory drop-down list, select an action that you want to perform:
   • Lock account

     If the user account is locked in response to the related alert or incident, an appropriate message is displayed on the screen. Otherwise, an error message is displayed.

   • Reset password

     If the user account password is reset in response to the related alert or incident, an appropriate message is displayed on the screen. Otherwise, an error message is displayed.

   • Add user to security group

     In the window that opens, in the mandatory field Security group DN, specify a full path to the security group to which you want to add the user. For example, CN = HQ Team, OU = Groups, OU = ExchangeObjects, DC = avp, DC = ru. Then click the Add button. Only one group can be specified within one operation.

     If the user is added to the security group in response to the related alert or incident, an appropriate message is displayed on the screen. Otherwise, an error message is displayed.

   • Delete user from security group

     In the window that opens, in the mandatory field Security group DN, specify a full path to the security group from which you want to delete the user. For example, CN = HQ Team, OU = Groups, OU = ExchangeObjects, DC = avp, DC = ru. Then click the Delete button. Only one group can be specified within one operation.

     If the user is deleted from the security group in response to the related alert or incident, an appropriate message is displayed on the screen. Otherwise, an error message is displayed.

Responding through KATA/KEDR

Expand all | Collapse all

After you configure integration between Kaspersky Next XDR Expert and Kaspersky Anti Targeted Attack Platform, you can perform response actions on a device or with a file hash in one of the following ways:

• From the alert or incident details
• From the device details
• From the event details

  This option is available for the Add prevention rule response action. 

• From an investigation graph

You can also configure the response action to run automatically when creating or editing a playbook.

To perform response actions through Kaspersky Anti Targeted Attack Platform, you must have one of the following XDR roles: Main administrator, Tenant administrator, Junior analyst, Tier 1 analyst, Tier 2 analyst.

Performing response actions from alert or incident details

To perform a response action from the alert or incident details:

1. Do one of the following:
   • In the main menu, go to Monitoring & reporting → Alerts. In the ID column, click the ID of the alert that includes the required device.
   • In the main menu, go to Monitoring & reporting → Incidents section. In the ID column, click the ID of the incident that includes the required device.
2. In the window that opens, go to the Assets tab.
3. Select the select check box next to the required device.

   You can select several devices, if necessary.

4. In the Select response actions drop-down list, select the response action that you want to perform:
   • Enable network isolation

     If you select this response action for a device on which network isolation is already enabled, the parameters are overwritten with new values.

     After you select this response action, you must configure the necessary settings in the window that opens on the right side of the screen.

   • Disable network isolation

     You can select this response action for devices on which network isolation is enabled.

   • Run executable file

     The executable file is always run on behalf of the system and must be available on the device before you start the response action.

     After you select this response action, you must configure the necessary settings in the window that opens on the right side of the screen.

   • Add prevention rule

     After you select this response action, you must configure the necessary settings in the window that opens on the right side of the screen.

   • Delete prevention rule

     You can select this response action for devices on which the prevention rule was applied.

   All of the listed response actions are available on devices that use Kaspersky Endpoint Agent for Windows or Kaspersky Endpoint Security for Windows in the role of the Endpoint Agent component. On devices with Kaspersky Endpoint Agent for Linux and Kaspersky Endpoint Security for Linux, the only available response action is Run executable file.

5. In the window that opens, set the necessary parameters for the response action you selected at step 4:
   • For network isolation
     1. Specify the period of the device isolation and the units.
     2. If you want to add an exception from the network isolation rule, click the Add exclusion button, and then fill in following fields:
        • Network traffic direction.

          You can select one of the values:

          • Inbound

            If you select this direction, you must specify a local ports range in the Start port and End port fields.

          • Outbound

            If you select this direction, you must specify a remote ports range in the Start port and End port fields.

          • Inbound/Outbound

            If you select this direction, you cannot specify a ports range.

        • Asset IP address.
     3. Click the Enable button.

        The window is closed.

   • For running executable file
     1. Fill in the following fields:
        • Path to an executable file
        • Command line parameters
        • Working directory
     2. Click the Run button.

        The window is closed.

   • For adding prevention rule
     1. Specify a hash of the file that you want to block:
        • SHA256
        • MD5

        If you want to specify more than one hash, click the Add hash button.

     2. Click the Add button.

        The window is closed.

   • For deleting prevention rule
     1. Select what you want to delete:
        • If you want to delete all prevention rules, select Delete everything.
        • If you want to delete a prevention rule by file hash, in the File hash field specify a hash of the file to delete.

          If you want to specify more than one hash, click the Add hash button.

     2. Click the Delete button.

        The window is closed.

If the response action is completed successfully, an appropriate message is displayed on the screen. Otherwise, an error message is displayed.

Performing response actions from the device details

To perform a response action from the device details:

1. Do one of the following:
   • In the main menu, go to Monitoring & reporting → Alerts. In the ID column, click the ID of the alert that includes the required device.
   • In the main menu, go to Monitoring & reporting → Incidents section. In the ID column, click the ID of the incident that includes the required device.
2. In the window that opens, go to the Assets tab.
3. Click the name of the required device, and then in the drop-down list, select View properties.
4. Perform the same actions as described at steps 4-5 in Performing response actions from the device details.

If the response action is completed successfully, an appropriate message is displayed on the screen. Otherwise, an error message is displayed.

Performing a response action from the event details

This option is available for the Add prevention rule response action. 

To perform a response action from the event details:

1. In the main menu, go to Monitoring & reporting → Alerts. In the ID column, click the ID of the alert that includes the required device.
2. In the window that opens, go to the Details tab, and select the required file hash.
3. Click the Add prevention rule button, and then select the device for which you want to add the prevention rule.

   You can also go to the Observables tab, select check box next to the file hash that you want to block, and then click the Add prevention rule button.

4. Perform the same actions as described at steps 4-5 in Performing response actions from the device details.

If the response action is completed successfully, an appropriate message is displayed on the screen. Otherwise, an error message is displayed.

Performing response actions from an investigation graph

This option is available if the investigation graph is built.

To perform a response action from an investigation graph:

1. In the main menu, go to Monitoring & reporting → Incidents section. In the ID column, click the ID of the incident that includes the required device.
2. In the window that opens, click the View on graph button.

   The investigation graph opens.

3. Click the device name to open the device details.
4. Perform the same actions as described at steps 4-5 in Performing response actions from the device details.

If the response action is completed successfully, an appropriate message is displayed on the screen. Otherwise, an error message is displayed.

If you encounter a failure when running the response actions, you have to make sure that the device name in Kaspersky Next XDR Expert is the same as in Kaspersky Anti Targeted Attack Platform.

Responding through UserGate

UserGate includes features of unified threat management solutions and provides the following means of protection for your local network:

• Firewall
• Intrusion and attack protection
• Anti-virus traffic scanning
• Application control

UserGate UTM API 7 version is supported.

You can respond to alerts and incidents through UserGate if you previously configured integration between Kaspersky Next XDR Expert and script launch service, as well as created a playbook that will launch a script for responding. You can download the scripts by clicking this link.

Download scripts

The login and password to access UserGate are stored in the ug.py script. You can change the endpoint, login, and password values in this script.

Python 3.10 is required to run the scripts.

To perform a response action through UserGate, you must have one of the following XDR roles: Main administrator, Tenant administrator, Junior analyst, Tier 1 analyst, Tier 2 analyst.

You can create playbooks that will perform the following response actions through UserGate:

• Block IP addresses, URL and domain names.

  UserGate will block IP addresses, URL and domain names as a result of the playbook launch.

• Log out the users.

  All users that are logged in to UserGate will be logged out as a result of the playbook launch.

To launch a script for responding through UserGate:

1. In the main menu, go to the Monitoring & reporting section, and then in Alerts or Incidents section, click the ID of the required alert or incident.
2. Click the Select playbook button, and then in the window that opens, select the playbook that you created for responding through UserGate.
3. Click the Launch button.

   The selected playbook launches the script for responding through UserGate.

   If the operation is completed successfully, an appropriate message is displayed on the screen. Otherwise, an error message is displayed.

The result of the playbook launch is available in the alert or incident details, on the History tab.

Responding through Ideco NGFW

Expand all | Collapse all

Ideco NGFW is a solution that acts as a filter for the internet traffic in corporate and private networks. It allows you to block IP addresses and URLs detected by Kaspersky Next XDR Expert, if you previously configured integration between Kaspersky Next XDR Expert and the script launch service.

Ideco NGFW version 16.0 or later is supported.

The login and password to access Ideco NGFW are stored in the script for integration with Ideco NGFW. You can download the script by clicking the following link:

Download script

To use the script:

1. Install the script in one of the following ways:
   • Via pip, for example:

     pip install -r requirements.txt

   • From the WHL file, for example:

     pip install ./dist/kaspersky_xdr_ideco_integration-<version>-py3-none-any.whl

   • Offline installation.

     If you do not have internet access, you must install the script offline. In this case, do the following:

     1. Download the dependencies on a computer that has internet access, by running the following command:

        pip download -r requirements.txt

     2. Move the downloaded dependencies to the device on which you will run the script.
     3. Install the dependencies by using the command:

        pip install --no-index --find-links <folder_path_to_downloaded_dependencies> -r requirements.txt

2. Configure the script in one of the following ways:
   • Via the ENV file, for example:

     cp .env.sample .env

     nano .env

   • In the body of the script (ideco.py), edit the parameters in the following strings:

     BASE_URL: str = getenv("BASE_URL", "https://your-ip:your-port")

     LOGIN: str = getenv("LOGIN", "your-login")

     PASSWORD: str = getenv("PASSWORD", "your-password")

     IP_DENY_LIMIT: int = int(getenv("IP_DENY_LIMIT", 1000))

3. Add deny rules for the IP addresses detected by Kaspersky Next XDR Expert and for malicious URLs.

To add a firewall rule that will block IP addresses:

1. Run the script by using the add_firewall_rule command.

   The command has the following logic:

   1. Check if the IP addresses exist in the Ideco NGFW object list.

      If they exist, the current IP address is not added.

      If they do not exist, the current IP address is added.

   2. Check if the list of IP addresses named XDR exists.

      If the list exists, it is reused, and IP addresses are added to it.

      If it does not exist, a new list is created, and IP addresses are added to it.

   3. Check if the firewall rule named XDR exists.

      If the firewall rule exists, it is reused, and the list of IP addresses from step 2 is added to it.

      If it does not exist, a new firewall rule is created, and the list of IP addresses from step 2 is added to it.

2. Specify the IP addresses that you want to block.

   By default, the maximum number of IP addresses is 1000. You can edit this value, as described at step 2 Configure the script.

   You must add valid IPv4 addresses, separated with commas and without spaces, for example:

   python ideco.py add_firewall_rule --ip_address "12.12.12.12, 13.13.13.13"

The deny rule for the selected IPv4 addresses is added, for example:

![Adding content filtering rule](./assets/screencasts/ideco_add_firewall_rule.gif)

To add a filtering rule that will block malicious URLs:

1. Run the script by using the add_content_filter_file command.

   The command has the following logic:

   1. Check if a category named XDR exists.

      If it exists, the URLs are added to this category.

      If it does not exist, a new category is created, and then the URLs are added to it.

   2. Check if the content filtering rule named XDR exists.

      If the content filtering rule exists, the category from step 1 is added to it.

      If it does not exist, a new content filtering rule is created, and then the category from step 1 is added to it.

2. Specify the URLs that you want to block.

   The URLs must be separated with commas, and have http:// or https:// prefixes, for example:

   python ideco.py add_content_filter_rule --url "https://url_1.com, http://url_2.com.uk, http://qwerty.nl, http://zxc.xc"

The deny rule for the specified URLs is added, for example:

![Adding content filtering rule](./assets/screencasts/ideco_add_content_filtering_rule.gif)

Responding through Ideco UTM

Ideco UTM is a solution providing the following means of protection for your corporate network:

• Firewall—Filtering network traffic, to protect the network from unauthorized access.
• Intrusion and attack protection—Identifying and blocking suspicious actions, to ensure system integrity.
• Anti-virus traffic scanning—Protecting against malware and malicious activities.
• Application control—Blocking or restricting execution of unauthorized applications.
• Web filtering—Restricting user access to websites that you consider unwanted.

Ideco UTM 15.7.35 version is supported.

You can respond to alerts and incidents by using Ideco UTM if you previously configured integration between Kaspersky Next XDR Expert and a script launch service, as well as created a playbook that will launch a script for responding. As a result of the playbook launch, Ideco UTM will block IP addresses, IP ranges, or URLs, depending on the action that you specify when creating a playbook.

To unblock the IP addresses, IP ranges, or URLs that have been blocked, you have to create and launch another playbook.

You can download the script by clicking this link:

Download script

The login and password to access Ideco UTM are stored in the env.sample configuration file. You have to copy the information from this file to a new ENV file that you create, and then specify the necessary parameters in the new file.

Python 3.10 is required to run the script.

To perform a response action through Ideco UTM, you must have one of the following XDR roles: Main administrator, Tenant administrator, Junior analyst, Tier 1 analyst, or Tier 2 analyst.

To launch a script for responding through Ideco UTM:

1. In the main menu, go to the Monitoring & reporting section, and then in the Alerts or Incidents sections, click the ID of the required alert or incident.
2. Click the Select playbook button, and then in the window that opens, select the playbook that you created for responding through Ideco UTM.
3. Click the Launch button.

   The selected playbook launches the script for responding through Ideco UTM.

   If the operation is completed successfully, an appropriate message is displayed on the screen. Otherwise, an error message is displayed.

The result of the playbook launch is available in the alert or incident details, on the History tab.

Responding through Redmine

Redmine is a web application for project management and issue tracking. It allows you to automate the scenario of working with issues in Redmine projects by using the script if you previously configured integration between Kaspersky Next XDR Expert and the script launch service.

Download the script by clicking this link:

Download script

To use the script:

1. Install the script in one of the following ways:
   • Via pip, for example:

     pip install -r requirements.txt

   • From the WHL file, for example:

     pip install ./dist/kaspersky_xdr_redmine_integration-1.0-py3-none-any.whl

   • Offline installation.

     If you do not have internet access, you have to install the script offline. In this case, do the following:

     1. Download the dependencies on a computer that has internet access, by using the following command:

        pip download -r requirements.txt

     2. Move the downloaded dependencies to the device on which you will run the script.
     3. Install the dependencies by using the following command:

        pip install --no-index --find-links <folder_path_to_downloaded_dependencies> -r requirements.txt

2. Configure the script in one of the following ways:
   • Via the ENV file, for example:

     cp .env.sample .env

     nano .env

   • In the body of the script (redmine.py), edit the parameters in the following strings:

     REDMINE_URL: str = getenv("REDMINE_URL", "http://<ip_or_hostname>")

     REDMINE_PORT: str = getenv("REDMINE_PORT", "8080")

     REDMINE_API_KEY: str = str(getenv("REDMINE_API_KEY", "<redmine_api_key>"))

You can use the script to work with issues in Redmine.

• If you want to create a new issue, run the following command:

  python redmine.py create_issue "project-identifier" "Issue subject" --description "Issue description text" --priority_id <id: int>

  Result:

  {"issue_id": 57}

• If you want to update an issue, run the following command:

  python redmine.py update_issue <issue_id: int> --subject "Subject text to be updated" --description "Description text to be updated" --priority_id <id: int>

  Result:

  {"status": "issue_updated"}

• If you want to get an issue, run the following command:

  python redmine.py get_issue <issue id: int>

  Result:

  {

  "subject": "86",

  "description": "18",

  "project_name": "Test project",

  "author_name": "Redmine Admin",

  "status_name": "backlog",

  "priority_name": "high",

  "start_date": "24.07.2023",

  "due_date": null,

  "created_on": "24.07.2023 10:56:15",

  "updated_on": "24.07.2023 17:18:38"

  }

Responding through Check Point NGFW

Expand all | Collapse all

Check Point NGFW is a solution that acts as a filter for internet traffic in corporate networks. Integration with Check Point NGFW allows you to block IP addresses and URLs detected by Kaspersky Next XDR Expert.

Check Point NGFW includes features of unified threat management solutions and provides the following means of protection for corporate networks:

• Firewall—Filtering network traffic, to protect the network from unauthorized access.
• Intrusion and attack protection—Identifying and blocking suspicious actions, to ensure system integrity.
• Anti-virus traffic scanning—Protecting against malware and malicious activities.
• Application control—Blocking or restricting execution of unauthorized applications.
• Web filtering—Restricting user access to websites that you consider unwanted.

Check Point NGFW version R81.20 or later is supported.

You can respond to alerts and incidents through Check Point NGFW if you previously configured integration between Kaspersky Next XDR Expert and the script launch service, as well as created a playbook that will launch a script for responding. To unblock the IP addresses or URLs that have been blocked, you have to create and launch another playbook.

Python 3.10 is required to run the scripts.

To perform a response action through Check Point NGFW, you must have one of the following XDR roles: Main administrator, Tenant administrator, Junior analyst, Tier 1 analyst, or Tier 2 analyst.

You can download the scripts for responding by clicking the following link:

Download script

The login and password to access Check Point NGFW are stored in the file .envSample.

To use the script:

1. Install the script in one of the following ways:
   • Via pip, for example:

     pip install -r requirements.txt

   • Offline installation.

     If you do not have internet access, you must install the script offline. In this case, do the following:

     1. Download the dependencies on a computer that has internet access, by running the following command:

        pip download -r requirements.txt

     2. Move the downloaded dependencies to the device on which you will run the script.
     3. Install the dependencies by using the command:

        pip install --no-index --find-links <folder_path_to_downloaded_dependencies> -r requirements.txt

2. Configure the script in one of the following ways:
   • Via the ENV file, for example:

     cp .env.sample .env

     nano .env

   • In the body of the script (main.py), edit the parameters in the following strings:

     BASE_IP: str = getenv("BASE_IP", "your-ip")

     BASE_PORT: str = getenv("BASE_PORT", "your-port")

     LOGIN: str = getenv("LOGIN", "your-login")

     PASSWORD: str = getenv("PASSWORD", "your-password")

3. Add deny rules for the IP addresses detected by Kaspersky Next XDR Expert and for malicious URLs.

To add a firewall rule that will block IP addresses:

1. Run the script by using the add_firewall_rule command.

   The command has the following logic:

   1. Check if the IP addresses exist in the Check Point NGFW object list.

      If they exist, the current IP address is not added.

      If they do not exist, the current IP address is added.

   2. Check if the list of IP addresses named XDR exists.

      If the list exists, it is reused, and IP addresses are added to it.

      If it does not exist, a new list is created, and IP addresses are added to it.

   3. Check if the firewall rule named XDR exists.

      If the firewall rule exists, it is reused, and the list of IP addresses from step 2 is added to it.

      If it does not exist, a new firewall rule is created, and the list of IP addresses from step 2 is added to it.

2. Specify the IP addresses that you want to block.

   By default, the maximum number of IP addresses is 1000. You can edit this value, as described in the previous procedure at step 2 Configure the script.

   You must add valid IPv4 addresses, separated with commas and without spaces, for example:

   python main.py add_firewall_rule --ip_address "12.12.12.12, 13.13.13.13"

The deny rule for the selected IPv4 addresses is added, for example:

![Adding content filtering rule](./assets/screencasts/main_add_firewall_rule.gif)

To delete a firewall rule that blocks IP addresses:

1. Run the script by using the delete_firewall_rule command.

   The command has the following logic:

   1. Check if the IP addresses exist in the Check Point NGFW object list.

      If they exist, the current IP address is not added.

      If they do not exist, the current IP address is added.

   2. Check if the list of IP addresses named XDR exists.

      If the list exists, it is reused, and IP addresses are added to it.

      If it does not exist, a new list is created, and IP addresses are added to it.

   3. Check if the firewall rule named XDR exists.

      If the firewall rule exists, it is reused, and the list of IP addresses from step 2 is added to it.

      If it does not exist, a new firewall rule is created, and the list of IP addresses from step 2 is added to it.

2. Specify the IP addresses that you want to block.

   By default, the maximum number of IP addresses is 1000. You can edit this value, as described in the previous procedure at step 2 Configure the script.

   You must add valid IPv4 addresses, separated with commas and without spaces, for example:

   python main.py delete_firewall_rule --ip_address "12.12.12.12, 13.13.13.13"

The deny rule for the selected IPv4 addresses is deleted.

To add a filtering rule that will block malicious URLs:

1. Run the script by using the add_content_filter_file command.

   The command has the following logic:

   1. Check if a category named XDR exists.

      If it exists, the URLs are added to this category.

      If it does not exist, a new category is created, and then the URLs are added to it.

   2. Check if the content filtering rule named XDR exists.

      If the content filtering rule exists, the category from step 1 is added to it.

      If it does not exist, a new content filtering rule is created, and then the category from step 1 is added to it.

2. Specify the URLs that you want to block.

   The URLs must be separated with commas, and have an http:// or https:// prefix, for example:

   python main.py add_content_filter_rule --url "https://url_1.com, http://url_2.com.uk, http://qwerty.nl, http://zxc.xc"

The deny rule for the specified URLs is added, for example:

![Adding content filtering rule](./assets/screencasts/main_add_content_filtering_rule.gif)

To delete a filtering rule that blocks malicious URLs:

1. Run the script by using the delete_content_filter_file command.

   The command has the following logic:

   1. Check if a category named XDR exists.

      If it exists, the URLs are added to this category.

      If it does not exist, a new category is created, and then the URLs are added to it.

   2. Check if the content filtering rule named XDR exists.

      If the content filtering rule exists, the category from step 1 is added to it.

      If it does not exist, a new content filtering rule is created, and then the category from step 1 is added to it.

2. Specify the URLs that you want to block.

   The URLs must be separated with commas, and have an http:// or https:// prefix, for example:

   python main.py delete_content_filter_rule --url "https://url_1.com, http://url_2.com.uk, http://qwerty.nl, http://zxc.xc"

The deny rule for the specified URLs is deleted.

To launch a script for responding through Check Point NGFW:

1. In the main menu, go to the Monitoring & reporting section, and then in the Alerts or Incidents sections, click the ID of the required alert or incident.
2. Click the Select playbook button, and then in the window that opens, select the playbook that you created for responding through Check Point NGFW.
3. Click the Launch button.

   The selected playbook launches the script for responding through Check Point NGFW.

   If the operation is completed successfully, an appropriate message is displayed on the screen. Otherwise, an error message is displayed.

The result of the playbook launch is available in the alert or incident details, on the History tab.

Responding through Sophos Firewall

Sophos Firewall is a solution providing the following means of protection for your corporate network:

• Firewall—Filtering network traffic, to protect the network from unauthorized access.
• Intrusion and attack protection—Identifying and blocking suspicious actions, to ensure system integrity.
• Anti-virus traffic scanning—Protecting against malware and malicious activities.
• Application control—Blocking or restricting execution of unauthorized applications.
• Web filtering—Restricting user access to websites that you consider unwanted.

Sophos Firewall 19.5 version is supported.

You can respond to alerts and incidents by using Sophos Firewall if you previously configured integration between Kaspersky Next XDR Expert and a script launch service, as well as created a playbook that will launch a script for responding. As a result of the playbook launch, Sophos Firewall will block IP addresses, IP ranges, or URLs, depending on the action that you specify when creating a playbook.

To unblock the IP addresses, IP ranges, or URLs that have been blocked, you have to create and launch another playbook.

You can download the script by clicking this link:

Download script

The login and password to access Sophos Firewall are stored in the env.sample configuration file. You have to copy the information from this file to a new ENV file that you create, and then specify the necessary parameters in the new file.

Python 3.10 is required to run the script.

To perform a response action through Sophos Firewall, you must have one of the following XDR roles: Main administrator, Tenant administrator, Junior analyst, Tier 1 analyst, or Tier 2 analyst.

To launch a script for responding through Sophos Firewall:

1. In the main menu, go to the Monitoring & reporting section, and then in the Alerts or Incidents sections, click the ID of the required alert or incident.
2. Click the Select playbook button, and then in the window that opens, select the playbook that you created for responding through Sophos Firewall.
3. Click the Launch button.

   The selected playbook launches the script for responding through Sophos Firewall.

   If the operation is completed successfully, an appropriate message is displayed on the screen. Otherwise, an error message is displayed.

The result of the playbook launch is available in the alert or incident details, on the History tab.

Responding through Continent 4

Continent 4 is a solution providing the following means of protection for your corporate network:

• Firewall—Filtering network traffic, to protect the network from unauthorized access.
• Intrusion and attack protection—Identifying and blocking suspicious actions, to ensure system integrity.
• VPN gateway—Creating secure tunnels for data transmission between your organization's networks.
• Access control—Managing user access to internal and external network resources, based on security rules and policies.
• Data encryption—Using cryptographic algorithms to protect the transmitted data.

Continent 4 version 4.1.7 is supported.

You can respond to alerts and incidents through Continent 4 if you previously configured integration between Kaspersky Next XDR Expert and a script launch service, as well as created a playbook that will launch a script for responding.

You can create playbooks that will perform the following response actions through Continent 4:

• Block IP addresses and URLs.

  Continent 4 will block IP addresses and URLs. To unblock the IP addresses or URLs that have been blocked, you have to create and launch another playbook.

• Blocking the Indicators of Compromise (hereinafter also referred to as IoCs).

  Continent 4 will block the observables that you specified in the playbook trigger.

You can download the script by clicking this link:

Download script

The login and password to access Continent 4 are stored in the env.sample configuration file. You have to copy the information from this file to a new ENV file that you create, and then specify the necessary parameters in the new file.

Python 3.10 is required to run the script.

To perform a response action through Continent 4, you must have one of the following XDR roles: Main administrator, Tenant administrator, Junior analyst, Tier 1 analyst, or Tier 2 analyst.

To launch a script for responding through Continent 4:

1. In the main menu, go to the Monitoring & reporting section, and then in the Alerts or Incidents sections, click the ID of the required alert or incident.
2. Click the Select playbook button, and then in the window that opens, select the playbook that you created for responding through Continent 4.
3. Click the Launch button.

   The selected playbook launches the script for responding through Continent 4.

   If the operation is completed successfully, an appropriate message is displayed on the screen. Otherwise, an error message is displayed.

The result of the playbook launch is available in the alert or incident details, on the History tab.

Responding through SKDPU NT

SKDPU NT is a solution for privileged accounts management.

SKDPU NT version 7.0.4 is supported.

You can respond to alerts and incidents through SKDPU NT if you previously configured integration between Kaspersky Next XDR Expert and a script launch service, as well as created a playbook that will launch a script for responding.  

You can create playbooks that will perform the following response actions through SKDPU NT:

• Termination of the user session. The playbook will terminate all sessions of the user when suspicious activities are detected or security rules are broken.
• Blocking the user account. The playbook will block the user account and limit the user's access to the system.
• Revoking the user rights. The user will be removed from the privileged user group, and the user's rights will be revoked.

You can download the script by clicking this link:

Download script

The login and password to access SKDPU NT are stored in the env.sample configuration file. You have to copy the information from this file to a new ENV file that you create, and then specify the necessary parameters in the new file. 

Python 3.10 is required to run the script.

To perform a response action through SKDPU NT, you must have one of the following XDR roles: Main administrator, Tenant administrator, Junior analyst, Tier 1 analyst, or Tier 2 analyst.

To launch a script for responding through SKDPU NT:

1. In the main menu, go to the Monitoring & reporting section, and then in the Alerts or Incidents sections, click the ID of the required alert or incident.
2. Click the Select playbook button, and then in the window that opens, select the playbook that you created for responding through SKDPU NT.
3. Click the Launch button.

   The selected playbook launches the script for responding through SKDPU NT.

   If the operation is completed successfully, an appropriate message is displayed on the screen. Otherwise, an error message is displayed.

The result of the playbook launch is available in the alert or incident details, on the History tab.

Responding through FortiGate

FortiGate is a solution providing the following means of protection for your corporate network:

• Firewall—Filters network traffic and prevents unauthorized access.
• Intrusion and attack protection—Identifies and blocks suspicious actions.
• Web filtering—Restricts user access to websites that you consider unwanted.
• Malware protection—Prevents malware infections.
• Email filtering—Blocks spam messages and suspicious emails.

FortiGate 7.6.0 version is supported.

You can respond to alerts and incidents by using FortiGate if you previously configured integration between Kaspersky Next XDR Expert and a script launch service, as well as created a playbook that will launch a script for responding. As a result of the playbook launch, FortiGate will block IP addresses, URLs, or domain names, depending on the action that you specify when creating a playbook.

To unblock IP addresses, URLs, or domain names that have been blocked, you have to create and launch another playbook.

You can download the script by clicking the following link:

Download script

The login, password, and API key to access FortiGate are stored in the env.sample configuration file. You have to copy the information from this file to a new ENV file that you create, and then specify the necessary parameters in the new file.

Python 3.10 is required to run the script.

To perform a response action through FortiGate, you must have one of the following XDR roles: Main administrator, Tenant administrator, Junior analyst, Tier 1 analyst, or Tier 2 analyst.

To launch a script for responding through FortiGate:

1. In the main menu, go to the Monitoring & reporting section, and then in the Alerts or Incidents sections, click the ID of the required alert or incident.
2. Click the Select playbook button, and then in the window that opens, select the playbook that you created for responding through FortiGate.
3. Click the Launch button.

   The selected playbook launches the script for responding through FortiGate.

   If the operation is completed successfully, an appropriate message is displayed on the screen. Otherwise, an error message is displayed.

The result of the playbook launch is available in the alert or incident details, on the History tab.

Viewing response history from alert or incident details

After you perform a response action, you can view the response history in one of the following ways:

• From the alert or incident details.
• From the Response history section.
• From a playbook details.

To view the response action history from the alert or incident details:

1. In the main menu, go to the Monitoring & reporting section.
2. Open the Alerts or Incidents section, and then click the ID of the alert or incident for which the response action was performed.
3. In the window that opens, go to the History tab, and then select the Response history tab.

   The table of events is displayed and contains the following columns:

   • Time. The time when the event occurred.
   • Launched by. Name of the user who launched the response action.
   • Events. Description of the event.
   • Response parameters. Response action parameters that are specified in the response action.
   • Asset. Number of the assets for which the response action was launched. You can click the link with the number of the assets to view the asset details.
   • Action status. Execution status of the response action. The following values can be shown in this column:
     • Awaiting approval—Response action awaiting approval for launch.
     • In progress—Response action is in progress.
     • Success—Response action is completed without errors or warnings.
     • Warning—Response action is completed with warnings.
     • Error—Response action is completed with errors.
     • Terminated—Response action is completed because the user interrupted the execution.
     • Approval time expired—Response action is completed because the approval time for the launch has expired.
     • Rejected—Response action is completed because the user rejected the launch.
   • Playbook. Name of the playbook in which the response action was launched. You can click the link to view the playbook details.
   • Response action. Name of the response action that was performed.
   • Asset type. Type of asset for which the response action was launched. Possible values: Device or User.
   • Asset tenant. The tenant that is the owner of the asset for which the response action was launched.
4. If necessary, click the settings icon (), and then select the columns to be displayed in the table.
5. If necessary, click the filter icon (), and then in the window that opens, specify and apply the filter criterion:
   • Add a new filter by clicking the Add filter button.
   • Edit a filter by selecting necessary values in the following fields:
     • Property
     • Condition
     • Value
   • Delete a filter.
   • Delete all filters by clicking the Reset all button.

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.

  When you apply the filter criterion for the Action status column, the table displays the manually launched responses whose status contains the selected value and the playbooks that include response actions whose status contains the selected value. It means that only the response actions of the playbook that meet the filter criterion will be displayed.

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.
• Playbook status. Execution status of the playbook. The following values can be shown in this column:
  • Awaiting approval—Playbook awaiting approval for launch.
  • In progress—Playbook is in progress.
  • Success—Playbook is completed without errors or warnings.
  • Warning—Playbook is completed with warnings.
  • Error—Playbook is completed with errors.
  • Terminated—Playbook is completed because the user interrupted the execution.
  • Approval time expired—Playbook is completed because the approval time for the launch has expired.
  • Rejected—Playbook is completed because the user rejected the launch.

  You can click the Playbook status value or the Action status value to open the window with the result of the playbook or the response action launch. The Launch ID can be used by Technical Support. If the status is In progress, you can view the Launch ID by hovering the mouse cursor over the icon next to the status.

• 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. The field is empty, if the playbook or response action does not involve assets.

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 any playbook that matches 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.

You can also launch a playbook for observables and assets if you have specified these objects when creating the playbook and when launching it.

Launching a playbook for an alert

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.

Launching a playbook for an incident

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.1.0",

"version": "1",

"actionSpecVersion": "1",

"executionFlow": [

{

"action": {

"function": {

"type": "executeCustomScript",

"params": {

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

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

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

}

},

"onError": "stop"

}

},

{

"action": {

"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.

By default, the table is sorted according to the time the playbook or response action was launched. The response actions in the playbooks are sorted according to their order in the playbook algorithm.

The toolbar in the upper part of the table allows you 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.

  When you apply the filter criterion for the Action status column, the table displays the manually launched responses whose status contains the selected value and the playbooks that include the response actions whose status contains the selected value. It means that only the response actions of the playbook that meet the filter criterion will be displayed.

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 response action. The following values can be shown in this column:
  • Awaiting approval—Response action awaiting approval for launch.
  • In progress—Response action is in progress.
  • Success—Response action is completed without errors or warnings.
  • Warning—Response action is completed with warnings.
  • Error—Response action is completed with errors.
  • Terminated—Response action is completed because the user interrupted the execution.
  • Approval time expired—Response action is completed because the approval time for the launch has expired.
  • Rejected—Response action is completed because the user rejected the launch.
• Playbook status. Execution status of the playbook. The following values can be shown in this column:
  • Awaiting approval—Playbook awaiting approval for launch.
  • In progress—Playbook is in progress.
  • Success—Playbook is completed without errors or warnings.
  • Warning—Playbook is completed with warnings.
  • Error—Playbook is completed with errors.
  • Terminated—Playbook is completed because the user interrupted the execution.
  • Approval time expired—Playbook is completed because the approval time for the launch has expired.
  • Rejected—Playbook is completed because the user rejected the launch.

  You can click the Playbook status value or the Action status value to open the window with the result of the playbook or the response action launch. The Launch ID can be used by Technical Support. If the status is In progress, you can view the Launch ID by hovering the mouse cursor over the icon next to the status.

• 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. The field is empty, if the playbook or response action does not involve assets.
• Tenant. Name of the tenant to which the playbook belongs.
• Approver. Name of the user who approved or rejected the playbook or response action launch.

  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 the playbook or response action launch was approved or rejected. This column is not displayed by default.

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

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.1.0",

"version": "1",

"actionSpecVersion": "1",

"executionFlow": [

{

"action": {

"function": {

"type": "resetLDAPPassword",

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

},

"onError": "stop"

}

},

{

"action": {

"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.1.0",

"version": "1",

"actionSpecVersion": "1",

"executionFlow": [

{

"action": {

"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.1.0",

"version": "1",

"actionSpecVersion": "1",

"executionFlow": [

{

"action": {

"function": {

"type": "blockLDAPAccount",

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

},

"onError": "stop"

}

},

{

"loop": {

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

"onError": "stop",

"steps": [

{

"action": {

"function": {

"type": "killProcess",

"params": {

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

},

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

}

}

}

]

}

},

{

"action": {

"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.

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 you start writing a trigger, 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 typing. For convenience, some suggestions contain a search string. For example, if you want to specify an incident type ID or incident status ID, you can search the corresponding record by the name, and the ID will be specified in the trigger.

Note that default statuses (New and Closed) have the same ID in different workflows, which means that the trigger will run for all incidents with the specified status ID. To limit the scope of incidents for which the playbook will run, in the trigger you have to specify the incident status ID and the incident type.

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

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. 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 the JSON format and consists of two main parts:

• General information on the 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 (actionsSpecVersion)
• Playbook execution steps (executionFlow).

The following parameters are required when writing the algorithm:

• dslSpecVersion. The required value: 1.1.0.
• actionsSpecVersion
• 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 the alert data model or incident data model in expressions written in the jq language. To do that, write expressions 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 using 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,

in the jq expression, write alert or incident and include 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.

How to call suggestions

You can call suggestions when writing the playbook algorithm. The suggestions contain a search string and help you specify the field value quickly. To view the suggestions, use quotation marks (""). A list of suggestions appears.

The suggestions also allow you to search by name. However, when you select the required value, the name will be automatically changed to an ID in the algorithm. For details, refer to Editing incidents by using playbooks and Editing alerts by using playbooks.

If you select and then delete the parameter name specified between the quotation marks, suggestions for the parameter will not appear, even if you have specified a new parameter between the quotation marks.

To return to the suggestion mode for the parameter, do one of the following:

• Delete the quotation marks, and then add an opening double quotation mark. A closing double quotation mark will be added automatically, and a suggestion will appear.
• Type any character between the quotation marks, and then press Backspace. This will return you to the suggestion mode.

If you delete the parameter name character by character, you will not exit the suggestion mode, even if you delete the parameter name completely.

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:

• Action
• Loop
• Parallel
• Decision
• UpdateData

Action parameters

The 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

Loop

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

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

Parallel

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

The Parallel parameters are used to perform several actions on the data at the same time. Unlike Loop, Parallel transmits the same input data to different execution branches.

Branch

Decision

The Decision execution step allows you to perform a step or set of steps according to a condition. Note that only the first verified condition is 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

Editing incidents by using playbooks

Expand all | Collapse all

Kaspersky Next XDR Expert allows you to edit incidents manually or by using playbooks. When creating a playbook, you can configure the playbook algorithm to edit the incident properties.

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

You cannot edit incidents that have the Closed status.

You can edit the following incident properties by using the playbook:

• Assignee
• Incident workflow status
• Incident type
• Comment
• Description
• Priority
• ExternalReference attribute
• Additional data attribute

Examples of the expressions that you can use in the playbook algorithm to edit the incident properties:

• Assigning an incident to a user
  { "dslSpecVersion": "1.1.0", "version": "1", "actionsSpecVersion": "1", "executionFlow": [ { "action": { "function": { "type": "assignIncident", "params": { "assignee": { "id": "user_ID" } } } } } ] }

  When you edit an assignee in the playbook algorithm, suggestions are displayed. For convenience, the suggestions contain a search string where you can search by name. If you want to specify an incident assignee, you can search the corresponding record by the user's name, and the ID will be specified in the algorithm.

• Unassigning an incident from a user
  { "dslSpecVersion": "1.1.0", "version": "1", "actionsSpecVersion": "1", "executionFlow": [ { "action": { "function": { "type": "assignIncident", "params": { "assignee": { "id": "nobody" } } } } } ] }
• Changing a status of the incident workflow

  To change the incident workflow status to Open:

  { "dslSpecVersion": "1.1.0", "version": "1", "actionsSpecVersion": "1", "executionFlow": [ { "action": { "function": { "type": "setIncidentStatus", "params": { "typeId": "af9dd279-fc30-4596-963b-942f79920375", "statusId": "4db36105-5223-4078-b72c-e9e9983b0987" } } } } ] }

  To change the incident workflow status to Closed:

  { "dslSpecVersion": "1.1.0", "version": "1", "actionsSpecVersion": "1", "executionFlow": [ { "action": { "function": { "type": "setIncidentStatus", "params": { "statusId": "INCIDENT_STATUS_ID", "statusResolution": "truePositive" } } } } ] }

  You can also specify the following values for the statusResolution parameter: falsePositive and lowPriority.

  To change the incident workflow status to a custom status:

  { "dslSpecVersion": "1.1.0", "version": "1", "actionsSpecVersion": "1", "executionFlow": [ { "action": { "function": { "type": "setIncidentStatus", "params": { "typeId": "22222222-2222-2222-2222-222222222222", "statusId": "11111111-1111-1111-1111-111111111111" } } } } ] }

  When you edit an incident workflow status in the playbook algorithm, suggestions are displayed. For convenience, the suggestions contain a search string where you can search by name. If you want to specify an incident workflow status, you can search the corresponding record by the name, and the ID will be specified in the algorithm.

• Changing the incident type
  { "dslSpecVersion": "1.1.0", "version": "1", "actionsSpecVersion": "1", "executionFlow": [ { "action": { "function": { "type": "setIncidentType", "params": { "id": "INCIDENT_TYPE_UUID" } } } } ] }

  When you edit an incident type in the playbook algorithm, suggestions are displayed. For convenience, the suggestions contain a search string where you can search by name. If you want to specify an incident type, you can search the corresponding record by the name, and the ID will be specified in the algorithm.

• Adding a comment to an incident
  { "dslSpecVersion": "1.1.0", "version": "1", "actionsSpecVersion": "1", "executionFlow": [ { "action": { "function": { "type": "addCommentToIncident", "params": { "text": "${ \"New comment for incident with ID: \\(incident.ID)\" }" } } } } ] }
• Editing the incident description
  { "dslSpecVersion": "1.1.0", "version": "1", "actionsSpecVersion": "1", "executionFlow": [ { "action": { "function": { "type": "setIncidentDescription", "params": { "description": "${ incident.ID | tostring | \"New comment for incident with ID: \" + . }", "mode": "replace" } } } } ] }

  To append to the existing description, specify the append value for the mode parameter.

• Changing the incident priority
  { "dslSpecVersion": "1.1.0", "version": "1", "actionsSpecVersion": "1", "executionFlow": [ { "action": { "function": { "type": "setIncidentPriority", "params": { "priority": "critical" } } } } ] }

  You can also specify the following values for the priority parameter: high, medium, low.

• Editing the ExternalReference attribute
  { "dslSpecVersion": "1.1.0", "version": "1", "actionsSpecVersion": "1", "executionFlow": [ { "action": { "function": { "type": "setIncidentExternalRef", "params": { "externalRef": "${ \"new extReference value\" }", "mode": "replace" } } } } ] }

  To append to the ExternalReference attribute, specify the append value for the mode parameter.

• Editing the Additional data attribute
  { "dslSpecVersion": "1.1.0", "version": "1", "actionsSpecVersion": "1", "executionFlow": [ { "action": { "function": { "type": "addIncidentAdditionalData", "params": { "data": "${ {\"customKey\": \"customValue\"} }", "mode": "replace" } } } } ] }

  To append to the Additional data attribute, specify the append value for the mode parameter.

Editing alerts by using playbooks

Expand all | Collapse all

Kaspersky Next XDR Expert allows you to edit incidents manually or by using playbooks. When creating a playbook, you can configure the playbook algorithm to edit the alert properties.

To edit an alert by using a playbook, you must have one of the following XDR roles: Main administrator, SOC administrator, Tier 1 analyst, Tier 2 analyst, or Tenant administrator.

You cannot edit alerts that have the Closed status.

You can edit the following alerts properties by using the playbook:

• Assignee
• Alert status
• Comment
• ExternalReference attribute
• Additional data attribute

Examples of the expressions that you can use in the playbook algorithm to edit the alert properties:

• Assigning an alert to a user
  { "dslSpecVersion": "1.1.0", "version": "1", "actionsSpecVersion": "1", "executionFlow": [ { "action": { "function": { "type": "assignAlert", "params": { "assignee": { "id": "user_ID" } } } } } ] }

  When you edit an assignee in the playbook algorithm, suggestions are displayed. For convenience, the suggestions contain a search string where you can search by name. If you want to specify an incident assignee, you can search the corresponding record by the user's name, and the ID will be specified in the algorithm.

• Unassigning an alert from a user
  { "dslSpecVersion": "1.1.0", "version": "1", "actionsSpecVersion": "1", "executionFlow": [ { "action": { "function": { "type": "assignAlert", "params": { "assignee": { "id": "nobody" } } } } } ] }
• Changing the alert status

  To change the alert status to In progress:

  { "dslSpecVersion": "1.1.0", "version": "1", "actionsSpecVersion": "1", "executionFlow": [ { "action": { "function": { "type": "setAlertStatus", "params": { "status": "inProgress" } } } } ] }

  To change the alert status to Closed:

  { "dslSpecVersion": "1.1.0", "version": "1", "actionsSpecVersion": "1", "executionFlow": [ { "action": { "function": { "type": "setAlertStatus", "params": { "status": "closed", "statusResolution": "truePositive" } } } } ] }

  You can also specify the following values for the statusResolution parameter: falsePositive and lowPriority.

  When you edit an alert status in the playbook algorithm, the following suggestions can be displayed: new, inProgress, closed.

• Adding a comment to an alert
  "dslSpecVersion": "1.1.0", "version": "1", "actionsSpecVersion": "1", "executionFlow": [ { "action": { "function": { "type": "addCommentToAlert", "params": { "text": "${ \"New comment for alert with ID: \" + alert.InternalID }" } } } } ] }
• Editing the ExternalReference attribute
  { "dslSpecVersion": "1.1.0", "version": "1", "actionsSpecVersion": "1", "executionFlow": [ { "action": { "function": { "type": "setAlertExternalRef", "params": { "externalRef": "${ \"Appended externalRef for alert with ID: \" + alert.InternalID }", "mode": "append" } } } } ] }

  To replace the current value of the ExternalReference attribute in the alert with the value from the playbook, specify the replace value for the mode parameter.

• Editing the Additional data attribute
  { "dslSpecVersion": "1.1.0", "version": "1", "actionsSpecVersion": "1", "executionFlow": [ { "action": { "function": { "type": "addAlertAdditionalData", "params": { "data": "${ {\"customKey_1 (alert.InternalID)\": (\"customValue_1 (\" + alert.InternalID + \")\" )} }", "mode": "append" } } } } ] }

  To replace the current value of the AdditionalData attribute in the alert with the value from the playbook, specify the replace value for the mode parameter.