Managing KUMA

This section describes managing users in KUMA, user roles and metrics.

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 user name 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.

Managing users

It is possible for multiple users to have access to KUMA. Users are assigned user roles, which affect the tasks the users can perform. The same user may have different roles with different tenants.

You can create or edit user accounts under Settings → Users in the KUMA web interface. Users are also created automatically in the program if KUMA integration with Active Directory is enabled and the user is logging in to the KUMA web interface for the first time using their domain account.

The table of user accounts is displayed in the Users window of the KUMA web interface. You can use the Search field to look for users. You can sort the table based on the User information column by clicking the column header and selecting Ascending or Descending.

User accounts can be created, edited, or disabled. When editing user accounts (your own or the accounts of others), you can generate an API token for them.

By default, disabled user accounts are not displayed in the users table. However, they can be viewed by clicking the User information column and selecting the Disabled users check box.

To disable a user:

In the KUMA web interface, under Settings → Users, select the check box next to the relevant user and click Disable user.

Creating a user

To create a user account:

1. In the KUMA web interface, open Settings → Users.

   In the right part of the Settings section the Users table will be displayed.

2. Click the Add user button and set the parameters as described below:
   • Name (required)—enter the user name. Must contain from 1 to 128 Unicode characters.
   • Login(required) – enter a unique user name for the user account. Must contain from 3 to 64 characters (only a–z, A–Z, 0–9, . \ - _).
   • Email (required)—enter the unique email address of the user. Must be a valid email address.
   • New password (required)—enter the password to the user account. Password requirements:
     • 8 to 128 characters long.
     • At least one lowercase character.
     • At least one uppercase character.
     • At lease one numeral.
     • At least one of the following special characters: !, @, #, %, ^, &, *.
   • Confirm password (required)—enter the password again for confirmation.
   • Disabled—select this check box if you want to disable a user account. By default, this check box is cleared.
   • In the Tenants for roles settings block, use the Add field buttons to specify which roles the user will perform on which tenants. Although a user can have different roles on different tenants, the user can have only one role on the same tenant.
   • Select the General administrator check box if you want to assign the general administrator role to the user. Users with the general administrator role can change the settings of other user accounts. By default, this check box is cleared.
3. Click Save.

The user account will be created and displayed in the Users table.

Editing user

To edit a user:

1. In the KUMA web interface, open Settings → Users.

   In the right part of the Settings section the Users table will be displayed.

2. Select the relevant user and change the necessary settings in the user details area that opens on the right.
   • Name (required)—edit the user name. Must contain from 1 to 128 Unicode characters.
   • Login(required) – enter a unique user name for the user account. Must contain from 3 to 64 characters (only a–z, A–Z, 0–9, . \ - _).
   • Email (required)—enter the unique email address of the user. Must be a valid email address.
   • Disabled—select this check box if you want to disable a user account. By default, this check box is cleared.
   • In the Tenants for roles settings block, use the Add field buttons to specify which roles the user will perform on which tenants. Although a user can have different roles on different tenants, the user can have only one role on the same tenant.
   • Select the General administrator check box if you want to assign the general administrator role to the user. Users with the general administrator role can change the settings of other user accounts. By default, this check box is cleared.
3. If you need to change the password, click the Change password button and fill in the fields described below in the opened window. When finished, click OK.
   • Current password (required)—enter the current password of your user account.
   • New password (required)—enter the password to the user account. Password requirements:
     • 8 to 128 characters long.
     • At least one lowercase character.
     • At least one uppercase character.
     • At lease one numeral.
     • At least one of the following special characters: !, @, #, %, ^, &, *.
   • Confirm password (required)—enter the password again for confirmation.
4. If necessary, use the Generate token button to generate an API token. Clicking this button displays a window containing the automatically created token.

   When the window is closed, the token is no longer displayed. If you did not copy the token before closing the window, you will have to generate a new token.

5. Click Save.

The user account will be changed.

Editing your user account

To edit your user account:

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

   The User window with your user account parameters opens.

2. Make the necessary changes to the parameters:
   • Name (required)—enter the user name. Must contain from 1 to 128 Unicode characters.
   • Login(required) – enter a unique user name for the user account. Must contain from 3 to 64 characters (only a–z, A–Z, 0–9, . \ - _).

     Email (required)—enter the unique email address of the user. Must be a valid email address.

   • Receive notification by SMTP—select this check box if you want to receive SMTP notifications from KUMA.
3. If you need to change the password, click the Change password button and fill in the fields described below in the opened window. When finished, click OK.
   • Current password (required)—enter the current password of your user account.
   • New password (required)—enter the password to the user account. Password requirements:
     • 8 to 128 characters long.
     • At least one lowercase character.
     • At least one uppercase character.
     • At lease one numeral.
     • At least one of the following special characters: !, @, #, %, ^, &, *.
   • Confirm password (required)—enter the password again for confirmation.
4. If necessary, use the Generate token button to generate an API token. Clicking this button displays a window containing the automatically created token.

   When the window is closed, the token is no longer displayed. If you did not copy the token before closing the window, you will have to generate a new token.

5. Click Save.

Your user account is changed.

User roles

KUMA users may have the following roles:

• General administrator—this role is designed for users who are responsible for the core functionality of KUMA systems. For example, they install system components, perform maintenance, work with services, create backups, and add users to the system. These users have full access to KUMA.
• Administrator—this role is for users responsible for the core functionality of KUMA systems owned by specific tenants.
• Analyst—this role is for users responsible for configuring the KUMA system to receive and process events of a specific tenant. They also create and tweak correlation rules.
• Operator—this role is for users dealing with immediate security threats of a specific tenant.

  User roles rights

  Web interface section and actions	General administrator	Administrator	Analyst	Operator	Comment
  Reports
  View and edit templates and reports	yes	yes	yes	no	Analysts can: View and edit templates and reports that they created themselves. View reports sent to them by email. View predefined templates.
  Generate reports	yes	yes	yes	no	Analysts can generate reports that they created themselves or that are predefined (from a template or report). Analysts cannot generate reports sent to them by email.
  Export generated reports	yes	yes	yes	no	Analysts can export the following: Reports that they created themselves. Predefined reports. Reports received by email.
  Delete templates and generated reports	yes	yes	yes	no	Analysts can delete the templates and reports that they generated themselves. Analysts should not delete: Predefined templates. Reports received by email. Only the general administrator can delete predefined templates and reports.
  Edit the settings for generating reports	yes	yes	yes	no	Analysts may change the settings for generating reports that they created themselves or that are predefined.
  Duplicate report template	yes	yes	yes	no	Analysts can duplicate predefined report templates and report templates that they created themselves.
  Dashboard
  View data on the dashboard and change layouts	yes	yes	yes	yes
  Add layouts	yes	yes	yes	no	This includes adding widgets to a layout.
  Edit and rename layouts	yes	yes	yes	no	This includes adding, editing, and deleting widgets. Analysts may change/rename predefined layouts and layouts that were created using their account.
  Delete layouts	yes	yes	yes	no	Tenant administrators may delete layouts in the tenants available to them. Analysts may delete layouts that were created using their account. Only the general administrator can delete predefined layouts.
  Resources → Services and Resources → Services → Active services
  View the list of active services	yes	yes	yes	no	Only the general administrator can view and delete storage spaces. Access rights do not depend on the tenants selected in the menu.
  View the contents of the active list	yes	yes	yes	no
  Import/export/clear the contents of the active list	yes	yes	yes	no
  Create a set of resources for services	yes	yes	yes	no	Analysts cannot create storages.
  Create a service under Resources - Services - Active services	yes	yes	no	no
  Delete services	yes	yes	no	no
  Restart services	yes	yes	no	no
  Update the settings of services	yes	yes	yes	no
  Reset certificates	yes	yes	no	no	A user with the administrator role can reset the certificates of services only in the tenants that are accessible to the user.
  Resources → Resources
  View the list of resources	yes	yes	yes	no*	Analysts cannot view the list of secret resources, but these resources are available to them when they create services.
  Add resources	yes	yes	yes	no	Analysts cannot add secret resources.
  Edit resources	yes	yes	yes	no	Analysts cannot change secret resources.
  Create/edit/delete resources in a shared tenant	yes	no	no	no
  Delete resources	yes	yes	yes	no	Analysts cannot delete secret resources.
  Import resources	yes	yes	yes	no	Only the general administrator can import resources to a shared tenant.
  Export resources	yes	yes	yes	no	This includes resources from a shared tenant.
  View/edit collector or correlator drafts	yes	yes	yes	no	The user may only access their own drafts, regardless of the selected tenant. The list of drafts is generated based on those that belong to the user.
  Sources status → List of event sources
  View sources of events	yes	yes	yes	yes
  Change sources of events	yes	yes	yes	no	Edit source name, assign monitoring policy, disable monitoring policy.
  Delete sources of events	yes	yes	yes	no
  Sources status → Monitoring policies
  View monitoring policies	yes	yes	yes	yes
  Create monitoring policies	yes	yes	yes	no
  Edit monitoring policies	yes	yes	yes	no	Only the general administrator can edit the predefined monitoring policies.
  Delete monitoring policies	yes	yes	yes	no	Predefined policies cannot be removed.
  Assets
  View assets and asset categories	yes	yes	yes	yes	This includes shared tenant categories.
  Add/edit/delete asset categories	yes	yes	yes	no	Within the tenant available to the user.
  Add asset categories in a shared tenant	yes	no	no	no	This includes editing and deleting shared tenant categories.
  Attach assets to an asset category of the shared tenant	yes	yes	yes	no
  Add assets	yes	yes	yes	no
  Edit assets	yes	yes	yes	no
  Delete assets	yes	yes	yes	no
  Import assets from Kaspersky Security Center	yes	yes	yes	no
  Launch tasks in the asset within Kaspersky Security Center	yes	yes	yes	no
  Alerts
  View the list of alerts	yes	yes	yes	yes
  Change the priority of alerts	yes	yes	yes	yes
  Open the details of alerts	yes	yes	yes	yes
  Assign responsible users	yes	yes	yes	yes
  Close alerts	yes	yes	yes	yes
  Add comments to alerts	yes	yes	yes	yes
  Attach an event to alerts	yes	yes	yes	yes
  Detach an event from alerts	yes	yes	yes	yes
  Edit and delete someone else's filters	yes	yes	no	no
  Incidents
  View the list of incidents	yes	yes	yes	yes
  Create blank incidents	yes	yes	yes	yes
  Manually create incidents from alerts	yes	yes	yes	yes
  Change the priority of incidents	yes	yes	yes	yes
  Open the details of incidents	yes	yes	yes	yes	Incident details display data from only those tenants to which the user has access.
  Assign executors	yes	yes	yes	yes
  Close incidents	yes	yes	yes	yes
  Add comments to incidents	yes	yes	yes	yes
  Attach alerts to incidents	yes	yes	yes	yes
  Detach alerts from incidents	yes	yes	yes	yes
  Edit and delete someone else's filters	yes	yes	no	no
  Export incidents to RuCERT	yes	yes	yes	yes
  Events
  View the list of events	yes	yes	yes	yes
  Search events	yes	yes	yes	yes
  Open the details of events	yes	yes	yes	yes
  Open statistics	yes	yes	yes	yes
  Conduct a retroscan	yes	yes	yes	no
  Export events to a TSV file	yes	yes	yes	yes
  Edit and delete someone else's filters	yes	yes	no	no
  Start ktl enrichment	yes	yes	yes	no
  Settings → Users					This section is available only to the general administrator.
  View the list of users	yes	no	no	no
  Add a user	yes	no	no	no
  Edit a user	yes	no	no	no
  View the data of their own profile	yes	yes	yes	yes
  Edit the data of their own profile	yes	yes	yes	yes	The user role is not available for change.
  Settings → LDAP
  View the LDAP connection settings	yes	yes	no	no
  Edit the LDAP connection settings	yes	yes	no	no
  Settings → Tenants					This section is available only to the general administrator.
  View the list of tenants	yes	no	no	no
  Add tenants	yes	no	no	no
  Change tenants	yes	no	no	no
  Disable tenants	yes	no	no	no
  Settings → Active directory					This section is available only to the general administrator.
  View the Active Directory connection settings	yes	no	no	no
  Edit the Active Directory connection settings	yes	no	no	no
  Add filters based on roles for tenants	yes	no	no	no
  Settings → Notifications					This section is available only to the general administrator.
  View the SMTP connection settings	yes	no	no	no
  Edit the SMTP connection settings	yes	no	no	no
  Settings → License					This section is available only to the general administrator.
  View the list of added licenses	yes	no	no	no
  Add licenses	yes	no	no	no
  Delete licenses	yes	no	no	no
  Settings → KSC
  View the list of successfully integrated Kaspersky Security Center servers	yes	yes	no	no
  Add Kaspersky Security Center connections	yes	yes	no	no
  Delete Kaspersky Security Center connections	yes	yes	no	no
  Settings → CyberTrace					This section is available only to the general administrator.
  View the CyberTrace integration settings	yes	no	no	no
  Edit the CyberTrace integration settings	yes	no	no	no
  Settings → R-Vision					This section is available only to the general administrator.
  View R-Vision IRP integration settings	yes	no	no	no
  Change R-Vision IRP integration settings	yes	no	no	no
  Settings → KTL					This section is available only to the general administrator.
  View the Threat Lookup integration settings	yes	no	no	no
  Edit the Threat Lookup integration settings	yes	no	no	no
  Settings → Alerts
  View the parameters	yes	yes	yes	no
  Edit the parameters	yes	yes	yes	no
  Settings → Incidents → Automatic linking of alerts to incidents
  See the settings	yes	no	no	no
  Edit the settings	yes	no	no	no
  Settings → Incidents → Incident types
  View the categories reference	yes	yes	no	no
  View the categories charts	yes	yes	no	no
  Add categories	yes	yes	no	no	Available if the user has the administrator role in at least one tenant.
  Edit categories	yes	yes	no	no	Available if the user has the administrator role in at least one tenant.
  Delete categories	yes	yes	no	no	Available if the user has the administrator role in at least one tenant.
  Settings → RuCERT
  View the parameters	yes	no	no	no
  Edit the parameters	yes	no	no	no
  Metrics
  Open metrics	yes	no	no	no
  Task manager
  View a list of your own tasks	yes	yes	yes	yes	The section and tasks are not tied to a tenant. The tasks are available only to the user who created them.
  Finish your own tasks	yes	yes	yes	yes
  Restart your own tasks	yes	yes	yes	yes
  View a list of all tasks	yes	no	no	no
  Finish any task	yes	no	no	no
  Restart any task	yes	no	no	no
  CyberTrace					This section is not displayed in the web interface unless CyberTrace integration is configured under Settings → CyberTrace.
  Open the section	yes	no	no	no
  Access to the data of tenants
  Access to tenants	yes	yes	yes	yes	A user has access to the main tenant if its name is indicated in the settings blocks of the roles assigned to the user account. The access level depends on which role is indicated for the tenant. Permissions to access the main tenant do not include access to all tenants, but only provide access to the data of the main tenant.
  Main tenant	yes	yes	yes	yes	A shared tenant is used to store shared resources that must be available to all tenants. Although services cannot be owned by the shared tenant, these services may utilize resources that are owned by the shared tenant. These services are still owned by their respective tenants. Events, alerts and incidents cannot be shared. Permissions to access the shared tenant: Read/write—only the general administrator. Read—all other users, including users that have permissions to access the main tenant.
  Shared tenant	yes	yes	yes	yes	A user has access to the main tenant if its name is indicated in the settings blocks of the roles assigned to the user account. The access level depends on which role is indicated for the tenant. Permissions to access the main tenant do not grant access to other tenants.

* A user with the operator role sees resources in a shared tenant through the REST API .

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 as the root user.
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.

Viewing KUMA tasks

In the Task manager section you can see the tasks created by the current user. The user with the general administrator role can see the tasks of all users.

The Task manager window displays the list of created tasks with the following columns:

• State—the state of the task.
  • Green dot blinking—the task is active.
  • The icon—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. Available task kinds:
  • event-export—event export task.
  • ktl—task for requesting information from the Kaspersky Threat Intelligence Portal.
  • replay—task for replaying events.
• Created by—which user created the task. This column is only displayed for user with roles General administrator and Administrator.
• Time created—when the task was created.
• Time updated—when the task was updated.

You can cancel an active task by clicking the task type name and selecting Cancel in the drop-down list.

It is also possible to repeat the task by clicking the task type name and selecting Restart in the drop-down list.

Managing SMTP server connection

KUMA can be configured to send email notifications using SMTP server. Only one SMTP server can be added to process KUMA notifications. An SMTP server connection is managed in the Settings → Notifications section of the KUMA web interface.

To configure SMTP server connection:

1. In the Resources section of the KUMA web interface, open the Secrets tab.

   The list of available secrets will be displayed.

2. Click the Add secret button to create a new secret. This resource is used to store credentials of the SMTP server.

   The secret window is displayed.

3. Enter information about the secret:
   1. In the Name field, choose a name for the added secret.
   2. In the Type drop-down list, select credentials.
   3. In the User and Password fields, enter credentials for your SMTP server.
   4. If you want, enter a Description of the secret.
4. Click Save.

   The SMTP server credentials are now saved and can be used in other KUMA resources.

5. Open the KUMA web interface and select Settings → Notifications.
6. Make the necessary changes to the following parameters:
   • 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)—valid email address of the notification sender. For example, kuma@company.com.
7. In the Secret drop-down list select the Secret resource you created before.
8. Select the necessary frequency of notifications in the Monitoring notifications interval drop-down list.
9. 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.
10. 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:

Open the KUMA web interface, click the name of your user account in the bottom-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. For example, executing the command journalctl -u kuma-collector* kuma-correlator* -f will return latest logs from the collectors and the correlators installed on the machine 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

Backing up KUMA

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 as the root user.
2. Execute the following command:

   /opt/kaspersky/kuma/kuma tools backup --dst <path to the backup folder> --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 as the root user.
2. On the KUMA Core server, run the following command:

   sudo systemctl stop kuma-core

3. Execute the following command:

   /opt/kaspersky/kuma/kuma tools restore --src <path to the backup folder> --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

Collectors are not required to be backed up, except for SQL-connected collectors. When restoring such collectors, you should revert to the original initial value of the ID.