Managing KUMA

This section describes KUMA general settings.

Logging in to the program web interface

To log in to the program web interface:

1. Enter the following address in your browser:

   https://<IP address or FQDN of KUMA Core server>:7220

   The web interface authorization page will open and prompt you to enter your login and password.

2. Enter the login of your account in the Login field.
3. Enter the password for the specified account in the Password field.
4. Click the Login button.

The main window of the program web interface opens.

In multitenancy mode, a user who is logging in to the program web interface for the first time will see the data only for those tenants that were selected for the user when their user account was created.

To log out of the program web interface,

open the KUMA web interface, click your user account name in the bottom-left corner of the window, and click the Logout button in the opened menu.

Viewing KUMA metrics

Comprehensive information about the performance of the KUMA Core, storage, collectors, and correlators is available in the Metrics section of the KUMA web interface. Selecting this section opens the Grafana portal deployed as part of KUMA Core installation and is updated automatically.

The default Grafana user name and password are admin and admin.

Available metrics

Collector indicators:

• IO—metrics related to the service input and output.
  • Processing EPS—the number of processed events per second.
  • Processing Latency—the time required to process a single event (the median is displayed).
  • Output EPS—the number of events, sent to the destination per second.
  • Output Latency—the time required to send a batch of events to the destination and receive a response from it (the median is displayed).
  • Output Errors—the number or errors when sending event batches to the destination per second. Network errors and errors writing the disk buffer are displayed separately.
  • Output Event Loss—the number of lost events per second. Events can be lost due to network errors or errors writing the disk buffer. Events are also lost if the destination responded with an error code (for example, if the request was invalid).
• Normalization—metrics related to the normalizers.
  • Raw & Normalized event size—the size of the raw event and size of the normalized event (the median is displayed).
  • Errors—the number of normalization errors per second.
• Filtration—metrics related to the filters.
  • EPS—the number of events rejected by the Collector per second. The Collector only rejects events if the user has added a Filter resource into the Collector service configuration.
• Aggregation—metrics related to the aggregation rules.
  • EPS—the number of events received and created by the aggregation rule per second. This metric helps determine the effectiveness of aggregation rules.
  • Buckets—the number of buckets in the aggregation rule.
• Enrichment—metrics related to the enrichment rules.
  • Cache RPS—the number requests to the local cache per second.
  • Source RPS—the number of requests to the enrichment source (for example, the Dictionary resource).
  • Source Latency—the time required to send a request to the enrichment source and receive a response from it (the median is displayed).
  • Queue—the enrichment requests queue size. This metric helps to find bottleneck enrichment rules.
  • Errors—the number of enrichment source request errors per second.

Correlator metrics

• IO—metrics related to the service input and output.
  • Processing EPS—the number of processed events per second.
  • Processing Latency—the time required to process a single event (the median is displayed).
  • Output EPS—the number of events, sent to the destination per second.
  • Output Latency—the time required to send a batch of events to the destination and receive a response from it (the median is displayed).
  • Output Errors—the number or errors when sending event batches to the destination per second. Network errors and errors writing the disk buffer are displayed separately.
  • Output Event Loss—the number of lost events per second. Events can be lost due to network errors or errors writing the disk buffer. Events are also lost if the destination responded with an error code (for example, if the request was invalid).
• Correlation—metrics related to the correlation rules.
  • EPS—the number of correlation events created per second.
  • Buckets—the number of buckets in the correlation rule (only for the standard kind of correlation rules).
• Active Lists—metrics related to the active lists.
  • RPS—the number of requests (and their type) to the Active list per second.
  • Records—the number of entries in the Active list.
  • WAL Size—the size of the Write-Ahead-Log. This metric helps determine the size of the Active list.

Storage indicators

• IO—metrics related to the service input and output.
  • RPS—the number of requests to the Storage service per second.
  • Latency—the time of proxying a single request to the ClickHouse node (the median is displayed).

Core service metrics

• IO—metrics related to the service input and output.
  • RPS—the number of requests to the Core service per second.
  • Latency—the time of processing a single request (the median is displayed).
  • Errors—the number of request errors per second.
• Notification Feed—metrics related to user activity.
  • Subscriptions—the number of clients, connected to the Core via SSE to receive server messages in real time. This number usually correlates with the number of clients using the KUMA web interface.
  • Errors—the number of message sending errors per second.
• Schedulers—metrics related to Core tasks.
  • Active—the number of repeating active system tasks. The tasks created by the user are ignored.
  • Latency—the time of processing a single request (the median is displayed).
  • Position—the position (timestamp) of the alert creation task. The next ClickHouse scan for correlation events will start from this position.
  • Errors—the number of task errors per second.

General metrics common for all services

• Process—general process metrics.
  • CPU—CPU usage.
  • Memory—RAM usage (RSS).
  • DISK IOPS—the number of disk read/write operations per second.
  • DISK BPS—the number of bytes read/written to the disk per second.
  • Network BPS—the number of bytes received/sent per second.
  • Network Packet Loss—the number of network packets lost per second.
  • GC Latency—the time of the GO Garbage Collector cycle (the median is displayed).
  • Goroutines—the number of active goroutines. This number differs from the thread count.
• OS—metrics related to the operating system.
  • Load—the average load.
  • CPU—CPU usage.
  • Memory—RAM usage (RSS).
  • Disk—disk space usage.

Metrics storage period

KUMA operation data is saved for 3 months by default. This storage period can be changed.

To change the storage period for KUMA metrics:

1. Log in to the OS of the server where the KUMA Core is installed.
2. In the file /etc/systemd/system/multi-user.target.wants/kuma-victoria-metrics.service, in the ExecStart parameter, edit the --retentionPeriod=<metrics storage period, in months> flag by inserting the necessary period. For example, --retentionPeriod=4 means that the metrics will be stored for 4 months.
3. Restart KUMA by running the following commands in sequence:
   1. systemctl daemon-reload
   2. systemctl restart kuma-victoria-metrics

The storage period for metrics has been changed.

Managing KUMA tasks

When working in the program web interface, you can use tasks to perform various operations. For example, you can import assets or export KUMA event information to a TSV file.

Viewing the tasks table

The tasks table contains a list of created tasks and is located in the Task manager section of the program web interface window. You can view the tasks that were created by you (current user).

A user with the General Administrator role can view the tasks of all users.

The tasks table contains the following information:

• State—the state of the task. One of the following statuses can be assigned to a task:
  • Green dot blinking—the task is active.
  • Completed—the task is complete.
  • Cancel—the task was canceled by the user.
  • Error—the task was not completed because of an error. The error message is displayed if you hover the mouse over the exclamation mark icon.
• Task—the task type. The program provides the following types of tasks:
  • Events export—export KUMA events.
  • Threat Lookup—request data from the Kaspersky Threat Intelligence Portal.
  • Retroscan—task for replaying events.
  • KSC assets import—imports asset data from Kaspersky Security Center servers.
  • Accounts import—imports user data from Active Directory.
  • KICS for Networks assets import—imports asset data from KICS for Networks.
• Created by—the user who created the task. If the task was created automatically, the column will show Scheduled task.

  This column is displayed only for users with the General Administrator and Administrator roles.

• Created—task creation time.
• Updated—time when the task was last updated.
• Tenant—the name of the tenant in which the task was started.

Displayed date format:

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

Configuring the display of the tasks table

You can customize the display of columns and the order in which they appear in the tasks table.

To customize the display and order of columns in the tasks table:

1. In the KUMA web interface, select the Task manager section.

   The tasks table is displayed.

2. In the table header, click the button.
3. In the opened window, do the following:
   • If you want to enable display of a column in the table, select the check box next to the name of the parameter that you want to display in the table.
   • If you do not want the parameter to be displayed in the table, clear the check box.

   At least one check box must be selected.

4. If you want to reset the settings, click the Default link.
5. If you want to change the order in which the columns are displayed in the table, move the mouse cursor over the name of the column, hold down the left mouse button and drag the column to the necessary position.

The display of columns in the tasks table will be configured.

Viewing task run results

To view the results of a task:

1. In the KUMA web interface, select the Task manager section.

   The tasks table is displayed.

2. Click the link containing the task type in the Task column.

   A list of the operations available for this task type will be displayed.

3. Select Show results.

The task results window opens.

Restarting a task

To restart a task:

1. In the KUMA web interface, select the Task manager section.

   The tasks table is displayed.

2. Click the link containing the task type in the Task column.

   A list of the operations available for this task type will be displayed.

3. Select Restart.

The task will be restarted.

Connecting to an SMTP server

KUMA can be configured to send email notifications using an SMTP server. Users will receive notifications if the Receive email notifications check box is selected in their profile settings.

Only one SMTP server can be added to process KUMA notifications. An SMTP server connection is managed in the KUMA web interface under Settings → General → SMTP server settings.

To configure SMTP server connection:

1. Open the KUMA web interface and select Settings → General.
2. In the SMTP server settings block, change the relevant settings:
   • Disabled—select this check box if you want to disable connection to the SMTP server.
   • Host (required)—SMTP host in one of the following formats: hostname, IPv4, IPv6.
   • Port (required)—SMTP port. The value must be an integer from 1 to 65535.
   • From (required)—email address of the message sender. For example, kuma@company.com.
   • Alias for KUMA Core server—name of the KUMA Core server that is used in your network. Must be different from the FQDN.
   • If necessary, use the Secret drop-down list to select a secret resource of the credentials type that contains the account credentials for connecting to the SMTP server.

     Add secret

     1. If you previously created a secret, select it from the Secret drop-down list.

        If no secret was previously added, the drop-down list shows No data.

     2. If you want to add a new secret, click the button on the right of the Secret list.

        The Secret window opens.

     3. In the Name field, enter the name that will be used to display the secret in the list of available secrets.
     4. In the User and Password fields, enter the credentials of the user account that the Agent will use to connect to the connector.
     5. If necessary, add any other information about the secret in the Description field.
     6. Click the Save button.

     The secret will be added and displayed in the Secret list.

   • Select the necessary frequency of notifications in the Monitoring notifications interval drop-down list.
   • Turn on the Disable monitoring notifications toggle button if you do not want to receive notifications about the state of event sources. The toggle switch is turned off by default.
3. Click Save.

The SMTP server connection is now configured, and users can receive email messages from KUMA.

Opening Online Help for KUMA

Online Help is available on the Kaspersky web resource.

Online Help provides information regarding the following tasks:

• Preparing to install and installing KUMA.
• Configuring and using KUMA.

To open Online Help for KUMA,

log in to the KUMA web interface, click the name of your user account in the lower-left corner of the window, then click the Help button in the opened menu.

KUMA logs

Some KUMA services and resources can log information related to their functioning. This feature is enabled by using the Debug drop-down list or check box in the settings of the service or the resource.

The logs are stored on the machine where the required service or the service using the required resource is installed:

• Logs residing on Linux machines can be viewed using the journalctl command in the Linux console.

  Examples:

  • journalctl -u kuma-collector * kuma-correlator * -f will return the latest logs from the collectors and the correlators installed on the server where the command was executed.
  • journalctl -u kuma-collector-<service ID> will return the latest logs of the specific collector installed on the server where the command was executed.
• Logs on Windows machines can be viewed in the file located at the path %PROGRAMDATA%\Kaspersky Lab\KUMA\<Agent ID>\agent.log. The activity of Agents on Windows machines is always logged if they are assigned the logon as a service permission. Data is specified in more detail when the Debug check box is selected.

Services where logging is available:

• Correlators
• Collectors
• Agents

Resources where logging is available:

• Connectors
• Enrichment rules
• Destinations

The logs on Windows machines are updated within a month. After a month expires, the log is archived, and events begin to be recorded in a new log. A maximum of three archived logs are stored on the server at a time. When a new log archive appears, if there are more than three archives, the oldest one is deleted.

KUMA backup

KUMA allows you to back up the KUMA Core database and certificates. Backups may be created using the executable file /opt/kaspersky/kuma/kuma.

Data may only be restored from a backup if it is restored to the KUMA of the same version as the backup one.

To perform a backup:

1. Log in to the OS of the server where the KUMA Core is installed.
2. Execute the following command:

   sudo /opt/kaspersky/kuma/kuma tools backup --dst <path to folder for backup copy> --certificates

   The flag --certificates is optional and is used to back up certificates.

The backup copy has been created.

To restore data from a backup:

1. Log in to the OS of the server where the KUMA Core is installed.
2. On the KUMA Core server, run the following command:

   sudo systemctl stop kuma-core

3. Execute the following command:

   sudo /opt/kaspersky/kuma/kuma tools restore --src <path to folder containing backup copy> --certificates

   The --certificates flag is optional and is used to restore certificates.

4. Start KUMA by running the following command:

   sudo systemctl start kuma-core

5. Rebuild the services using the recovered service resource sets.

Data is restored from the backup.

What to do if KUMA malfunctions after restoring data from a backup copy

Backup of collectors is not required unless the collectors have an SQL connection. When restoring such collectors, you should revert to the original initial value of the ID.

KUMA notifications

Standard notifications

KUMA can be configured to send email notifications using an SMTP server. To do so, configure a connection to an SMTP server and select the Receive email notifications check box for users who should receive notifications.

KUMA automatically notifies users about the following events:

• A report was created (the users listed in the report template receive a notification).
• An alert was created (all users receive a notification).
• An alert was assigned to a user (the user to whom the alert was assigned receives a notification).
• A task was performed (the users who created the task receive a notification).

Custom notifications

Instead of the standard KUMA notifications about the alert generation, you can send notifications based on custom templates. To configure custom notifications instead of standard notifications, take the following steps:

• Create an email template resource.
• Create a notification rule that specifies the correlation rules and email addresses.

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.