Contents
- Threat detection
- Working with alerts
- About alerts
- Alert data model
- Viewing the alert table
- Viewing alert details
- Assigning alerts to analysts
- Changing an alert status
- Creating alerts manually
- Linking alerts to incidents
- Unlinking alerts from incidents
- Linking events to alerts
- Unlinking events from alerts
- Editing alerts by using playbooks
- Working with alerts on the investigation graph
- Aggregation rules
- Working with incidents
- About incidents
- Incident data model
- Creating incidents
- Viewing the incident table
- Exporting information about incidents
- Viewing incident details
- Assigning incidents to analysts
- Changing an incident status
- Changing an incident priority
- Merging incidents
- Editing incidents by using playbooks
- Investigation graph
- Segmentation rules
- Copying segmentation rules to another tenant
- Managing incident types
- Managing incident workflows
- Configuring the retention period of alerts and incidents
- Viewing asset details
- Working with alerts
Threat detection
Open Single Management Platform uses alerts and incidents as work items that are to be processed by analysts.
The Alerts and Incidents sections are displayed in the main menu if the following conditions are met:
- You have a license key for Kaspersky Next XDR Expert.
- You are connected to the root Administration Server in OSMP Console.
- You have one of the following XDR roles: Main administrator, Tenant administrator, Junior analyst, Tier 1 analyst, Tier 2 analyst, SOC manager, Interaction with NCIRCC, Approver, Observer.
Working with alerts
This section contains general information about alerts, their properties, typical life cycle, and connection with incidents. The instructions that are provided will help you analyze the alert table, change alert properties according to the current state in the life cycle, and combine alerts into incidents by linking or unlinking the alerts.
The Alerts 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 alerts
An alert is an event in the organization's IT infrastructure that was marked by Open Single Management Platform as unusual or suspicious, and that may pose a threat to the security of the organization's IT infrastructure.
Open Single Management Platform generates an alert when an EPP application (for example, Kaspersky Endpoint Security for Windows) detects certain activity in the infrastructure that corresponds to conditions defined in the detection rules.
The alert is created within 30 seconds after the KUMA correlation event has occurred.
You can also create an alert manually from a set of events.
After detection, Open Single Management Platform adds alerts to the alert table as work items that are to be processed by analysts. You cannot delete alerts—you can only close them.
Alerts can be assigned only to analysts who have the access right to read and modify alerts and incidents.
You can manage alerts as work items by using the following alert properties:
You can combine and link alerts to bigger work items called incidents. You can link alerts to incidents manually, or enable the rules to create incidents and link alerts automatically. By using incidents, analysts can investigate multiple alerts as a single issue. When you link a currently unlinked alert to an incident, the alert loses its current status and gains the status In incident. You can link a currently linked alert to another incident. In this case, the In incident status of the alert is kept. You can link a maximum of 200 alerts to an incident.
Each alert has alert details that provide all of the information related to the alert. You can use this information to investigate the alert, track the events that preceded the alert, view detection artifacts, affected assets, or link the alert to an incident.
Alert data model
The structure of an alert 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 Assets
fields).
Alert
Field |
Value type |
Is required |
Description |
|
String |
Yes |
Internal alert ID, in the UUID format. The field value may match the |
|
Integer |
Yes |
Short internal alert ID. |
|
String |
Yes |
ID of the tenant that the alert is associated with, in the UUID format. |
|
String |
Yes |
Date and time of the alert generation, in the RFC 3339 format. |
|
String |
Yes |
Date and time of the last alert change, in the RFC 3339 format. |
|
String |
No |
Date and time of the last alert status change, in the RFC 3339 format. |
|
String |
Yes |
Severity of the alert. Possible values:
|
|
String |
Yes |
ID of the Kaspersky application management plug-in that is integrated in OSMP. |
|
String |
Yes |
Version of the Kaspersky application management plug-in that is integrated in OSMP. |
|
String |
No |
Unique alert identifier in the integrated component. |
|
String |
No |
Date and time of the alert generation in the integrated component, in the RFC 3339 format. |
|
String |
Yes |
Date and time of the first telemetry event related to the alert, in the RFC 3339 format. |
|
String |
Yes |
Date and time of the last telemetry event related to the alert, in the RFC 3339 format. |
|
String |
No |
Component that detects and generates the alert. |
|
Array of strings |
No |
Triggered detection technology. |
|
String |
Yes |
Alert status. Possible values:
|
|
String |
No |
Resolution of the alert status. Possible values:
|
|
String |
No |
Internal ID of the incident associated with the alert. |
|
String |
No |
Way to add an alert to an incident. Possible values:
|
|
|
No |
Operator to whom the alert is assigned. |
|
Array of |
No |
MITRE tactics related to all triggered IOA rules in the alert. |
|
Array of |
No |
MITRE techniques related to all triggered IOA rules in the alert. |
|
Array of |
No |
Observables related to the alert. |
|
Array of |
No |
Assets affected by the alert. |
|
Array of |
No |
Triggered correlation rules, on the basis of which the alert is generated. |
|
Array of objects |
No |
Events, on the basis of which the alert is generated. |
|
String |
Yes |
Link to an entity in an external system (for example, a link to a Jira ticket). |
|
Object |
No |
Data related to the alert, in the JSON format. This data is obtained from managed Kaspersky applications when events are transformed into alerts. This field is not used in the interface. |
|
Object |
No |
Additional information about the alert, in the JSON format. This information can be filled in by a user or a playbook. |
|
String |
Yes |
Alert name. |
|
Array of |
No |
Attachments related to the incident. |
Assignee
Field |
Value type |
Is required |
Description |
|
String |
Yes |
User account ID of the operator to whom the alert is assigned. |
|
String |
Yes |
Name of the operator to whom the alert is assigned. |
MITRETactic
Field |
Value type |
Is required |
Description |
|
String |
Yes |
ID of the MITRE tactic related to all triggered IOA rules in the alert. |
|
String |
Yes |
Name of the MITRE tactic related to all triggered IOA rules in the alert. |
MITRETechnique
Field |
Value type |
Is required |
Description |
|
String |
Yes |
ID of the MITRE technique related to all triggered IOA rules in the alert. |
|
String |
Yes |
Name of the MITRE technique related to all triggered IOA rules in the alert. |
Observable
Field |
Value type |
Is required |
Description |
|
String |
Yes |
Type of the observable object. Possible values:
|
|
String |
Yes |
Value of the observable object. |
|
String |
No |
Additional information about the observable object. |
Rule
Field |
Value type |
Is required |
Description |
|
String |
Yes |
ID of the triggered rule. |
|
String |
No |
Name of the triggered rule. |
|
String |
No |
Severity of the triggered rule. Possible values:
|
|
String |
No |
Confidence level of the triggered rule. Possible values:
|
|
Boolean |
No |
Indicator that the alert is based on custom rules. |
Asset
Field |
Value type |
Is required |
Description |
|
String |
Yes |
Type of the affected asset (a device or an account). Possible values:
|
|
String |
Yes |
ID of the affected asset (a device or an account). |
|
String |
No |
The name of the affected device that the alert is associated with (if The user name of the affected user account associated with events, on the basis of which the alert is generated (if |
|
Boolean |
No |
Indicator that the affected asset (a device or an account) is an attacker. |
|
Boolean |
No |
Indicator that the affected asset (a device or an account) is a victim. |
UnkeyedAttachment
Field |
Value type |
Is required |
Description |
|
String |
Yes |
Attachment ID, in the UUID format. |
|
String |
Yes |
Attachment name. |
|
String |
Yes |
Date and time of the attachment creation, in the UTC format. |
|
String |
Yes |
Date and time of the last attachment change, in the UTC format. |
|
String |
Yes |
Indicator that the affected asset (a device or an account) is a victim. |
|
Integer |
Yes |
Attachment size, specified in bytes. |
|
String |
Yes |
Attachment status that indicates whether the attachment upload is in progress, completed, or aborted with an error. Possible values:
|
|
String |
No |
Attachment description. |
|
String |
No |
Text of the status that is displayed to a user (for example, an error message that is displayed when the attachment upload fails). |
Viewing the alert table
The alert table provides you with an overview of all alerts registered by Open Single Management Platform.
To view the alert table:
- In the main menu, go to Monitoring & reporting → Alerts.
- If necessary, apply the tenant filter. By default, the tenant filter is disabled and the alert table displays the alerts related to all of the tenants to which you have access rights. To apply the tenant filter:
- Click the link next to the Tenant filter setting.
The tenant filter opens.
- Select the check boxes next to the required tenants.
The alert table displays only the alerts detected on the selected tenants.
- Click the link next to the Tenant filter setting.
The alert table is displayed.
The alert table has the following columns:
- Alert ID. The unique identifier of an alert.
- Registered. The date and time when the alert was added to the alert table.
- Updated. The date and time of the last change from the alert history.
- Status. The current status of the alert.
- Analyst. The current assignee of the alert.
- Tenant. The name of the tenant in which the alert was detected.
- Technology. The technology that detected the alert.
- Rules. The IOC or IOA rules that were triggered to detect the alert.
- Affected assets. The devices and users that were affected by the alert.
- Observables. Detection artifacts, for example IP addresses or MD5 hashes of files.
- Incident link type. Way to add an alert to an incident.
- Severity. Severity of the alert.
- Status changed. The date and time of the last alert status change.
Viewing alert details
Alert details are a page in the interface that contains all of the information related to the alert, including the alert properties.
To view alert details:
- In the main menu, go to Monitoring & reporting → Alerts.
- In the alert table, click the ID of the required alert.
The alert details are displayed.
If necessary, you can refresh the information in the alert details by clicking the refresh () icon next to the alert name.
The toolbar in the upper part of the alert details allows you to perform the following actions:
- Edit the External reference field value
- Assign the alert to an analyst
- Change the alert status
- Link the alert to an incident
- Unlink the alert from the incident
- Select a playbook
- Create a new incident and link the alert to it
Alert details contain the following sections:
Assigning alerts to analysts
As a work item, an alert can be assigned to an SOC analyst for inspection and possible investigation. You can change the assignee of an active alert at any time. You cannot change an assignee of a closed alert.
Alerts can be assigned only to analysts who have the access right to read and modify alerts and incidents.
To assign one or several alerts to an analyst:
- In the main menu, go to Monitoring & reporting → Alerts.
- Select the check boxes next to the alerts that you want to assign to an analyst.
You must select only the alerts detected in the same tenant. Otherwise, the Assign to button will be disabled.
Alternatively, you can assign an alert to an analyst from the alert details. To open the alert details, click the link with the alert ID you need.
- Click the Assign to button.
- 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 for all alerts, except alerts with the Closed status.
- Click the Assign button.
The alerts are assigned to the analyst.
You also can assign an alert to an analyst by using playbooks.
Changing an alert status
As a work item, an alert has a status that shows the current state of the alert in its life cycle.
You can change alert statuses for your own alerts or the alerts of other analysts only if you have the access right to read and modify alerts and incidents.
If the alert status is changed manually, playbooks will not launch automatically. You can launch a playbook for such an alert manually.
An alert can have one of the following statuses:
To change the status of one or several alerts:
- In the main menu, go to Monitoring & reporting → Alerts.
- Do one of the following:
- Select the check boxes next to the alerts whose status you want to change.
- Click the link with the ID of the alert whose status you want to change.
The Alert details window opens.
- Click the Change status button.
- In the Change status pane, select the status to set.
If you select the Closed status, you must select a resolution.
If you change the alert status to Closed and this alert contains uncompleted playbooks or response actions, all related playbooks and response actions will be terminated.
- Click the Save button.
The status of the selected alerts is changed.
If an alert is added to the investigation graph, you can also change the alert status through the graph.
You also can change the alert status by using playbooks.
Creating alerts manually
You can create an alert manually from a set of events. You can use this functionality to examine a hypothetical incident that has not been detected automatically.
If the alert is created manually, playbooks will not launch automatically. You can launch a playbook for such an alert manually.
To create an alert manually:
- In the main menu, go to Monitoring & reporting → Threat hunting.
- Select the events for which you want to create an alert. The events should belong to the same tenant.
- Click the Create alert button.
A window shows up that displays the created alert. The Severity field value corresponds to the maximum severity among the selected events.
Manually created alerts have a blank Rules value in the Monitoring & reporting → Alerts table.
Page topLinking alerts to incidents
You can link one or multiple alerts to an incident for the following reasons:
- Multiple alerts may be interpreted as indicators of the same issue in an organization's IT infrastructure. If this is the case, the alerts in the incident can be investigated as a single issue. You can link up to 200 alerts to an incident.
- A single alert may be linked to an incident if the alert is defined as true positive.
You can link an alert to an incident if the alert has any status other than Closed. When linked to an incident, an alert loses its current status and gains the special status In incident. If you link alerts that are currently linked to other incidents, the alerts are unlinked from the current incidents, because an alert can be linked to only one incident.
Alerts can only be linked to an incident that belongs to the same tenant.
Alerts can be linked to an incident manually or automatically.
Linking alerts manually
To link alerts to an existing or new incident:
- In the main menu, go to Monitoring & reporting → Alerts.
- Select the check boxes next to the alerts that you want to link to an incident.
- If you want to link alerts to an existing incident:
- Click the Link to incident button.
- Select an incident to link the alerts to.
Alternatively, click an alert to display its details and click the Link to incident button in the toolbar at the top.
- If you want to link alerts to a new incident:
- Click the Create incident button.
- Fill in the properties of the new incident: name, assignee, priority, and description.
Alternatively, click an alert to display its details and click the Create incident button in the toolbar at the top.
- Click the Save button.
The selected alerts are linked to an existing or new incident.
Linking alerts automatically
If you want alerts to automatically link to an incident, you have to configure segmentation rules.
Unlinking alerts from incidents
You might need to unlink an alert from an incident, for example, if the alert analysis and investigation showed that the alert is not connected to other alerts in the incident. When you unlink an alert from an incident, Open Single Management Platform performs the following actions:
- Refreshes all of the data related to the incident, to reflect that the alert no longer belongs to the incident. For example, you can view the changes in the incident details.
- Resets the status of the unlinked alerts to New.
To unlink an alert from an incident:
- Open the alert details.
- Click the Unlink from incident button in the toolbar at the top.
The Unlink alerts window opens.
- If you want to change the assignee, select Assign the alerts to, and then specify the new assignee.
- If you want to add a comment, specify it in the Comment section. The comment you specify will be displayed in the Details column in the History section.
The selected alerts are unlinked from the incident.
Linking events to alerts
If during the investigation you found an event that is related to the alert being investigated, you can link this event to the alert manually.
You can link an event to an alert that has any status other than Closed.
To link an event to an alert:
- In the main menu, go to Monitoring & reporting → Alerts.
- In the list of alerts, click the link with the ID of the alert to which you want to link the event.
The Alert details window opens.
- Go to the Details section, and then click the Find in Threat hunting button.
The Threat hunting section opens. By default, the event table contains events related to the selected alert.
The event table contains only events related to tenants that you have access to.
- In the upper part of the window, open the first drop-down list, and then select Storage.
- Open the third drop-down list, and then specify the time range.
You can select predefined ranges relative to the current date and time, specify a custom range by using the Range start and Range end fields, or by selecting dates in the calendar.
- Click the Run query button.
- In the updated list of events, select an event that you want to link to the alert, and then click Link to alert.
The selected events are linked to the alert.
Page topUnlinking events from alerts
You might need to unlink an event from an alert, for example, if the alert analysis and investigation showed that the event is not connected to the alert.
To unlink an event from an alert:
- In the main menu, go to Monitoring & reporting → Alerts.
- In the list of alerts, click the link with the ID of the alert from which you want to unlink the event.
The Alert details window opens.
- In the Details section, select the events that you want to unlink, and then click the Unlink from alert button.
The selected event are unlinked from the alert.
Page topEditing alerts by using playbooks
Kaspersky Next XDR Expert allows you to edit incidents manually or by using playbooks. When creating a playbook, you can configure the playbook algorithm to edit the alert properties.
To edit an alert by using a playbook, you must have one of the following XDR roles: Main administrator, SOC administrator, Tier 1 analyst, Tier 2 analyst, or Tenant administrator.
You cannot edit alerts that have the Closed status.
You can edit the following alerts properties by using the playbook:
- Assignee
- Alert status
- Comment
- ExternalReference attribute
- Additional data attribute
Examples of the expressions that you can use in the playbook algorithm to edit the alert properties:
- Assigning an alert to a user
- Unassigning an alert from a user
- Changing the alert status
- Adding a comment to an alert
- Editing the ExternalReference attribute
- Editing the Additional data attribute
Working with alerts on the investigation graph
On the investigation graph, you can perform the following actions with alerts:
- Add an alert to the graph.
- Hide an alert from the graph.
- View an alert details by selecting the corresponding item from the context menu of the alert node.
- Change an alert status.
- View events related to an alert.
- View assets related to an alert.
- View observables related to an alert.
Adding alerts to the investigation graph
You can add an alert to the investigation graph in one of the of the following ways:
- From the general table of alerts that opens when you click the Add alert button on the investigation graph. You have to select the check boxes next to the alerts that you want to be displayed on the investigation graph, and then click the Show on graph button.
- From the table of similar alerts.
To add an alert to the investigation graph from the table of similar alerts:
- Do one of the following:
- If on the investigation graph you have an asset, observable, or segmentation rule, click its node, and then in the context menu, click Find similar alerts.
- If on the investigation graph you have an event, click its node, and then in the context menu, click View details. In the window that opens, click the Show on graph button.
- If on the investigation graph you have an alert, click its node, and in the context menu, click Events. In the table of events, click the event whose details you want to open. If the event details contain an observable, asset, or segmentation rule, click the link in the corresponding field, and then in the context menu, click Find similar alerts.
- On the investigation graph, click the Threat hunting button, and then in the general table of events, click the event whose details you want to open. If the event details contain an observable, asset, or segmentation rule, click the link in the corresponding field, and then in the context menu, click Find similar alerts.
The table of similar alerts is displayed.
- Select the check boxes next to the alerts that you want to be displayed on the investigation graph, and then click the Show on graph button.
The selected alerts are added to the investigation graph.
Hiding alerts from the investigation graph
You can hide an alert from the investigation graph in one of the following ways:
- By clicking the alert node and selecting Hide in the context menu.
- Through the table of alerts.
To hide an alert from the graph through the table of alerts:
- Do one of the following:
- In the toolbar at the top of the investigation graph, click the Add alert button.
- If you have observables, assets, or events nodes displayed on the graph, click the node for which you want to add an alert, and then in the context menu, select Find similar alerts.
The table of alerts is displayed.
- Select the check boxes next to the alerts that you want to hide from the investigation graph, and then click the Show on graph button.
The selected alerts and their links will be hidden from the investigation graph. The related nodes remain on the investigation graph.
Changing an alert status
To change an alert status:
- Click the alert node, and in the context menu, select Change status.
- In the Change status pane that opens, select the status, and then click Save.
If you select the Closed status, you must select a resolution.
The status of the selected alerts is changed.
Viewing the events related to an alert
To view events related to an alert, do one of the following:
- Click the digit next to the alert node for which you want to display the events. The digit shows the number of events related to the alert.
- Click the alert node for which you want to display the events, and then in the context menu, click Events.
If you want to add the events from the table to the investigation graph, select the check boxes next to the events, and then click the Show on graph button.
If you want to hide the events from the investigation graph, select the check boxes next to the events, and then click the Hide on graph button.
Viewing assets related to an alert
To view assets related to an alert, click the alert node.
In the context menu, the digits next to the Devices and Users items show the number of devices and users related to the alert.
If you want to add devices or users to the investigation graph, click the corresponding menu item.
Viewing observables related to an alert
To view observables related to an alert, click the alert node, and in the context menu, click Events.
In the menu that opens, the digits next to the items show the number of observables relate related to the alert.
If you want to add an observable (for example, Hash, Domain, IP address) to the investigation graph, click the corresponding menu item.
Page topAggregation rules
You can use aggregation rules to combine correlation events into alerts. We recommend that you use segmentation rules together with aggregation rules to define more precise rules for creating incidents.
The default Kaspersky Next XDR Expert behavior is to combine events that have the same rule identifier with the following limitations:
- By time, within 30 seconds
- By the number of events, 100
- By the number of assets, 100
- By the number of observables, 200
- By total size of events, 4 MB
You can use REST API to customize aggregation rules.
Aggregation rules. Example
The table below illustrates how to perform penetration testing with predetermined IP and user accounts.
Rule 1. Penetration testing by IP
Attribute |
Value |
Description |
Priority |
0 |
Highest priority. |
Trigger |
any(.Observables[]? | select(.Type == "ip") | .Value; . == "10.10.10.10" or . == "10.20.20.20") |
Triggers if an alert includes an IP observable with any of the following values:
|
Aggregation ID |
"Pentest" |
Specifies the identifier by which to combine events in an alert. |
Alert Name |
"[Pentest] " + ([.Rules[]?.Name] | join(",")) |
Adds the "[Pentest]" tag and the rule name to the alert name. The rule name is from the first aggregated alert, subsequent alerts do not affect the resulting alert name even if they were created by a different rule. |
Aggregation Interval |
30 seconds |
|
Rule 2. Penetration testing by user account
Attribute |
Value |
Description |
Priority |
1 |
|
Trigger |
any(.Observables[]? | select(.Type | ascii_downcase == "username") | .Value; . == "Pentester-1" or . == "Pentester-2") |
Triggers if an alert includes a username observable with any of the following values:
|
Aggregation ID |
"Pentest" |
Specifies the identifier by which to combine events in an alert. |
Alert Name |
"[Pentest] " + ([.Rules[]?.Name] | join(",")) |
Adds the "[Pentest]" tag and the rule name to the alert name. The rule name is from the first aggregated event, subsequently aggregated events do not affect the resulting alert name. |
Aggregation Interval |
30 seconds |
|
Rule 3. Aggregation rule
Attribute |
Value |
Description |
Priority |
2 |
|
Trigger |
.Rules | length > 0 |
Triggers if the rule list is not empty. |
Aggregation ID |
([.Rules[].ID // empty] | sort | join(";")) |
Combines rule identifiers. |
Alert Name |
([.Rules[]?.Name // empty] | sort | join(",")) + " " + (.SourceCreatedAt) |
Combines rule names and adds the alert creation date. |
Aggregation Interval |
30 seconds |
|
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
Attribute |
Value |
Description |
Trigger |
any(.Rules[]?; .ID == "123") |
Searches alerts with the rule id set to "123". |
Aggregation ID |
if any(.OriginalEvents[]?.BaseEvents[]?.DestinationUserName // empty; startswith("adm_")) then "rule123_DestinationUserName_adm" else "rule123_DestinationUserName_not_adm" end |
Searches for user names with the "adm_" prefix. |
Alert Name |
if any(.OriginalEvents[]?.BaseEvents[]?.DestinationUserName // empty; startswith("adm_")) then "Rule123 admin" else "Rule123 not admin" end |
Sets the alert name depending on the user name prefix. |
Segmentation rule
Attribute |
Value |
Trigger |
.AggregationID | startswith("rule123_DestinationUserName") |
Groups |
[.AggregationID] |
Incident Name |
.Name |
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
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:
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
Field |
Value type |
Is required |
Description |
|
String |
Yes |
Internal incident ID, in the UUID format. |
|
Integer |
Yes |
Short internal incident ID. |
|
String |
Yes |
ID of the tenant that the incident is associated with, in the UUID format. |
|
|
Yes |
Incident type. |
|
String |
Yes |
Incident name. |
|
String |
Yes |
Name of the incident workflow. |
|
String |
Yes |
Unique identifier of the incident workflow, in the UUID format. |
|
String |
No |
Incident description. |
|
String |
Yes |
Date and time of the incident creation, in the RFC 3339 format. |
|
String |
Yes |
Date and time of the last incident change, in the RFC 3339 format. |
|
String |
No |
Date and time of the incident status change, in the RFC 3339 format. |
|
String |
No |
Severity of the incident. Possible values:
|
|
String |
Yes |
Priority of the incident. Possible values:
|
|
|
No |
Operator to whom the incident is assigned. |
|
String |
No |
Date and time of the first telemetry event of the alert related to the incident, in the RFC 3339 format. |
|
String |
No |
Date and time of the last telemetry event of the alert related to the incident, in the RFC 3339 format. |
|
String |
Yes |
Incident status. Possible values:
|
|
String |
Yes |
Incident status ID, in the UUID format. |
|
String |
No |
Resolution of the incident status. Possible values:
|
|
Array of strings |
No |
Components that detect and generate the incident. |
|
Array of strings |
No |
Triggered detection technology. |
|
No |
Alerts included in the incident. |
|
|
Object |
No |
Additional information about the alert, in the JSON format. This information can be filled in by a user or a playbook. |
|
String |
Yes |
Link to an entity in an external system (for example, a link to a Jira ticket). |
|
String |
Yes |
Method of creating an incident. |
|
Array of |
No |
Attachments related to the incident. |
IncidentType
Field |
Value type |
Is required |
Description |
|
String |
Yes |
Incident type ID, in the UUID format. |
|
String |
Yes |
Name of the incident type. |
|
String |
Yes |
Description of the incident type. |
Assignee
Field |
Value type |
Is required |
Description |
|
String |
Yes |
User account ID of the operator to whom the incident is assigned. |
|
String |
Yes |
Name of the operator to whom the incident is assigned. |
UnkeyedAttachment
Field |
Value type |
Is required |
Description |
|
String |
Yes |
Attachment ID, in the UUID format. |
|
String |
Yes |
Attachment name. |
|
String |
Yes |
Date and time of the attachment creation, in the UTC format. |
|
String |
Yes |
Date and time of the last attachment change, in the UTC format. |
|
String |
Yes |
Indicator that the affected asset (a device or an account) is a victim. |
|
Integer |
Yes |
Attachment size, specified in bytes. |
|
String |
Yes |
Attachment status that indicates whether the attachment upload is in progress, completed, or aborted with an error. Possible values:
|
|
String |
No |
Attachment description. |
|
String |
No |
Text of the status that is displayed to a user (for example, an error message that is displayed when the attachment upload fails). |
Creating incidents
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:
- In the main menu, go to Monitoring & reporting → Incidents. Click the Create incident button.
- On the General settings step, specify the following settings:
- Incident name
- Tenant
- Assignee
- Priority
- Description
- 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:
- In the main menu, go to Monitoring & reporting → Incidents.
- 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:
- Click the link next to the Tenant filter setting.
The tenant filter opens.
- 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.
- Click the link next to the Tenant filter setting.
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:
- In the main menu, go to Monitoring & reporting → Incidents.
The incident table is displayed.
- 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.
- Click the filter icon (
- Click the Export button.
- 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.
Page topViewing incident details
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:
- In the main menu, go to Monitoring & reporting → Incidents.
- 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:
Page topAssigning 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:
- In the main menu, go to Monitoring & reporting → Incidents.
- 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.
- Click the Assign to button.
- 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.
- 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
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:
To change status of one or several incidents:
- In the main menu, go to MONITORING & REPORTING → Incidents.
- 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.
- Click the Change status button.
- 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.
- 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:
- In the main menu, go to Monitoring & reporting → Incidents.
- 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.
- Click the Change priority button.
- In the Change priority window, select the priority to set.
- 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:
- In the main menu, go to Monitoring & reporting → Incidents.
- 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.
- Click the Merge incidents button.
The Merge incidents Wizard opens.
- Select the target incident.
- Click the OK button.
The incidents are merged.
To merge incidents by using incident details:
- In the main menu, go to Monitoring & reporting → Incidents.
- 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.
- Click the Merge incident button.
The Merge incidents Wizard opens.
- Select the target incident.
- Click the OK button.
The incidents are merged.
Editing incidents by using playbooks
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
- Unassigning an incident from a user
- Changing a status of the incident workflow
- Changing the incident type
- Adding a comment to an incident
- Editing the incident description
- Changing the incident priority
- Editing the ExternalReference attribute
- Editing the Additional data attribute
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:
- In the main menu, go to Monitoring & reporting → Incidents.
- In the incident table, click the ID of the required incident.
The window with incident details is displayed.
- 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:
- Click a graph element corresponding to an alert group.
A table shows up that lists the alerts.
- Select an alert that you want to show on the graph.
- Click the Show on graph button in the table toolbar.
The alert is added as a graph node.
- 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:
- Click the Link nodes button.
Link points appear around graph nodes.
- 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.
Page topSegmentation 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:
- In the main menu, go to Settings → Tenants.
- Click the tenant for which you want to create a segmentation rule.
- In the Settings tab, select Segmentation rules.
- Click Create.
A Segmentation rule window appears.
- 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 ]
- Status
- 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
Attribute |
Value |
Trigger |
.AggregationID == "Pentest" |
Groups |
["Pentest"] |
Incident Name |
"Pentest incident" |
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
Attribute |
Value |
Description |
Trigger |
any(.Rules[]?; .ID == "123") |
Searches alerts with the rule id set to "123". |
Aggregation ID |
if any(.OriginalEvents[]?.BaseEvents[]?.DestinationUserName // empty; startswith("adm_")) then "rule123_DestinationUserName_adm" else "rule123_DestinationUserName_not_adm" end |
Searches for user names with the "adm_" prefix. |
Alert Name |
if any(.OriginalEvents[]?.BaseEvents[]?.DestinationUserName // empty; startswith("adm_")) then "Rule123 admin" else "Rule123 not admin" end |
Sets the alert name depending on the user name prefix. |
Segmentation rule
Attribute |
Value |
Trigger |
.AggregationID | startswith("rule123_DestinationUserName") |
Groups |
[.AggregationID] |
Incident Name |
.Name |
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:
- In the main menu, go to Settings → Tenants.
- Click the tenant that has the segmentation rule that you want to copy.
- In the Settings tab, select Segmentation rules.
- Select segmentation rules you want to copy and click Copy to tenant.
- 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.
Page topViewing the incident types table
To view the incident types table:
- In the main menu, go to Settings → Tenants.
- Click the name of the required tenant.
The tenant's properties window opens.
- On the Settings tab, click Incident management.
The Types tab is displayed with the incident types table.
- 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.
- Click the filter icon (
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
- Common
- 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.
Page topCreating incident types
To create an incident type:
- In the main menu, go to Settings → Tenants.
- Click the name of the required tenant.
The tenant's properties window opens.
- On the Settings tab, click Incident management, and then select the Types tab.
- Click the Create button.
The Create incident type window opens.
- If you want the new incident type to be active, switch on the Active type toggle button.
- In the Name field, enter the name of the new incident type.
- 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.
- In the Workflow field, select the incident workflow.
- If necessary, in the Description field, enter an incident type description or a comment.
- Click the Create button.
The new incident type is displayed in the incident types table.
Page topEditing incident types
If necessary, you can edit incident types.
To edit an incident type:
- In the main menu, go to Settings → Tenants.
- Click the name of the required tenant.
The tenant's properties window opens.
- On the Settings tab, click Incident management.
The Types tab is displayed with the incident types table.
- Click the name of the incident type that you want to edit.
The Edit incident type window opens.
- 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.
Page topDeleting 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:
- In the main menu, go to Settings → Tenants.
- Click the name of the required tenant.
The tenant's properties window opens.
- On Settings, click Incident management.
The Types tab is displayed with the incident types table.
- 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.
- In the confirmation dialog box, click Delete.
The incident type is deleted.
Page topManaging 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.
Page topViewing incident workflows table
To view the incident workflows table:
- In the main menu, go to Settings → Tenants.
- Click the name of the required tenant.
The tenant's properties window opens.
- 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.
Status |
Reasons |
Initial |
|
In progress |
The user manually changed the incident status from Initial or On hold to In progress. |
On hold |
The user manually changed the incident status from In progress to On hold. |
Done |
|
Creating incident workflows
The incident workflow allows you to manage incident lifecycle.
To create an incident workflow:
- In the main menu, go to Settings → Tenants.
- Click the name of the required tenant.
The tenant's properties window opens.
- On the Settings tab, click Incident management, and then select the Workflows tab.
- 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.
- In the Name field, enter the name of the new workflow.
- If necessary, in the Description field, enter a workflow description or a comment.
- To add new statuses, in the Workflow section, click Add status.
- In the window that opens, specify the following settings:
- In the Status name field, enter the name of the new status.
- 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.
- 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.
- 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.
- Click Add.
The visualized workflow is displayed in the Create workflow window.
If necessary, repeat steps 7-8e to add new statuses.
- In the Create workflow window, click Save.
The new incident workflow is displayed in the table.
Page topEditing incident workflows and statuses
You can edit workflow properties, as well as workflow' statuses and transitions.
To edit the incident workflow:
- In the main menu, go to Settings → Tenants.
- Click the name of the required tenant.
The tenant's properties window opens.
- On the Settings tab, click Incident management, and then select the Workflows tab.
- Click the name of the workflow that you want to edit.
The Edit workflow window opens.
- 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:
- In the main menu, go to Settings → Tenants.
- Click the name of the required tenant.
The tenant's properties window opens.
- On the Settings tab, click Incident management, and then select the Workflows tab.
- Click the name of the workflow that you want to edit.
The Edit workflow window opens.
- Click the name of the status that you want to edit.
The Edit status window opens.
- 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.
- Click the Save button.
The workflow statuses are modified and saved.
Page topDeleting 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:
- In the main menu, go to Settings → Tenants.
- Click the name of the required tenant.
The tenant's properties window opens.
- On the Settings tab, click Incident management, and then select the Workflows tab.
- In the list of workflows, select the workflow that you want to delete, and then click Delete.
- In the confirmation dialog box, click Delete.
The incident workflow is deleted.
Page topConfiguring the retention period of alerts and incidents
Kaspersky Next XDR Expert allows you to reduce or increase the retention periods of alerts and incidents, depending on your needs. By default, the retention period of alerts and incidents is 360 days.
The child tenant copies the retention period of alerts and incidents from the parent tenant. If necessary, you can edit the retention period for the child tenant.
To configure the alert or incident retention period:
- In the main menu, go to Settings → Tenants.
- Click the name of the required tenant.
The tenant's properties window opens.
- On the Settings tab, click Retention period.
- Specify the new retention period in one or both of the following fields:
- Alert retention period (days)
- Incident retention period (days)
The minimum value is
1
. - Click Save.
The new retention period is configured.
Regardless of the configured retention period, if the expired alert is linked to an unexpired incident, the alert will be deleted only after the retention period of the linked incident expires. If the expired incident has unexpired linked alerts, the incident will be deleted only after the retention period of the linked alerts expires.
Page topViewing asset details
Asset details are a window that contains all information related to the asset.
You can view asset details in one of the following ways:
- From alert details
- From incident details
- From event details (if the event contains assets)
To view asset details:
- In the main menu, go to Monitoring & reporting, and then do one of the following:
- If you want to view asset details from alert details, click Alerts, and then in the ID column, click the ID of the alert that includes the asset whose details you want to view. In the window that opens, go to the Assets tab.
- If you want to view asset details from incident details, click Incidents, and then in theID column, click the ID of the incident that includes the asset whose details you want to view. In the window that opens, go to the Assets tab.
- If you want to view asset details from event details, click Threat hunting, and then click the event that contains the asset whose details you want to view.
- Click the name of the required asset, and then in the drop-down list, select View properties.
The asset details window is displayed.
The asset details window contains the following sections:
- Asset properties—Information about the asset, for example, asset name, ID, and tenant to which the asset belongs.
If the current license in KUMA includes the AI module, the AI score field is displayed and shows the asset score. This field shows the degree of atypical activity on the asset and may take the values in the range from 0 to1, where 0 is expected behavior, and 1 is completely unexpected behavior for the asset within the infrastructure.
- Categories—Information about the categories associated with the asset.
- Custom fields—Asset fields that you created in KUMA Console.
- Installed software—Information about software installed on the asset.
- KSC: vulnerabilities—Vulnerabilities of the asset, if provided. This information is available for assets imported from Kaspersky Security Center.
- Kaspersky applications—Information about the Kaspersky applications installed on the asset.
- Device protection status—Status of the asset; the following values are possible: OK, Critical, Warning. This information is available for assets imported from Kaspersky Security Center.
- KICS for Networks: asset properties—Information about the asset. This information is imported from KICS for Networks.
- KICS for Networks: vulnerabilities—Vulnerabilities of the asset, if provided. This information is available for assets imported from KICS for Networks.
You can expand the sections by clicking the chevron icons () next to their names.