Managing KUMA

This section describes KUMA general settings.

Viewing KUMA metrics

To monitor the performance of its components, the event stream, and the correlation context, KUMA collects and stores a large number of parameters. The VictoriaMetrics time series database is used to collect, store and analyze the parameters. The collected metrics are visualized using Grafana. Dashboards that visualize key performance parameters of various KUMA components can be found in the KUMA → Metrics section.
The KUMA Core service configures VictoriaMetrics and Grafana automatically, no user action is required.

The collected metrics are visualized using the Grafana solution. The RPM package of the 'kuma-core' service generates the Grafana configuration and creates a separate dashboard for visualizing the metrics of each service. Graphs in the Metrics section appear with a delay of approximately 1.5 minutes.

For full information about the metrics, you can refer to the Metrics section of the KUMA Console. Selecting this section opens the Grafana portal that is deployed as part of Core installation and is updated automatically. If the Metrics section shows core: <port number>, this means that KUMA is deployed in a high availability configuration and the metrics were received from the host on which the Core was installed. In other configurations, the name of the host from which KUMA receives metrics is displayed.

Collector metrics

Correlator metrics

Storage metrics

Core metrics

KUMA agent metrics

Event routers metrics

General metrics common for all services

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.

By default, the Display only my own filter is applied in the Task manager section. To see tasks, clear the check box from the Display only my own filter.

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 Open Single Management Platform servers.
  • Accounts import—imports user data from Active Directory.
  • KICS/KATA assets import—imports asset data from KICS/KATA.
  • Repository update—updates the KUMA repository to receive the resource packages from the source specified in settings.
• Created by—the user who created the task. If the task was created automatically, the column will show Scheduled task.
• Created—task creation time.
• Updated—time when the task was last updated.
• Tenant—the name of the tenant in which the task was started.

The task 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.

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 Console, 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 Console, 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.

In this section, the Display only my own filter is applied by default in the Created by column of the task table. To view all tasks, disable this filter.

Restarting a task

To restart a task:

1. In the KUMA Console, 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.

Proxies

Proxy servers are used to store proxy server configuration settings, for example, in destinations. The http type is supported. Available proxy server settings are listed in the table below.

Available proxy server settings

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 Console under Settings → Other → SMTP server settings.

To configure SMTP server connection:

1. Open the KUMA Console and select Settings → Other.
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 65,535.
   • 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 of the credentials type that contains the account credentials for connecting to the SMTP server.

     Add secret

     To create a secret:

     1. In the Name field, enter the name of the secret.
     2. In the User and Password fields, enter the credentials of the user account that the Agent will use to connect to the connector.
     3. If necessary, enter a description of the secret in the Description field.
     4. Click the Create button.

     The secret is added and displayed in the Secret drop-down list.

   • Select the necessary frequency of notifications in the Monitoring notifications interval drop-down list.

     Notifications from the source about a monitoring policy triggering are repeated after the selected period until the status of the source becomes green again.

     If the Notify once setting is selected, you receive a notification about monitoring policy activation only once.

   • 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.

Working with Open Single Management Platform tasks

You can connect Open Single Management Platform assets to KUMA and download database and application module updates to these assets, or run an anti-virus scan on them by using Open Single Management Platform tasks. Tasks are started in the KUMA Console.

To run Open Single Management Platform tasks on assets connected to KUMA, it is recommended to use the following script:

1. Creating a user account in the Open Single Management Platform Administration Console

   The credentials of this account are used when creating a secret to establish a connection with Open Single Management Platform, and can be used to create a task.

   For more details about creating a user account and assigning permissions to a user, please refer to the Open Single Management Platform Help Guide.

2. Creating KUMA tasks in Open Single Management Platform
3. Configuring KUMA integration with Open Single Management Platform
4. Importing asset information from Open Single Management Platform into KUMA
5. Assigning a category to the imported assets

   After import, the assets are automatically placed in the Uncategorized devices group. You can assign one of the existing categories to the imported assets, or create a category and assign it to the assets.

6. Running tasks on assets

   You can manually start tasks in the asset information or configure tasks to start automatically.

Creating KUMA tasks in Open Single Management Platform

You can run the anti-virus database and application module update task, and the virus scan task on Open Single Management Platform assets connected to KUMA. The assets must have Kaspersky Endpoint Security for Windows or Linux installed. The tasks are created in OSMP Console.

For details about creating the Update and Virus scan tasks on the assets with Kaspersky Endpoint Security for Windows, refer to the Kaspersky Endpoint Security for Windows Help.

For more details about creating the Update and Virus scan tasks on the assets with Kaspersky Endpoint Security for Linux, refer to the Kaspersky Endpoint Security for Linux Help.

Task names must begin with "kuma" (not case-sensitive and without quotations). For example, KUMA antivirus check. Otherwise, the task is not displayed in the list of available tasks in the KUMA Console.

Starting Open Single Management Platform tasks manually

You can manually run the anti-virus database, application module update task, and the anti-virus scan task on Open Single Management Platform assets connected to KUMA. The assets must have Kaspersky Endpoint Security for Windows or Linux installed.

First, you need to configure the integration of Open Single Management Platform with KUMA and create tasks in Open Single Management Platform.

To manually start a Open Single Management Platform task:

1. In the Assets section of the KUMA Console, select the asset that was imported from Open Single Management Platform.

   The Asset details window opens.

2. Click the KSC response button.

   This button is displayed if the connection to the Open Single Management Platform that owns the selected asset is enabled.

3. In the opened Select task window, select the check boxes next to the tasks that you want to start, and click the Start button.

Open Single Management Platform starts the selected tasks.

Some types of tasks are available only for certain assets.

You can obtain vulnerability and software information only for assets running a Windows operating system.

Starting Open Single Management Platform tasks automatically

You can configure the automatic start of the anti-virus database and application module update task and the virus scan task for Open Single Management Platform assets connected to KUMA. The assets must have Kaspersky Endpoint Security for Windows or Linux installed.

First, you need to configure the integration of Open Single Management Platform with KUMA and create tasks in Open Single Management Platform.

Configuring automatic start of Open Single Management Platform tasks includes the following steps:

Step 1. Adding a correlation rule

To add a correlation rule:

1. In the KUMA Console, select the Resources section.
2. Select Correlation rules and click the Add correlation rule button.
3. On the General tab, specify the following settings:
   1. In the Name field, define the rule name.
   2. In the Tenant drop-down list, select the tenant that owns the resource.
   3. In the Type drop-down list, select simple.
   4. In the Propagated fields field, add the following fields: DestinationAssetID.
   5. If required, define the values for the following fields:
      • In the Rate limit field, define the maximum number of times per second that the rule will be triggered.
      • In the Severity field, define the severity of alerts and correlation events that will be created as a result of the rule being triggered.
      • In the Description field, provide any additional information.
4. On the Selectors → Settings tab:
   1. In the Filter drop-down list, select Create new.
   2. In the Conditions field, click the Add group button.
   3. In the operator field for the group you added, select AND.
   4. Add a condition for filtering by the DeviceProduct field value:
      1. In the Conditions field, click the Add condition button.
      2. In the condition field, select If.
      3. In the Left operand field, select event field.
      4. In the 'Event field' field, select DeviceProduct.
      5. In the Operator field, select =.
      6. In the Right operand field, select constant.
      7. In the value field, enter KSC.
   5. Add a condition for filtering by the Name field value:
      1. In the Conditions field, click the Add condition button.
      2. In the condition field, select If.
      3. In the Left operand field, select event field.
      4. In the event field, select Name.
      5. In the Operator field, select =.
      6. In the Right operand field, select constant.
      7. In the value field, enter the name of the event. When this event is detected, the task is started automatically.

         For example, if you want the Virus scan task to start when Open Single Management Platform registers the Malicious object detected event, specify this name in the Value field.

         You can view the event name in the Name field of the event details.

5. On the Actions tab, specify the following settings:
   1. In the Actions section, open the On every event drop-down list.
   2. Select the Output check box.

      You do not need to fill in other fields.

6. Click the Save button.

The correlation rule will be created.

Step 2. Creating a correlator

You need to launch the correlator installation wizard. At step 3 of the wizard, you are required to select the correlation rule that you added by following this guide.

The DeviceHostName field must display the domain name (FQDN) of the asset. If it is not displayed, create a DNS record for this asset and create a DNS enrichment rule at Step 4 of the wizard.

Step 3. Adding a filter

To add a filter:

1. In the KUMA Console, select the Resources section.
2. Select Filters and click the Add filter button.
3. In the Name field, specify the filter name.
4. In the Tenant drop-down list, select the tenant that owns the resource.
5. In the Conditions field, click the Add group button.
6. In the operator field for the group you added, select AND.
7. Add a condition for filtering by the DeviceProduct field value:
   1. In the Conditions field, click the Add condition button.
   2. In the condition field, select If.
   3. In the Left operand field, select event field.
   4. In the 'Event field' field, select Type.
   5. In the Operator field, select =.
   6. In the Right operand field, select constant.
   7. In the Value field, enter 3.
8. Add a condition for filtering by the Name field value:
   1. In the Conditions field, click the Add condition button.
   2. In the condition field, select If.
   3. In the Left operand field, select event field.
   4. In the event field, select Name.
   5. In the Operator field, select =.
   6. In the Right operand field, select constant.
   7. In the Value field, enter the name of the correlation rule created at Step 1.

Step 4. Adding a response rule

To add a response rule:

1. In the KUMA Console, select the Resources section.
2. Select Response rules and click the Add response rule button.
3. In the Name field, define the rule name.
4. In the Tenant drop-down list, select the tenant that owns the resource.
5. In the Type drop-down list, select Response via KSC.
6. In the Open Single Management Platform task drop-down list, select the Open Single Management Platform task you want to start.
7. In the Event field drop-down list, select the DestinationAssetID.
8. In the Workers field, specify the number of processes that the service can run simultaneously.

   By default, the number of work processes is the same as the number of virtual processors on the server where the correlator service is installed.

• In the Description field, you can add up to 4,000 Unicode characters.
• In the Filter drop-down list, select the filter added at Step 3 of this instruction.

To send requests to Open Single Management Platform, you must ensure that Open Single Management Platform is available over the UDP protocol.

If a response rule is owned by the shared tenant, the displayed Open Single Management Platform tasks that are available for selection are from the Open Single Management Platform server that the main tenant is connected to.

If a response rule has a selected task that is absent from the Open Single Management Platform server that the tenant is connected to, the task is not performed for assets of this tenant. This situation could arise when two tenants are using a common correlator, for example.

Step 5. Adding a response rule to the correlator

To add a response rule to the correlator:

1. In the KUMA Console, select the Resources section.
2. Select Correlators.
3. In the list of correlators, select the correlator added at Step 2 of this instruction.
4. In the steps tree, select Response rules.
5. Click Add.
6. In the Response rule drop-down list, select the rule added at step 4 of these instructions.
7. In the steps tree, select Setup validation.
8. Click the Save and restart services button.
9. Click the Save button.

The response rule will be added to the correlator.

The automatic start will be configured for the anti-virus database and application module update task and the virus scan task on Open Single Management Platform assets connected to KUMA. The tasks are started when a threat is detected on the assets and KUMA receives the corresponding events.

Checking the status of Open Single Management Platform tasks

In the Kaspersky Unified Monitoring and Analysis Platform web interface, you can check whether a Open Single Management Platform task was started or whether a search for events owned by the collector listening for Open Single Management Platform events was completed.

To check the status of Open Single Management Platform tasks:

1. In Kaspersky Unified Monitoring and Analysis Platform, select the Resources → Active services section.
2. Select the collector that is configured to receive events from the Open Single Management Platform server and click the Go to Events button.

This opens a new browser tab with the Events section of Kaspersky Unified Monitoring and Analysis Platform. The table displays events from the Open Single Management Platform server. The status of the tasks can be seen in the Name column.

Open Single Management Platform event fields:

• Name—status or type of the task.
• Message—message about the task or event.
• FlexString<number>Label—name of the attribute received from Open Single Management Platform. For example, FlexString1Label=TaskName.
• FlexString<number>—value of the FlexString<number>Label attribute. For example, FlexString1=Download updates.
• DeviceCustomNumber<number>Label—name of the attribute related to the task state. For example, DeviceCustomNumber1Label=TaskOldState.
• DeviceCustomNumber<number>—value related to the task state. For example, DeviceCustomNumber1=1 means the task is executing.
• DeviceCustomString<number>Label—name of the attribute related to the detected vulnerability: for example, a virus name, affected application.
• DeviceCustomString<number>—value related to the detected vulnerability. For example, the attribute-value pairs DeviceCustomString1Label=VirusName and DeviceCustomString1=EICAR-Test-File mean that the EICAR test virus was detected.

KUMA logs

KUMA provides the following types of logs:

• Installer logs
• Component logs

You can also generate a report with diagnostic information about your device using the collect.sh utility. For detailed information on using the utility, please refer to the Knowledge Base.

Installer logs

KUMA automatically creates files containing logs of installation, reconfiguration, or removal.

The logs are stored in the ./log/ subdirectory in the installer directory. The name of the log file reflects the date and time when the corresponding script was started.

Names are generated in the following formats:

• Installation log: install-YYYYMMDD-HHMMSS.log. For example: install-20231031-102409.log
• Removal logs: uninstall-YYYYMMDD-HHMMSS.log. For example: uninstall-20231031-134011.log
• Reconfiguration logs: expand-YYYYMMDD-HHMMSS.log. For example: expand-20231031-105805.log

KUMA creates a new log file each time the installation, reconfiguration, or removal script is started. Log rotation or automatic deletion is not performed.

The log incorporates the lines of the inventory file used when the corresponding command was invoked, and the ansible log. For each task, the following information is listed in this order: task start time (Tuesday, October 31, 2023 10:29:14 +0300), run time of the previous task (0:00:02.611), and the total time passed since the installation, reconfiguration, or removal was initiated (0:04:56.906).

Example:

TASK [Add columns to the replicated table] ***************************************

Tuesday, October 31, 2023 10:29:14 +0300 (0:00:02.611) 0:04:56.906 *******

Component logs

By default, only errors are logged for all KUMA components. To receive detailed data in logs, configure Debug mode in the component settings.

The Core logs are stored in the /opt/kaspersky/kuma/core/00000000-0000-0000-0000-000000000000/log/core directory and are archived when they reach the size of 5 GB or the age of 7 days, whichever occurs first. These conditions are checked once daily. Archives are kept in the log folder for 7 days, after 7 days the archive is deleted. A maximum of four archived logs are stored on the server at the same time. Whenever a new log archive is created, if the total number of archives becomes greater than four, the oldest log archive is deleted. If the logs fill up quickly, you must have enough disk space to create a copy of the log file and archive it as part of log rotation.

The component logs are appended until the file reaches 5 GB. When the log reaches 5 GB, it is archived and new events are written to a new log. Archives are kept in the log folder for 7 days, after 7 days the archive is deleted. A maximum of four archived logs are stored on the server at the same time. Whenever a new log archive is created, if the total number of archives becomes greater than four, the oldest log archive is deleted.

Debug mode is available for the following components:

Viewing Core logs in Kubernetes

When Core log files reach 100 MB, they are archived and a new log is written. No more than five files are stored at a time. If there are more than five files when a new log appears, the oldest file is deleted.

On worker nodes, you can view the logs of containers and pods residing on these nodes in the file system of the node.
For example:
/var/log/pods/kuma_core-deployment-<UID>/core/*.log
/var/log/pods/kuma_core-deployment-<UID>/mongodb/*.log

To view the logs of all containers in the Core pod:

k0s kubectl logs -l app=core --all-containers -n kuma

To view the log of a specific container:

k0s kubectl logs -l app = core -c <container_name> -n kuma

To enable real-time log viewing, add the -f switch:

k0s kubectl logs -f -l app=core --all-containers -n kuma

To view the logs of the previous pod that was overwritten by a new one (for example, when recovering from a critical error or after redeployment), add the --previous switch:

k0s kubectl logs -l app=core -c core -n kuma --previous

To access the logs from other hosts that are not included in the cluster, you need the k0s-kubeconfig.yml file containing the access credentials created during KUMA installation, and the locally installed kubectl cluster management utility.
The cluster controller or traffic balancer specified in the server parameter of the k0s-kubeconfig.yml file must be accessible over the network.

The file path must be exported to a variable: 
export KUBECONFIG=/<file path>/k0s-kubeconfig.yml

You can use kubeclt to view the logs. For example:

kubectl logs -l app=core -c mongodb -n kuma

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. Only a user with the General administrator role can receive email notifications.

If the Receive email notifications check box is selected for a user with the General administrator role, after enabling the setting, an email notification is sent to the user every 6 hours in accordance with the following rule:

• If at least one server has a non-empty Warning field at the time scheduled for sending the message, the message is sent.
• One message is sent for all services with the yellow status. If no services have the yellow status, no message is sent.

The 6-hour interval is respected unless the KUMA Core is restarted. After each restart of the Core, the 6-hour interval is reset.

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).
• New resource packages are available. They can be obtained by updating the KUMA repository (the users whose email address is specified in the task settings are notified).
• The daily average EPS has exceeded the limit set by the license.
• The hourly average EPS has exceeded the limit set by the SMB license.

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.
• 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.