Kaspersky Next XDR Expert Help

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.

In this section

Terminating processes

Moving devices to another administration group

Running a malware scan

Viewing the result of the malware scan

Updating databases

Moving files to quarantine

Changing authorization status of devices

Viewing information about KASAP users and changing learning groups

Responding through Active Directory

Responding through KATA/KEDR

Responding through UserGate

Responding through Ideco NGFW

Responding through Ideco UTM

Responding through Redmine

Responding through Check Point NGFW

Responding through Sophos Firewall

Responding through Continent 4

Responding through SKDPU NT

Viewing response history from alert or incident details

Page top

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:

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.
In the window that opens, go to the Observables tab.
In the list of observables, select one or several observables for which you want to terminate the process. The observables may include:
- MD5
- SHA256
Click the Terminate process button.
In the Terminate process pane that opens, select assets for which you want to terminate the process.
Click the Terminate button.

The process is terminated.

Running the Terminate process for assets

To run the Terminate process for assets:

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.
In the window that opens, go to the Assets tab.
In the list of assets, select one or several devices you need.
Click the Select response action button, and then click Terminate process.
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.
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:

In the main menu, go to Monitoring & reporting → Incidents. In the ID column, click the link with the incident ID you need.
In the Incident details window that opens, click the View on graph button.
The Investigation graph window opens.
Click the name of the alert you need, and then click View details.
In the window that opens, go to the Observables tab.
In the list of observables, select one or several observables for which you want to terminate the process. The observables may include:
- MD5
- SHA256
Click the Terminate process button.
In the Terminate process pane that opens, select assets for which you want to terminate the process.
Click the Terminate button.

The process is terminated.

Page top

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:

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.
In the window that opens, go to the Assets tab.
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.
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.
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:

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.
In the window that opens, go to the Assets tab.
Click the name of the required device, and then in the drop-down list, select View properties.
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.
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:

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.
Click the View on graph button.
In the investigation graph that opens, click the device name to open the device details.
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.
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.

Page top

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:

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.
In the window that opens, go to the Assets tab.
Select check box next to the device to be scanned.
You can select several devices, if necessary.
In the Select response actions drop-down list, select Run virus scan.
The Virus scan window opens on the right side of the screen.
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.
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:

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.
In the window that opens, go to the Assets tab.
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.
In the Select response actions drop-down list, select Run virus scan.
The Virus scan window opens on the right side of the screen.
Select the type of malware scan. The types are described at step 5 in Running a malware scan from the alert or incident details.
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:

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.
Click the View on graph button.
In the investigation graph that opens, click the device name to open the device details.
In the Select response actions drop-down list, select Run virus scan.
The Virus scan window opens on the right side of the screen.
Select the type of malware scan. The types are described at step 5 in Running a malware scan from the alert or incident details.
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.

Page top

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:

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

Page top

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:

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.
In the window that opens, go to the Assets tab.
Select check box next to the devices on which databases are to be updated.
You can select several devices, if necessary.
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:

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.
In the window that opens, go to the Assets tab.
Click the name of the required device, and then in the drop-down list, select View properties.
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:

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.
Click the View on graph button.
In the investigation graph that opens, click the device name to open the device details.
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.

Page top

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:

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.
In the window that opens, go to the Assets tab.
Select check box next to the device which is to be moved to quarantine.
You can select several devices, if necessary.
In the Select response actions drop-down list, select Move to quarantine.
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.
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:

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.
In the window that opens, go to the Assets tab.
Click the name of the required device, and then in the drop-down list, select View properties.
In the Select response actions drop-down list, select Move to quarantine.
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.
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:

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 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.
In the Select response actions drop-down list, select Move to quarantine.
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.
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:

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.
In the window that opens, click the View on graph button.
The investigation graph opens.
Click the device name to open the device details.
In the Select response actions drop-down list, select Move to quarantine.
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.
Click the Move button.

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

Page top

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:

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.
In the window that opens, go to the Assets tab.
Select check box next to the device which authorization status is to be changed.
You can select several devices, if necessary.
In the Select response actions drop-down list, select Change authorization status.
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:

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.
In the window that opens, go to the Assets tab.
Click the name of the required device, and then in the drop-down list, select View properties.
In the Select response actions drop-down list, select Change authorization status.
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:

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 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.
In the Select response actions drop-down list, select Change authorization status.
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:

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.
In the window that opens, click the View on graph button.
The investigation graph opens.
Click the device name to open the device details.
In the Select response actions drop-down list, select Change authorization status.
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.

Page top

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:

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.
Click the ID of the required alert or incident.
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.
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:

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.
Click the ID of the required alert or incident.
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.
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.

Page top

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:

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.
Click the ID of the required alert or incident.
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.
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.

Page top

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:

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.
In the window that opens, go to the Assets tab.
Select the select check box next to the required device.
You can select several devices, if necessary.
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.
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:

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.
In the window that opens, go to the Assets tab.
Click the name of the required device, and then in the drop-down list, select View properties.
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:

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 window that opens, go to the Details tab, and select the required file hash.
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.
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:

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.
In the window that opens, click the View on graph button.
The investigation graph opens.
Click the device name to open the device details.
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.

Page top

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:

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.
Click the Select playbook button, and then in the window that opens, select the playbook that you created for responding through UserGate.
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.

Page top

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:

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
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))
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:

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

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

Page top

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:

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.
Click the Select playbook button, and then in the window that opens, select the playbook that you created for responding through Ideco UTM.
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.

Page top

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:

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

}

Page top

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:

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
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")
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:

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

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.
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 addresses is deleted.

To add a filtering rule that will block malicious URLs:

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

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

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.
Click the Select playbook button, and then in the window that opens, select the playbook that you created for responding through Check Point NGFW.
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.

Page top

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:

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.
Click the Select playbook button, and then in the window that opens, select the playbook that you created for responding through Sophos Firewall.
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.

Page top

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:

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.
Click the Select playbook button, and then in the window that opens, select the playbook that you created for responding through Continent 4.
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.

Page top

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:

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.
Click the Select playbook button, and then in the window that opens, select the playbook that you created for responding through SKDPU NT.
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.

Page top

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:

In the main menu, go to the Monitoring & reporting section.
Open the Alerts or Incidents section, and then click the ID of the alert or incident for which the response action was performed.
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.
If necessary, click the settings icon (), and then select the columns to be displayed in the table.
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.

Page top

Contents

Response actions

Terminating processes

Moving devices to another administration group

Running a malware scan

Viewing the result of the malware scan

Updating databases

Moving files to quarantine

Changing authorization status of devices

Viewing information about KASAP users and changing learning groups

Responding through Active Directory

Responding through KATA/KEDR

Responding through UserGate

Responding through Ideco NGFW

Responding through Ideco UTM

Responding through Redmine

Responding through Check Point NGFW

Responding through Sophos Firewall

Responding through Continent 4

Responding through SKDPU NT

Viewing response history from alert or incident details