Working with incidents

In the Incidents section of the KUMA web interface, you can create, view and process incidents. You can also filter incidents if needed. Clicking the name of an incident opens a window containing information about the incident.

Displayed date format:

• English localization: YYYY-MM-DD.
• Russian localization: DD.MM.YYYY.

About the incidents table

The main part of the Incidents section shows a table containing information about registered incidents. If required, you can change the set of columns and the order in which they are displayed in the table.

How to customize the incidents table

Available columns of the incidents table:

• Name—the name of the incident.
• Threat duration—the time span during which the incident occurred (the time between the first and the last event related to the incident).
• Assigned to—the name of the security officer to whom the incident was assigned for investigation or response.
• Created—the date and time when the incident was created. This column allows you to filter incidents by the time they were created.
  • The following preset periods are available: Today, Yesterday, This week, Previous week.
  • If required, you can set an arbitrary period by using the calendar that opens when you select Before date, After date, or In period.
• Tenant—the name of the tenant that owns the incident.
• Status—current status of the incident:
  • Opened—new incident that has not been processed yet.
  • Assigned—the incident has been processed and assigned to a security officer for investigation or response.
  • Closed—the incident is closed; the security threat has been resolved.
• Alerts number—the number of alerts included in the incident. Only the alerts of those tenants to which you have access are taken into account.
• Priority shows how important a possible security threat is: Critical , High , Medium , Low .
• Affected asset categories—categories of alert-related assets with the highest severity. No more than three categories are displayed.
• Updated—the date and time of the last change made in the incident.
• First event time and Last event time—dates and times of the first and last events in the incident.
• Incident category and Incident type—category and type of threat assigned to the incident.
• Export to RuCERT—the status of the export of the incident data to the National Coordinating Center for Computer Incidents (also known as RuCERT):
  • Not exported—the data was not forwarded to RuCERT.
  • Export failed—an attempt to forward data to RuCERT ended with an error, and the data was not transmitted.
  • Exported—data on the incident has been successfully transmitted to RuCERT.
• Branch—data on the specific node where the incident was created. Incidents of your node are displayed by default. This column is displayed only when hierarchy mode is enabled.

In the Search field, you can enter a regular expression for searching incidents based on their related assets, users, tenants, and correlation rules. Parameters that can be used for a search:

• Assets: name, FQDN, IP address.
• Active Directory accounts: attributes displayName, SAMAccountName, and UserPrincipalName.
• Correlation rules: name.
• KUMA users who were assigned alerts: name, login, email address.
• Tenants: name.

When filtering incidents based on a specific parameter, the corresponding column in the incidents table is highlighted in yellow.

Saving and selecting incident filter configuration

In KUMA, you can save changes to incident table settings as filters. Filter configurations are saved on the KUMA Core server and are available to all KUMA users of the tenant for which they were created.

To save the current filter configuration settings:

1. In the Incidents section of KUMA, open the Select filter drop-down list.
2. Select Save current filter.

   A window will open for entering the name of the new filter and selecting the tenant that will own the filter.

3. Enter a name for the filter configuration. The name must be unique for alert filters, incident filters, and event filters.
4. In the Tenant drop-down list, select the tenant that will own the filter and click Save.

The filter configuration is now saved.

To select a previously saved filter configuration:

1. In the Incidents section of KUMA, open the Select filter drop-down list.
2. Select the configuration you want.

The filter configuration is now active.

You can select the default filter by putting an asterisk to the left of the required filter configuration name in the Filters drop-down list.

To reset the current filter settings,

open the Filters drop-down and select Clear filter.

Deleting incident filter configurations

To delete a previously saved filter configuration:

1. In the Incidents section of KUMA, open the Filters drop-down list.
2. Click the button next to the configuration you want to delete.
3. Click OK.

The filter configuration is now deleted for all KUMA users.

Viewing information about an incident

To view information about an incident:

1. In the program web interface window, select the Incidents section.
2. Select the incident whose information you want to view.

This opens a window containing information about the incident.

Some incident parameters are editable.

The upper part of the incident information window displays a toolbar and the name of the user to whom the incident was assigned. In this window, you can process the incident: assign it to a user, combine it with another incident, or close it.

The Description section contains the following data:

• Created—the date and time when the incident was created.
• Name—the name of the incident.

  You can change the name of an incident by entering a new name in the field and clicking Save The name must contain from 1 to 128 Unicode characters.

• Tenant—the name of the tenant that owns the incident.

  The tenant can be changed by selecting the required tenant from the drop-down list and clicking Save

• Status—current status of the incident:
  • Opened—new incident that has not been processed yet.
  • Assigned—the incident has been processed and assigned to a security officer for investigation or response.
  • Closed—the incident is closed; the security threat has been resolved.
• Priority—the severity of the threat posed by the incident. Possible values:
  • Critical
  • High
  • Medium
  • Low

  Priority can be changed by selecting the required value from the drop-down list and clicking Save.

• Affected asset categories—the assigned categories of assets associated with the incident.
• First event time and Last event time—dates and times of the first and last events in the incident.
• Type and Category—type and category of the threat assigned to the incident. You can change these values by selecting the relevant value from the drop-down list and clicking Save.
• Export to RuCERT—information on whether or not this incident was exported to RuCERT.
• Description—description of the incident.

  To change the description, edit the text in the field and click Save The description can contain no more than 256 Unicode characters.

• Related tenants—tenants associated with incident-related alerts, assets, and users.
• Available tenants—tenants whose alerts can be linked to the incident automatically.

  The list of available tenants can be changed by checking the boxes next to the required tenants in the drop-down list and clicking Save.

The Related alerts section contains a table of alerts related to the incident. When you click on the alert name, a window opens with detailed information about this alert.

The Related endpoints and Related users sections contain tables with data on assets and users related to the incident. This information comes from alerts that are related to the incident.

You can add data to the tables in the Related alerts, Related endpoints and Related users sections by clicking the Link button in the appropriate section and selecting the object to be linked to the incident in the opened window. If required, you can unlink objects from the incident. To do this, select the objects as required, click Unlink in the section to which they belong, and save the changes. If objects were automatically added to the incident, they cannot be unlinked until the alert mentioning those objects is unlinked.

The Change log section contains a record of the changes you and your users made to the incident. Changes are automatically logged, but it is also possible to add comments manually.

Incident creation

To create an incident:

1. Open the KUMA web interface and select the Incidents section.
2. Click Create incident.

   The window for creating an incident will open.

3. Fill in the mandatory parameters of the incident:
   • In the Name field enter the name of the incident. The name must contain from 1 to 128 Unicode characters.
   • In the Tenant drop-down list, select the tenant that owns the created incident.
4. If necessary, provide other parameters for the incident:
   • In the Priority drop-down list, select the severity of the incident. Available options: Low, Medium, High, Critical.
   • In the First event time and Last event time fields, specify the time range in which events related to the incident were received.
   • In the Category and Type drop-down lists, select the category and type of the incident. The available incident types depend on the selected category.
   • Add the incident Description. The description can contain no more than 256 Unicode characters.
   • In the Available tenants drop-down list, select the tenants whose alerts can be linked to the incident automatically.
   • In the Related alerts section, add alerts related to the incident.

     Linking alerts to incidents

     To link an alert to an incident:

     1. In the Related alerts section of the incident window click Link.

        A window with a list of alerts not linked to incidents will open.

     2. Select the required alerts.

        PCRE regular expressions can be used to search alerts by user, asset, tenant, and correlation rule.

     3. Click Link.

     Alerts are now related to the incident and displayed in the Related alerts section.

     To unlink alerts from an incident:

     1. Select the relevant alerts in the Related alerts section and click Unlink.
     2. Click Save.

     Alerts have been unlinked from the incident. Also, the alert can be unlinked from the incident in the alert window using the Unlink button.

   • In the Related endpoints section, add assets related to the incident.

     Linking assets to incidents

     To link an asset to an incident:

     1. In the Related endpoints section of the incident window, click Link.

        A window containing a list of assets will open.

     2. Select the relevant assets.

        You can use the Search field to look for assets.

     3. Click Link.

     Assets are now linked to the incident and are displayed in the Related endpoints section.

     To unlink assets from an incident:

     1. Select the relevant assets in the Related endpoints section and click Unlink.
     2. Click Save.

     The assets are now unlinked from the incident.

   • In the Related users section, add users related to the incident.

     Linking users to incidents

     To link a user to an incident:

     1. In the Related users section of the incident window, click Link.

        The user list window opens.

     2. Select the required users.

        You can use the Search field to look for users.

     3. Click Link.

     Users are now linked to the incident and appear in the Related users section.

     To unlink users from the incident:

     1. Select the required users in the Related users section and click the Unlink button.
     2. Click Save.

     Users are unlinked from the incident.

   • Add a Comment to the incident.
5. Click Save.

The incident has been created.

Incident processing

You can assign an incident to a user, aggregate it with other incidents, or close it.

To process an incident:

1. Select required incidents using one of the methods below:
   • In the Incidents section of the KUMA web interface, click on the incident to be processed.

     The incident window will open, displaying a toolbar on the top.

   • In the Incidents section of the KUMA web console, select the check box next to the required incidents.

     A toolbar will appear at the bottom of the window.

2. In the Assign to drop-down list, select the user to whom you want to assign the incident.

   You can assign the incident to yourself by selecting Me.

   The status of the incident changes to assigned and the name of the selected user is displayed in the Assign to drop-down list.

3. If required, edit the incident parameters
4. After investigating, close the incident:
   1. Click Close.

      A confirmation window opens.

   2. Select the reason for closing the incident:
      • Approved. This means the appropriate measures were taken to eliminate the security threat.
      • Not approved. This means the incident was a false positive and the received events do not indicate a security threat.
   3. Click Close.

   The Closed status will be assigned to the incident. Incidents with this status cannot be edited, and they are displayed in the incidents table only if you selected the Closed check box in the Status drop-down list when filtering the table. You cannot change the status of a closed incident or assign it to another user, but you can aggregate it with another incident.

5. If requited, aggregate the selected incidents with another incident:
   1. Click Merge. In the opened window, select the incident in which all data from the selected incidents should be placed.
   2. Confirm your selection by clicking Merge.

   The incidents will be aggregated.

The incident has been processed.

Changing incidents

To change the parameters of an incident:

1. In the Incidents section of the KUMA web interface, click on the incident you want to modify.

   The Incident window opens.

2. Make the necessary changes to the parameters. All incident parameters that can be set when creating it are available for editing.
3. Click Save.

The incident will be modified.

Automatic linking of alerts to incidents

In KUMA, you can configure automatic linking of generated alerts to existing incidents if alerts and incidents have related assets or users in common. If this setting is enabled, when creating an alert the program searches for incidents falling into a specified time interval that includes assets or users from the alert. In addition, the program checks whether the generated alert pertains to the tenants specified in the incidents' Available tenants parameter. If a matching incident is found, the program links the generated alert to the incident it found.

To set up automatic linking of alerts to incidents:

1. In the KUMA web interface, open Settings → Incidents → Automatic linking of alerts to incidents.
2. Select the Enable check box in the Link by assets and/or Link by accounts parameter blocks depending on the types of connections between incidents and alerts that you are looking for.
3. Define the Incidents must not be older than value for the parameters that you want to use when searching links. The generated alerts will be compared with incidents no older than the specified interval.

Automatic linking of alerts to incidents is configured.

To disable automatic linking of alerts to incidents,

In the KUMA web interface, under Settings → Incidents → Automatic linking of alerts to incidents, select the Disabled check box.

Categories and types of incidents

For your convenience, you can assign categories and types. If an incident has been assigned a RuCERT category, it can be exported to RuCERT.

Categories and types of incidents that can be exported to RuCERT

The categories of incidents can be viewed or changed under Settings → Incidents → Incident types, in which they are displayed as a table. By clicking on the column headers, you can change the table sorting options. The resource table contains the following columns:

• Category—a common characteristic of an incident or cyberattack. The table can be filtered by the values in this column.
• Type—the class of the incident or cyberattack.
• RuCERT category—incident type according to RuCERT nomenclature. Incidents that have been assigned custom types and categories cannot be exported to RuCERT. The table can be filtered by the values in this column.
• Vulnerability—specifies whether the incident type indicates a vulnerability.
• Created—the date the incident type was created.
• Updated—the date the incident type was modified.

To add an incident type:

1. In the KUMA web interface, under Settings → Incidents → Incident types, click Add.

   The incident type creation window will open.

2. Fill in the Type and Category fields.
3. If the created incident type matches the RuCERT nomenclature, select the RuCERT category check box.
4. If the incident type indicates a vulnerability, check Vulnerability.
5. Click Save.

The incident type has been created.

Exporting incidents to RuCERT

Incidents created in KUMA can be exported to the National Coordinating Center for Computer Incidents (also known as RuCERT). Prior to exporting incidents, you must configure integration with RuCERT. An incident can be exported only once. Incidents can be exported to RuCERT by users that have the Can interact with RuCERT check box selected in the user settings.

You can export incidents to RuCERT only if your application license includes the GosSOPKA module (GosSOPKA is a Russian government system for the detection, prevention, and mitigation of computer attacks).

To export an incident to RuCERT:

1. In the Incidents section of the KUMA web interface, select the incident that you want to export using one of the following ways:
   • Select the check box next to the relevant incident.
   • Open the relevant incident.
2. Click Export to RuCERT.

   This opens the export settings window.

3. Specify the settings on the Basic tab of the Export to RuCERT window:
   • Category and Type—specify the type and category of the incident. Only incidents of specific categories and types can be exported to RuCERT.

     Categories and types of incidents that can be exported to RuCERT

     The table below lists the categories and types of incidents that can be exported to RuCERT:

     Incident category	Incident type
     Computer incident notification	Involvement of a controlled resource in malicious software infrastructure
     	Slowed operation of the resource due to a DDoS attack
     	Malware infection
     	Network traffic interception
     	Use of a controlled resource for phishing
     	Compromised user account
     	Unauthorized data modification
     	Unauthorized disclosure of information
     	Publication of illegal information on the resource
     	Distribution of spam messages from the controlled resource
     	Successful exploitation of a vulnerability
     Notification about a computer attack	DDoS attack
     	Unsuccessful authorization attempts
     	Malware injection attempts
     	Attempts to exploit a vulnerability
     	Publication of fraudulent information
     	Network scanning
     	Social engineering
     Notification about a detected vulnerability	Vulnerable resource

   • TLP (required)—assign a Traffic Light Protocol marker to an incident to define the nature of information about the incident. The default value is RED. Available values:
     • WHITE—disclosure is not restricted.
     • GREEN—disclosure is only for the community.
     • AMBER—disclosure is only for organizations.
     • RED—disclosure is only for a specific group of people.
   • Affected system name (required)—specify the name of the information resource where the incident occurred. You can enter up to 500,000 characters in the field.
   • Affected system category (required)—specify the critical information infrastructure (CII) category of your organization. If your organization does not have a CII category, select Information resource is not a CII object.
   • Affected system function (required)—specify the scope of activity of your organization. The value specified in RuCERT integration settings is used by default.

     Available company business sectors

     • Nuclear energy
     • Banking and other financial market sectors
     • Mining
     • Federal/municipal government
     • Healthcare
     • Metallurgy
     • Science
     • Defense industry
     • Education
     • Aerospace industry
     • Communication
     • Mass media
     • Fuel and power
     • Transportation
     • Chemical industry
     • Other
   • Location (required)—select the location of your organization from the drop-down list.
   • Affected system has Internet connection—select this check box if the assets related to this incident have an Internet connection. In addition, after completing an export in the GosSOPKA account dashboard, provide technical information about the computer incident, computer attack, or vulnerability in the notification card. By default, this check box is cleared.
   • Product info (required)—this table becomes available if you selected Notification about a detected vulnerability as the incident category.

     You can use the Add new element button to add a string to the table. In the Name column, you must indicate the name of the application (for example, MS Office). Specify the application version in the Version column (for example, 2.4).

   • Vulnerability ID—if necessary, specify the identifier of the detected vulnerability. For example, CVE-2020-1231.

     This field becomes available if you selected Notification about a detected vulnerability as the incident category.

   • Product category—if necessary, specify the name and version of the vulnerable product. For example, Microsoft operating systems and their components.

     This field becomes available if you selected Notification about a detected vulnerability as the incident category.

4. If required, define the settings on the Advanced tab of the Export to RuCERT window.

   The available settings on the tab depend on the selected category and type of incident:

   • Detection tool—specify the name of the product that was used to register the incident. For example, KUMA 1.5.
   • Assistance required—select this check box if you need help from GosSOPKA employees.
   • Incident end time—specify the date and time when the critical information infrastructure (CII object) was restored to normal operation after a computer incident, computer attack was ended, or a vulnerability was fixed.
   • Availability impact—assess the degree of impact that the incident had on system availability:
     • High
     • Low
     • None
   • Integrity impact—assess the degree of impact that the incident had on system integrity:
     • High
     • Low
     • None
   • Confidentiality impact—assess the degree of impact that the incident had on data confidentiality:
     • High
     • Low
     • None
   • Custom impact—specify other significant impacts from the incident.
   • City—indicate the city where your organization is located.
5. Click Export.
6. Confirm the export.

Information about the incident is submitted to RuCERT, and the Export to RuCERT incident parameter is changed to Exported successfully. If changes need to be made to the exported incident, you should do this in your GosSOPKA account dashboard.

Sending incidents involving personal information leaks to RuCERT

KUMA 2.1.x does not have a separate section with incident parameters for submitting information about personal information leaks to RuCERT. Since such incidents do occur and a need exists to submit information to RuCERT, use the following solution.

To submit incidents involving personal information leaks:

1. In the KUMA web interface, in the Incidents section, when creating an incident involving a personal information leak, in the Category field, select Notification about a computer incident.
2. In the Type field, select one of the options that involves submission of information about personal information leak:
   • Malware infection
   • Compromised user account
   • Unauthorized disclosure of information
   • Successful exploitation of a vulnerability
   • Event is not related to a computer attack
3. In the Description field, enter "The incident involves a leak of personal information. Please set the status to "More information required"".
4. Click Save.
5. Export the incident to RuCERT.

After RuCERT employees set the status to "More information required" and return the incident for further editing, in your RuCERT account, you can provide additional information about the incident in the "Details of the personal information leak" section.