Working with incidents

This section contains general information about incidents, their properties, typical life cycle, and connection with alerts. This section also gives instructions on how to create incidents, analyze the incident table, change incident properties according to the current state in the life cycle, and merge incidents.

The Incidents section is 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.

About incidents

Expand all | Collapse all

An incident is a container of alerts that normally indicates a true positive issue in the organization's IT infrastructure. An incident may contain a single or several alerts. By using incidents, analysts can investigate multiple alerts as a single issue.

You can create incidents manually or enable the rules for automatic creation of incidents. After an incident is created, you can link alerts to the incident. You can link no more than 200 alerts to an incident.

After creation, Open Single Management Platform adds incidents to the incident table as work items that are to be processed by analysts.

Incidents can be assigned only to analysts who have the access right to read and modify alerts and incidents.

You can manage incidents as work items by using the following incident properties:

• Incident status

  Possible values: New, In progress, On hold, or Closed.

  The incident status shows the current state of the incident in its life cycle. You can change the status as you like, with the following exceptions:

  • Status New cannot be changed to On hold.
  • Status Closed can only be changed to New.
• Incident severity

  Possible values: Low, Medium, High, or Critical.

  The incident severity shows the impact this incident may have on computer security or corporate LAN security, based on Kaspersky experience. An incident's severity corresponds to the highest severity of the linked alerts and cannot be changed manually.

• Incident priority

  Possible values: Low, Medium, High, or Critical.

  Incident priority defines the order in which the incidents must be investigated by analysts. Incidents with the Critical priority are the most urgent ones and must be investigated first. You can change the incident priority manually.

• Incident assignee

  This is an incident owner, the analyst who is responsible for the incident investigation and process. You can change an incident assignee at any time if the Status parameter is not set to Closed.

Two or more incidents may be interpreted as indicators of the same issue in an organization's IT infrastructure. If this is the case, you can merge the incidents to investigate them as a single issue.

Each incident has incident details that provide all of the information related to the incident. You can use this information to investigate the incident or merge incidents.

For each incident, you can create child incidents. Child incidents allow you to investigate and respond to incidents across different tenants. You can also create a child incident of another child incident. A parent incident can have no more than 200 child incidents.

Incident data model

The structure of an incident is represented by fields that contain values (see the table below). Some fields are objects or arrays of objects with their own set of fields (for example, the Assignee and Alerts fields).

Incident

IncidentType

Assignee

UnkeyedAttachment

Creating incidents

Expand all | Collapse all

You can create incidents manually or enable the rules for automatic creation of incidents. This topic describes how to create incidents manually.

To be able to create incidents, you must have the access right to read and modify alerts and incidents.

If the incident is created manually, playbooks will not launch automatically. You can launch a playbook for such an incident manually.

You can create incidents by using the incident table or the alert table.

Creating incidents by using the incident table

To create an incident:

1. In the main menu, go to Monitoring & reporting → Incidents. Click the Create incident button.
2. On the General settings step, specify the following settings:
   • Incident name
   • Tenant

     A tenant that the incident is associated with. Alerts can only be attached to an incident that belongs to the same tenant. You cannot change the incident's tenant later.

   • Assignee

     This is an incident owner, the analyst who is responsible for the incident investigation and process. You can change an incident assignee at any time if the Status parameter is not set to Closed.

   • Priority

     Possible values: Low, Medium, High, or Critical.

     Incident priority defines the order in which the incidents must be investigated by analysts. Incidents with the Critical priority are the most urgent ones and must be investigated first. You can change the incident priority manually.

   • Description

     In this field, you can leave a description of the incident. For example, you can describe the issue or provide investigation results of the linked alerts. The description is added to the Description section of the incident details.

     This field is optional.

3. Click OK.

   The incident is created.

Creating incidents by using the alert table

You create an incident by selecting the alerts to link to the new incident. Refer to linking alerts to incidents.

Viewing the incident table

The incident table provides an overview of all created incidents.

To view the incident table:

1. In the main menu, go to Monitoring & reporting → Incidents.
2. If necessary, apply the tenant filter. By default, the tenant filter is disabled and the incident table displays the incidents related to all of the tenants to which you have access rights. To apply the tenant filter:
   1. Click the link next to the Tenant filter setting.

      The tenant filter opens.

   2. Select the check boxes next to the required tenants.

      The incident table displays only the incidents that were detected on the assets that belong to the selected tenants.

The incident table is displayed.

The incident table has the following columns:

• Created. Date and time when the incident was created.
• Threat duration. Time between the earliest and the most recent events among all of the alerts linked to the incident. By default, this column is hidden.
• Updated. Date and time of the last change, from the incident history. By default, this column is hidden.
• Incident ID. A unique identifier of an incident.
• Status. Current status of the incident.
• Status changed. The date and time when the incident status has been changed.
• Severity. Severity of the incident.
• Priority. Priority of the incident.
• Number of linked alerts. How many alerts are included in the incident. By default, this column is hidden.
• Name. A name of an incident.
• Rules. The rules that were triggered to create the incident.
• Affected assets. Devices and users that were affected by the incident. If the number of assets affected by or involved in the incident is greater than or equal to three, the number of affected devices is displayed. By default, this column is hidden.
• Tenant. The name of the tenant in which the incident was detected.
• Analyst. Current assignee of the incident.
• Technology. The technology that detected the incident. By default, this column is hidden.
• Creation method. How the incident was created—manually or automatically. By default, this column is hidden.
• Observables. Number of the detection artifacts, for example, IP addresses or MD5 hashes of files. If the number of observables is greater than or equal to three, the number of observables is displayed. By default, this column is hidden.

If necessary, you can export information about all incidents displayed in the incident table to a JSON file.

Exporting information about incidents

You can export information about all incidents displayed in the incident table to a JSON file. This may be required when you have to provide this information to third parties.

To export information about incidents, you must 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, or Observer.

To export information about incidents:

1. In the main menu, go to Monitoring & reporting → Incidents.

   The incident table is displayed.

2. If necessary, group and filter the data in the table as follows:
   • Click the filter icon (), and then specify and apply the filter criterion in the invoked menu.
   • Click the settings icon (), and then select the columns to be displayed in the table.

   The filtered incident table is displayed.

3. Click the Export button.
4. In the window that opens, select the folder to save the JSON file, and then click the Save button.

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

Viewing incident details

Expand all | Collapse all

Incident details are a page in the interface that contains all of the information related to the incident, including the incident properties.

To view incident details:

1. In the main menu, go to Monitoring & reporting → Incidents.
2. In the incident table, click the ID of the required incident.

The window with incident details is displayed.

If necessary, you can refresh the information in the incident details by clicking the refresh () icon next to the incident name.

The toolbar in the upper part of the incident details allows you to perform the following actions:

• Edit the Name, Description and External reference field values
• View the incident on the investigation graph
• Change the incident status
• Change the incident priority
• Assign the incident to an analyst
• Select a playbook
• Link alerts to the incident
• Merge the incident with other incidents

Incident details contain the following sections:

• Summary

  The summary section contains the following incident properties:

  • Type. Incident type.
  • Analyst. Current assignee of the incident.
  • Creation method. How the incident was created—manually or automatically.
  • Name. Name specified at the incident creation. You can click the Edit button at the top to change the incident name.
  • Tenant. Name of the tenant in which the incident was detected.
  • Related tenants. Names of the tenants whose alerts are linked to the incident.
  • Assets. Number of users and devices that were affected by the incident.
  • Registered. Date and time when the incident was created.
  • Updated. Date and time of the last change from the incident history.
  • First event. A date and time of the first event related to the incident. This is the earliest event in the Details section of the alert details among all of the alerts linked to the incident.
  • Last event. A date and time of the most recent event related to the incident. This is the most recent event in the Details section of the alert details among all of the alerts linked to the incident.
  • Description. Incident description. You can click the Edit button at the top to specify the description.
  • External reference. Link to an entity in an external system. You can click the Edit button at the top to specify the external reference.
  • Priority. Possible values: Low, Medium, High, or Critical. Incident priority defines the order in which the incidents can be investigated. Incidents with the Critical priority are the most urgent ones and can be investigated first. You can change the priority by clicking the current priority value.
  • Severity. Possible values: Low, Medium, or High. Incident severity shows the impact this incident may have on computer security or corporate LAN security based on Kaspersky experience.
  • Rules. The rules that were triggered to detect the linked alerts. By clicking the ellipsis icon next to the rule name, you can open the shortcut menu. Use this menu to learn more details about the rule, find alerts or incidents that were detected by the same rule, or search the rule-triggering events in Threat hunting for the period between the first and the last event of the incident.

    When you click Go to Threat hunting in the menu, the Threat hunting section opens in the same tab. If you want to open the Threat hunting section in a new browser tab, click and hold the Ctrl key, and then click Go to Threat hunting in the menu.

  • Technology. List of technologies that detected the alerts linked to the incident.
  • MITRE tactic. A tactic or several tactics detected in the alerts linked to the incident. The tactics are defined in the MITRE ATT&CK knowledge base.
  • MITRE technique. A technique or several techniques detected in the alerts linked to the incident. The techniques are defined in the MITRE ATT&CK knowledge base.
  • Additional data. Additional information on the incident. You can edit a value in this field only by using a playbook. The field is displayed if you added a value.
• Details

  In the Details section, you can track the telemetry events related to the incident.

  To view the events related to the incident, click the Find in Threat hunting button. The opened table displays alert events related to the incident.

  The toolbar of the event table allows you to perform the following actions:

  • Download events. You can click the TSV button to download information about related events into a TSV file.
  • Unlink from incident. You can select an event or several events in the table, and then click this button to unlink the selected events from the alert related to the incident.

  You can go back to the incident details by clicking Incident investigation or by clicking the back button in your browser.

• Similar incidents

  In the Similar incidents section, you can view the list of incidents that have the same affected artifacts as the current incident. The affected artifacts include both observables and affected devices of the alerts linked to an incident. The list contains incidents in any status.

  By using the list, you can evaluate the degree of similarity of the current incident and other incidents. The similarity is calculated as follows:

  Similarity = M / T * 100

  Here, M is a number of artifacts that matched in the current and a similar incident, and T is total number of artifacts in the current incident.

  If the similarity is 100%, the current incident has nothing new in comparison with the similar incident. If the similarity is 0%, the current and the similar incident are completely different. Incidents that have similarity of 0% are not included in the list.

  The calculated value is rounded off to the nearest whole number. If similarity is equal to a value between 0% and 1%, the application does not round such value down to 0%. In this case, the value is displayed as less than 1%.

  Clicking an incident ID opens the incident details.

  Customizing the similar incidents list

  You can customize the table by using the following options:

  • Filter the incidents by selecting the term for which the incidents have been updated. By default, the list contains the incidents that have been updated for the last 30 days.
  • Click the Columns settings icon (), and then select which columns to display and in which order.
  • Click the Filter icon (), and then select and configure the filters that you want to apply. If you select several filters, they are applied simultaneously by logical AND operator.
  • Click a column header, and then select the sorting options. You can sort the incidents in ascending or descending order.
• Alerts

  In the Alerts section, you can view the list of the alerts linked to the current incident.

  By clicking an alert ID, you can open the alert details. You can also use the toolbar buttons to unlink alerts from the incident.

• Assets

  In the Assets section, you can view the devices and users affected by or involved in the incident.

  The asset table contains the following columns:

  • Asset type

    Possible values: device or user.

  • Asset name
  • Asset ID
  • Has signs of

    Possible values: attacker or victim.

  • Authorization status

    This parameter is only applied to device asset type. A device authorization status is defined by KICS for Networks. You can change the authorization status by applying the corresponding response action to a device.

  • Administration Server

    The Administration Server that manages the device.

  • Administration Group

    The administration group to which the device belongs.

  • Categories

    Asset categories which include the asset.

  By clicking a user name or a device name, you can:

  • Search the user name or the device ID in Threat hunting for the period between the first and the last event of the incident.

    When after clicking a user name or a device name you select Go to Threat hunting in the menu, the Threat hunting section opens in the same tab. If you want to open the Threat hunting section in a new browser tab, click and hold the Ctrl key, and then click Go to Threat hunting in the menu.

  • Search the user name or the device ID in other alerts.
  • Search the user name or the device ID in other incidents.
  • Copy the user name or the device name in the clipboard.

  You can also click a device name to open the device properties.

  By clicking a user ID or a device ID, you can:

  • Search the user ID or the device ID in Threat hunting for the period between the first and the last event of the incident.

    When after clicking a user ID or a device ID you select Go to Threat hunting in the menu, the Threat hunting section opens in the same tab. If you want to open the Threat hunting section in a new browser tab, click and hold the Ctrl key, and then click Go to Threat hunting in the menu.

  • Search the user ID or the device ID in other alerts.
  • Search the user ID or the device ID in other incidents.
  • Copy the user ID or the device ID in the clipboard.

  You can also click a device ID to open the device properties.

• Files

  In the Files section, you can upload, download, edit, or delete files related to the incident.

  You can upload files of any extension. Duplicate file names are allowed. The maximum number of files that you can attach to the incident and the maximum total file size you can specify in the configuration file.

  To upload files, click the Upload button and select one or multiple files. If you attempt to upload files exceeding the limitations, the Uploading files panel displaying a warning message will open. In this panel, you can remove files from the upload queue until the warning message disappears and click the Upload button to upload files. If you click the Upload button ignoring the warning message, upload will fail and the file list will include files that could not be uploaded with a warning icon next to the file names.

  Click a file to open the Edit file panel that displays file details. In this panel, you can edit file description.

  Use check boxes to select a file or multiple files. Select a file and click the Download button to download it. Select a file or multiple files and click the Delete button to delete the selected files.

  The Write permission in the Alerts and incidents functional area is required to upload and delete files and edit file descriptions. The Read permission in the Alerts and incidents functional area is required to download files.

• Observables

  In the Observables section, you can view the observables that relate to the alerts linked to the current incident. The observables may include:

  • MD5 hash
  • IP address
  • URL
  • Domain name
  • SHA256
  • UserName
  • HostName

  By clicking a link in the Value column, you can:

  • Search the observable value in Threat hunting for the period between the first and the last event of the incident.

    When after clicking a link in the Value column you select Go to Threat hunting in the menu, the Threat hunting section opens in the same tab. If you want to open the Threat hunting section in a new browser tab, click and hold the Ctrl key, and then click Go to Threat hunting in the menu.

  • Search the observable in Kaspersky Threat Intelligence Portal (opens in a new browser tab).
  • Search the observable value in other alerts.
  • Search the observable value in other incidents.
  • Copy the observable value in the clipboard.

  The toolbar of this section contains the following buttons:

  • Request status from Kaspersky TIP. Use this button to obtain detailed information about the selected observable from Kaspersky Threat Intelligence Portal (Kaspersky TIP). As a result, the information is updated in the Status update column. Requires integration with Kaspersky Threat Intelligence Portal (Premium access).
  • Enrich data from Kaspersky TIP. Use this button to obtain detailed information about all of the listed observables from Kaspersky TIP. As a result, the information is updated in the Enrichment column. Use a link in the Enrichment column to open the obtained enrichment details about an observable. Requires integration with Kaspersky Threat Intelligence Portal (Premium access).
  • Move to quarantine. Use this button to move the device on which the file is located to quarantine. This button is only available for hash (MD5 or SHA256) observables.
  • Add prevention rule. Use this button to add a rule that prevents the file from running. This button is only available for hash (MD5 or SHA256) observables.
  • Delete prevention rule. Use this button to delete the rule that prevents the file from running. This button is only available for hash (MD5 or SHA256) observables.
  • Terminate process. Use this button to terminate processes associated with the file. This button is only available for hash (MD5 or SHA256) observables.
• History

  In the Incident log section, you can track the changes that were made to the incident as a work item:

  • Changing incident status
  • Changing incident assignee
  • Linking an alert to the incident
  • Unlinking an alert from the incident
  • Merging the incident with other incidents
  • Uploading a file to the incident
  • Deleting a file from the incident

  In the Response history section, you can see the log of manual and playbook response actions. The table 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.
• Comments

  In the Comments section, you can leave comments related to the incident. For example, you can enter a comment about investigation results or when you change the incident properties, such as the incident assignee or status.

  You can edit or remove your own comments. The comments of other users cannot be modified or removed.

  To save your comment, press Enter. To start a new line, press Shift+Enter. To edit or delete your comment, use the buttons on the top right.

  The Write permission in the Alerts and incidents functional area is required to leave comments.

Assigning incidents to analysts

As a work item, an incident must be assigned to an SOC analyst for inspection and possible investigation. You can change the assignee at any time.

Incidents can be assigned only to analysts who have the access right to read and modify alerts and incidents.

To assign one or several incidents to an analyst:

1. In the main menu, go to Monitoring & reporting → Incidents.
2. Select the check boxes next to the incidents that you want to assign to an analyst.

   You must select only the incidents detected in the same tenant. Otherwise, the Assign to button will be disabled.

   Alternatively, you can assign an incident to an analyst from the incident details. To open the incident details, click the link with the incident ID.

3. Click the Assign to button.
4. In the Assign to analyst window that opens, start typing the analyst's name or email address, and then select the analyst from the list.

   You can also select the Not assigned option.

5. Click the Assign button.

The incidents are assigned to the analyst.

You also can assign an incident to an analyst by using playbooks.

Changing an incident status

Expand all | Collapse all

As a work item, an incident has a status that shows the current state of the incident in its life cycle.

You can change the status of your own incidents or the incidents of other analysts only if you have the access right to read and modify alerts and incidents.

If the incident status is changed manually, playbooks will not launch automatically. You can launch a playbook for such an incident manually.

An incident can have one of the following statuses:

• New

  When you create an incident or it is created automatically, the incident has the New status. You can change the status to In progress or Closed. When you change the New status to Closed and the incident has no assignee, the incident is automatically assigned to you.

• In progress

  This status means that an analyst started working on the incident or resumed the work by changing the On hold status. You can change the In progress status to any other status.

• On hold

  This status means that an analyst suspended work on the incident. Normally, you change the On hold status to In progress when the work is resumed, but you can change the On hold status to other statuses as well.

• Closed

  You close incidents when no additional work on the incident is expected. You can close an incident with one of the following resolutions:

  • True positive
  • False positive
  • Low priority

  When you close an incident, the linked alerts also gain the Closed status and inherit the resolution from the incident. If the incident has no assignee, the closed incident is automatically assigned to you. If the closed incident has unassigned linked alerts, those alerts are automatically assigned to you.

  The Closed status can only be changed to status New. If you want to return a closed incident back to work, change its status as follows: Closed → New → In progress.

To change status of one or several incidents:

1. In the main menu, go to MONITORING & REPORTING → Incidents.
2. Do one of the following:
   • Select the check boxes next to the incidents whose status you want to change.
   • Click the link with the ID of the incident whose status you want to change.

     The Incident details window opens.

3. Click the Change status button.
4. In the Change status pane, select the status to set.

   When you select the Closed status, you must select a resolution.

   If you have selected the Allow users with certain permissions only to close this incident check box when editing the Closed status in the incident workflow, you must have either Main Administrator or Approver XDR role to close the incident.

   If you change the incident status to Closed and this incident contains uncompleted playbooks or response actions, all related playbooks and response actions will be terminated.

5. Click the Save button.

The status of the selected incidents is changed.

You also can change an incident status by using playbooks.

Changing an incident priority

As a work item, an incident has a priority that defines the order in which the incident must be investigated by analysts. You can change the incident priority manually.

You can change incident priorities of your own incidents or incidents of other analysts only if you have the access right to read and modify alerts and incidents.

An incident can have one of the following priorities:

• Low
• Medium (default value)
• High
• Critical

Incidents with the Critical priority are the most urgent ones and must be investigated first. The Low priority usually means that the incident is placed in the backlog. You can define your own criteria as to which priority should be set to which incident.

To change an incident priority:

1. In the main menu, go to Monitoring & reporting → Incidents.
2. Do one of the following:
   • Select the check boxes next to the incidents whose priority you want to change.
   • Click the incident ID to open the details of the incident whose priority you want to change.
3. Click the Change priority button.
4. In the Change priority window, select the priority to set.
5. Click the Save button.

The priority of the selected incidents is changed.

You also can change an incident priority by using playbooks.

Merging incidents

Two or more incidents may be interpreted as indicators of the same issue in an organization's IT infrastructure. If this is the case, you can merge the incidents to investigate them as a single issue.

When you merge incidents, you need to select a target incident among them. After the incident consolidation, the issue is to be investigated within the target incident. The target incident must have a status other than Closed. Other incidents are merged into the target one and, after consolidation, gain the Closed status and the Merged resolution.

All of the alerts linked to the merged incidents are automatically linked to the target incident. Because an incident can have no more than 200 linked alerts, the application counts the alerts linked to the incidents that you want to merge. If the total number of linked alerts exceeds 200, the selected incidents cannot be merged.

You cannot merge child incidents or incidents that have child incidents.

To merge incidents from the incident table:

1. In the main menu, go to Monitoring & reporting → Incidents.
2. Select the check boxes next to the incidents that you want to merge into a target incident. You will select the target incident on the first step of the Wizard.
3. Click the Merge incidents button.

   The Merge incidents Wizard opens.

4. Select the target incident.
5. Click the OK button.

The incidents are merged.

To merge incidents by using incident details:

1. In the main menu, go to Monitoring & reporting → Incidents.
2. Click an incident ID to open the incident details. This incident will be merged into a target incident. You will select the target incident on the first step of the Wizard.
3. Click the Merge incident button.

   The Merge incidents Wizard opens.

4. Select the target incident.
5. Click the OK button.

The incidents are merged.

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.

Investigation graph

The investigation graph is a visual analysis tool that shows relationships between the following objects:

• Events
• Alerts
• Incidents
• Observables
• Assets (devices)
• Segmentation rules

The graph displays the details for an incident: the corresponding alerts and their common properties.

To open the investigation graph:

1. In the main menu, go to Monitoring & reporting → Incidents.
2. In the incident table, click the ID of the required incident.

   The window with incident details is displayed.

3. Click the View on graph button.

The Write permission in the Alerts and incidents functional area is required to view the graph. Refer to the following topic for details: Predefined user roles.

You can use the pan and zoom panel on the bottom right to navigate a complex graph.

Interacting with graph nodes

You can use the toolbar at the top to add alerts and observables.

You can click and drag graph nodes to rearrange them.

You can click a graph node to bring the context menu.

Common context menu items:

• View details

  Opens a details window for the selected node.

• Copy

  Copies the node value to clipboard.

• Hide

  Removes the selected node from the graph.

Event-specific context menu items:

Process tree

Only available for specific event types. Generates a process tree for the event. The blue color indication for an event indicates that you can generate a process tree for this event.

Alert-specific context menu items:

• Change status

  Invokes a Change status panel that allows you to change the alert status.

• Observables

  A sub-menu that allows you to add common observables as graph nodes.

• Devices

  A sub-menu that allows you to add common devices as graph nodes.

Observable-specific context menu items:

• Find similar events

  Invokes a Threat Hunting panel that shows similar events.

• Find similar alerts

  Invokes an Alerts panel that shows similar alerts.

• Request status from Kaspersky TIP

  Allows you to obtain detailed information about the selected observable from Kaspersky Threat Intelligence Portal (Kaspersky TIP). Refer to the following topic for details: Integration with Kaspersky Threat Intelligence Portal.

• Enrich data from Kaspersky TIP

  Use this button to obtain detailed information about the selected observable from Kaspersky TIP. Refer to the following topic for details: Integration with Kaspersky Threat Intelligence Portal.

Segmentation rule-specific context menu items:

• View details in KUMA

  Opens the KUMA Console in a new browser tab that displays the rule details.

• Find similar alerts

  Invokes an Alerts panel that shows similar alerts.

If you attempt to add an alert for a different tenant, the alert will not be shown on the investigation graph.

You can also add observables by clicking an alert or event. To do this, in the context menu that opens, you need to select Observables, and then click the observable. The observable will be added to the investigation graph. You can remove an observable from the investigation graph, if needed. To do this, you have to click the observable, and then click Hide in the context menu that opens.

Grouping graph elements

The investigation graph automatically groups alerts with common properties.

To ungroup an alert:

1. Click a graph element corresponding to an alert group.

   A table shows up that lists the alerts.

2. Select an alert that you want to show on the graph.
3. Click the Show on graph button in the table toolbar.

   The alert is added as a graph node.

4. Click the Hide on graph button, if you want to hide an alert.

Linking graph elements

The investigation graph automatically creates links for new items when applicable. Links can be added manually.

To manually add a link:

1. Click the Link nodes button.

   Link points appear around graph nodes.

2. Click and drag from a link point of one node to a link point of another node.

Manually created links have a color indication.

Threat hunting

You can analyze events to search threats and vulnerabilities that have not been detected automatically. To do this, you need to click the Threat Hunting button in the toolbar at the top or invoke a graph node's context menu and click Events or Find similar events. The Threat Hunting panel opens. Refer to the following section for details: Threat Hunting.

Exporting the graph

You can save the graph in the SVG format. To do this, you need to click the Export button in the toolbar at the top.

Segmentation rules

Segmentation rules allow you to automatically split related alerts into different incidents based on the conditions that you specify when creating the rules.

Use segmentation rules to create different incidents based on related alerts. For example, you can combine several alerts with an important distinguishing feature into a separate incident.

Alerts can only be linked to an incident that belongs to the same tenant.

We recommend that you use segmentation rules together with aggregation rules to define more precise rules for creating incidents.

When you write a jq expression while creating a segmentation rule, an error about invalid expression may appear though the expression is valid. This error does not block the creation of the segmentation rule. This is a known issue.

To create a segmentation rule:

1. In the main menu, go to Settings → Tenants.
2. Click the tenant for which you want to create a segmentation rule.
3. In the Settings tab, select Segmentation rules.
4. Click Create.

   A Segmentation rule window appears.

5. Specify the segmentation rule settings:
   • Status

     Enable or disable the rule.

   • Rule name

     A unique name for the rule. Must contain 1 to 255 Unicode characters.

   • Max alerts in incident

     Maximum number of alerts in a single incident. If the number of alerts exceeds the specified value, another incident is created.

   • Min alerts in incident

     Minimum number of alerts in a single incident. If the number of alerts does not reach the specified value, an incident is not created.

   • Incident name (template)

     A jq expression that defines the template for naming the incidents created according to this segmentation rule.

     Example: "Malware Detected with MD5 \(.Observables[] | select(.Type == "md5") | .Value)"

   • Search interval

     A time interval from which to select alerts and incidents.

   • Description

     Optional. Rule description.

   • Trigger

     A jq expression that defines the condition for including alerts in the incident.

     Example: any(.Rules[]?; .Name == "R077_02_KSC. Malware detected")

   • Groups

     A jq expression that defines the array of string identifiers by which to assign alerts to incidents.

     Example: [.Observables[] | select(.Type == "md5") | .Value ]

6. Click Save.

The segmentation rule is saved and displayed in the table of segmentation rules. If necessary, you can edit the rule setting by clicking its name in the table.

The rules are prioritized in the table in descending order.

When an alert is created, it is checked by all active segmentation rules in accordance with their priority. After the first rule is triggered, an array of string identifiers is formed for the alert, and the search starts for the incident to which the alert will be linked.

A rule is triggered if the jq expression that you have specified in Trigger returns true.

Alerts cannot be linked to incidents created manually.

An incident also has an array of string identifiers, which include the arrays of the alerts already linked to this incident. If the alert for which the segmentation rule was triggered has at least one element in its array that matches with any of those in the incident's array, the alert is linked to the incident. As a result, the array of this alert is added to the incident's array.

If there are several incidents meeting the condition, the alert is linked to the one with the most recent update. If there are no incidents with matching elements in arrays, a new incident is created.

When an incident is new, its array is empty. A new incident takes the array of string identifiers from an alert after the alert is linked.

Segmentation rule. Example

Configure the aggregation rules from the Aggregation rules. Example section in this topic.

The table below illustrates how to combine all penetration testing alerts in a single incident.

Segmentation rule

Aggregation and segmentation rules. Example

The table below illustrates how to combine alerts that have the same rule id in two incidents based on the user name prefix.

Aggregation rule

Segmentation rule

Copying segmentation rules to another tenant

You can copy an existing segmentation rule to another tenant.

When a child tenant is created, it automatically copies all segmentation rules from the parent tenant. Editing segmentation rules in the parent tenant does not affect already created child tenants.

To copy segmentation rules:

1. In the main menu, go to Settings → Tenants.
2. Click the tenant that has the segmentation rule that you want to copy.
3. In the Settings tab, select Segmentation rules.
4. Select segmentation rules you want to copy and click Copy to tenant.
5. Select one or multiple target tenants and click Copy.

   If the target tenant contains a segmentation rule with an identical name, an Overwrite or rename segmentation rules? window appears. Click Overwrite to delete the previously created rule for the target tenant and replace it with the rule that you want to copy. Click Copy and rename to preserve the previously created rule and copy the specified rule with (copy) appended to its title.

Managing incident types

Kaspersky Next XDR Expert allows you to manage incidents and customize the incident handling process by using incident types.

An incident type is a set of attributes, for which you can configure different processes, for example, assign a workflow to the incident type, configure a trigger, or configure a playbook algorithm.

You can create an incident type or use predefined incident types that you can customize.

Incident types can be active or inactive. If the incident type is active, you can select this type in the incident details window.

The incident type marked as a default type is assigned to all new incidents automatically. You cannot switch a default incident type to inactive.

The Common incident type is set as default. You can edit this setting.

You can create only one default incident type in a tenant.

Viewing the incident types table

To view the incident types table:

1. In the main menu, go to Settings → Tenants.
2. Click the name of the required tenant.

   The tenant's properties window opens.

3. On the Settings tab, click Incident management.

   The Types tab is displayed with the incident types table.

4. If you want to configure the incident types table, do any of the following:
   • Click the filter icon (), and then specify and apply the filter criterion in the invoked menu.
   • To hide or display a column, click the settings icon (), and then select the necessary column.

The incident types table contains the following information:

• Name. Name of the custom or predefined incident type.

  The table contains the following predefined incident types:

  • Common

    By default, this type has the Yes value in the Default column.

  • Information gathering
  • Compromise
  • Unauthorized access
  • Malware attack
  • Phishing
  • Availability
  • Insider threat
  • Data breaches
  • Configuration error
  • Supply chain attack
  • Web application attack
  • Vulnerability exploitation
• Active type. If the incident type is active, you will be able to select this type in the incident details window.
• Default. When you create an incident, the default type is automatically assigned to it. Possible values:
  • True
  • False
• Workflow. Incident workflow.
• Tenant. Name of the tenant to which the incident type belongs.
• Creation type. Way the incident type was created. Possible values:
  • Custom
  • Predefined
• ID. Unique identifier of the custom or predefined incident type. By default, this column is hidden.
• Description. Incident type description. By default, this column is hidden.

If necessary, you can create new incident types, as well as edit and delete predefined and custom incident types.

Creating incident types

To create an incident type:

1. In the main menu, go to Settings → Tenants.
2. Click the name of the required tenant.

   The tenant's properties window opens.

3. On the Settings tab, click Incident management, and then select the Types tab.
4. Click the Create button.

   The Create incident type window opens.

5. If you want the new incident type to be active, switch on the Active type toggle button.
6. In the Name field, enter the name of the new incident type.
7. If you want all new incidents to be assigned this type by default, select the Set as default check box.

   There can be only one default incident in a tenant. It means that if the tenant already has a default incident type, this type will no longer be default after you select this check box.

8. In the Workflow field, select the incident workflow.
9. If necessary, in the Description field, enter an incident type description or a comment.
10. Click the Create button.

The new incident type is displayed in the incident types table.

Editing incident types

If necessary, you can edit incident types.

To edit an incident type:

1. In the main menu, go to Settings → Tenants.
2. Click the name of the required tenant.

   The tenant's properties window opens.

3. On the Settings tab, click Incident management.

   The Types tab is displayed with the incident types table.

4. Click the name of the incident type that you want to edit.

   The Edit incident type window opens.

5. Make your edits, and then click Save. For more details on the incident types properties that you can edit, refer to Creating incident types.

The incident type properties are edited and saved.

Deleting incident types

If you want to delete an incident type that is used in a playbook, you have to delete this incident type from the playbook trigger and/or algorithm to avoid errors.

You cannot delete an incident type in the following cases:

• An incident type is set as default in the tenant where this incident type was created.

  When trying to delete this incident type, you are prompted to set a new default incident type. In the window that opens, you have to select the incident type from the list.

• An incident type is set as default in a child tenant.
• The current tenant or a child tenant contains an incident with the type that you want to delete.

  Before deleting such a type, you have to assign another type to the incident.

To delete the incident type:

1. In the main menu, go to Settings → Tenants.
2. Click the name of the required tenant.

   The tenant's properties window opens.

3. On Settings, click Incident management.

   The Types tab is displayed with the incident types table.

4. Do one of the following:
   • Select the incident type that you want to delete, and then click Delete.
   • Click the name of the incident type that you want to delete, and then in the Edit incident type window, click Delete.
5. In the confirmation dialog box, click Delete.

The incident type is deleted.

Managing incident workflows

Kaspersky Next XDR Expert allows you to configure a flexible incident workflow. Kaspersky Next XDR Expert also visualizes the workflow in the visual editor.

The incident workflow is a set of statuses and transitions that an incident goes through during its lifecycle. Status is a step in the incident handling process. Transition helps the incident to move between different statuses. A transition is a link that allows you to configure transitions from one incident status to another and back. If necessary, you can use a transition as a one-way link.

You can create an incident workflow or use a predefined workflow that you can customize.

You also can assign a workflow to the incident types. This will help you manage the incident lifecycle in the most convenient way.

Viewing incident workflows table

To view the incident workflows table:

1. In the main menu, go to Settings → Tenants.
2. Click the name of the required tenant.

   The tenant's properties window opens.

3. On the Settings tab, click Incident management, and then select the Workflows tab.

The incident workflows table is displayed.

To configure the incident workflows table, do any of the following:

• Click the filter icon () button, and then specify and apply the filter criterion in the invoked menu.
• To hide or display a column, click the settings icon (), and then select the necessary column.

The incident workflows table is configured and displays the data you need.

The incident workflows table contains the following information:

• Name. Name of the custom or predefined incident workflow.
• Linked types. Number of linked incident types.
• Tenant name. Name of the tenant to which the incident workflow belongs.
• Creation type. Way the incident workflow was created. Possible values:
  • Custom.
  • Predefined.
• Workflow ID. Unique identifier of the incident workflow. By default, this column is hidden.
• Description. Incident workflow description.By default, this column is hidden.

Predefined incident workflows

Kaspersky Next XDR Expert allows you to manage incidents by using the predefined incident workflow. In the incident workflows table, such workflow is named Standard. In the Creation type column, these workflows are marked as Predefined.

If necessary, you can edit the predefined workflow to customize it.

The table below shows the statuses of the predefined workflow, and the reasons why incidents switch to these statuses.

Creating incident workflows

The incident workflow allows you to manage incident lifecycle.

To create an incident workflow:

1. In the main menu, go to Settings → Tenants.
2. Click the name of the required tenant.

   The tenant's properties window opens.

3. On the Settings tab, click Incident management, and then select the Workflows tab.
4. Click the Create button.

   The Create workflow window opens.

   By default, each incident workflow contains predefined statuses Initial and Done. You cannot delete or edit these statuses.

5. In the Name field, enter the name of the new workflow.
6. If necessary, in the Description field, enter a workflow description or a comment.
7. To add new statuses, in the Workflow section, click Add status.
8. In the window that opens, specify the following settings:
   1. In the Status name field, enter the name of the new status.
   2. In the Category field, select one of the following status categories:
      • Initial
      • In progress
      • Resolved
      • Done

      The category determines the color of the status icon.

   3. In the Incoming transition field, select one or several incoming statuses.

      If you want to configure a transition from all statuses to the incoming statuses, select the Allow all statuses to transition to this one option.

   4. In the Outgoing transition field, select one or several outgoing statuses.

      If you want to configure a transition from the outgoing statuses to all statuses, select the Allow this status to transition to all statuses option.

   5. Click Add.

      The visualized workflow is displayed in the Create workflow window.

      If necessary, repeat steps 7-8e to add new statuses.

9. In the Create workflow window, click Save.

The new incident workflow is displayed in the table.

Editing incident workflows and statuses

You can edit workflow properties, as well as workflow' statuses and transitions.

To edit the incident workflow:

1. In the main menu, go to Settings → Tenants.
2. Click the name of the required tenant.

   The tenant's properties window opens.

3. On the Settings tab, click Incident management, and then select the Workflows tab.
4. Click the name of the workflow that you want to edit.

   The Edit workflow window opens.

5. Edit the workflow properties. For more details on the workflow properties that you can edit, see Creating incident workflows.

The workflow's properties are modified and saved.

To edit statuses of the incident workflow:

1. In the main menu, go to Settings → Tenants.
2. Click the name of the required tenant.

   The tenant's properties window opens.

3. On the Settings tab, click Incident management, and then select the Workflows tab.
4. Click the name of the workflow that you want to edit.

   The Edit workflow window opens.

5. Click the name of the status that you want to edit.

   The Edit status window opens.

6. Edit the status and transition settings. For more details on the status settings that you can edit, see Creating incident workflows.

   If necessary, you can delete the status by clicking the Delete button.

   You cannot edit the name and the category of the following predefined statuses: Initial and Done statuses. You also cannot delete these predefined statuses.

   You cannot delete a status if it is assigned to an incident.

7. Click the Save button.

The workflow statuses are modified and saved.

Deleting incident workflows

You cannot delete the incident workflow if there are linked incident types that belong to the parent or child tenant. In this case, you need to assign a different workflow to the linked incident types, and then try to delete incident workflow again.

If you want to delete a workflow that is used in a playbook, before deleting, edit the playbook's trigger and/or algorithm to avoid errors.

To delete an incident workflow:

1. In the main menu, go to Settings → Tenants.
2. Click the name of the required tenant.

   The tenant's properties window opens.

3. On the Settings tab, click Incident management, and then select the Workflows tab.
4. In the list of workflows, select the workflow that you want to delete, and then click Delete.
5. In the confirmation dialog box, click Delete.

The incident workflow is deleted.