Working with alerts

Alerts are created when a sequence of events is received that triggers a correlation rule. You can find more information about alerts in this section.

In the Alerts section of the KUMA web interface, you can view and process the alerts registered by the application. Alerts can be filtered. When you click the alert name, a window with its details opens.

The alert date format depends on the localization language selected in the application settings. Possible date format options:

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

Alert life cycle

Below is the life cycle of an alert:

1. KUMA creates an alert when a correlation rule is triggered. The alert is named after the correlation rule that generated it. Alert is assigned the New status.

   Alerts with the New status continue to be updated with data when correlation rules are triggered. If the alert status changes, the alert is no longer updated with new events, and if the correlation rule is triggered again, a new alert is created.

2. A security officer assigns the alert to an operator for investigation. The alert status changes to assigned.
3. The operator performs one of the following actions:
   • Close the alert as false a positive (alert status changes to closed).
   • Respond to the threat and close the alert (alert status changes to closed).
   • Creates an incident based on the alert (the alert status changes to In incident).

Alert overflow

Each alert and its related events cannot exceed the size of 16 MB. When this limit is reached:

• New events can no longer be linked to the alert.
• The alert has an Overflowed tag displayed in the Detected column. The same tag is displayed in the Details on alert section of the alert details window.

Overflowed alerts should be handled as soon as possible because new events are not added to overflowed alerts. You can filter out all events that could be linked to an alert after the overflow by clicking the All possible related events link.

Alert segmentation

Using the segmentation rules, the stream of correlation events of the same type can be divided to create more than one alert.

Configuring alerts table

The main part of the Alerts section shows a table containing information about registered alerts.

The following columns are displayed in the alerts table:

• Severity ()—shows the importance of a possible security threat: Critical , High , Medium , or Low .
• Name—alert name.

  If Overflowed tag is displayed next to the alert name, it means the alert size has reached or is about to reach the limit and should be processed as soon as possible.

• Status—current status of an alert:
  • New—a new alert that hasn't been processed yet.
  • Assigned—the alert has been processed and assigned to a security officer for investigation or response.
  • Closed—the alert was closed. Either it was a false alert, or the security threat was eliminated.
  • Escalated—an incident was generated based on this alert.
• Assigned to—the name of the security officer the alert was assigned to for investigation or response.
• Incident—name of the incident to which this alert is linked.
• First seen—the date and time when the first correlation event of the event sequence was created, triggering creation of the alert.
• Last seen—the date and time when the last correlation event of the event sequence was created, triggering creation of the alert.
• Categories—categories of alert-related assets with the highest severity. No more than three categories are displayed.
• Tenant—the name of the tenant that owns the alert.
• CII—an indication whether the related to the alert assets are the CII objects. The column is hidden from the users who do not have access to CII objects.

You can view the alert filtering tools by clicking the column headers. When filtering alerts based on a specific parameter, the corresponding header of the alerts table is highlighted in yellow.

Click the button to configure the displayed columns of the alerts table.

In the Search field, you can enter a regular expression for searching alerts 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.

Filtering alerts

In KUMA, you can perform alert selection by using the filtering and sorting tools in the Alerts section.

The filter settings can be saved. Existing filters can be deleted.

Saving and selecting an alert filter

In KUMA, you can save changes to the alert table settings as filters. Filters 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 settings:

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

   A field will appear for entering the name of the new filter and selecting the tenant that will own it.

3. Enter a name for the filter. 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 is saved.

To select a previously saved filter:

1. In the Alerts section of KUMA open the Filters drop-down list.
2. Select the relevant filter.

   To select the default filter, put an asterisk to the left of the relevant filter name in the Filters drop-down list.

The filter is selected.

To reset the current filter settings,

Open the Filters drop-down list and select Clear filters.

Deleting an alert filter

To delete a previously saved filter:

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

The filter is deleted for all KUMA users.

Viewing details on an alert

To view details on an alert:

1. In the application web interface window, select the Alerts section.

   The alerts table is displayed.

2. Click the name of the alert whose details you want to view.

   This opens a window containing information about the alert.

The upper part of the alert details window contains a toolbar and shows the alert severity and the user name to which the alert is assigned. In this window, you can process the alert: change its severity, assign it to a user, and close and create an incident based on the alert.

Details on alert section

This section lets you view basic information about an alert. It contains the following data:

• Correlation rule severity is the severity of the correlation rule that triggered the creation of the alert.
• Max asset category severity—the highest severity of an asset category assigned to assets related to this alert. If multiple assets are related to the alert, the largest value is displayed.
• Linked to incident—if the alert is linked to an incident, the name and status of the alert are displayed. If the alert is not linked to an incident, the field is blank.
• First seen—the date and time when the first correlation event of the event sequence was created, triggering creation of the alert.
• Last seen—the date and time when the last correlation event of the event sequence was created, triggering creation of the alert.
• Alert ID—the unique identifier of an alert in KUMA.
• Tenant—the name of the tenant that owns the alert.
• Correlation rule—the name of the correlation rule that triggered the creation of the alert. The rule name is represented as a link that can be used to open the settings of this correlation rule.
• Overflowed is a tag meaning that the alert size has reached or will soon reach the limit of 16 MB and the alert must be handled. New events are not added to the overflowed alerts, but you can click the All possible related events link to filter all events that could be related to the alert if there were no overflow.

  A quick alert overflow may mean that the corresponding correlation rule is configured incorrectly, and this leads to frequent triggers. Overflowed alerts should be handled as soon as possible to correct the correlation rule if necessary.

Related events section

This section contains a table of events related to the alert. If you click the arrow () icon near a correlation rule, the base events from this correlation rule will be displayed. Events can be sorted by severity and time.

Selecting an event in the table opens the details area containing information about the selected event. The details area also displays the Detailed view button, which opens a window containing information about the correlation event.

The Find in events links below correlation events and the Find in events button to the right of the section heading are used to go to alert investigation.

You can use the Download events button to download information about related events into a CSV file (in UTF-8 encoding). The file contains columns that are populated in at least one related event.

Some CSV file editors interpret the separator value (for example, \n) in the CSV file exported from KUMA as a line break, not as a separator. This may disrupt the line division of the file. If you encounter a similar issue, you may need to additionally edit the CSV file received from KUMA.

In the events table, in the event details area, in the alert window, and in the widgets, the names of assets, accounts, and services are displayed instead of the IDs as the values of the SourceAssetID, DestinationAssetID, DeviceAssetID, SourceAccountID, DestinationAccountID, and ServiceID fields. When exporting events to a file, the IDs are saved, but columns with names are added to the file. The IDs are also displayed when you point the mouse over the names of assets, accounts, or services.

Searching for fields with IDs is only possible using IDs.

Related endpoints section

This section contains a table of assets related to the alert. Asset information comes from events that are related to the alert. You can search for assets by using the Search for IP addresses or FQDN field. Assets can be sorted using the Count and Endpoint columns.

This section also displays the assets related to the alert. Clicking the name of the asset opens the Asset details window.

You can use the Download assets button to download information about related assets into a CSV file (in UTF-8 encoding). The following columns are available in the file: Count, Name, IP address, FQDN, Categories.

Related users section

This section contains a table of users related to the alert. User information comes from events that are related to the alert. You can search for users using the Search for users field. Users can be sorted by the Count, User, User principal name and Email columns.

You can use the Download users button to download information about related users into a CSV file (in UTF-8 encoding). The following columns are available in the file: Count, User, User principal name, Email, Domain, Tenant.

Change log section

This section contains entries about changes made to the alert by users. Changes are automatically logged, but it is also possible to add comments manually. Comments can be sorted by using the Time column.

If necessary, you can enter a comment for the alert in the Comment field and click Add to save it.

Changing alert names

To change the alert name:

1. In the KUMA web interface window, select the Alerts section.

   The alerts table is displayed.

2. Click the name of the alert whose details you want to view.

   This opens a window containing information about the alert.

3. In the upper part of the window, click and in the field that opens, enter the new name of the alert. To confirm the name, press ENTER or click outside the entry field.

Alert name is changed.

Processing alerts

You can change the alert severity, assign an alert to a user, close the alert, or create an incident based on the alert.

To process an alert:

1. Select required alerts using one of the methods below:
   • In the Alerts section of the KUMA web interface, click the alert whose information you want to view.

     The Alert window opens and provides an alert processing toolbar at the top.

   • In the Alerts section of the KUMA web interface, select the check box next to the required alert. It is possible to select more than one alert.

     Alerts with the closed status cannot be selected for processing.

     A toolbar will appear at the bottom of the window.

2. If you want to change the severity of an alert, select the required value in the Severity drop-down list:
   • Low
   • Medium
   • High
   • Critical

   The severity of the alert changes to the selected value.

3. If you want to assign an alert to a user, select the relevant user from the Assign to drop-down list.

   You can assign the alert to yourself by selecting Me.

   The status of the alert will change to Assigned and the name of the selected user will be displayed in the Assign to drop-down list.

4. In the Related users section, select a user and configure Active Directory response settings.
   1. After the related user is selected, in the Account details window that opens, click Response via Active Directory.
   2. In the AD command drop-down list, select one of the following values:
      • Add account to group

        The Active Directory group to move the account from or to.
        In the mandatory field Distinguished name, you must specify the full path to the group.
        For example, CN = HQ Team, OU = Groups, OU = ExchangeObjects, DC = avp, DC = ru.
        Only one group can be specified within one operation.

      • Remove account from group

        The Active Directory group to move the account from or to.
        In the mandatory field Distinguished name, you must specify the full path to the group.
        For example, CN = HQ Team, OU = Groups, OU = ExchangeObjects, DC = avp, DC = ru.
        Only one group can be specified within one operation.

      • Reset account password
      • Block account
   3. Click Apply.
5. If required, create an incident based on the alert:
   1. Click Create incident.

      The window for creating an incident will open. The alert name is used as the incident name.

   2. Update the desired incident parameters and click the Save button.

   The incident is created, and the alert status is changed to Escalated. An alert can be unlinked from an incident by selecting it and clicking Unlink.

6. If you want to close the alert:
   1. Click Close alert.

      A confirmation window opens.

   2. Select the reason for closing the alert:
      • Responded. This means the appropriate measures were taken to eliminate the security threat.
      • Incorrect data. This means the alert was a false positive and the received events do not indicate a security threat.
      • Incorrect correlation rule. This means the alert was a false positive and the received events do not indicate a security threat. The correlation rule may need to be updated.
   3. Click OK.

   The status of the alert is changed to Closed. Alerts with this status are no longer updated with new correlation events and aren't displayed in the alerts table unless the Closed check box is selected in the Status drop-down list in the alerts table. You cannot change the status of a closed alert or assign it to another user.

Alert investigation

Alert investigation is used when you need to find more information about the threat that triggered the alert — is the threat real, what is its origin, what elements of the network environment are affected by it, how should the threat be dealt with. Studying the events related to the correlation events that triggered an alert can help you determine the course of action.

For convenience of investigating alerts, make sure that time is synchronized on all devices involved in the event life cycle (event sources, KUMA servers, client hosts) with the help of Network Time Protocol (NTP) servers.

The alert investigation mode is enabled in KUMA when you click the Find in events link in the alert window or the correlation event window. When the alert investigation mode is enabled, the events table is shown with filters automatically set to match the events from the alert or correlation event. The filters also match the time period of the alert duration or the time when the correlation event was registered. You can change these filters to find other events and learn more about the processes related to the threat.

An additional drop-down list becomes available in alert investigation mode:

• All events—view all events.
• Related to alert (selected by default)—view only events related to the alert.

  When filtering events related to an alert, there are limitations on the complexity of SQL search queries.

You can manually assign an event of any type except the correlation event to an alert. Only events that are not related to the alert can be linked to it.

You can create and save event filters in alert investigation mode. When using this filter in normal mode, all events that match the filter criteria are selected regardless of whether or not they are related to the alert that was selected for alert investigation.

To link an event to an alert:

1. In the Alerts section of the KUMA web interface, click the alert that you want to link to the event.

   The Alert window opens.

2. In the Related events section, click the Find in events button.

   The events table is opened and displayed with active date and time filters matching the date and time of events linked to the alert. The columns show the settings used by the correlation rule to generate the alert. The Link to alert column is also added to the events table showing the events linked to the alert.

3. In the drop-down list select All events.
4. If necessary, modify the filters to find the event that you need to link to the alert.
5. Select the relevant event and click the Link to alert button in the lower part of the event details area.

The event will be linked to the alert. You can unlink this event from the alert by clicking in the Unlink from alert detailed view.

When an event is linked to or unlinked from an alert, a corresponding entry is added to the Change log section in the Alert window. You can click the link in this entry to open the details area and unlink or link the event to the alert by clicking the corresponding button.

Retention period for alerts and incidents

Alerts and incidents are stored in KUMA for a year by default. This period can be changed by editing the application startup parameters in the file /usr/lib/systemd/system/kuma-core.service on the KUMA Core server.

To change the retention period for alerts and incidents:

1. Log in to the OS of the server where the KUMA Core is installed.
2. In the /usr/lib/systemd/system/kuma-core.service file, edit the following string by inserting the necessary number of days:

   ExecStart=/opt/kaspersky/kuma/kuma core --alerts.retention <number of days to store alerts and incidents> --external :7220 --internal :7210 --mongo mongodb://localhost:27017

3. Restart KUMA by running the following commands in sequence:
   1. systemctl daemon-reload
   2. systemctl restart kuma-core

The retention period for alerts and incidents will be changed.

Alert notifications

Standard KUMA notifications are sent by email when alerts are generated and assigned. You can configure delivery of alert generation notifications based on a custom email template.

To configure delivery of alert generation notifications based on a custom template:

1. In the KUMA web interface, open Settings → Alerts → Notification rules.
2. Select the tenant for which you want to create a notification rule:
   • If the tenant already has notification rules, select it in the table.
   • If the tenant has no notification rules, click Add tenant and select the relevant tenant from the Tenant drop-down list.
3. Under Notification rules, click Add and specify the notification rule settings:
   • Name (required)—specify the notification rule name in this field.
   • Recipient emails (required)—in this settings block, you can use the Email button to add the email addresses to which you need to send notifications about alert generation. Addresses are added one at a time.

     Cyrillic domains are not supported. For example, a notification cannot be sent to login@domain.us.

   • Correlation rules (required)—in this settings block, you must select one or more correlation rules that, when triggered, will cause notification sending.

     The window displays a tree structure representing the correlation rules from the shared tenant and the user-selected tenant. To select a rule, select the check box next to it. You can select the check box next to a folder to select all correlation rules in that folder and its subfolders.

   • Template (required)—in this settings block, you must select an email template that will be used to create the notifications. To select a template, click the icon, select the required template in the opened window, and click Save.

     You can create a template by clicking the plus icon or edit the selected template by clicking the pencil icon.

   • Disabled—by selecting this check box, you can disable the notification rule.
4. Click Save.

The notification rule is created. When an alert is created based on the selected correlation rules, notifications created based on custom email templates will be sent to the specified email addresses. Standard KUMA notifications about the same event will not be sent to the specified addresses.

To disable notification rules for a tenant:

1. In the KUMA web interface, open Settings → Alerts → Notification rules and select the tenant whose notification rules you want to disable.
2. Select the Disabled check box.
3. Click Save.

The notification rules of the selected tenant are disabled.

For disabled notification rules, the correctness of the specified parameters is not checked; at the same time, notifications cannot be enabled for a tenant if incorrect rules exist. If you create or edit individual notification rules with tenant notification rules disabled, before enabling tenant notification rules, it is recommended to: 1) disable all individual notification rules, 2) enable tenant notification rules, 3) enable individual notification rules one by one.