Contents
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.
Incident data model
The structure of an incident is represented by fields that contain values (see the table below). Fields can also contain nested structures.
Section and subsections |
Incident field |
Value type |
Is required |
Description |
|
|
String |
Yes |
Short internal incident ID. |
|
String |
Yes |
Internal incident ID. |
|
|
String |
Yes |
ID of the tenant that the incident is associated with. |
|
|
String |
Yes |
Date and time of the incident creation. |
|
|
Nested list of strings |
Yes |
Detection technology triggered when the alert included in the incident was detected. Possible values:
|
|
|
String |
Yes |
Date and time of the first telemetry event of the alert related to the incident. |
|
|
String |
Yes |
Date and time of the last telemetry event of the alert related to the incident. |
|
|
String |
Yes |
Severity of the incident. Possible values:
|
|
|
String |
No |
Link to an entity in an external system (for example, a link to a Jira ticket). |
|
|
String |
Yes |
Incident status. Possible values:
|
|
|
String |
No |
Date and time of the incident status change. |
|
|
String |
No |
Resolution of the incident status. Possible values:
|
|
|
String |
Yes |
Date and time of the last incident change. |
|
|
String |
No |
Incident description. |
|
|
String |
Yes |
Method of creating an incident. Possible values:
|
|
|
String |
Yes |
Priority of the incident. Possible values:
|
|
|
String |
No |
Data of the application that provides the incident. Application data is presented in the JSON format. |
|
|
|
String |
No |
User account ID of the operator to whom the incident is assigned. |
|
String |
No |
Name of the operator to whom the incident is assigned. |
|
|
|
String |
No |
Array of tactics from MITRE related to all triggered IOA rules in the incident. |
|
|
String |
No |
Array of techniques from MITRE related to all triggered IOA rules in the incident. |
|
|
String |
No |
Additional information about observables. |
|
String |
No |
Observables type. Possible values:
|
|
|
String |
No |
Observables value. |
|
|
|
String |
No |
Confidence level of the triggered rule. Possible values:
|
|
Boolean |
No |
Indicator that the incident is based on custom rules. |
|
|
String |
No |
ID of the triggered rule. |
|
|
String |
No |
Name of the triggered rule. |
|
|
String |
No |
Severity of the triggered rule. |
|
|
String |
No |
Type of the triggered rule. |
|
|
|
String |
No |
ID of the affected asset (a device or an account). |
|
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. |
|
|
String |
No |
Administration Server that the affected asset (a device or an account) belongs to. This property is used to obtain the asset administration group. |
|
|
String |
No |
The name of the affected device that the incident is associated with (if The user name of the affected user account that the incident associated with (if |
|
|
String |
No |
Type of the affected asset (a device or an account). Possible values:
|
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:
- Incident ID, name. A name and a unique identifier of an incident.
- Created. Date and time when the incident was created.
- Updated. Date and time of the last change, from the incident history.
- Threat duration. Time between the earliest and the most recent events among all of the alerts linked to the incident.
- Status. Current status of the incident.
- Severity, priority. Severity and priority of the incident.
- Analyst. Current assignee of the incident.
- Tenant. The name of the tenant in which the incident was detected.
- Technology. The technologies that detected the alerts linked to the incident.
- Affected assets. Devices and users that were affected by the incident.
- Observables. Number of the detection artifacts, for example, IP addresses or MD5 hashes of files.
- Resolution. The resolution for incidents with the Closed status.
- Creation method. How the incident was created—manually or automatically.
- Number of linked alerts. How many alerts are included in the incident.
- Rules. The rules that were triggered to create the incident.
- Number of affected assets. How many devices and users affected by or involved in the incident.
- Number of observables. How many observables are related to the alerts linked to the incident.
Viewing 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.
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
- Assign the incident to an analyst
- Change the incident status
- Change the incident priority
- Link alerts to the incident
- Merge the incident with other incidents
- Open the investigation graph
- Select a playbook
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.
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.
If you select the Closed status, you must select a resolution.
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.
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.
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.
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.
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 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 specified conditions.
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.
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:
.Rules[].Name | . == "R077_02_KSC. Malware detected"
- Groups
A jq expression that defines the array of rules by which to assign alerts to incidents.
Example:
[.Observables[] | select(.Type == "md5") | .Value ]
- Status
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.