Kaspersky Unified Monitoring and Analysis Platform

Configuring integration in R-Vision SOAR

Managing alerts using R-Vision SOAR

Page top

[Topic 224436]

Configuring integration in KUMA

This section describes integration of KUMA with R-Vision SOAR from the KUMA side.

Integration in KUMA is configured in the web interface under Settings → IRP / SOAR.

To configure integration with R-Vision SOAR:

In the KUMA web interface, open Resources → Secrets.
The list of available secrets will be displayed.
Click the Add secret button to create a new secret. This resource is used to store token for R-Vision SOAR API requests.
The secret window is displayed.
Enter information about the secret:
1. In the Name field, enter a name for the added secret. The name must contain 1 to 128 Unicode characters.
2. In the Tenant drop-down list, select the tenant that will own the created resource.
3. In the Type drop-down list, select token.
4. In the Token field, enter your R-Vision SOAR API token.
  You can obtain the token in the R-Vision SOAR web interface under Settings → General → API.
5. If necessary, in the Description field, add up to 4,000 Unicode characters describing the secret.
Click Save.
The R-Vision SOAR API token is now saved and can be used in other KUMA resources.
In the KUMA web interface, go to Settings → IRP / SOAR.
The window containing R-Vision SOAR integration settings opens.
Make the necessary changes to the following parameters:
- Disabled—select this check box if you want to disable R-Vision SOAR integration with KUMA.
- In the Secret drop-down list, select the previously created secret.
  You can create a new secret by clicking the button with the plus sign. The created secret will be saved in the Resources → Secrets section.
- URL (required)—URL of the R-Vision SOAR server host.
- Field name where KUMA alert IDs must be placed (required)—name of the R-Vision SOAR field where the ID of the KUMA alert must be written.
- Field name where KUMA alert URLs must be placed (required)—name of the R-Vision SOAR field where the link for accessing the KUMA alert should be written.
- Category (required)—category of R-Vision SOAR incident that is created after KUMA alert is received.
- KUMA event fields that must be sent to IRP / SOAR (required)—drop-down list for selecting the KUMA event fields that should be sent to R-Vision SOAR.
- Severity group of settings (required)—used to map KUMA severity values to R-Vision SOAR severity values.
Click Save.

In KUMA integration with R-Vision SOAR is now configured. If integration is also configured in R-Vision SOAR, when alerts appear in KUMA, information about those alerts will be sent to R-Vision SOAR to create an incident. The Details on alert section in the KUMA web interface displays a link to R-Vision SOAR.

If you are working with multiple tenants and want to integrate with R-Vision SOAR, the names of tenants must match the abbreviated names of companies in R-Vision SOAR.

Page top

[Topic 224437]

Configuring integration in R-Vision SOAR

This section describes KUMA integration with R-Vision SOAR from the R-Vision SOAR side.

Integration in R-Vision SOAR is configured in the Settings section of the R-Vision SOAR web interface. For details on configuring R-Vision SOAR, please refer to the documentation on this application.

Configuring integration with KUMA consists of the following steps:

Configuring R-Vision SOAR user role
1. Assign the Incident manager system role to the R-Vision SOAR user utilized for integration. The role is assigned when a user is selected in the R-Vision SOAR web interface in the Settings → General → System users section. The role is added in the System Roles block of settings.
  R-Vision SOAR version 4.0 user with the Incident Manager role
  
  R-Vision SOAR version 5.0 user with the Incident Manager role
2. Make sure that the API token of the R-Vision SOAR user utilized for integration is indicated in the secret in the KUMA web interface. The token is displayed in the R-Vision SOAR web interface under Settings → General → API.
  API token in R-Vision SOAR version 4.0
  
  API token in R-Vision SOAR version 5.0
Configuring R-Vision SOAR incident fields and KUMA alert fields
1. Add the ALERT_ID and ALERT_URL incident fields.
2. Configure the category of R-Vision SOAR incidents created based on KUMA alerts. You can do this in the R-Vision SOAR web interface, in the Settings → Incident management → Incident categories section. Add a new incident category or edit an existing incident category by indicating the previously created Alert ID and Alert URL incident fields in the Category fields settings block. The Alert ID field can be hidden.
  Incident categories with data from KUMA alerts in R-Vision SOAR version 4.0
  
  Incident categories with data from KUMA alerts in R-Vision SOAR version 5.0
3. Block editing of previously created Alert ID and Alert URL incident fields. In the R-Vision SOAR web interface, under Settings → Incident management → Presentation, select the category of R-Vision SOAR incidents that will be created based on KUMA alerts and put a lock icon next to the Alert ID and Alert URL incident fields.
  The Alert URL field is not editable in R-Vision SOAR version 4.0
  
  The Alert URL field is not editable in R-Vision SOAR version 5.0
Creating R-Vision SOAR collector and connector
1. Create an R-Vision SOAR collector to interact with KUMA.
2. Create and configure an R-Vision SOAR connector to send API requests to close KUMA alerts.
Creating a rule to close a KUMA alert
Create a rule for sending KUMA alert closing request when R-Vision SOAR incident is closed.

Integration with KUMA is now configured in R-Vision SOAR. If integration is also configured in KUMA, when alerts appear in KUMA, information about those alerts is sent to R-Vision SOAR to create an incident. The Details on alert section in the KUMA web interface displays a link to R-Vision SOAR.

In this section

Adding the ALERT_ID and ALERT_URL incident fields

Creating a collector in R-Vision SOAR

Creating connector in R-Vision SOAR

Creating rule for closing KUMA alert when R-Vision SOAR incident is closed

Page top

[Topic 225573]

Adding the ALERT_ID and ALERT_URL incident fields

To add the ALERT_ID incident field in the R-Vision SOAR:

In the R-Vision SOAR web interface, under Settings → Incident management → Incident fields, select the No group group of fields.
Click the plus icon in the right part of the screen.
The right part of the screen will display the settings area for the incident field you are creating.
In the Title field, enter the name of the field (for example: Alert ID).
In the Type drop-down list, select Text field.
In the Parsing Tag field, enter ALERT_ID.

ALERT_ID field added to R-Vision SOAR incident.

ALERT_ID field in R-Vision SOAR version 4.0

rvision_3

ALERT_ID field in R-Vision SOAR version 5.0

rvision_3_v5

To add the ALERT_URL incident field in R-Vision SOAR:

In the R-Vision SOAR web interface, under Settings → Incident management → Incident fields, select the No group group of fields.
Click the plus icon in the right part of the screen.
The right part of the screen will display the settings area for the incident field you are creating.
In the Title field, enter the name of the field (for example: Alert URL).
In the Type drop-down list, select Text field.
In the Parsing Tag field, enter ALERT_URL.
Select the Display links and Display URL as links check boxes.

ALERT_URL field added to R-Vision SOAR incident.

ALERT_URL field in R-Vision SOAR version 4.0

rvision_5

ALERT_URL field in R-Vision SOAR version 5.0

rvision_5_v5

If necessary, you can likewise configure the display of other data from a KUMA alert in an R-Vision SOAR incident.

Page top

[Topic 225575]

Creating a collector in R-Vision SOAR

To create a collector in R-Vision SOAR:

In the R-Vision SOAR web interface, under Settings → Common → Collectors, click the plus icon.
Specify the collector name in the Name field (for example, Main collector).
In the Collector address field, enter the IP address or hostname where the R-Vision SOAR is installed (for example, 127.0.0.1).
In the Port field type 3001.
Click Add.
On the Organizations tab, select the organization for which you want to add integration with KUMA and select the Default collector and Response collector check boxes.

The R-Vision SOAR collector is created.

Page top

[Topic 225576]

Creating connector in R-Vision SOAR

To create connector in R-Vision SOAR:

In the R-Vision SOAR web interface, under Settings → Incident management → Connectors, click the plus icon.
In the Type drop-down list, select REST.
In the Name field, specify the connector name, such as KUMA.
In the URL field type API request to close an alert in the format <KUMA Core server FQDN>:<Port used for API requests (7223 by default)>/api/v1/alerts/close.
Example: https://kuma-example.com:7223/api/v1/alerts/close
In the Authorization type drop-down list, select Token.
In the Auth header field type Authorization.
In the Auth value field enter the token of KUMA user with general administrator role in the following format:
Bearer <KUMA General administrator token>
In the Collector drop-down list select previously created collector.
Click Save.

The connector has been created.

Connector in R-Vision SOAR version 4.0

rvision_7

Connector in R-Vision SOAR version 5.0

rvision_7_v5

When connector is created you must configure sending API queries for closing alerts in KUMA.

To configure API queries in R-Vision SOAR:

In the R-Vision SOAR web interface, under Settings → Incident management → Connectors, open for editing the newly created connector.
In the request type drop-down list, select POST.
In the Params field type API request to close an alert in the format <KUMA Core server FQDN>:<Port used for API requests (7223 by default)>/api/v1/alerts/close.
Example: https://kuma-example.com:7223/api/v1/alerts/close
On the HEADERS tab add the following keys and values:
- Key Content-Type; value: application/json.
- Key Authorization; value: Bearer <KUMA general administrator token>.
  The token of the KUMA general administrator can be obtained in the KUMA web interface under Settings → Users.
On the BODY → Raw tab type contents of the API request body:
{

"id":"{{tag.ALERT_ID}}",

"reason":"<Reason for closing the alert. Available values: "Incorrect Correlation Rule", "Incorrect Data", "Responded".> "

}
Click Save.

The connector is configured.

Connector in R-Vision SOAR version 4.0

API request header

rvision_7.2

API request body

rvision_7.3

Connector in R-Vision SOAR version 5.0

rvision_7-2_v5

rvision_7.3_v5

Page top

[Topic 225579]

Creating rule for closing KUMA alert when R-Vision SOAR incident is closed

To create a rule for sending an alert closing request to KUMA when an R-Vision SOAR incident is closed:

In the R-Vision SOAR web interface, under Settings → Incident management → Response playbooks, click the plus icon.
In the Name field, type the name of the rule, for example, Close alert.
In the Group drop-down list select All playbooks.
In the Autostart criteria settings block, click Add and enter the conditions for triggering the rule in the opened window:
1. In the Type drop-down list, select Field value.
2. In the Field drop-down list, select Incident status.
3. Select the Closed status.
4. Click Add.
Rule trigger conditions are added. The rule will trigger when an incident is closed.
In the Incident Response Actions settings block, click Add → Run connector. In the opened window, select the connector that should be run when the rule is triggered:
1. In the Connector drop-down list select previously created connector.
2. Click Add.
Connector added to the rule.
Click Add.

A rule is created for sending a KUMA alert closing request when an R-Vision SOAR incident is closed.

R-Vision IRP version 4.0 playbook rule

rvision_9

R-Vision SOAR version 5.0 playbook rule

rvision_9_v5

Page top

[Topic 224487]

Managing alerts using R-Vision SOAR

After integration of KUMA and R-Vision SOAR is configured, data on KUMA alerts starts coming into R-Vision SOAR. Changes of alert parameters in KUMA are reflected in R-Vision SOAR. Any changes in the statuses of alerts in KUMA or R-Vision SOAR (except closing an alert) are also reflected in the other system.

Alert management scenarios when KUMA and R-Vision SOAR are integrated:

Send cyberthreat data from KUMA to R-Vision SOAR
Data on detected alerts is automatically sent from KUMA to R-Vision SOAR. An incident is also created in R-Vision SOAR.

The following information about the KUMA alert is sent to R-Vision SOAR:
- ID.
- Name.
- Status.
- Date of the first event related to the alert.
- Date of the last detection related to the alert.
- User account name or email address of the security officer assigned to process the alert.
- Alert severity.
- Category of the R-Vision SOAR incident corresponding to the KUMA alert.
- Hierarchical list of events related to the alert.
- List of alert-related assets (internal and external).
- List of users related to the alert.
- Alert change log.
- Link to the alert in KUMA.
Investigate cyberthreats in KUMA
Initial processing of an alert is performed in KUMA. The security officer can update and change any parameters of an alert except its ID and name. Any changes are reflected in the R-Vision SOAR incident card.

If a cyberthreat turns out to be a false positive and its alert is closed in KUMA, its corresponding incident in R-Vision SOAR is also automatically closed.
Close incident in R-Vision SOAR
After all necessary work is completed on an incident and the course of the investigation is recorded in R-Vision SOAR, the incident is closed. The corresponding KUMA alert is also automatically closed.
Open a previously closed incident
If active monitoring detects that an incident was not completely resolved or if additional information comes up, this incident is re-opened in R-Vision SOAR. However, the alert remains closed in KUMA.

The security officer can use a link to navigate from an R-Vision SOAR incident to the corresponding alert in KUMA and make the necessary changes to any of its parameters except the ID, name, and status of the alert. Any changes are reflected in the R-Vision SOAR incident card.

Further analysis is performed in R-Vision SOAR. When the investigation is complete and the incident is closed again in R-Vision SOAR, the status of the corresponding alert in KUMA remains closed.
Request additional data from the source system as part of the response playbook or manually
If additional information is required from KUMA when analyzing incidents in R-Vision SOAR, in R-Vision SOAR, you can create a search request to KUMA (for example, you can request telemetry data, reputation, host information). This request is sent via KUMA REST API and the response is recorded in the R-Vision SOAR incident card for further analysis and reporting.

This same sequence of actions is performed during automatic processing if it is not possible to immediately save all information on an incident during an import.

Page top

[Topic 217926]

Integration with Active Directory, Active Directory Federation Services and FreeIPA

You can integrate KUMA with the Active Directory, Active Directory Federation Services, and FreeIPA services used in your organization.

You can configure a connection to the Active Directory catalog service over the LDAP protocol. This lets you use information from Active Directory in correlation rules for enrichment of events and alerts, and for analytics.

If you configure a connection to a domain controller server, you can use domain authorization. In this case, you can bind the domain groups of users to the KUMA role filters. The users belonging to these groups will be able to use their domain account credentials to log in to the KUMA web interface and will obtain access to application sections based on their assigned role.

It is recommended to create the groups of users in Actions Active Directory, Active Directory Federation Services, or FreeIPA in advance if you want to provide such groups with the capability for authorization using their domain account in the KUMA web interface. An email address must be indicated in the properties of a user account in Active Directory.

In this section

Connecting over LDAP

Authentication using domain accounts

Page top

[Topic 221426]

Connecting over LDAP

LDAP connections are created and managed under Settings → LDAP server in the KUMA web interface. The LDAP server integration by tenant section shows the tenants for which LDAP connections were created. Tenants can be created or deleted.

If you select a tenant, the LDAP server integration window opens to show a table containing existing LDAP connections. Connections can be created or edited. In this window, you can change the frequency of queries sent to LDAP servers and set the retention period for obsolete data.

After integration is enabled, information about Active Directory accounts becomes available in the alert window, the correlation events detailed view window, and the incidents window. If you click an account name in the Related users section of the window, the Account details window opens with the data imported from Active Directory.

Data from LDAP can also be used when enriching events in collectors and in analytics.

Imported Active Directory attributes

The following account attributes can be requested from Active Directory:

accountExpires
badPasswordTime
cn
co
company
department
description
displayName
distinguishedName
division
employeeID
givenName
l
lastLogon
lastLogonTimestamp
Mail
mailNickname
managedObjects
manager
memberOf (this attribute can be used for search during correlation)
mobile
name
objectCategory
objectGUID (this attribute always requested from Active Directory even if a user doesn't specify it)
objectSID
physicalDeliveryOfficeName
pwdLastSet
sAMAccountName
sAMAccountType
sn
streetAddress
telephoneNumber
title
userAccountControl
UserPrincipalName
whenChanged
whenCreated

In this section

Enabling and disabling LDAP integration

Adding a tenant to the LDAP server integration list

Creating an LDAP server connection

Creating a copy of an LDAP server connection

Changing an LDAP server connection

Changing the data update frequency

Changing the data storage period

Starting account data update tasks

Deleting an LDAP server connection

Page top

[Topic 221481]

Enabling and disabling LDAP integration

You can enable or disable all LDAP connections of the tenant at the same time, or enable and disable an LDAP connection individually.

To enable or disable all LDAP connections of a tenant:

In the KUMA web interface, open Settings → LDAP server and select the tenant for which you want to enable or disable all LDAP connections.
The LDAP server integration by tenant window opens.
Select or clear the Disabled check box.
Click Save.

To enable or disable a specific LDAP connection:

In the KUMA web interface, open Settings → LDAP server and select the tenant for which you want to enable or disable an LDAP connection.
The LDAP server integration window opens.
Select the relevant connection and either select or clear the Disabled check box in the opened window.
Click Save.

Page top

[Topic 233077]

Adding a tenant to the LDAP server integration list

To add a tenant to the list of tenants for integration with an LDAP server:

Open the KUMA web interface and select Settings → LDAP server.
The LDAP server integration by tenant window opens.
Click the Add tenant button.
The LDAP server integration window is displayed.
In the Tenant drop-down list, select the tenant that you need to add.
Click Save.

The selected tenant is added to the LDAP server integration list.

To delete a tenant from the list of tenants for integration with an LDAP server:

Open the KUMA web interface and select Settings → LDAP server.
The LDAP server integration by tenant window is displayed.
Select the check box next to the tenant that you need to delete, and click Delete.
Confirm deletion of the tenant.

The selected tenant is deleted from the LDAP server integration list.

Page top

[Topic 217795]

Creating an LDAP server connection

To create a new LDAP connection to Active Directory:

In the KUMA web interface, open Settings → LDAP server.
Select or create a tenant for which you want to create a LDAP connection.
The LDAP server integration by tenant window opens.
Click the Add connection button.
The Connection parameters window opens.
Add a secret containing the account credentials for connecting to the Active Directory server. To do so:
1. If you previously added a secret, in the Secret drop-down list, select the existing secret (with the credentials type).
  The selected secret can be changed by clicking on the button.
2. If you want to create a new secret, click the button.
  The Secret window opens.
3. In the Name (required) field, enter the name of the secret containing 1 to 128 Unicode characters.
4. In the User and Password (required) fields, enter the account credentials for connecting to the Active Directory server.
  You can enter the user name in one of the following formats: <user name>@<domain> or <domain><user name>.
5. In the Description field, enter a description of up to 4,000 Unicode characters.
6. Click the Save button.
In the Name (required) field, enter the unique name of the LDAP connection.
The length of the string must be 1 to 128 Unicode characters.
In the URL (required) field, enter the address of the domain controller in the format <hostname or IP address of server>:<port>.
In case of server availability issues, you can specify multiple servers with domain controllers by separating them with commas. All of the specified servers must reside in the same domain.
If you want to use TLS encryption for the connection with the domain controller, select one of the following options from the Type drop-down list:
- startTLS.
  When the
  startTLS
  Text exchange protocol enhancement that lets you create an encrypted connection (TLS or SSL) directly over an ordinary TCP connection instead of opening a separate port for the encrypted connection.
  
  Text exchange protocol enhancement that lets you create an encrypted connection (TLS or SSL) directly over an ordinary TCP connection instead of opening a separate port for the encrypted connection.
  
  Text exchange protocol enhancement that lets you create an encrypted connection (TLS or SSL) directly over an ordinary TCP connection instead of opening a separate port for the encrypted connection.
  
  method is used, first it establishes an unencrypted connection over port 389, then it sends an encryption request. If the STARTTLS command ends with an error, the connection is terminated.
  
  Make sure that port 389 is open. Otherwise, a connection with the domain controller will be impossible.
- ssl.
  When using SSL, an encrypted connection is immediately established over port 636.
- insecure.
When using an encrypted connection, it is impossible to specify an IP address as a URL.
If you enabled TLS encryption at the previous step, add a TLS certificate. To do so:
1. If you previously uploaded a certificate, select it from the Certificate drop-down list.
  If no certificate was previously added, the drop-down list shows No data.
2. If you want to upload a new certificate, click the button on the right of the Certificate list.
  The Secret window opens.
3. In the Name field, enter the name that will be displayed in the list of certificates after the certificate is added.
4. Click the Upload certificate file button to add the file containing the Active Directory certificate. X.509 certificate public keys in Base64 are supported.
5. If necessary, provide any relevant information about the certificate in the Description field.
6. Click the Save button.
The certificate will be uploaded and displayed in the Certificate list.
In the Timeout in seconds field, indicate the amount of time to wait for a response from the domain controller server.
If multiple addresses are indicated in the URL field, KUMA will wait the specified number of seconds for a response from the first server. If no response is received during that time, the program will contact the next server, and so on. If none of the indicated servers responds during the specified amount of time, the connection will be terminated with an error.
In the Base DN field, enter the base distinguished name of the directory in which you need to run the search query.
In the Custom AD Account Attributes field, specify the additional attributes that you want to use to enrich events.
Before configuring event enrichment using custom attributes, make sure that custom attributes are configured in AD.

To enrich events with accounts using custom attributes:
1. Add Custom AD Account Attributes in the LDAP connection settings.
  Standard imported attributes from AD cannot be added as custom attributes. For example, if you add the standard accountExpires attribute as a custom attribute, KUMA returns an error when saving the connection settings.
  The following account attributes can be requested from Active Directory:
  - accountExpires
  - badPasswordTime
  - cn
  - co
  - company
  - department
  - description
  - displayName
  - distinguishedName
  - division
  - employeeID
  - givenName
  - l
  - lastLogon
  - lastLogonTimestamp
  - Mail
  - mailNickname
  - managedObjects
  - manager
  - memberOf (this attribute can be used for search during correlation)
  - mobile
  - name
  - objectCategory
  - objectGUID (this attribute always requested from Active Directory even if a user doesn't specify it)
  - objectSID
  - physicalDeliveryOfficeName
  - pwdLastSet
  - sAMAccountName
  - sAMAccountType
  - sn
  - streetAddress
  - telephoneNumber
  - title
  - userAccountControl
  - UserPrincipalName
  - whenChanged
  - whenCreated
  After you add custom attributes in the LDAP connection settings, the LDAP attribute to receive drop-down list in the collector automatically includes the new attributes. Custom attributes are identified by a question mark next to the attribute name. If you added the same attribute for multiple domains, the attribute is listed only once in the drop-down list. You can view the domains by moving your cursor over the question mark. Domain names are displayed as links. If you click a link, the domain is automatically added to LDAP accounts mapping if it was not previously added.
  
  If you deleted a custom attribute in the LDAP connection settings, manually delete the row containing the attribute from the mapping table in the collector. Account attribute information in KUMA is updated each time you import accounts.
2. Import accounts.
3. In the collector, in the LDAP mapping table, define the rules for mapping KUMA fields to LDAP attributes.
4. Restart the collector.
  After the collector is restarted, KUMA begins enriching events with accounts.
Select the Disabled check box if you do not want to use this LDAP connection.
This check box is cleared by default.
Click the Save button.

The LDAP connection to Active Directory will be created and displayed in the LDAP server integration window.

Account information from Active Directory will be requested immediately after the connection is saved, and then it will be updated at the specified frequency.

If you want to use multiple LDAP connections simultaneously for one tenant, you need to make sure that the domain controller address indicated in each of these connections is unique. Otherwise KUMA lets you enable only one of these connections. When checking the domain controller address, the program does not check whether the port is unique.

Page top

[Topic 231112]

Creating a copy of an LDAP server connection

You can create an LDAP connection by copying an existing connection. In this case, all settings of the original connection are duplicated in the newly created connection.

To copy an LDAP connection:

In the KUMA web interface, open Settings → LDAP server and select the tenant for which you want to copy an LDAP connection.
The LDAP server integration window opens.
Select the relevant connection.
In the opened Connection parameters window, click the Duplicate connection button.
The New Connection window opens. The word copy will be added to the connection name.
If necessary, change the relevant settings.
Click the Save button.

The new connection is created.

Page top

[Topic 233080]

Changing an LDAP server connection

To change an LDAP server connection:

Open the KUMA web interface and select Settings → LDAP server.
The LDAP server integration by tenant window opens.
Select the tenant for which you want to change the LDAP server connection.
The LDAP server integration window opens.
Click the LDAP server connection that you want to change.
The window with the settings of the selected LDAP server connection opens.
Make the necessary changes to the settings.
Click the Save button.

The LDAP server connection is changed. Restart the KUMA services that use LDAP server data enrichment for the changes to take effect.

Page top

[Topic 233081]

Changing the data update frequency

KUMA queries the LDAP server to update account data. This occurs:

Immediately after creating a new connection.
Immediately after changing the settings of an existing connection.
According to a regular schedule every several hours. Every 12 hours by default.
Whenever a user creates a task to update account data.

When querying LDAP servers, a task is created in the Task manager section of the KUMA web interface.

To change the schedule of KUMA queries to LDAP servers:

In the KUMA web interface, open Settings → LDAP server → LDAP server integration by tenant.
Select the relevant tenant.
The LDAP server integration window opens.
In the Data refresh interval field, specify the required frequency in hours. The default value is 12.

The query schedule has been changed.

Page top

[Topic 233213]

Changing the data storage period

Received user account data is stored in KUMA for 90 days by default if information about these accounts is no longer received from the Active Directory server. After this period, the data is deleted.

After KUMA account data is deleted, new and existing events are no longer enriched with this information. Account information will also be unavailable in alerts. If you want to view information about accounts throughout the entire period of alert storage, you must set the account data storage period to be longer than the alert storage period.

To change the storage period for the account data:

In the KUMA web interface, open Settings → LDAP server → LDAP server integration by tenant.
Select the relevant tenant.
The LDAP server integration window opens.
In the Data storage time field, specify the number of days you need to store data received from the LDAP server.

The account data storage period is changed.

Page top

[Topic 233094]

Starting account data update tasks

After a connection to an Active Directory server is created, tasks to obtain account data are created automatically. This occurs:

Immediately after creating a new connection.
Immediately after changing the settings of an existing connection.
According to a regular schedule every several hours. Every 12 hours by default. The schedule can be changed.

Account data update tasks can be created manually. You can download data for all connections or for one connection of the required tenant.

To start an account data update task for all LDAP connections of a tenant:

In the KUMA web interface, open Settings → LDAP server → LDAP server integration by tenant.
Select the relevant tenant.
The LDAP server integration window opens.
Click the Import accounts button.

A task to receive account data from the selected tenant is added to the Task manager section of the KUMA web interface.

To start an account data update task for one LDAP connection of a tenant:

In the KUMA web interface, open Settings → LDAP server → LDAP server integration by tenant.
Select the relevant tenant.
The LDAP server integration window opens.
Select the relevant LDAP server connection.
The Connection parameters window opens.
Click the Import accounts button.

A task to receive account data from the selected connection of the tenant is added to the Task manager section of the KUMA web interface.

Page top

[Topic 217830]

Deleting an LDAP server connection

To delete LDAP connection to Active Directory:

In the KUMA web interface, open Settings → LDAP server and select the tenant that owns the relevant LDAP connection.
The LDAP server integration window opens.
Click the LDAP connection that you want to delete and click the Delete button.
Confirm deletion of the connection.

The LDAP connection to Active Directory will be deleted.

Page top

[Topic 221427]

Authentication using domain accounts

To enable users to perform authentication in the KUMA web interface using their own domain account credentials, perform the following configuration steps.

Enable domain authentication if it is disabled.
Domain authorization is enabled by default, but a connection to the domain is not configured.
Configure a connection to the domain controller.
The following connections are available:
The AD and ADFS connection settings can be configured at the same time.

You can connect to one domain only.
Add groups of user roles.
You can specify a domain group for each KUMA role. After performing authentication using their domain accounts, the users from this group get access to the KUMA web interface in accordance with the specified role.

The application checks whether the user group matches the specified filter according to the following order of roles in the KUMA web interface: operator → first line analyst → analyst → tenant administrator → general administrator. Upon the first match, the program assigns a role to the user and does not check any further. If a user matches two groups in the same tenant, the role with the least privileges will be used. If multiple groups are matched for different tenants, the user will be assigned the specified role in each tenant.

Special considerations for logging in after configuring domain authentication

For successful authentication, the following conditions must be met:

FreeIPA: when logging into the system, the user must capitalize the domain name in the login. Example: user@FREEIPA.COM.
AD/ADFS: when logging into the system, the user must specify UserPrincipalName in the login. Example: user@domain.ru.

If you complete all the configuration steps but the users are not able to use their domain accounts for authentication in the KUMA web interface, it is recommended to check the configuration for the following issues:

An email address is not indicated in the properties of the user account in Active Directory. If this is the case, an error message is displayed during the user's first authentication attempt and a KUMA account is not created.
There is already an existing local KUMA account with the email address indicated in the domain account properties. If this is the case, the error message is displayed when the user attempts to perform authentication with the domain account.
Domain authorization is disabled in the KUMA settings.
An error occurred when entering the group of roles.
The domain user name contains a space.

In this section

Enabling and disabling domain authentication

Configuring connection between KUMA and FreeIPA

Configuring connection between KUMA and Active Directory

Configuring connection between KUMA and Active Directory Federation Services

Page top

[Topic 221428]

Enabling and disabling domain authentication

Domain authorization is enabled by default, but a connection to the domain is not configured. If you want to temporarily suspend domain authentication after configuring a connection, you can disable it in the KUMA web interface without deleting the previously defined values of settings. If necessary, you can enable authentication again at any time.

To enable or disable domain authorization of users in the KUMA web interface:

In the application web interface, select Settings → Domain authorization.
In the Authorization type drop-down list, select one of the options:
- FreeIPA
- AD/ADFS
Do one of the following:
- To disable domain authentication, select the Disabled check box in the upper part of the workspace.
- To enable domain authentication, clear the Disabled check box in the upper part of the workspace.
Click the Save button.

The selected settings are saved and applied.

Page top

[Topic 244887]

Configuring connection between KUMA and FreeIPA

You can connect only to one FreeIPA domain. To do so, you must configure a connection to the domain controller.

To configure a connection to a FreeIPA domain controller:

In the application web interface, select Settings → Domain authorization.
In the Authorization type drop-down list, select FreeIPA.
In the FreeIPA settings block, in the Base DN field, enter the DistinguishedName of the root record to search for access groups in the FreeIPA catalog service. Record format: dc=example,dc=com.
In the URL field, indicate the address of the domain controller in the format <hostname or IP address of server>:<port>.
In case of server availability issues, you can specify up to three servers with domain controllers by separating them with commas. All of the specified servers must reside in the same domain.
If you want to use TLS encryption for the connection with the domain controller, select one of the following options from the TLS mode drop-down list:
- startTLS.
  When the startTLS method is used, first it establishes an unencrypted connection over port 389, then it sends an encryption request. If the STARTTLS command ends with an error, the connection is terminated.
  
  Make sure that port 389 is open. Otherwise, a connection with the domain controller will be impossible.
- ssl.
  When using SSL, an encrypted connection is immediately established over port 636.
- insecure.
When using an encrypted connection, it is impossible to specify an IP address as a URL.
If TLS encryption is enabled, the Secret field becomes required and you must specify a secret of the 'certificate' type in that field. If you previously uploaded a secret, select it from the Secret drop-down list. If necessary, click the button to create a new secret of the 'certificate' type and select the secret from the drop-down list.
In the Timeout in seconds field, indicate the amount of time to wait for a response from the domain controller server. The default value is 0.
If multiple addresses are indicated in the URL field, KUMA waits for the specified number of seconds for a response from the first server. If no response is received during that time, the application contacts the next server. If none of the indicated servers responds during the specified amount of time, the connection will be terminated with an error.
In the Custom integration secret drop-down list, select a secret with the 'credentials' type.
If you want to upload a new secret of the 'credentials' type, click the button on the right of the Custom integration secret drop-down list. This opens the Secret window; in that window, in the Name field, enter the name of the secret that will be displayed in the list after it is saved. In the User field, specify the DistinguishedName in the following format: uid=admin,cn=users,cn=accounts,dc=ipa,dc=test. Enter the Password and click Save.

The secret is uploaded and becomes available for selection in the Custom integration secret drop-down list.
If you want to configure domain authentication for a user with the KUMA general administrator role, use the General administrators group field to specify the DistinguishedName of the FreeIPA group containing the user.
If the user belongs to several groups within the same tenant, the role with the least privileges is used.

Filter input example: CN=KUMA team,OU=Groups,OU=Clients,DC=test,DC=domain.
Click the Save button.

A connection with the FreeIPA domain controller is now configured.

You can also check the connection for the previously entered domain controller connection settings.

To check the connection to the domain controller:

In the application web interface, select Settings → Domain authorization.
In the Authorization type drop-down list, select FreeIPA.
In the FreeIPA settings block, select the relevant secret in the User credentials field.
If necessary, you can create a new secret by clicking the button or change the settings of an existing secret by clicking the button. If integration with FreeIPA is enabled, the secret selection is always reset when the page is loaded.
Click Test.
After clicking the Test button, the system tests the connection with the domain and returns a notification with the test results. The system does not check if the users can log in or if the user group is configured correctly.

For domain authentication, add the groups for the KUMA user roles.

You can specify the groups only for the roles that require the configuration of domain authentication. You can leave the rest of the fields empty.

To add groups of user roles:

In the application web interface, select Settings → Domain authorization.
In the Role groups settings block, click the Add role groups button.
In the Tenant drop-down list, select the tenant of the users for whom you want to configure domain authentication.
In the fields for the following roles, specify the DistinguishedName of the domain group. The users of this domain group must have the capability to perform authentication with their domain accounts:
- Operator.
- First line analyst.
- Analyst.
- Administrator.
Group input example: CN=KUMA team,OU=Groups,OU=Clients,DC=test,DC=domain.

You can specify only one domain group for each role. If you need to specify multiple groups, you must repeat steps 2–4 for each group while indicating the same tenant.
If necessary, repeat steps 2–4 for each tenant for which you want to configure domain authentication with the following roles: operator, first line analyst, analyst, and tenant administrator.
Click the Save button.

The groups of user roles will be added. The defined settings will be applied the next time the user logs in to the KUMA web interface.

After the first authentication of the user, information about this user is displayed under Settings → Users. The Login and Password fields received from the domain cannot be edited. The user role will also be unavailable for editing. To edit a role, you will have to change the user role groups. Changes to a role are applied after the next authentication of the user. The user continues working under the current role until the current session expires.

If the user name or email address is changed in the domain account properties, these changes must be manually made in the KUMA account.

Page top

[Topic 221429]

Configuring connection between KUMA and Active Directory

You can connect only to one Active Directory domain. To do so, you must configure a connection to the domain controller.

To configure a connection to an Active Directory domain controller:

In the application web interface, select Settings → Domain authorization.
In the Authorization type drop-down list, select AD/ADFS.
In the Active Directory group of settings, in the Base DN field, enter the DistinguishedName of the root record to search for access groups in the Active Directory catalog service.
In the URL field, indicate the address of the domain controller in the format <hostname or IP address of server>:<port>.
In case of server availability issues, you can specify multiple servers with domain controllers by separating them with commas. All of the specified servers must reside in the same domain.
If you want to use TLS encryption for the connection with the domain controller, select one of the following options from the TLS mode drop-down list:
- startTLS.
  When the startTLS method is used, first it establishes an unencrypted connection over port 389, then it sends an encryption request. If the STARTTLS command ends with an error, the connection is terminated.
  
  Make sure that port 389 is open. Otherwise, a connection with the domain controller will be impossible.
- ssl.
  When using SSL, an encrypted connection is immediately established over port 636.
- insecure.
When using an encrypted connection, it is impossible to specify an IP address as a URL.
If you enabled TLS encryption at the previous step, add a TLS certificate:
- If you previously uploaded a certificate, select it from the Secret drop-down list.
  If no certificate was previously added, the drop-down list shows No data.
- If you want to upload a new certificate, click the button on the right of the Secret list. In the opened window, in the Name field, enter the name that will be displayed in the list of certificates after the certificate is added. Add the file containing the Active Directory certificate (X.509 certificate public keys in Base64 are supported) by clicking the Upload certificate file button. Click the Save button.
  The certificate will be uploaded and displayed in the Secret list.
In the Timeout in seconds field, indicate the amount of time to wait for a response from the domain controller server.
If multiple addresses are indicated in the URL field, KUMA waits for the specified number of seconds for a response from the first server. If no response is received during that time, the application contacts the next server. If none of the indicated servers responds during the specified amount of time, the connection will be terminated with an error.
To configure domain authentication for a user with the KUMA general administrator role, specify the DistinguishedName of the Active Directory group the user belongs to in the General administrators group field.
If the user belongs to several groups within the same tenant, the role with the least privileges is used.

Filter input example: CN=KUMA team,OU=Groups,OU=Clients,DC=test,DC=domain.
Click the Save button.

A connection with the Active Directory domain controller is now configured.

You can also check the connection for the previously entered domain controller connection settings.

To check the connection to the domain controller:

In the application web interface, select Settings → Domain authorization.
In the Authorization type drop-down list, select AD/ADFS.
In the Test connection settings block, select the relevant secret in the User credentials field.
If necessary, you can create a new secret by clicking the button or change the settings of an existing secret by clicking the button.

The following formats for specifying a user are available in the User field: UserPrincipalName and domain\user.
Click Test.
After clicking the Test button, the system tests the connection with the domain and returns a notification with the test results. The system does not check if the users can log in or if the user group is configured correctly.

For domain authentication, add the groups for the KUMA user roles.

You can specify the groups only for the roles that require the configuration of domain authentication. You can leave the rest of the fields empty.

To add groups of user roles:

In the application web interface, select Settings → Domain authorization.
In the Role groups settings block, click the Add role groups button.
In the Tenant drop-down list, select the tenant of the users for whom you want to configure domain authentication.
In the fields for the following roles, specify the DistinguishedName of the domain group. The users of this domain group must have the capability to perform authentication with their domain accounts:
- Operator.
- First line analyst.
- Analyst.
- Administrator.
Group input example: CN=KUMA team,OU=Groups,OU=Clients,DC=test,DC=domain.

You can specify only one domain group for each role. If you need to specify multiple groups, you must repeat steps 2–4 for each group while indicating the same tenant.
If necessary, repeat steps 2–4 for each tenant for which you want to configure domain authentication with the following roles: operator, first line analyst, analyst, and tenant administrator.
Click the Save button.

The groups of user roles will be added. The defined settings will be applied the next time the user logs in to the KUMA web interface.

If the user name or email address is changed in the domain account properties, these changes must be manually made in the KUMA account.

Page top

[Topic 244876]

Configuring connection between KUMA and Active Directory Federation Services

To configure domain authentication in KUMA and ensure that users can log in to KUMA using their accounts without specifying a user name and password, first create a connection group and configure the rules in ADFS or make sure that the necessary connection groups and rules already exist.

After configuration, the Sign in via ADFS button appears on the KUMA login page.

The Sign in via ADFS button is hidden on the KUMA login page in the following conditions:

The FreeIPA option is selected in the Authorization type drop-down list.
The AD/ADFS option is selected in the Authorization type drop-down list and the settings for ADFS are not specified or the Disabled check box is selected for ADFS settings.

You can connect only to one ADFS domain. To do so, you must configure a connection to the domain controller.

To configure a connection to an ADFS domain controller:

In the application web interface, select Settings → Domain authorization.
In the Authorization type drop-down list, select AD/ADFS.
In the Active Directory Federation Services settings block, in the Client ID field, enter the KUMA ID from the Client ID field in the ADFS.
In the Relying party identifier field, enter the KUMA ID from the Relying party identifiers field in the ADFS.
Enter the Connect Metadata URI from the Connect Metadata URI field. This parameter consists of the host where the ADFS resides (https://adfs.example.com), and the endpoint setting (/adfs/.well-known/openid-configuration).
For example, https://adfs.example.com/adfs/.well-known/openid-configuration).
Enter the ADFS redirect URL from the Redirect URL field in the ADFS. The value of the Redirect URL field in the ADFS is defined when the Application group is configured. In the ADFS, you must indicate the KUMA FQDN and the </sso-callback> substring. In KUMA, the URL must be indicated without the substring, for example: https://kuma-example:7220/
If you want to configure domain authentication for a user with the KUMA general administrator role, use the General administrators group field to specify the DistinguishedName of the Active Directory Federation Services group containing the user.
If the user belongs to several groups within the same tenant, the role with the least privileges is used.

Filter input example: CN=KUMA team,OU=Groups,OU=Clients,DC=test,DC=domain.
Click the Save button.

A connection with the Active Directory Federation Services domain controller is now configured.

For domain authentication, add the groups for the KUMA user roles.

You can specify the groups only for the roles that require the configuration of domain authentication. You can leave the rest of the fields empty.

To add groups of user roles:

In the application web interface, select Settings → Domain authorization.
In the Role groups settings block, click the Add role groups button.
In the Tenant drop-down list, select the tenant of the users for whom you want to configure domain authentication.
In the fields for the following roles, specify the DistinguishedName of the domain group. The users of this domain group must have the capability to perform authentication with their domain accounts:
- Operator.
- First line analyst.
- Analyst.
- Administrator.
Group input example: CN=KUMA team,OU=Groups,OU=Clients,DC=test,DC=domain.

You can specify only one domain group for each role. If you need to specify multiple groups, you must repeat steps 2–4 for each group while indicating the same tenant.
If necessary, repeat steps 2–4 for each tenant for which you want to configure domain authentication with the following roles: operator, first line analyst, analyst, and tenant administrator.
Click the Save button.

The groups of user roles will be added. The defined settings will be applied the next time the user logs in to the KUMA web interface.

If the user name or email address is changed in the domain account properties, these changes must be manually made in the KUMA account.

Page top

[Topic 245272]

Configuring connection in Active Directory Federation Services

This section provides instructions on how to create a new connection group and configure rules for the created connection group in Active Directory Federation Services (ADFS).

The ADFS role must already be configured on the server.

Creating a new connection group

In Server Manager, in the Tools menu, select ADFS Management.
In ADFS, select the Application groups section and in the Actions section click Add Application Group.
In the Add Application Group Wizard window that opens, in the Welcome section Name field, specify the name of the new connection group. Example: new-application-group.
In the Template field, in the Client-Server applications group, select Native application accessing a web API.

Click Next to proceed to the next step of creating and configuring a connection group.
In the Native application section that opens, the Name and
Client Identifier
fields are filled in automatically.
Specify the value of the Client Identifier field in KUMA, when configuring domain authentication.

In the

Redirect URI field, enter the URI for redirection from ADFS with the /sso-callback substring, and click Add. Example: https://adfs.example.com:7220/sso-callback

Click Next to proceed to the next configuration step.
In the Configure Web API section that opens, in the
Identifiers
field add the trusted party ID and click Add. It can be any arbitrary value. Example: test-demo
Specify the value of the Identifier field in KUMA, in the Relying party identifiers field, when configuring domain authentication.

Click Next to proceed to the next configuration step.
In the Apply Access Control Policy section that opens, select the Permit everyone policy value.
Click Next to proceed to the next configuration step.
In the Configure Application Permissions section that opens, the Client application field is filled in automatically.
In the Permitted scopes field, select the check box for the allatclaims and openid options.

Click Next to proceed to the next configuration step.
In the Summary section that opens, check the settings.
If the settings are correct and you are ready to add a group, click Next.

A new group is added. You can proceed to configure the rules for the created group.

Adding rules for a connection group

In Server Manager, in the Tools menu, select ADFS Management.
In ADFS, select the Application groups section and select the required connection group from the list. Example: new-application-group.
In the Application groups window, in the Actions section, click Properties.
In the new-application-group Properties window that opens, in the Applications section, double-click new-application-group - Web API.

In the new-application-group - Web API Properties window that opens, open the
Issuance Transform Rules
tab and click Add rule.

In the Add Transform Claim Rule Wizard window that opens, in the Choose Rule Type section, select Send LDAP Attributes as Claims from the drop-down list.

Click Next to proceed to the next configuration step.
In the Configure Claim Rule section, specify the rule name in the Claim rule name field. Example: rule-name-01.
In the Attribute store drop-down list, select Active directory.

In the Mapping of LDAP attributes to outgoing claim types field, map the following fields:

LDAP Attribute

Outgoing Claim Type

User-Principal-Name

UserPrincipalName

Display-Name

displayName

E-Mail-Addresses

Mail

Is-Member-Of-DL

MemberOf

Click Finish to complete the configuration.
Go to the new-application-group - Web API Properties window, open the
Issuance Transform Rules
tab and click Add rule. In the Add Transform Claim Rule Wizard window that opens, in the Choose Rule Type section, select Send claims using a custom rule from the drop-down list.
Click Finish to continue the configuration.
In the Configure Claim Rule section, specify the rule name in the Claims rule name field. Example: rule-name-02.
In the Custom rule field, specify the following settings:

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
=> issue(store = "Active Directory", types = ("ObjectGUID"), query = ";ObjectGUID;{0}", param = c.Value);

Click Finish to complete the configuration.
The system proceeds to the new-application-group - Web API Properties window and the Issuance Transform Rules tab.
To apply the rules, on the Issuance Transform Rules tab that opens, click Apply or OK.

The configuration of groups and rules in ADFS is completed. You can proceed to configure domain authentication in KUMA.

Page top

[Topic 245317]

Troubleshooting the Access denied error

When you try to log in to KUMA using ADFS, the Access denied or Insufficient rights pop-up message may appear. The KUMA Core log shows the Data source certificate has been changed error.

This error indicates that the ADFS certificate is changed. To fix the error and resume domain authentication, update the certificate thumbprint saved in KUMA.

To update the certificate thumbprint on an Astra Linux or Oracle Linux host:

Contact Technical support to obtain the adfs_fingerprint_changer_tool binary file.
Place the received adfs_fingerprint_changer_tool binary file in any folder on the host with the KUMA Core. For example, /root/kuma-ansible-installer.
On the host with the KUMA Core, start the command line interpreter and use the cd command to go to the folder containing the adfs_fingerprint_changer_tool file.
For example, you can enter the following command and press Enter:

cd /root/kuma-ansible-installer
To grant the permissions to run a binary file and run the binary file, sequentially execute the following commands:
chmod +x adfs_fingerprint_changer_tool

./adfs_fingerprint_changer_tool

To update the certificate thumbprint on a Kubernetes host:

Contact Technical support to obtain the adfs_fingerprint_changer_tool binary file.
Place the received adfs_fingerprint_changer_tool binary file in any folder on the computer of an administrator with access to the Kubernetes cluster and execute the following commands:
k0s kubectl cp <path to adfs_fingerprint_changer_tool> $(k0s kubectl get pod -l app=core -n kuma -o name | cut -d/ -f2):/tmp/ -c mongodb -n kuma

k0s kubectl exec $(k0s kubectl get pod -l app=core -n kuma -o name) -c mongodb -n kuma -- bash -c "chmod a+x /tmp/adfs_fingerprint_changer_tool && /tmp/adfs_fingerprint_changer_tool"

After you run the binary file, the certificate thumbprint is updated and the domain authentication by means of ADFS is again available.

Page top

[Topic 221777]

RuCERT integration

In the KUMA web interface, you can create a connection to the National Computer Incident Response & Coordination Center Incidents (hereinafter referred to as "RuCERT"). This will let you export incidents registered by KUMA to RuCERT. Integration is configured under Settings → RuCERT in the KUMA web interface.

Data in KUMA and RuCERT is synchronized every 5-10 minutes.

To create a connection to RuCERT:

In the KUMA web interface, open Settings → RuCERT.
In the URL field, enter the URL for accessing RuCERT.
In the Token settings block, create or select an existing secret with the API token that was issued to your organization for a connection to RuCERT:
- If you already have a secret, you can select it from the drop-down list.
- If you want to create a new secret:
  1. Click the button and specify the following settings:
    - Name (required)—unique name of the service you are creating. The name must contain 1 to 128 Unicode characters.
    - Token (required)—token that was issued to your organization for a connection to RuCERT.
    - Description—service description: up to 256 Unicode characters.
  2. Click Save.
  The secret containing the token for connecting to RuCERT will be created. It is saved under Resources → Secrets and is owned by the main tenant.
The selected secret can be changed by clicking on the button.
In the Affected system function drop-down list, select the area of activity of your organization.
Available company business sectors
- Nuclear energy
- Banking and other financial market sectors
- Mining
- Federal/municipal government
- Healthcare
- Metallurgy
- Science
- Defense industry
- Education
- Aerospace industry
- Communication
- Mass media
- Fuel and power
- Transportation
- Chemical industry
- Other
In the Company field, indicate the name of your company. This data will be forwarded to RuCERT when incidents are exported.
Use the Location drop-down list to specify where your company is located. This data will be forwarded to RuCERT when incidents are exported.
If necessary, under Proxy, create or select an existing proxy server that must be used when connecting to RuCERT.
Click Save.

KUMA is now integrated with RuCERT. Now you can export incidents to it. You can click the Test connection button to make sure that a connection with RuCERT is established.

You can use the Disabled check box to enable or disable integration.

Possible errors

If the "https://lk.cert.gov.ru/api/v2/incidents? x509: certificate signed by unknown authority" error is returned when you configure integration with RuCERT, use commands of your operating system to install and trust the following certificates of intermediate certification authorities to the KUMA Core server:

The ISRG Root X1 certificate can be downloaded from https://letsencrypt.org/certs/isrgrootx1.der
The R3 certificate can be downloaded from https://letsencrypt.org/certs/lets-encrypt-r3.der

For details on installing certificates, refer to the vendor documentation for your operating system.

After installing the certificate, restart the Core server and continue configuring the integration with RuCERT.

See also:

Interaction with RuCERT

Page top

[Topic 232020]

Integration with Security Vision Incident Response Platform

Security Vision Incident Response Platform (hereinafter referred to as Security Vision IRP) is a software platform used for automation of monitoring, processing, and responding to information security incidents. It aggregates cyberthreat data from various sources into a single database for further analysis and investigation to facilitate incident response capabilities.

Security Vision IRP can be integrated with KUMA. After configuring integration in Security Vision IRP, you can perform the following tasks:

Request information about alerts from KUMA. In Security Vision IRP, incidents are created based on received data.
Send requests to KUMA to close alerts.

Integration is implemented by using the KUMA REST API. On the Security Vision IRP side, integration is carried out by using the preconfigured Kaspersky KUMA connector. Contact your Security Vision IRP vendor to learn more about the methods and conditions for obtaining a Kaspersky KUMA connector.

Working with Security Vision IRP incidents

Security Vision IRP incidents generated from KUMA alert data can be viewed in Security Vision IRP under Incidents → Incidents (2 lines) → All incidents (2 lines). Events related to KUMA alerts are logged in each Security Vision IRP incident. Imported events can be viewed on the Response tab.

KUMA alert imported as Security Vision IRP incident

commandSV

Security Vision IRP incident that was created based on KUMA alert

incidentSV-2

Events from KUMA alert that were imported to Security Vision IRP

In this section

Configuring integration in Security Vision IRP

See also:

Page top

Configuring integration in KUMA

To configure KUMA integration with Security Vision IRP, you must configure authorization of API requests in KUMA. To do so, you need to create a token for the KUMA user on whose behalf the API requests will be processed on KUMA side.

A token can be generated in your account profile. Users with the General Administrator role can generate tokens in the accounts of other users. You can always generate a new token.

To generate a token in your account profile:

In the KUMA web interface, click the user account name in the lower-left corner of the window and click the Profile button in the opened menu.
The User window with your user account parameters opens.
Click the Generate token button.
Copy the generated token displayed in the opened window. This will be required to configure Security Vision IRP.
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.

The generated token must be indicated in the Security Vision IRP connector settings.

Page top

[Topic 232073]

Configuring integration in Security Vision IRP

Configuration of integration in Security Vision IRP consists of importing and configuring a connector. If necessary, you can also change other Security Vision IRP settings related to KUMA data processing, such as the data processing schedule and worker.

For more detailed information about configuring Security Vision IRP, please refer to the product documentation.

In this section

Importing and configuring a connector

Configuring the handler, schedule, and worker process

See also:

Security Vision IRP connector settings

Page top

[Topic 232293]

Importing and configuring a connector

Adding a connector in Security Vision IRP

Integration of Security Vision IRP and KUMA is carried out by using the Kaspersky KUMA connector. Contact your Security Vision IRP vendor to learn more about the methods and conditions for obtaining a Kaspersky KUMA connector.

To import a Kaspersky KUMA connector into Security Vision IRP:

In Security Vision IRP, open Settings → Connectors → Connectors.
You will see a list of connectors that have been added to Security Vision IRP.
At the top of the screen, click the import button and select the ZIP archive containing the Kaspersky KUMA connector.

The connector has been imported into Security Vision IRP and is ready to be configured.

Configuring a connector for a connection to KUMA

To use a connector, you need to configure its connection to KUMA.

To configure a connection to KUMA in Security Vision IRP using the Kaspersky KUMA connector:

In Security Vision IRP, open Settings → Connectors → Connectors.
You will see a list of connectors that have been added to your Security Vision IRP.
Select the Kaspersky KUMA connector.
The general settings of the connector will be displayed.
Under Connector settings, click the Edit button.
The connector configuration will be displayed.
In the URL field, specify the address and port of KUMA. For example, kuma.example.com:7223.
In the Token field, specify KUMA user API token.

The connection to KUMA has been configured in the Security Vision IRP connector.

connectorSV-config

Configuring commands for interaction with KUMA in the Security Vision IRP connector

You can use Security Vision IRP to receive information about KUMA alerts (referred to as incidents in Security Vision IRP terminology) and send requests to close these alerts. To perform these actions, you need to configure the appropriate commands in the Security Vision IRP connector.

The instructions below describe how to add commands to receive and close alerts. However, if you need to implement more complex logic of interaction between Security Vision IRP and KUMA, you can similarly create your own commands containing other API requests.

To configure a command to receive alert information from KUMA:

In Security Vision IRP, open Settings → Connectors → Connectors.
You will see a list of connectors that have been added to Security Vision IRP.
Select the Kaspersky KUMA connector.
The general settings of the connector will be displayed.
Click the +Command button.
The command creation window opens.
Specify the command settings for receiving alerts:
- In the Name field, enter the command name: Receive incidents.
- In the Request type drop-down list, select GET.
- In the Called method field, enter the API request to search for alerts:
  api/v1/alerts/?withEvents&status=new
- Under Request headers, in the Name field, indicate authorization. In the Value field, indicate Bearer <token>.
- In the Content type drop-down list, select application/json.
Save the command and close the window.

The connector command is configured. When this command is executed, the Security Vision IRP connector will query KUMA for information about all alerts with the New status and all events related to those alerts. The received data will be relayed to the Security Vision IRP handler, which will create Security Vision IRP incidents based on this data. If an already imported alert is updated in KUMA with additional information, new data will be imported to Security Vision IRP incident.

To configure a command to close KUMA alerts:

In Security Vision IRP, open Settings → Connectors → Connectors.
You will see a list of connectors that have been added to Security Vision IRP.
Select the Kaspersky KUMA connector.
The general settings of the connector will be displayed.
Click the +Command button.
The command creation window will be displayed.
Specify the command settings for receiving alerts:
- In the Name field, enter the command name: Close incident.
- In the Request type drop-down list, select POST.
- In the Called method field, enter API request to close an alert:
  api/v1/alerts/close
- In the Request field, enter the contents of the sent API request:
  {"id":"<Alert ID>","reason":"responded"}
  
  You can create multiple commands for different reasons to close alerts, such as responded, incorrect data, and incorrect correlation rule.
- Under Request headers, in the Name field, indicate authorization. In the Value field, indicate Bearer <token>.
- In the Content type drop-down list, select application/json.
Save the command and close the window.

The connector command is configured. When this command is executed, the incident will be closed in Security Vision IRP and the corresponding alert will be closed in KUMA.

Creating commands in Security Vision IRP

commandSV

After configuring the connector, KUMA alerts will be sent to the platform as Security Vision IRP incidents. Then you need to configure incident handling in Security Vision IRP based on the security policies of your organization.

Page top

[Topic 232323]

Configuring the handler, schedule, and worker process

Security Vision IRP handler

The Security Vision IRP handler receives KUMA alert data from the Security Vision IRP connector and creates Security Vision IRP incidents based on this data. A predefined KUMA (Incidents) handler is used for processing data. The settings of the KUMA (Incidents) handler are available in Security Vision IRP under Settings → Event processing → Event handlers:

The rules for processing KUMA alerts can be viewed in the handler settings on the Normalization tab.
The available actions when creating new objects can be viewed in the handler settings on the Actions tab for creating objects of the Incident (2 lines) type.

Handler run schedule

The connector and handler are started according to a predefined KUMA schedule. This schedule can be configured in Security Vision IRP under Settings → Event processing → Schedule:

In the Connector settings block, you can configure the settings for starting the connector.
In the Handler settings block, you can configure the settings for starting the handler.

Security Vision IRP worker process

The life cycle of Security Vision IRP incidents created based on KUMA alerts follows the preconfigured Incident processing (2 lines) worker. The worker can be configured in Security Vision IRP under Settings → Workers → Worker templates: select the Incident processing (2 lines) worker and click the transaction or state that you need to change.

Page top

[Topic 233668]

Kaspersky Industrial CyberSecurity for Networks integration

Kaspersky Industrial CyberSecurity for Networks (hereinafter referred to as "KICS for Networks") is an application designed to protect the industrial enterprise infrastructure from information security threats, and to ensure uninterrupted operation. The application analyzes industrial network traffic to identify deviations in the values of process parameters, detect signs of network attacks, and monitor the operation and current state of network devices.

KICS for Networks version 4.0 or later can be integrated with KUMA. After configuring integration, you can perform the following tasks in KUMA:

Import asset information from KICS for Networks to KUMA.
Send asset status change commands from KUMA to KICS for Networks.

Unlike KUMA, KICS for Networks refers to assets as devices.

The integration of KICS for Networks and KUMA must be configured in both applications:

In KICS for Networks, you need to create a KUMA connector and save the communication data package of this connector.
In KUMA, the communication data package of the connector is used to create a connection to KICS for Networks.

The integration described in this section applies to importing asset information. KICS for Networks can also be configured to send events to KUMA. To do so, you need to create a SIEM/Syslog connector in KICS for Networks, and configure a collector on the KUMA side.

In this section

Configuring integration in KICS for Networks

Enabling and disabling integration with KICS for Networks

Changing the data update frequency

Special considerations when importing asset information from KICS for Networks

Changing the status of a KICS for Networks asset

Page top

[Topic 233670]

Configuring integration in KICS for Networks

The program supports integration with KICS for Networks version 4.0 or later.

It is recommended to configure integration of KICS for Networks and KUMA after ending Process Control rules learning mode. For more details, please refer to the documentation on KICS for Networks.

On the KICS for Networks side, integration configuration consists of creating a KUMA-type connector. In KICS for Networks, connectors are specialized application modules that enable KICS for Networks to exchange data with recipient systems, including KUMA. For more details on creating connectors, please refer to the documentation on KICS for Networks.

When a connector is added to KICS for Networks, a communication data package is automatically created for this connector. This is an encrypted configuration file for connecting to KICS for Networks that is used when configuring integration on the KUMA side.

Page top

[Topic 233669]

Configuring integration in KUMA

It is recommended to configure integration of KICS for Networks and KUMA after ending Process Control rules learning mode. For more details, please refer to the documentation on KICS for Networks.

To configure integration with KICS for Networks in KUMA:

Open the KUMA web interface and select Settings → Kaspersky Industrial CyberSecurity for Networks.
The Kaspersky Industrial CyberSecurity for Networks integration by tenant window opens.
Select or create a tenant for which you want to create an integration with KICS for Networks.
The Kaspersky Industrial CyberSecurity for Networks integration window opens.
Click the Communication data package field and select the communication data package that was created in KICS for Networks.
In the Communication data package password field, enter the password of the communication data package.
Select the Enable response check box if you want to change the statuses of KICS for Networks assets by using KUMA response rules.
Click Save.

Integration with KICS for Networks is configured in KUMA, and the window shows the IP address of the node where the KICS for Networks connector will be running and its ID.

Page top

[Topic 233717]

Enabling and disabling integration with KICS for Networks

To enable or disable KICS for Networks integration for a tenant:

In the KUMA web interface, open Settings → Kaspersky Industrial CyberSecurity for Networks and select the tenant for which you want to enable or disable KICS for Networks integration.
The Kaspersky Industrial CyberSecurity for Networks integration window opens.
Select or clear the Disabled check box.
Click Save.

Page top

[Topic 233718]

Changing the data update frequency

KUMA queries KICS for Networks to update its asset information. This occurs:

Immediately after creating a new integration.
Immediately after changing the settings of an existing integration.
According to a regular schedule every several hours. This occurs every 3 hours by default.
Whenever a user creates a task for updating asset data.

When querying KICS for Networks, a task is created in the Task manager section of the KUMA web interface.

To edit the schedule for importing information about KICS for Networks assets:

In the KUMA web interface, open Settings → Kaspersky Industrial CyberSecurity for Networks.
Select the relevant tenant.
The Kaspersky Industrial CyberSecurity for Networks integration window opens.
In the Data refresh interval field, specify the required frequency in hours. The default value is 3.

The import schedule has been changed.

Page top

[Topic 233699]

Special considerations when importing asset information from KICS for Networks

Importing assets

Assets are imported according to the asset import rules. Only assets with the Authorized and Unauthorized statuses are imported.

KICS for Networks assets are identified by a combination of the following parameters:

IP address of the KICS for Networks instance with which the integration is configured.
KICS for Networks connector ID is used to configure the integration.
ID assigned to the asset (or "device") in the KICS for Networks instance.

Importing vulnerability information

When importing assets, KUMA also receives information about active vulnerabilities in KICS for Networks. If a vulnerability has been flagged as Remediated or Negligible in KICS for Networks, the information about this vulnerability is deleted from KUMA during the next import.

Information about asset vulnerabilities is displayed in the localization language of KICS for Networks in the Asset details window in the Vulnerabilities settings block.

In KICS for Networks, vulnerabilities are referred to as risks and are divided into several types. All types of risks are imported into KUMA.

Imported data storage period

If information about a previously imported asset is no longer received from KICS for Networks, the asset is deleted after 30 days.

Page top

[Topic 233750]

Changing the status of a KICS for Networks asset

After configuring integration, you can change the statuses of KICS for Networks assets from KUMA. Statuses can be changed either automatically or manually.

Asset statuses can be changed only if you enabled a response in the settings for connecting to KICS for Networks.

Manually changing the status of a KICS for Networks asset

Users with the General Administrator, Administrator, and Analyst roles in the tenants available to them can manually change the statuses of assets imported from KICS for Networks.

To manually change a KICS for Networks asset status:

In the Assets section of the KUMA web interface, click the asset that you want to edit.
The Asset details area opens in the right part of the window.
In the Status in KICS for Networks drop-down list, select the status that you need to assign to the KICS for Networks asset. The Authorized or Unauthorized statuses are available.

The asset status is changed. The new status is displayed in KICS for Networks and in KUMA.

Automatically changing the status of a KICS for Networks asset

Automatic changes to the statuses of KICS for Networks assets are implemented using response rules. The rules must be added to the correlator, which will determine the conditions for triggering these rules.

Page top

[Topic 242818]

Kaspersky Automated Security Awareness Platform

Kaspersky Automated Security Awareness Platform (hereinafter also referred to as "ASAP") is an online learning platform that allows users to learn the rules of information security and threats related to it in their daily work, as well as to practice using real examples.

ASAP can be integrated with KUMA. After configuring integration, you can perform the following tasks in KUMA:

Change user learning groups.
View information about the courses taken by the users and the certificates they received.

Integration between ASAP and KUMA includes configuring API connection to ASAP. The process takes place in both solutions:

In ASAP, create an authorization token and obtain an address for API requests.
In KUMA, specify the address for API requests in ASAP, add an authorization token for API requests, and specify the email address of the ASAP administrator to receive notifications.

In this section

Creating a token in ASAP and getting a link for API requests

Viewing information about the users from ASAP and changing learning groups

Page top

[Topic 242820]

Creating a token in ASAP and getting a link for API requests

In order to be authorized, the API requests from KUMA to ASAP must be signed by a token created in ASAP. Only the company administrators can create tokens.

Creating a token

To create a token:

Sign in to the ASAP web interface.
In the Control panel section, click the Import and synchronization button, and then open the Open API tab.
Click the New token button and select the API methods used for integration in the window that opens:
- GET /openapi/v1/groups
- POST /openapi/v1/report
- PATCH /openapi/v1/user/:userid
Click the Generate token button.
Copy the token and save it in any convenient way. This token is required to configure integration in KUMA.

The token is not stored in the ASAP system in the open form. After you close the Get token window, the token is unavailable for viewing. If you close the window without copying the token, you will need to click the New token button again for the system to generate a new token.

The issued token is valid for 12 months. After this period, the token is revoked. The issued token is also revoked if it is not used for 6 months.

Getting a link for API requests

To get the link used in ASAP for API requests:

Sign in to the ASAP web interface.
In the Control panel section, click the Import and synchronization button, and then open the Open API tab.
A link for accessing ASAP using the Open API is located at the bottom part of the window. Copy the link and save it in any convenient way. This link is required to configure integration in KUMA.

Page top

[Topic 242823]

Configuring integration in KUMA

To configure KUMA integration with ASAP:

Open the KUMA web interface and select Settings → Kaspersky Automated Security Awareness Platform.
The Kaspersky Automated Security Awareness Platform window opens.
In the Secret field click the button to create a secret of the token by entering the token received from ASAP:
1. In the Name field, enter the name of the secret. Must contain 1 to 128 Unicode characters.
2. In the Token field, enter the authorization token for API requests to ASAP.
3. If necessary, add the secret description in the Description field.
4. Click Save.
In the ASAP Open API URL field, specify the address used by ASAP for API requests.
In the ASAP administrator email field, specify the email address of the ASAP administrator who receives notifications when users are added to the learning groups using KUMA.
If necessary, in the Proxy drop-down list select the proxy server resource to be used to connect to ASAP.
To disable or enable integration with ASAP, select or clear the Disabled check box.
Click Save.

Integration with ASAP is configured in KUMA. When viewing information about alerts and incidents, you can select associated users to view which learning courses they have taken and to change their learning group.

Page top

[Topic 242830]

Viewing information about the users from ASAP and changing learning groups

After configuring the integration between ASAP and KUMA, the following information from ASAP becomes available in alerts and incidents when you view data about associated users:

The learning group to which the user belongs.
The trainings passed by the user.
The planned trainings and the current progress.
The received certificates.

To view data about the user from ASAP:

In the KUMA web interface, in the Alerts or Incidents section, select the required alert or incident.
In the Related users section, click the desired account.
The Account details window opens on the right side of the screen.
Select the ASAP courses details tab.

The window displays information about the user from ASAP.

You can change the learning group of a user in ASAP.

To change a user learning group in ASAP:

In the KUMA web interface, in the Alerts or Incidents section, select the required alert or incident.
In the Related users section, click the desired account.
The Account details window opens on the right side of the screen.
In the Assign ASAP group drop-down list, select the ASAP learning group you want to assign the user to.
Click Apply.

The user is moved to the selected ASAP group, the ASAP company administrator is notified of the change in the learning group, and the study plan is recalculated for the selected learning group.

For details on learning groups and how to get started, refer to the ASAP documentation.

Page top

[Topic 258846]

Sending notifications to Telegram

This integration is an example and may require additional configuration depending on the versions used and the specifics of the infrastructure.
Compatibility is confirmed only for KUMA 2.0 and later.
The terms and conditions of premium technical support do not apply to this integration; support requests are processed without a guaranteed response time.

You can configure sending notifications to Telegram when KUMA correlation rules are triggered. This can reduce the response time to threats and, if necessary, make more persons informed.

Configure Telegram notifications involves the following steps:

Creating and configuring a Telegram bot
A special bot sends notifications about triggered correlation rules. It can send notifications to a private or group Telegram chat.
Creating a script for sending notifications
You must create a script and save it on the server where the correlator is installed.
Configuring notifications in KUMA
Configure a KUMA response rule that starts a script to send notifications and add this rule to the correlator.

In this section

Creating and configuring a Telegram bot

Creating a script for sending notifications

Configuring notifications in KUMA

Page top

[Topic 258850]

Creating and configuring a Telegram bot

To create and configure a Telegram bot:

In the Telegram application, find the BotFather bot and open a chat with it.
In the chat, click Start.
Create a new bot using the following command:
/newbot
Enter the name of the bot.
Enter the login name of the bot.
The bot is created. You receive a link to the chat that looks like t.me/<bot login> and a token for contacting the bot.
If you want to use the bot in a group chat, and not in private messages, edit privacy settings:
1. In the BotFather chat, enter the command:
  /mybots
2. Select the relevant bot from the list.
3. Click Bot Settings → Group Privacy and select Turn off.
  The bot can now send messages to group chats.
To open a chat with the bot you created, use the t.me/<botlogin> link that you obtained at step 5, and click Start.
If you want the bot to send private messages to the user:
1. In the chat with the bot, send any message.
2. Follow the https://t.me/getmyid_bot link and click Start.
3. The response contains the Current chat ID. You need this value to configure the sending of messages.
If you want the bot to send messages to the group chat:
1. Add https://t.me/getmyid_bot to the group chat for receiving notifications from KUMA.
  The bot sends a message to the group chat, the message contains the Current chat ID value. You need this value to configure the sending of messages.
2. Remove the bot from the group.
Send a test message through the bot. To do so, paste the following link into the address bar of your browser:
https://api.telegram.org/bot<token>/sendMessage?chat_id=<chat_id>&text=test

where <token> is the value obtained at step 5, and <chat_id> is the value obtained at step 8 or 9.

As a result, a test message should appear in the personal or group chat, and the JSON in the browser response should be free of errors.

Page top

[Topic 258851]

Creating a script for sending notifications

To create a script:

In the console of the server on which the correlator is installed, create a script file and add the following lines to it:
#!/bin/bash

set -eu

CHAT_ID=<Current chat ID value obtained at step 8 or 9 of the Telegram bot setup instructions>

TG_TOKEN=<token value obtained at step 5 of the Telegram bot setup instructions>

RULE=$1

TEXT="<b>$RULE</b> rule triggered."

curl --data-urlencode "chat_id=$CHAT_ID" --data-urlencode "text=$TEXT" --data-urlencode "parse_mode=HTML" https://api.telegram.org/bot$TG_TOKEN/sendMessage

If the correlator server does not have Internet access, you can use a proxy server:

#!/bin/bash

set -eu

CHAT_ID=<Current chat ID value obtained at step 8 or 9 of the Telegram bot setup instructions>

TG_TOKEN=<token value obtained at step 5 of the Telegram bot setup instructions>

RULE=$1

TEXT="<b>$RULE</b> rule triggered."

PROXY=<address and port of the proxy server>

curl --proxy $PROXY --data-urlencode "chat_id=$CHAT_ID" --data-urlencode "text=$TEXT" --data-urlencode "parse_mode=HTML" https://api.telegram.org/bot$TG_TOKEN/sendMessage
Save the script to the correlator directory at /opt/kaspersky/kuma/correlator/<ID of the correlator that must respond to events>/scripts/.
For information about obtaining the correlator ID, see the Getting service identifier section.
Make the 'kuma' user the owner of the file and grant execution rights:
chown kuma:kuma /opt/kaspersky/kuma/correlator/<ID of the correlator that must respond>/scripts/<script name>.sh

chmod +x /opt/kaspersky/kuma/correlator/<ID of the correlator that must respond>/scripts/<script name>.sh

Page top

[Topic 258852]

Configuring sending notifications in KUMA

To configure the sending of KUMA notifications to Telegram:

Create a response rule:
1. In the KUMA web interface, select the Resources → Response rules section and click Add response rule.
2. This opens the Create response rule window; in that window, in the Name field, enter the name of the rule.
3. In the Tenant drop-down list, select the tenant that owns the resource.
4. In the Type drop-down list, select Run script.
5. In the Script name field, enter the name of the script.
6. In the Script arguments field, enter {{.Name}}.
  This passes the name of the correlation event as the argument of the script.
7. Click Save.
Add the response rule to the correlator:
1. In the Resources → Correlators section, select the correlator in whose folder you placed the created script for sending notifications.
2. In the steps tree, select Response rules.
3. Click Add.
4. In the Response rule drop-down list, select the rule added at step 1 of these instructions.
5. In the steps tree, select Setup validation.
6. Click the Save and restart services button.
7. Click the Save button.

Sending notifications about triggered KUMA rules to Telegram is configured.

See also:

Response rules for a custom script

Page top

[Topic 259114]

UserGate integration

This integration is an example and may require additional configuration depending on the versions used and the specifics of the infrastructure.
Compatibility is confirmed only for KUMA 2.0 or later and UserGate 6.0 or later.
The terms and conditions of premium technical support do not apply to this integration; support requests are processed without a guaranteed response time.

UserGate is a network infrastructure security solution that protects personal information from the risks of external intrusions, unauthorized access, viruses, and malware.

Integration with UserGate allows automatically blocking threats by IP address, URL, or domain name whenever KUMA response rules are triggered.

Configuring the integration involves the following steps:

Configuring integration in UserGate
Preparing a script for the response rule
Configuring the KUMA response rule

In this section

Configuring integration in UserGate

Preparing a script for integration with UserGate

Configuring a response rule for integration with UserGate

Page top

[Topic 259137]

Configuring integration in UserGate

To configure integration in UserGate:

Connect to the UserGate web interface under an administrator account.
Go to UserGate → Administrators → Administrator profiles, and click Add.
In the Profile settings window, specify the profile name, for example, API .
On the API Permissions tab, add read and write permissions for the following objects:
- content
- core
- firewall
- nlists
Click Save.
In the UserGate → Administrators section, click Add → Add local administrator.
In the Administrator properties window, specify the login and password of the administrator.
In the Administrator profile field, select the profile created at step 3.
Click Save.
In the address bar of your browser, after the address and port of UserGate, add ?features=zone-xml-rpc and press ENTER.
Go to the Network → Zones section and for the zone of the interface that you want to use for API interaction, go to the Access Control tab and select the check box next to the XML-RPC for management service.
If necessary, you can add the IP address of the KUMA correlator whose correlation rules must trigger blocking in UserGate, to the list of allowed addresses.
Click Save.

Page top

[Topic 259221]

Preparing a script for integration with UserGate

To prepare a script for use:

Copy the ID of the correlator whose correlation rules you want to trigger blocking of URL, IP address, or domain name in UserGate:
1. In the KUMA web interface, go to the Resources → Active services.
2. Select the check box next to the correlator whose ID you want to obtain, and click Copy ID.
  The correlator ID is copied to the clipboard.
Download the script:
https://box.kaspersky.com/d/2dfd1d677c7547a7ac1e/
Open the script file and in the Enter UserGate Parameters section, in the login and password parameters, specify the credentials of the UserGate administrator account that was created at step 7 of configuring the integration in UserGate.
Place the downloaded script on the KUMA correlator server at the following path: /opt/kaspersky/kuma/correlator/<correlator ID from step 1>/scripts/.
Connect to the correlator server via SSH and go to the path from step 4:
cd /opt/kaspersky/kuma/correlator/<correlator ID from step 1>/scripts/
Run the following command:
chmod +x ug.py && chown kuma:kuma ug.py

The script is ready to use.

Page top

[Topic 259222]

Configuring a response rule for integration with UserGate

To configure a response rule:

Create a response rule:
1. In the KUMA web interface, select the Resources → Response rules section and click Add response rule.
2. This opens the Create response rule window; in that window, in the Name field, enter the name of the rule.
3. In the Tenant drop-down list, select the tenant that owns the resource.
4. In the Type drop-down list, select Run script.
5. In the Script name field, enter the name of the script. ug.py.
6. In the Script arguments field, specify:
  - one of the operations depending on the type of the object being blocked:
    - blockurl to block access by URL
    - blockip to block access by IP address
    - blockdomain to block access by domain name
  - -i {{<KUMA field from which the value of the blocked object must be taken, depending on the operation>}}
    
    Example:
    
    blockurl -i {{.RequetstUrl}}
7. In the Conditions section, add conditions corresponding to correlation rules that require blocking in UserGate when triggered.
8. Click Save.
Add the response rule to the correlator:
1. In the Resources → Correlators section, select the correlator that must respond and in whose directory you placed the script.
2. In the steps tree, select Response rules.
3. Click Add.
4. In the Response rule drop-down list, select the rule added at step 1 of these instructions.
5. In the steps tree, select Setup validation.
6. Click Save and reload services.
7. Click the Save button.

The response rule is linked to the correlator and ready to use.

Page top

[Topic 259321]

Integration with Kaspersky Web Traffic Security

This integration is an example and may require additional configuration depending on the versions used and the specifics of the infrastructure.
Compatibility is confirmed only for KUMA 2.0 or later and Kaspersky Web Traffic Security 6.0 or later.
The terms and conditions of premium technical support do not apply to this integration; support requests are processed without a guaranteed response time.

You can configure integration with the Kaspersky Web Traffic Security web traffic analysis and filtering system (hereinafter also referred to as "KWTS").

Configuring the integration involves creating KUMA response rules that allow running KWTS tasks. Tasks must be created in advance in the KWTS web interface.

Configuring the integration involves the following steps:

Configuring integration in KWTS
Preparing a script for the response rule
Configuring the KUMA response rule

In this section

Configuring integration in KWTS

Preparing a script for integration with KWTS

Configuring a response rule for integration with KWTS

Page top

[Topic 259340]

Configuring integration in KWTS

To prepare the integration in KWTS:

Connect to the KWTS web interface under an administrator account and create a role with permissions to view and create/edit a rule.
For more details on creating a role, see the Kaspersky Web Traffic Security Help.
Assign the created role to a user with NTML authentication.
You can use a local administrator account instead.
In the Rules section, go to the Access tab and click Add rule.
In the Action drop-down list, select Block.
In the Traffic filtering drop-down list, select the URL value, and in the field on the right, enter a nonexistent or known malicious address.
In the Name field, enter the name of the rule.
Enable the rule using the Status toggle switch.
Click Add.
In the KWTS web interface, open the rule you just created.
Make a note of the ID value that is displayed at the end of the page address in the browser address bar.
You must use this value when configuring the response rule in KUMA.

The integration is prepared on the KWTS side.

Page top

[Topic 259341]

Preparing a script for integration with KWTS

To prepare a script for use:

Copy the ID of the correlator whose correlation rules you want to trigger blocking of URL, IP address, or domain name in KWTS:
1. In the KUMA web interface, go to the Resources → Active services.
2. Select the check box next to the correlator whose ID you want to obtain, and click Copy ID.
  The correlator ID is copied to the clipboard.
Download the script and library:
https://box.kaspersky.com/d/2dfd1d677c7547a7ac1e/
Place the downloaded script on the KUMA correlator server at the following path: /opt/kaspersky/kuma/correlator/<correlator ID from step 1>/scripts/.
Connect to the correlator server via SSH and go to the path from step 3:
cd /opt/kaspersky/kuma/correlator/<correlator ID from step 1>/scripts/
Run the following command:
chmod +x kwts.py kwtsWebApiV6.py && chown kuma:kuma kwts.py kwtsWebApiV6.py

The script is ready to use.

Page top

[Topic 259342]

Configuring a response rule for integration with KWTS

To configure a response rule:

Create a response rule:
1. In the KUMA web interface, select the Resources → Response rules section and click Add response rule.
2. This opens the Create response rule window; in that window, in the Name field, enter the name of the rule.
3. In the Tenant drop-down list, select the tenant that owns the resource.
4. In the Type drop-down list, select Run script.
5. In the Script name field, enter the name of the script, kwts.py.
6. In the Script arguments field, specify:
  - --host — address of the KWTS server.
  - --username — name of the user account created in KWTS or local administrator.
  - --password — KWTS user account password.
  - --rule_id — ID of the rule created in KWTS.
  - Specify one of the options depending on the type of the object being blocked:
    - --url — specify the field of the KUMA event from which you want to obtain the URL, for example, {{.RequestUrl}}.
    - --ip — specify the field of the KUMA event from which you want to obtain the IP address, for example, {{.DestinationAddress}}.
    - --domain — specify the field of the KUMA event from which you want to obtain the domain name, for example, {{.DestinationHostName}}.
  - --ntlm — specify this option if the KWTS user was created with NTLM authentication.
    
    Example:
    
    --host <address> --username <user> --password <pass> --rule_id <id> --url {{.RequestUrl}}
7. In the Conditions section, add conditions corresponding to correlation rules that require blocking in KWTS when triggered.
8. Click Save.
Add the response rule to the correlator:
1. In the Resources → Correlators section, select the correlator that must respond and in whose directory you placed the script.
2. In the steps tree, select Response rules.
3. Click Add.
4. In the Response rule drop-down list, select the rule added at step 1 of these instructions.
5. In the steps tree, select Setup validation.
6. Click Save and reload services.
7. Click the Save button.

The response rule is linked to the correlator and ready to use.

Page top

[Topic 259353]

Integration with Kaspersky Secure Mail Gateway

This integration is an example and may require additional configuration depending on the versions used and the specifics of the infrastructure.
Compatibility is confirmed only for KUMA 2.0 or later and Kaspersky Secure Mail Gateway 2.0 or later.
The terms and conditions of premium technical support do not apply to this integration; support requests are processed without a guaranteed response time.

You can configure integration with the Kaspersky Secure Mail Gateway mail traffic analysis and filtering system (hereinafter also referred to as "KSMG").

Configuring the integration involves creating KUMA response rules that allow running KSMG tasks. Tasks must be created in advance in the KSMG web interface.

Configuring the integration involves the following steps:

Configuring integration in KSMG
Preparing a script for the response rule
Configuring the KUMA response rule

In this section

Configuring integration in KSMG

Preparing a script for integration with KSMG

Configuring a response rule for integration with KSMG

Page top

[Topic 259354]

Configuring integration in KSMG

To prepare the integration in KSMG:

Connect to the KSMG web interface under an administrator account and create a role with permissions to view and create/edit a rule.
For more details on creating a role, see the Kaspersky Secure Mail Gateway Help.
Assign the created role to a user with NTML authentication.
You can use the 'Administrator' local administrator account.
In the Rules section, click Create.
In the left pane, select the General section.
Enable the rule using the Status toggle switch.
In the Rule name field, enter the name of the new rule.
Under Mode, select one of the message processing options that meets the criteria of this rule.
Under Sender on the Email addresses tab, enter a nonexistent or known malicious sender address.
Under Recipient on the Email addresses tab, specify the relevant recipients or the "*" character to select all recipients.
Click the Save button.
In the KSMG web interface, open the rule you just created.
Make a note of the ID value that is displayed at the end of the page address in the browser address bar.
You must use this value when configuring the response rule in KUMA.

The integration is prepared on the KSMG side.

Page top

[Topic 259355]

Preparing a script for integration with KSMG

To prepare a script for use:

Copy the ID of the correlator whose correlation rules must trigger the blocking of the IP address or email address of the message sender in KSMG:
1. In the KUMA web interface, go to the Resources → Active services.
2. Select the check box next to the correlator whose ID you want to obtain, and click Copy ID.
  The correlator ID is copied to the clipboard.
Download the script and library:
https://box.kaspersky.com/d/2dfd1d677c7547a7ac1e/
Place the downloaded script on the KUMA correlator server at the following path: /opt/kaspersky/kuma/correlator/<correlator ID from step 1>/scripts/.
Connect to the correlator server via SSH and go to the path from step 3:
cd /opt/kaspersky/kuma/correlator/<correlator ID from step 1>/scripts/
Run the following command:
chmod +x ksmg.py ksmgWebApiV2.py && chown kuma:kuma ksmg.py ksmgWebApiV2.py

The script is ready to use.

Page top

[Topic 259356]

Configuring a response rule for integration with KSMG

To configure a response rule:

Create a response rule:
1. In the KUMA web interface, select the Resources → Response rules section and click Add response rule.
2. This opens the Create response rule window; in that window, in the Name field, enter the name of the rule.
3. In the Tenant drop-down list, select the tenant that owns the resource.
4. In the Type drop-down list, select Run script.
5. In the Script name field, enter the name of the script, ksmg.py.
6. In the Script arguments field, specify:
  - --host — address of the KSMG server.
  - --username — name of the user account created in KSMG.
    You can specify the Administrator account.
  - --password — KSMG user account password.
  - --rule_id — ID of the rule created in KSMG.
  - Specify one of the options depending on the type of the object being blocked:
    - --email — specify the field of the KUMA event from which you want to obtain the URL, for example, {{.SourceUserName}}.
    - --ip — specify the field of the KUMA event from which you want to obtain the IP address, for example, {{.SourceAddress}}.
  - --ntlm — specify this option if the KSMG user was created with NTLM authentication.
    
    Example:
    
    --host <address> --username <user> --password <pass> --ntlm --rule_id <id> --email {{.SourceUserName}}
7. In the Conditions section, add conditions corresponding to the correlation rules that when triggered require blocking the IP address or email address of the message sender in KSMG.
8. Click Save.
Add the response rule to the correlator:
1. In the Resources → Correlators section, select the correlator that must respond and in whose directory you placed the script.
2. In the steps tree, select Response rules.
3. Click Add.
4. In the Response rule drop-down list, select the rule added at step 1 of these instructions.
5. In the steps tree, select Setup validation.
6. Click Save and reload services.
7. Click the Save button.

The response rule is linked to the correlator and ready to use.

Page top

[Topic 259370]

Importing asset information from RedCheck

This integration is an example and may require additional configuration depending on the versions used and the specifics of the infrastructure.
Compatibility is confirmed only for KUMA 2.0 or later and RedCheck 2.6.8 or later.
The terms and conditions of premium technical support do not apply to this integration; support requests are processed without a guaranteed response time.

RedCheck is a system for monitoring and managing the information security of an organization.

You can import asset information from RedCheck network device scan reports into KUMA.

Import is available from simple "Vulnerabilities" and "Inventory" reports in CSV format, grouped by hosts.

Imported assets are displayed in the KUMA web interface in the Assets section. If necessary, you can edit the settings of assets.

Data is imported through the API using the redcheck-tool.py utility. The utility requires Python 3.6 or later and the following libraries:

csv
re
json
requests
argparse
sys

To import asset information from a RedCheck report:

Generate a network asset scan report in RedCheck in CSV format and copy the report file to the server where the script is located.
For more details about scan tasks and output file formats, refer to the RedCheck documentation.
Create a file with the token for accessing the KUMA REST API.
The account for which the token is created must satisfy the following requirements:
- Administrator or Analyst role.
- Access to the tenant into which the assets will be imported.
- Rights to use API requests: GET /assets, GET /tenants, POST/assets/import.
Download the script:
https://box.kaspersky.com/d/2dfd1d677c7547a7ac1e/
Copy the redcheck-tool.py tool to the server hosting the KUMA Core and make the tool's file executable:
chmod +x <path to the redcheck-tool.py file>
Run the redcheck-tool.py utility:
python3 redcheck-tool.py --kuma-rest <address and port of the KUMA REST API server> --token <API token> --tenant <name of the tenant in which the assets must be placed> --vuln-report <full path to the "Vulnerabilities" report file> --inventory-report <full path to the "Inventory" report file>

Example:

python3 --kuma-rest example.kuma.com:7223 --token 949fc03d97bad5d04b6e231c68be54fb --tenant Main --vuln-report /home/user/vuln.csv --inventory-report /home/user/inventory.csv

You can use additional flags and commands for import operations. For example, the -v command displays an extended report on the received assets. A detailed description of the available flags and commands is provided in the "Flags and commands of redcheck-tool.py" table. You can also use the --help command to view information on the available flags and commands.

The asset information is imported from the RedCheck report to KUMA. The console displays information on the number of new and updated assets.

Example:

inventory has been imported for 2 host(s)

software has been imported for 5 host(s)

vulnerabilities has been imported for 4 host(s)

Example of extended import information:

[inventory import] Host: localhost Code: 200 Response: {'insertedIDs': {'0': '52ca11c6-a0e6-4dfd-8ef9-bf58189340f8'}, 'updatedCount': 0, 'errors': []}

[inventory import] Host: 10.0.0.2 Code: 200 Response: {'insertedIDs': {'0': '1583e552-5137-4164-92e0-01e60fb6edb0'}, 'updatedCount': 0, 'errors': []}

[software import][error] Host: localhost Skipped asset with FQDN localhost or IP 127.0.0.1

[software import] Host: 10.0.0.2 Code: 200 Response: {'insertedIDs': {}, 'updatedCount': 1, 'errors': []}

[vulnerabilities import] Host: 10.0.0.2 Code: 200 Response: {'insertedIDs': {}, 'updatedCount': 1, 'errors': []}

[vulnerabilities import] Host: 10.0.0.1 Code: 200 Response: {'insertedIDs': {'0': '0628f683-c20c-4107-abf3-d837b3dbbf01'}, 'updatedCount': 0, 'errors': []}

[vulnerabilities import] Host: localhost Code: 200 Response: {'insertedIDs': {}, 'updatedCount': 1, 'errors': []}

[vulnerabilities import] Host: 10.0.0.3 Code: 200 Response: {'insertedIDs': {'0': 'ed01e0a8-dcb0-4609-ab2b-91e50092555d'}, 'updatedCount': 0, 'errors': []}

inventory has been imported for 2 host(s)

software has been imported for 1 host(s)

vulnerabilities has been imported for 4 host(s)

The tool works as follows when importing assets:

KUMA overwrites the data of assets imported through the API, and deletes information about their resolved vulnerabilities.

KUMA skips assets with invalid data.

Flags and commands of redcheck-tool.py

Flags and commands	Mandatory	Description
`--kuma-rest <address and port of the KUMA server>`	Yes	Port 7223 is used for API requests by default. You can change the port if necessary.
`--token <token>`	Yes	The value of the option must contain only the token. The Administrator or Analyst role must be assigned to the user account for which the API token is being generated.
`--tenant <tenant name>`	Yes	Name of the KUMA tenant in which the assets from the RedCheck report will be imported.
`--vuln-report <full path to the "Vulnerabilities" report>`	Yes	"Vulnerabilities" report file in CSV format.
`--inventory-report <full path to the "Inventory" report file>`	No	"Inventory" report file in CSV format.
`-v`	No	Display extended information about the import of assets.

Possible errors

Error message	Description
Tenant %w not found	The tenant name was not found.
Tenant search error: Unexpected status Code: %d	An unexpected HTTP response code was received while searching for the tenant.
Asset search error: Unexpected status Code: %d	An unexpected HTTP response code was received while searching for an asset.
[%w import][error] Host: %w Skipped asset with FQDNlocalhost or IP 127.0.0.1	When importing inventory/vulnerabilities information, host cfqdn=localhost or ip=127.0.0.1 was skipped.

Page top

[Topic 217934]

Managing KUMA

This section describes KUMA general settings.

In this Help topic

Logging in to the program web interface

Viewing KUMA metrics

Managing KUMA tasks

Proxies

Connecting to an SMTP server

Working with Kaspersky Security Center tasks

KUMA logs

KUMA notifications

Page top

[Topic 218007]

Logging in to the program web interface

To log in to the program web interface:

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.
Enter the login of your account in the Login field.
Enter the password for the specified account in the Password field.
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.

Page top

[Topic 218035]

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. If the Metrics section shows core: <port number>, this means that KUMA is deployed in a fault-tolerant 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.

To determine on which host the Core is running, run the following command in the terminal of one of the controllers:

k0s kubectl get pod -n kuma -o wide

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 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:

Log in to the OS of the server where the KUMA Core is installed.
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.
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.

Page top

[Topic 234574]

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.

In this Help topic

Viewing the tasks table

Configuring the display of the tasks table

Viewing task run results

Restarting a task

Page top

[Topic 218036]

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

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.

Page top

[Topic 234604]

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:

In the KUMA web interface, select the Task manager section.
The tasks table is displayed.
In the table header, click the button.
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.
If you want to reset the settings, click the Default link.
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.

Page top

[Topic 234598]

Viewing task run results

To view the results of a task:

In the KUMA web interface, select the Task manager section.
The tasks table is displayed.
Click the link containing the task type in the Task column.
A list of the operations available for this task type will be displayed.
Select Show results.

The task results window opens.

Page top

[Topic 234601]

Restarting a task

To restart a task:

In the KUMA web interface, select the Task manager section.
The tasks table is displayed.
Click the link containing the task type in the Task column.
A list of the operations available for this task type will be displayed.
Select Restart.

The task will be restarted.

Page top

[Topic 217960]

Proxies

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

Available settings:

Name (required)—unique name of the proxy server. Must contain 1 to 128 Unicode characters.
Tenant (required)—name of the tenant that owns the resource.
Use URL from the secret (required)—drop-down list to select a secret resource that stores URLs of proxy servers. If required, a secret can be created in the proxy server creation window by using the button. The selected secret can be changed by clicking on the button.
Do not use for domains—one or more domains that require direct access.
Description—up to 4,000 Unicode characters.

Page top

[Topic 217936]

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:

Open the KUMA web interface and select Settings → General.
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
  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.
  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.
Click Save.

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

Page top

[Topic 218045]

Working with Kaspersky Security Center tasks

You can connect Kaspersky Security Center assets to KUMA and download database and application module updates to these assets, or run an anti-virus scan on them by using Kaspersky Security Center tasks. Tasks are started in the KUMA web interface.

To run Kaspersky Security Center tasks on assets connected to KUMA, it is recommended to use the following script:

Creating a user account in the Kaspersky Security Center Administration Console
The credentials of this account are used when creating a secret to establish a connection with Kaspersky Security Center, 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 Kaspersky Security Center Help Guide.
Creating KUMA tasks in Kaspersky Security Center
Configuring KUMA integration with Kaspersky Security Center
Importing asset information from Kaspersky Security Center into KUMA
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.
Running tasks on assets
You can manually start tasks in the asset information or configure tasks to start automatically.

In this section

Creating KUMA tasks in Kaspersky Security Center

Starting Kaspersky Security Center tasks manually

Starting Kaspersky Security Center tasks automatically

Checking the status of Kaspersky Security Center tasks

Page top

[Topic 240903]

Creating KUMA tasks in Kaspersky Security Center

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

For more 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 Guide.

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

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 web interface.

Page top

[Topic 218009]

Starting Kaspersky Security Center tasks manually

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

First, you need to configure the integration of Kaspersky Security Center with KUMA and create tasks in Kaspersky Security Center.

To manually start a Kaspersky Security Center task:

In the Assets section of the KUMA web interface, select the asset that was imported from Kaspersky Security Center.
The Asset details window opens.
Click the KSC response button.
This button is displayed if the connection to the Kaspersky Security Center that owns the selected asset is enabled.
In the opened Select task window, select the check boxes next to the tasks that you want to start, and click the Start button.

Kaspersky Security Center 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.

Page top

[Topic 218008]

Starting Kaspersky Security Center tasks automatically

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

First, you need to configure the integration of Kaspersky Security Center with KUMA and create tasks in Kaspersky Security Center.

Configuring automatic start of Kaspersky Security Center tasks includes the following steps:

Step 1. Adding a correlation rule

To add a correlation rule:

In the KUMA web interface, select the Resources section.
Select Correlation rules and click the Add correlation rule button.
On the General tab, define 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.
On the Selectors → Settings tab, do the following:
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 Kaspersky Security Center 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.
On the Actions tab, define 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.
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:

In the KUMA web interface, select the Resources section.
Select Filters and click the Add filter button.
In the Name field, specify the filter name.
In the Tenant drop-down list, select the tenant that owns the resource.
In the Conditions field, click the Add group button.
In the operator field for the group you added, select AND.
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.
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:

In the KUMA web interface, select the Resources section.
Select Response rules and click the Add response rule button.
In the Name field, define the rule name.
In the Tenant drop-down list, select the tenant that owns the resource.
In the Type drop-down list, select Response via KSC.
In the Kaspersky Security Center task drop-down list, select the Kaspersky Security Center task you want to start.
In the Event field drop-down list, select the DestinationAssetID.
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 Kaspersky Security Center, you must ensure that Kaspersky Security Center is available over the UDP protocol.

If a response rule is owned by the shared tenant, the displayed Kaspersky Security Center tasks that are available for selection are from the Kaspersky Security Center server that the main tenant is connected to.

If a response rule has a selected task that is absent from the Kaspersky Security Center 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:

In the KUMA web interface, select the Resources section.
Select Correlators.
In the list of correlators, select the correlator added at Step 2 of this instruction.
In the steps tree, select Response rules.
Click Add.
In the Response rule drop-down list, select the rule added at step 4 of these instructions.
In the steps tree, select Setup validation.
Click the Save and restart services button.
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 Kaspersky Security Center assets connected to KUMA. The tasks are started when a threat is detected on the assets and KUMA receives the corresponding events.

Page top

[Topic 217753]

Checking the status of Kaspersky Security Center tasks

In the KUMA web interface, you can check whether a Kaspersky Security Center task was started or whether a search for events owned by the collector listening for Kaspersky Security Center events was completed.

To check the status of Kaspersky Security Center tasks:

In KUMA, select Resources → Active services.
Select the collector that is configured to receive events from the Kaspersky Security Center server and click the Go to Events button.

A new browser tab will open in the Events section of KUMA. The table displays events from the Kaspersky Security Center server. The status of the tasks can be seen in the Name column.

Kaspersky Security Center 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 Kaspersky Security Center. 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.

Page top

[Topic 217686]

KUMA 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 log is updated for 30 days or until its size reaches 1 GB. After 30 days, the log is archived and new events are written to a new log. Archives are stored in the logs folder. 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. Archives containing logs older than 365 days are also deleted.

Debug mode is available for the following components:

Core

To enable it: in the KUMA web interface, select Settings → General → Core settings → Debug.

Logs are stored in the Core installation directory. For example: /opt/kaspersky/kuma/core/log/core.

If KUMA is installed in a fault-tolerant configuration, please refer to the Viewing Core logs in Kubernetes section.

Services:

Storage
Correlators
Collectors
Agents

To enable it: in the service settings, use the Debug drop-down list or check box.

Storage location: the service installation directory. For example, /opt/kaspersky/kuma/<service name>/log/<service name>. You can download the service logs from the KUMA web interface, in the Resources → Active services section by selecting the desired service and clicking Log.

Logs residing on Linux machines can be viewed by running the journalctl and tail command. For example:

Storage. To return the latest logs from the storage installed on the server, run the following command:
journalctl -f -u kuma-storage-<storage ID>
Correlators. To return the latest logs from correlators installed on the server, run the following command:
journalctl -f -u kuma-correlator-<correlator ID>
Collectors. To return the latest logs from a specific collector installed on the server, run the following command:
journalctl -f -u kuma-collector-<collector ID>
Agents. To return the latest logs from an agent installed on the server, run the following command:
tail -f /opt/kaspersky/agent/<Agent ID>/log/agent

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. Agent logs on Windows machines can be viewed in the file located at the path %PROGRAMDATA%\Kaspersky Lab\KUMA\<Agent ID>\agent.log. Logs of Agents on Linux machines are stored in the agent installation directory.

Resources:

Connectors
Destinations
Enrichment rules

To enable it: in the settings of the service linked to the resource, use the Debug drop-down list or check box.

The logs are stored on the machine hosting the installed service that uses the relevant resource. Detailed data for resources can be viewed in the log of the service linked to a resource.

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

Page top

[Topic 233516]

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

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.

Page top

[Topic 229568]

Working in hierarchy mode

When multiple KUMA instances are deployed in various organizations, they may be merged into a hierarchical structure. Interaction between parent and child instances of KUMA (or nodes) provides the following capabilities:

Child KUMA nodes relay data on other descendant nodes to parent KUMA nodes. This enables the parent node to see its entire branch of the hierarchical tree.
Parent KUMA nodes receive data on incidents from descendant nodes, and can also receive data on incident-related alerts and events if the corresponding settings are enabled in a child node.
Child KUMA nodes do not receive information about upstream nodes, except information about their parent KUMA node.

Parent and child nodes interact via API. Authentication relies on self-signed certificates, which the administrators of the parent and child organization must exchange over an encrypted channel when they connect to each other.

One parent node can have more than one child node. A child node can be connected to only one parent node. A parent node cannot be a child node of its descendants.

General administrator users can configure hierarchy mode in the KUMA web interface under Settings → Hierarchy:

On the Node profile tab, you can configure the profile of your node, create a certificate, and enable or disable hierarchy mode.
On the Structure tab, you can view your available branch of the hierarchical tree, change the connected nodes, or disconnect them.
You can connect parent and child nodes on either of these tabs.

Incidents of child nodes can be viewed by users of all roles in the KUMA web interface under Incidents. In incidents, you can obtain information about their related alerts, events, assets, and users.

In this section

Enabling hierarchy mode for the first time

Creating a node certificate

Connecting nodes into a hierarchical structure

Viewing your own branch of the hierarchy and available nodes

Editing a node profile

Viewing incidents from child nodes

Enabling and disabling hierarchy mode

Page top

[Topic 230727]

Enabling hierarchy mode for the first time

When enabling hierarchy mode for the first time, you must complete the profile of your node.

To complete the profile of your node:

In the KUMA web interface, open Settings → Hierarchy → Node profile.
In the Organization name field, indicate the name of your company (1–128 characters). This name will be used for the name of your node in the hierarchy.
To change the organization name, you will have to regenerate the certificate of your node and replace it on the nodes that you are connected to.
In the FQDN field, specify the FQDN of your node.
If necessary, in the Proxy drop-down list, select the proxy server that must be used to communicate with other nodes. You can create a proxy server by using the button. The selected proxy server can be changed by clicking the button.
The user account credentials entered into the proxy server URL can contain only the following characters: letters of the English alphabet, numbers, and special characters ("-", ".", "_", ":", "~", "!", "$", "&", "\", "(", ")", "*", "+", ",", ";", "=", "%", "@"). The URL in the proxy server settings is set using a secret, which you can select from the Use URL from the secret drop-down list.
Click Generate certificate.

The profile of your KUMA node is complete and hierarchy mode is enabled. When hierarchy mode is enabled, a certificate is automatically created for authentication of your node. You can use the SaveButton icon to download the certificate and then forward it to other nodes over an encrypted channel to create a connection between these nodes.

Page top

[Topic 229603]

Creating a node certificate

Nodes in the hierarchy are authenticated using self-signed certificates of the nodes. A certificate contains the name of the organization and its FQDN.

The certificate is created when hierarchy mode is enabled, but you can also recreate a certificate if necessary. The certificate must be recreated whenever you change the name of a node or its FQDN.

To create a node certificate:

In the KUMA web interface, open Settings → Hierarchy → Node profile.
You will see a window containing the settings of your node in the hierarchy.
Click the Generate certificate button.
The certificate creation window opens.
In the FQDN field, specify the FQDN of your node.
In the Organization name field, indicate the name of your company (1–128 characters). This name will be used for the name of your node in the hierarchy.
Close the window by clicking Save.

The node certificate will be created and can be downloaded by clicking the SaveButton icon. Then it can be transferred to other nodes over an encrypted channel to create a connection between these nodes.

Page top

[Topic 229596]

Connecting nodes into a hierarchical structure

Prior to connecting nodes, you should make sure that they have hierarchy mode enabled, their node profiles have been configured, and certificates have been created for the nodes. Parent and child nodes must exchange their certificates over encrypted communication channels.

Nodes in the hierarchy must be connected in the following order:

Connect the child node to the parent node. You must add the parent node certificate on the Add parent node tab.
Connect the parent node to the child node. You must add the child node certificate on the Add child node tab.

Before you connect the nodes, make sure that the system time on the machines is synchronized with an NTP server. For more details, please refer to the appropriate documentation for Oracle Linux and for Astra Linux Special Edition.

When a connection is established, the parent node polls its child nodes for their available hierarchy data every 5 minutes, and thereby identify the structure of their available branch of the hierarchical tree. This data is displayed in the KUMA web interface under Settings → Hierarchy → Structure after the web page is refreshed.

Information about the hierarchical structure can be manually refreshed by using the Update structure button. To display the updated data, you must refresh the page of your web browser.

In this section

Connecting to a parent node

Connecting a child node

Disconnecting a node

Changing a node

Errors when connecting nodes

Page top

[Topic 229673]

Connecting to a parent node

To connect to a parent node:

In the KUMA web interface, open Settings → Hierarchy and click the Add parent node button.
The Connect to parent node window opens.
Use the Upload certificate button to upload the certificate to KUMA.
The window will display a description of the certificate and indicate the organization that issued it and its FQDN.
If necessary, use the Port field to specify the port used for accessing the parent node.
Click Save.

You are now connected to the parent node. It can now add your node as a child node so that it will receive data on your child nodes and view your incidents.

Page top

[Topic 229674]

Connecting a child node

If you connected a parent node, you will be able to add child nodes only after your parent node adds you as a child node. Prior to connecting a child node, make sure that it has added your node as the parent node.

To connect a child node:

In the KUMA web interface, open Settings → Hierarchy and click the Add child node button.
The Connect to child node window opens.
Use the Upload certificate button to upload the certificate of the child node to KUMA.
The window will display a description of the certificate and indicate the organization that issued it and its FQDN.
If necessary, use the Port field to specify the port used for accessing the child node.
Click Save.

The child node is added and displayed on the Settings → Hierarchy → Structure tab. This tab also displays the descendants of the child node. You can view the incidents of your child nodes and their descendants.

Page top

[Topic 229676]

Disconnecting a node

You can disconnect from a parent node or child node. However, it is impossible to disconnect from nodes that are descendants of your child nodes.

To disconnect from a node:

In the KUMA web interface, open Settings → Hierarchy and select the Structure tab.
The hierarchical structure will be displayed.
Select the node that you want to disconnect from.
The right side of the window will display the details area containing information about this node.
Click Disconnect.

You have disconnected from the node. If you have disconnected from a parent node, it will no longer receive information about your child nodes and incidents. If you have disconnected from a child node, you will no longer receive information about its child nodes and its incidents.

Page top

[Topic 229677]

Changing a node

If the name and/or FQDN of a node has changed, this node must reissue a certificate. Then the procedure for connecting the nodes must be repeated. Outdated nodes must be disconnected.

The port for connecting to nodes can be changed in the details area of the node without reissuing a certificate.

To change the settings for connecting to a node:

In the KUMA web interface, open the Structure tab under Settings → Hierarchy and select the relevant node.
The right side of the window will display the details area of the node.
In the Port field, enter the required port.
Change the settings for email notifications regarding incidents on the child node:
- If you need to disable notifications, clear the Monitoring incidents check box.
- If you need to enable notifications, select the Monitoring incidents check box and use the input field to add the necessary email addresses.
  To send email notifications, you need to configure a connection to the SMTP server.
Click Save.

The node connection settings have been changed.

Page top

[Topic 230313]

Errors when connecting nodes

Errors that occur when connecting nodes may be incompletely displayed in the KUMA web interface. You can use the developer's console of your browser to view the full server report.

The table below lists the errors that may arise when connecting KUMA nodes into a hierarchy, and includes recommendations on resolving those errors.

Errors that occur when establishing a connection to a node are displayed in pop-up windows in the lower part of the screen. Errors in already connected nodes can be viewed in the KUMA web interface under Settings → Hierarchy → Structure. The error text is displayed when you move your mouse cursor over the red triangle icon next to the node that encountered the error.

Error message	Possible cause of the error	Recommended remediation
`failed to exchange settings with child: <Post request for child node address>: connect: connection refused`	Connection refused. There was an attempt to add a child node that did not add the certificate of the parent node.	First connect the parent node on the child node, then add the child node on the parent node. Verify that the hierarchy is enabled on the child node.
`You cannot add your own KUMA node as a parent node or child node.`	You cannot generate a cyclical structure out of KUMA nodes.	Make sure that the hierarchical structure you are creating is a tree structure.
`corrupted certificate`	Invalid certificate.	You must check the certificate file.
`failed to exchange settings with child: <Post request for child node address>: context deadline exceeded`	Connection could not be established due to exceeded response timeout.	Verify that the child node machine is running.
`failed to exchange settings with child: <Post request for child node address>: x509: certificate has expired or is not yet valid`	Connection refused due to invalid certificate.	Make sure that the child node certificate is valid. Make sure that the system time of nodes is synchronized with the NTP server.
`failed to exchange settings with child: <Post request for child node address>: certificate signed by unknown authority (possibly because of "x509: invalid signature: parent certificate cannot sign this kind of certificate" while trying to verify candidate authority certificate "<node name>"`	Connection refused due to invalid certificate.	Make sure that the parent node certificate is valid.
`failed to exchange settings with child: <Post request for child node address>: dial tcp: lookup <child node address> on <IP address of child node>: no such host`	Child node certificate contains a non-existent FQDN.	Make sure that the child node certificate is valid.
`Already exists`	This node already exists within the structure.	Check the hierarchical structure that you are trying to build.
`The parent node is already indicated as a child node.`		Do not connect a parent node that is already a child node within this hierarchy.
`Failed to query branch {"branchID":"<branch ID>","branchName":"<node name>","branchFQDN":"<node FQDN>","error":"Get \"<URL of child node>/children\": remote error: tls: bad certificate"}`	Child node deleted the parent.	The child node must connect the parent node.
`error: <Post request for child node address>: read tcp <IP addresses of nodes>: read: connection reset by peer`	Invalid ports are indicated in node connection settings.	Make sure that the correct port is indicated in the node settings and that a valid certificate is being used.
`"error":"Get \"<Child node URL>/children\": proxyconnect tcp: x509: certificate signed by unknown authority"`	Connecting to a node using wrong proxy server settings.	Make sure correct proxy server settings are used.

Page top

[Topic 229678]

Viewing your own branch of the hierarchy and available nodes

In the KUMA web interface, under Settings → Hierarchy, select the Structure tab to view your branch of the hierarchical tree extending from the parent node to all descendants of its child nodes. Your node in the hierarchy is highlighted in green.

When you click a node of the branch, the right side of the window shows the node details area in which you can do the following:

Change the port for connecting to the parent node or child node.
Disable a parent node or child node.
Change the settings of email notifications regarding incidents for child nodes and their descendants.

Page top

[Topic 229679]

Editing a node profile

You can modify the profile settings of your node.

To change the settings of your node:

In the KUMA web interface, open Settings → Hierarchy → Node profile.
If necessary, in the Proxy drop-down list, select the proxy server that must be used to communicate with other nodes. You can create a proxy server by using the button. The selected proxy server can be changed by clicking the button.
The user account credentials entered into the proxy server URL can contain only the following characters: letters of the English alphabet, numbers, and special characters ("-", ".", "_", ":", "~", "!", "$", "&", "\", "(", ")", "*", "+", ",", ";", "=", "%", "@"). The URL in the proxy server settings is set using a secret, which you can select from the Use URL from the secret drop-down list.
If necessary, use the Port field to enter the port used for accessing your node. Make sure that access to the port is open.
If necessary, use the Timeout field to indicate how many seconds to wait for a response from nodes when attempting a connection. The default value is 60.
If necessary, select or clear the following check boxes: Do not include events to the incidents relayed to parent nodes or Do not include alerts to the incidents relayed to parent nodes. These check boxes are cleared by default.
Click Save.

The settings of your node are changed.

If you want to change the FQDN or name of your node, regenerate a certificate for the node.

Page top

[Topic 229682]

Viewing incidents from child nodes

If hierarchy mode is enabled, you can view the Incidents section to inspect the incidents that were created on child nodes and their descendants. The incidents table displays the Branch column, which can be used to filter incidents based on the nodes in which they were created. By default, the incidents table displays the incidents that were created on your node.

To select the nodes whose incidents you want to view:

In the KUMA web interface, open the Incidents section.
Click the header of the Branch column and click the icon in the opened window.
The right side of the window will display the details area containing the hierarchical structure of the organization. You can use the button to expand or collapse all branches of the structure, or select all KUMA nodes.
Select the relevant nodes and click Save.

The incidents table displays the incidents that were created on the nodes that you selected.

When you click an incident, a window opens with detailed information about the incident. The data is read-only. An incident from another node cannot be edited or processed.

Special considerations when viewing data on an incident created on a different node:

The Related alerts section of the incident window contains information only if the child node is configured to forward data on incident-related alerts to the parent node.
When you click on the name of an incident-related alert, a window opens with detailed information about this alert. This data is also read-only. An alert from another node cannot be edited or processed.
The Related events section in the window of an alert related to an incident of another node contains information only if the child node is configured to forward data on incident-related events to the parent node.
In this case, you can use the Find in events button to open the events table and search for relevant events. However, you cannot select the storage, and there are limitations applied to SQL queries when searching events in alert investigation mode. This mode employs data enrichment (for example, using Kaspersky Threat Intelligence Portal, Kaspersky CyberTrace or Active Directory). The results of Kaspersky Threat Intelligence Portal data enrichment performed on child nodes are not available on parent nodes.

See also:

About incidents

About alerts

Converting geographic data from MaxMind to IP2Location

Interaction with RuCERT

Page top

[Topic 229681]

Enabling and disabling hierarchy mode

To enable or disable hierarchy mode:

In the KUMA web interface, open Settings → Hierarchy → Node profile.
Enable or disable hierarchy mode:
- If you want to enable hierarchy mode, clear the Disabled check box.
- If you want to disable hierarchy mode, select the Disabled check box.
Click Save.

Hierarchy mode will be enabled or disabled according to your selection.

Page top

[Topic 233257]

Working with geographic data

A list of mappings of IP addresses or ranges of IP addresses to geographic data can be uploaded to KUMA for use in event enrichment.

In this section

Geodata format

Importing and exporting geographic data

Default mapping of geographic data

Page top

[Topic 233258]

Geodata format

Geodata can be uploaded to KUMA as a CSV file in UTF-8 encoding. A comma is used as the delimiter. The first line of the file contains the field headers: Network,Country,Region,City,Latitude,Longitude.

CSV file description

Field header name in CSV	Field description	Example
`Network`	IP address in one of the following formats: Single IP address Range of IP addresses IP address in CIDR format. Mixing of IPv4 and IPv6 addresses is allowed. Required field.	`192.168.2.24` `192.168.2.25-192.168.2.35` `131.10.55.70/8` `2001:DB8::0/120`
`Country`	Country designation used by your organization. For example, this could be its name or code. Required field.	`Russia` `RU`
`Region`	Regional designation used by your organization. For example, this could be its name or code.	`Sverdlovsk Oblast` `RU-SVE`
`City`	City designation used by your organization. For example, this could be its name or code.	`Yekaterinburg` `65701000001`
`Latitude`	Latitude of the described location in decimal format. This field can be empty, in which case the value 0 will be used when importing data into KUMA.	`56.835556`
`Longitude`	Longitude of the described location in decimal format. This field can be empty, in which case the value 0 will be used when importing data into KUMA.	`60.612778`

Page top

[Topic 233259]

Converting geographic data from MaxMind to IP2Location

Geographic data obtained from MaxMind and IP2Location can be used in KUMA if the data files are first converted to a format supported by KUMA. Conversion can be done using the script below. Make sure that the files do not contain duplicate records. For example, if a file has few columns, different records may contain data from the same network with the same geodata. Such files cannot be converted. To successfully perform the conversion, make sure that there are no duplicate rows and that every row has at least one unique field.

Download script

Python 2.7 or later is required to run the script.

Script start command:

python converter.py --type <type of geographic data being processed: "maxmind" or "ip2location"> --out <directory where a CSV file containing geographic data in KUMA format will be placed> --input <path to the ZIP archive containing geographic data from MaxMind or IP2location>

When the script is run with the --help flag, help is displayed for the available script parameters: python converter.py --help

Command for converting a file containing a Russian database of IP address ranges from a MaxMind ZIP archive:

python converter.py --type maxmind --lang ru --input MaxMind.zip --out geoip_maxmind_ru.csv

If the --lang parameter is not specified, the script receives information from the GeoLite2-City-Locations-en.csv file from the ZIP archive by default.

Absence of the --lang parameter for MaxMind is equivalent to the following command:

python converter.py --type maxmind --input MaxMind.zip --out geoip_maxmind.csv

Command for converting a file from an IP2Location ZIP archive:

python converter.py --type ip2location --input IP2LOCATION-LITE-DB11.CSV.ZIP --out geoip_ip2location.csv

Command for converting a file from several IP2Location ZIP archives:

python converter.py --type ip2location --input IP2LOCATION-LITE-DB11.CSV.ZIP IP2LOCATION-LITE-DB11.IPV6.CSV.ZIP --out geoip_ip2location_ipv4_ipv6.csv

The --lang parameter is not used for IP2Location.

Required sets of fields

The MaxMind source files GeoLite2-City-Blocks-IPv4.csv and GeoLite2-City-Blocks-IPv6.csv must contain the following set of fields:

network,geoname_id,registered_country_geoname_id,represented_country_geoname_id,
is_anonymous_proxy,is_satellite_provider,postal_code,latitude,longitude,accuracy_radius

Example set of source data:

network,geoname_id,registered_country_geoname_id,represented_country_geoname_id,
is_anonymous_proxy,is_satellite_provider,postal_code,latitude,longitude,accuracy_radius

1.0.0.0/24,2077456,2077456,,0,0,,-33.4940,143.2104,1000

1.0.1.0/24,1814991,1814991,,0,0,,34.7732,113.7220,1000

The remaining CSV files with the locale code must contain the following set of fields:

geoname_id,locale_code,continent_code,continent_name,country_iso_code,country_name,
subdivision_1_iso_code,subdivision_1_name,subdivision_2_iso_code,subdivision_2_name,
city_name,metro_code,time_zone,is_in_european_union

Example set of source data:

geoname_id,locale_code,continent_code,continent_name,country_iso_code,country_name,
subdivision_1_iso_code,subdivision_1_name,subdivision_2_iso_code,subdivision_2_name,
city_name,metro_code,time_zone,is_in_european_union

1392,de,AS,Asien,IR,Iran,02,Mazandaran,,,,,Asia/Tehran,0

7240,de,AS,Asien,IR,Iran,28,Nord-Chorasan,,,,,Asia/Tehran,0

The source IP2Location files must contain data on the network ranges, Country, Region, City, Latitude, and Longitude

Example set of source data:

"0","16777215","-","-","-","-","0.000000","0.000000","-","-"

"16777216","16777471","US","United States of America","California","Los Angeles","34.052230","-118.243680","90001","-07:00"

"16777472","16778239","CN","China","Fujian","Fuzhou","26.061390","119.306110","350004","+08:00"

If the source files contain a different set of fields than the one indicated in this section, or if some fields are missing, the missing fields in the target CSV file will be empty after conversion.

Page top

[Topic 233260]

Importing and exporting geographic data

If necessary, you can manually import and export geographic data into KUMA. Geographic data is imported and exported in a CSV file. If the geographic data import is successful, the previously added data is overwritten and an audit event is generated in KUMA.

To import geographic data into KUMA:

Prepare a CSV file containing geographic data.
Geographic data received from MaxMind and IP2Location must be converted to a format supported by KUMA.
In the KUMA web interface, open Settings → General.
In the Geographic data settings block, click the Import from file button and select a CSV file containing geographic data.
Wait for the geographic data import to finish. The data import is interrupted if the page is refreshed.

The geographic data is uploaded to KUMA.

To export geographic data from KUMA:

In the KUMA web interface, open Settings → General.
In the Geographic data settings block, click the Export button.

Geographic data will be downloaded as a CSV file named geoip.csv (in UTF-8 encoding) based on the settings of your browser.

The data is exported in the same format as it was uploaded, with the exception of IP address ranges. If a range of addresses was indicated in the format 1.0.0.0/24 in a file imported into KUMA, the range will be displayed in the format 1.0.0.0-1.0.0.255 in the exported file.

Page top

[Topic 233399]

Default mapping of geographic data

If you select the SourceAddress, DestinationAddress and DeviceAddress event fields as the IP address source when configuring a geographic data enrichment rule, the Apply default mapping button becomes available. You can use this button to add preconfigured mapping pairs of geographic data attributes and event fields as described below.

Default mappings for the SourceAddress event field

Geodata attribute	Event field
Country	`SourceCountry`
Region	`SourceRegion`
City	`SourceCity`
Latitude	`SourceLatitude`
Longitude	`SourceLongitude`

Default mappings for the DestinationAddress event field

Geodata attribute	Event field
Country	`DestinationCountry`
Region	`DestinationRegion`
City	`DestinationCity`
Latitude	`DestinationLatitude`
Longitude	`DestinationLongitude`

Default mappings for the DeviceAddress event field

Geodata attribute	Event field
Country	`DeviceCountry`
Region	`DeviceRegion`
City	`DeviceCity`
Latitude	`DeviceLatitude`
Longitude	`DeviceLongitude`

Page top

[Topic 249556]

User guide

This chapter provides information about managing the KUMA SIEM system.

In this Help topic

KUMA resources

Example of incident investigation with KUMA

Analytics

Page top

[Topic 217687]

KUMA resources

Resources are contained in the Resources section, Resources block of KUMA web interface. The following resource types are available:

Correlation rules—resources of this type contain rules for identifying event patterns that indicate threats. If the conditions specified in these resources are met, a correlation event is generated.
Normalizers—resources of this type contain rules for converting incoming events into the format used by KUMA. After processing in the normalizer, the "raw" event becomes normalized and can be processed by other KUMA resources and services.
Connectors—resources of this type contain settings for establishing network connections.
Aggregation rules—resources of this type contain rules for combining several basic events of the same type into one aggregation event.
Enrichment rules—resources of this type contain rules for supplementing events with information from third-party sources.
Destinations—resources of this type contain settings for forwarding events to a destination for further processing or storage.
Filters—resources of this type contain conditions for rejecting or selecting individual events from the stream of events.
Response rules—resources of this type are used in correlators to, for example, execute scripts or launch Kaspersky Security Center tasks when certain conditions are met.
Notification templates—resources of this type are used when sending notifications about new alerts.
Active lists—resources of this type are used by correlators for dynamic data processing when analyzing events according to correlation rules.
Dictionaries—resources of this type are used to store keys and their values, which may be required by other KUMA resources and services.
Proxies—resources of this type contain settings for using proxy servers.
Secrets—resources of this type are used to securely store confidential information (such as credentials) that KUMA needs to interact with external services.

When you click on a resource type, a window opens displaying a table with the available resources of this type. The resource table contains the following columns:

Name—the name of a resource. Can be used to search for resources and sort them.
Updated—the date and time of the last update of a resource. Can be used to sort resources.
Created by—the name of the user who created a resource.
Description—the description of a resource.

The maximum table size is not limited. If you want to select all resources, scroll to the end of the table and select the Select all check box, which selects all available resources in the table.

Resources can be organized into folders. The folder structure is displayed in the left part of the window: root folders correspond to tenants and contain a list of all resources of the tenant. All other folders nested within the root folder display the resources of an individual folder. When a folder is selected, the resources it contains are displayed as a table in the right pane of the window.

Resources can be created, edited, copied, moved from one folder to another, and deleted. Resources can also be exported and imported.

KUMA comes with a set of predefined resources, which can be identified by the "[OOTB]<resource_name>" name. OOTB resources are protected from editing.

If you want to adapt a predefined OOTB resource to your organization's infrastructure:

In the Resources-<resource type> section, select the OOTB resource that you want to edit.
In the upper part of the KUMA web interface, click Duplicate, then click Save.
A new resource named "[OOTB]<resource_name> - copy" is displayed in the web interface.
Edit the copy of the predefined resource as necessary and save your changes.

The adapted resource is available for use.

In this Help topic

Operations with resources

Notification templates

Page top

Operations with resources

To manage KUMA resources, you can create, move, copy, edit, delete, import, and export them. These operations are available for all resources, regardless of the resource type.

KUMA resources reside in folders. You can add, rename, move, or delete resource folders.

In this section

Creating, renaming, moving, and deleting resource folders

Creating, duplicating, moving, editing, and deleting resources

Page top

Creating, renaming, moving, and deleting resource folders

You can create, rename, move and delete folders.

To create a folder:

Select the folder in the tree where the new folder is required.
Click the Add folder button.

The folder will be created.

To rename a folder:

Locate required folder in the folder structure.
Hover over the name of the folder.
The icon will appear near the name of the folder.
Open the drop-down list and select Rename.
The folder name will become active for editing.
Enter the new folder name and press ENTER.
The folder name cannot be empty.

The folder will be renamed.

To move a folder,

Drag and drop the folder to a required place in folder structure by clicking its name.

Folders cannot be dragged from one tenant to another.

To delete a folder:

Locate required folder in the folder structure.
Hover over the name of the folder.
The icon will appear near the name of the folder.
Open the drop-down list and select Delete.
The conformation window appears.
Click OK.

The folder will be deleted.

The program does not delete folders that contain files or subfolders.

Page top

[Topic 218050]

Creating, duplicating, moving, editing, and deleting resources

You can create, move, copy, edit, and delete resources.

To create the resource:

In the Resources → <resource type> section, select or create a folder where you want to add the new resource.
Root folders correspond to tenants. For a resource to be available to a specific tenant, it must be created in the folder of that tenant.
Click the Add <resource type> button.
The window for configuring the selected resource type opens. The available configuration parameters depend on the resource type.
Enter a unique resource name in the Name field.
Specify the required parameters (marked with a red asterisk).
If necessary, specify the optional parameters (not required).
Click Save.

The resource will be created and available for use in services and other resources.

To move the resource to a new folder:

In the Resources → <resource type> section, find the required resource in the folder structure.
Select the check box near the resource you want to move. You can select multiple resources.
The icon appears near the selected resources.
Use the icon to drag and drop resources to the required folder.

The resources will be moved to the new folders.

You can only move resources to folders of the tenant in which the resources were created. Resources cannot be moved to another tenant's folders.

To copy the resource:

In the Resources → <resource type> section, find the required resource in the folder structure.
Select the check box next to the resource that you want to copy and click Duplicate.
A window opens with the settings of the resource that you have selected for copying. The available configuration parameters depend on the resource type.

The <selected resource name> - copy value is displayed in the Name field.
Make the necessary changes to the parameters.
Enter a unique name in the Name field.
Click Save.

The copy of the resource will be created.

To edit the resource:

In the Resources → <resource type> section, find the required resource in the folder structure.
Select the resource.
A window with the settings of the selected resource opens. The available configuration parameters depend on the resource type.
Make the necessary changes to the parameters.
Click Save.

The resource will be updated. If this resource is used in a service, restart the service to apply the new settings.

To delete the resource:

In the Resources → <resource type> section, find the required resource in the folder structure.
Select the check box next to the resource that you want to delete and click Delete.
A confirmation window opens.
Click OK.

The resource will be deleted.

Page top

[Topic 242817]

Updating resources

Kaspersky regularly releases packages with resources that can be imported from the repository. You can specify an email address in the settings of the Repository update task. After the first execution of the task, KUMA starts sending notifications about the packages available for update to the specified address. You can update the repository, analyze the contents of each update, and decide if to import and deploy the new resources in the operating infrastructure. KUMA supports updates from Kaspersky servers and from custom sources, including offline update using the update mirror mechanism. If you have other Kaspersky products in the infrastructure, you can connect KUMA to existing update mirrors. The update subsystem expands KUMA capabilities to respond to the changes in the threat landscape and the infrastructure. The capability to use it without direct Internet access ensures the privacy of the data processed by the system.

To update resources, perform the following steps:

Update the repository to deliver the resource packages to the repository. The repository update is available in two modes:
- Automatic update
- Manual update
Import the resource packages from the updated repository into the tenant.

For the service to start using the resources, make sure that the updated resources are mapped after performing the import. If necessary, link the resources to collectors, correlators, or agents, and update the settings.

To enable automatic update:

In the Settings → Repository update section, configure the Data refresh interval in hours. The default value is 24 hours.
Specify the Update source. The following options are available:
- Kaspersky update servers
  The servers are located in many countries around the world, which ensures the high reliability of the update. If the update cannot be performed from one server, KUMA switches to another server.
  
  .
  You can view the list of servers in the Knowledge Base, article 15998.
- Custom source:
  - The URL to the shared folder on the HTTP server.
  - The full path to the local folder on the host where the KUMA Core is installed.
    If a local folder is used, the kuma system user must have read access to this folder and its contents.
Specify the Emails for notification by clicking the Add button. The notifications that new packages or new versions of the packages imported into the tenant are available in the repository are sent to the specified email addresses.
If you specify the email address of a KUMA user, the Receive email notifications check box must be selected in the user profile. For emails that do not belong to any KUMA user, the messages are received without additional settings. The settings for connecting to the SMTP server must be specified in all cases.
Click Save. The update task starts shortly. Then the task restarts according to the schedule.

To manually start the repository update:

To disable automatic updates, in the Settings → Repository update section, select the Disable automatic update check box. This check box is cleared by default. You can also start a manual repository update without disabling automatic update. Starting an update manually does not affect the automatic update schedule.
Specify the Update source. The following options are available:
- Kaspersky update servers.
- Custom source:
  - The URL to the shared folder on the HTTP server.
  - The full path to the local folder on the host with the KUMA Core
    If a local folder is used, the kuma user must have access to this folder and its contents.
Specify the Emails for notification by clicking the Add button. The notifications that new packages or new versions of the packages imported into the tenant are available in the repository are sent to the specified email addresses.
If you specify the email address of a KUMA user, the Receive email notifications check box must be selected in the user profile. For emails that do not belong to any KUMA user, the messages are received without additional settings. The settings for connecting to the SMTP server must be specified in all cases.
Click Run update. Thus, you simultaneously save the settings and manually start the Repository update task.

Page top

[Topic 245074]

Configuring a custom source using Kaspersky Update Utility

You can update resources without Internet access by using a custom update source via the Kaspersky Update Utility.

Configuration consists of the following steps:

Configuring a custom source using Kaspersky Update Utility:
1. Installing and configuring Kaspersky Update Utility on one of the computers in the corporate LAN.
2. Configuring copying of updates to a shared folder in Kaspersky Update Utility settings.
Configuring update of the KUMA repository from a custom source.

Configuring a custom source using Kaspersky Update Utility:

You can download the Kaspersky Update Utility distribution kit from the Kaspersky Technical Support website.

In Kaspersky Update Utility, enable the download of updates for KUMA 2.1:
- Under Applications – Perimeter control, select the check box next to KUMA 2.1 to enable the update capability.
- If you work with Kaspersky Update Utility using the command line, add the following line to the [ComponentSettings] section of the updater.ini configuration file or specify the true value for an existing line:
  KasperskyUnifiedMonitoringAndAnalysisPlatform_2_1=true
In the Downloads section, specify the update source. By default, Kaspersky update servers are used as the update source.
In the Downloads section, in the Update folders group of settings, specify the shared folder for Kaspersky Update Utility to download updates to. The following options are available:
- Specify the local folder on the host where Kaspersky Update Utility is installed. Deploy the HTTP server for distributing updates and publish the local folder on it. In KUMA, in the Settings → Repository update → Custom source section, specify the URL of the local folder published on the HTTP server.
- Specify the local folder on the host where Kaspersky Update Utility is installed. Make this local folder available over the network. Mount the network-accessible local folder on the host where KUMA is installed. In KUMA, in the Settings → Repository update → Custom source section, specify the full path to the local folder.

For detailed information about working with Kaspersky Update Utility, refer to the Kaspersky Knowledge Base.

Page top

[Topic 217870]

Exporting resources

If shared resources are hidden for a user, the user cannot export shared resources or resources that use shared resources.

To export resources:

In the Resources section, click Export resources.
The Export resources window opens with the tree of all available resources.
In the Password field enter the password that must be used to protect exported data.
In the Tenant drop-down list, select the tenant whose resources you want to export.
Check boxes near the resources you want to export.
If selected resources are linked to other resources, linked resources will be exported, too.
Click the Export button.

The resources in a password-protected file are saved on your computer using your browser settings. The Secret resources are exported blank.

Page top

[Topic 242787]

Importing resources

To import resources:

In the Resources section, click Import resources.
The Resource import window opens.
In the Tenant drop-down list, select the tenant to assign the imported resources to.
In the Import source drop-down list, select one of the following options:
- File
  If you select this option, enter the password and click the Import button.
- Repository
  If you select this option, a list of packages available for import is displayed. We recommend starting the import with the "OOTB resources for KUMA 2.1" package and then importing the packages one by one. If you receive a "Database error" error when importing packages, try importing the package mentioned in the error message again, selecting only the specified package for import. You can also configure automatic updates.
  
  You can select one or more packages to import and click the Import button.
  
  The imported resources can only be deleted. To rename, edit or move an imported resource, make a copy of the resource using the Duplicate button and perform the desired actions with the resource copy. When importing future versions of the package, the duplicate is not updated because it is a separate object.
Resolve the conflicts between the resources imported from the file and the existing resources if they occur. Read more about resource conflicts below.
1. If the name, type, and guid of an imported resource fully match the name, type, and guid of an existing resource, the Conflicts window opens with the table displaying the type and the name of the conflicting resources. Resolve displayed conflicts:
  - To replace the existing resource with a new one, click Replace.
    To replace all conflicting resources, click Replace all.
  - To leave the existing resource, click Skip.
    To keep all existing resources, click Skip all.
2. Click the Resolve button.
The resources are imported to KUMA. The Secret resources are imported blank.

About conflict resolving

When resources are imported into KUMA from a file, they are compared with existing resources; the following parameters are compared:

Name and kind. If an imported resource's name and kind parameters match those of the existing one, the imported resource's name is automatically changed.
ID. If identifiers of two resources match, a conflict appears that must be resolved by the user. This could happen when you import resources to the same KUMA server from which they were exported.

When resolving a conflict you can choose either to replace existing resource with the imported one or to keep exiting resource, skipping the imported one.

Some resources are linked: for example, in some types of connectors, the connector secret must be specified. The secrets are also imported if they are linked to a connector. Such linked resources are exported and imported together.

Special considerations of import:

Resources are imported to the selected tenant.
Starting with version 2.1.3, if a linked resource is in the Shared tenant, it ends up in the Shared tenant when imported.
In version 2.1.3 and later, in the Conflicts window, the Parent column always displays the top-most parent resource among those that were selected during import.
In version 2.1.3 and later, if a conflict occurs during import and you choose to replace existing resource with a new one, it would mean that all the other resources linked to the one being replaced are automatically replaced with the imported resources.

Known bugs in version 2.1.3:

The linked resource ends up in the tenant specified during the import, and not in the Shared tenant, as indicated in the Conflicts window, under the following conditions:
1. The associated resource is initially in the Shared tenant.
2. In the Conflicts window, you select Skip for all parent objects of the linked resource from the Shared tenant.
3. You leave the linked resource from the Shared tenant for replacement.
After importing, the categories do not have a tenant specified in the filter under the following conditions:
1. The filter contains linked asset categories from different tenants.
2. Asset category names are the same.
3. You are importing this filter with linked asset categories to a new server.
In Tenant 1, the name of the asset category is duplicated under the following conditions:
1. in Tenant 1, you have a filter with linked asset categories from Tenant 1 and the Shared tenant.
2. The names of the linked asset categories are the same.
3. You are importing such a filter from Tenant 1 to the Shared tenant.
You cannot import conflicting resources into the same tenant.
The error "Unable to import conflicting resources into the same tenant" means that the imported package contains conflicting resources from different tenants and cannot be imported into the Shared tenant.

Solution: Select a tenant other than Shared to import the package. In this case, during the import, resources originally located in the Shared tenant are imported into the Shared tenant, and resources from the other tenant are imported into the tenant selected during import.
Only the general administrator can import categories into the Shared tenant.
The error "Only the general administrator can import categories into the Shared tenant" means that the imported package contains resources with linked shared asset categories. You can see the categories or resources with linked shared asset categories in the KUMA Core log. Path to the Core log:

/opt/kaspersky/kuma/core/log/core

Solution. Choose one of the following options:
- Do not import resources to which shared categories are linked: clear the check boxes next to the relevant resources.
- Perform the import under a General administrator account.
Only the general administrator can import resources into the Shared tenant.
The error "Only the general administrator can import resources into the Shared tenant" means that the imported package contains resources with linked shared resources. You can see the resources with linked shared resources in the KUMA Core log. Path to the Core log:

/opt/kaspersky/kuma/core/log/core

Solution. Choose one of the following options:
- Do not import resources that have linked resources from the Shared tenant, and the shared resources themselves: clear the check boxes next to the relevant resources.
- Perform the import under a General administrator account.

Page top

[Topic 217842]

Destinations

Destinations define network settings for sending normalized events. Collectors and correlators use destinations to describe where to send processed events. Typically, the destination points are the correlator and storage.

The settings of destinations are configured on two tabs: Basic settings and Advanced settings. The available settings depend on the selected type of destination:

nats-jetstream—used for NATS communications.
tcp—used for communications over TCP.
http—used for HTTP communications.
diode—used to transmit events using a data diode.
kafka—used for Kafka communications.
file—used for writing to a file.
storage—used to transmit data to the storage.
correlator—used to transmit data to the correlator.

In this section

Predefined destinations

Page top

[Topic 232952]

Nats type

The nats-jetstream type is used for NATS communications.

Basic settings tab

Setting	Description
Name	Required setting. Unique name of the resource. Must contain 1 to 128 Unicode characters.
Tenant	Required setting. The name of the tenant that owns the resource.
Disabled switch	Used when events must not be sent to the destination. By default, sending events is enabled.
Type	Required setting. Destination type, nats-jetstream.
URL	Required setting. URL that you want to connect to.
Topic	Required setting. The topic of NATS messages. Must contain Unicode characters.
Delimiter	Specify a character that defines where one event ends and the other begins. By default, `\n` is used.
Authorization	Type of authorization when connecting to the specified URL Possible values: disabled is the default value. plain — if this option is selected, you must indicate the secret containing user account credentials for authorization when connecting to the connector. Add secret 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. If you want to add a new secret, click the button on the right of the Secret list. The Secret window opens. In the Name field, enter the name that will be used to display the secret in the list of available secrets. In the User and Password fields, enter the credentials of the user account that the Agent will use to connect to the connector. If necessary, add any other information about the secret in the Description field. Click the Save button. The secret will be added and displayed in the Secret list.
Description	Resource description: up to 4,000 Unicode characters.

Advanced settings tab

Setting	Description
Compression	You can use Snappy compression. By default, compression is disabled.
Buffer size	Sets the size of the buffer. The default value is 1 KB, and the maximum value is 64 MB.
Timeout	The time (in seconds) to wait for a response from another service or component. The default value is `30`.
Disk buffer size limit	Size of the disk buffer in bytes. The default value is 10 GB.
Cluster ID	ID of the NATS cluster.
TLS mode	Use of TLS encryption. Available values: Disabled (default) means TLS encryption is not used. Enabled means encryption is used, but the certificate is not verified. With verification means encryption is used with verification that the certificate was signed with the KUMA root certificate. The root certificate and key of KUMA are created automatically during program installation and are stored on the KUMA Core server in the folder /opt/kaspersky/kuma/core/certificates/. Custom CA means encryption is used with verification that the certificate was signed by a Certificate Authority. The secret containing the certificate is selected from the Custom CA drop-down list, which is displayed when this option is selected. Creating a certificate signed by a Certificate Authority To use this TLS mode, you must do the following on the KUMA Core server (OpenSSL commands are used in the examples below): Create the key that will be used by the Certificate Authority. Example command: `openssl genrsa -out ca.key 2048` Generate a certificate for the key that was just created. Example command: `openssl req -new -x509 -days 365 -key ca.key -subj "/CN=<common host name of Certificate Authority>" -out ca.crt` Create a private key and a request to have it signed by the Certificate Authority. Example command: `openssl req -newkey rsa:2048 -nodes -keyout server.key -subj "/CN=<common host name of KUMA server>" -out server.csr` Create a certificate signed by the Certificate Authority. The subjectAltName must include the domain names or IP addresses of the server for which the certificate is being created. Example command: `openssl x509 -req -extfile <(printf "subjectAltName=DNS:domain1.ru,DNS:domain2.com,IP:192.168.0.1") -days 365 -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt` The obtained `server.crt` certificate should be uploaded in the KUMA web interface as a certificate-type secret, which should then be selected from the Custom CA drop-down list. When using TLS, it is impossible to specify an IP address as a URL.
Delimiter	In the drop-down list, you can select the character to mark the boundary between events. By default, `\n` is used.
Buffer flush interval	Time (in seconds) between sending batches of data to the destination. The default value is `1 second`.
Workers	This field is used to set the number of services processing the queue. By default, this value is equal to the number of vCPUs of the KUMA Core server.
Debug	A drop-down list in which you can specify whether resource logging must be enabled. The default value is Disabled.
Disk buffer disabled	Drop-down list that lets you enable or disable the disk buffer. By default, the disk buffer is enabled. The disk buffer is used if the collector cannot send normalized events to the destination. The amount of allocated disk space is limited by the value of the Disk buffer size limit setting. If the disk space allocated for the disk buffer is exhausted, events are rotated as follows: new events replace the oldest events written to the buffer.
Filter	In the Filter section, you can specify the criteria for identifying events that must be processed by the resource. You can select an existing filter from the drop-down list or create a new filter. Creating a filter in resources In the Filter drop-down list, select Create new. If you want to keep the filter as a separate resource, select the Save filter check box. In this case, you will be able to use the created filter in various services. This check box is cleared by default. If you selected the Save filter check box, enter a name for the created filter resource in the Name field. The name must contain 1 to 128 Unicode characters. In the Conditions settings block, specify the conditions that the events must meet: Click the Add condition button. In the Left operand and Right operand drop-down lists, specify the search parameters. Depending on the data source selected in the Right operand field, you may see fields of additional parameters that you need to use to define the value that will be passed to the filter. For example, when choosing active list you will need to specify the name of the active list, the entry key, and the entry key field. In the operator drop-down list, select the relevant operator. Filter operators =—the left operand equals the right operand. <—the left operand is less than the right operand. <=—the left operand is less than or equal to the right operand. >—the left operand is greater than the right operand. >=—the left operand is greater than or equal to the right operand. inSubnet—the left operand (IP address) is in the subnet of the right operand (subnet). contains—the left operand contains values of the right operand. startsWith—the left operand starts with one of the values of the right operand. endsWith—the left operand ends with one of the values of the right operand. match—the left operand matches the regular expression of the right operand. The RE2 regular expressions are used. hasBit—checks whether the left operand (string or number) contains bits whose positions are listed in the right operand (in a constant or in a list). The value to be checked is converted to binary and processed right to left. Chars are checked whose index is specified as a constant or a list. If the value being checked is a string, then an attempt is made to convert it to integer and process it in the way described above. If the string cannot be converted to a number, the filter returns False. hasVulnerability—checks whether the left operand contains an asset with the vulnerability and vulnerability severity specified in the right operand. If you do not specify the ID and severity of the vulnerability, the filter is triggered if the asset in the event being checked has any vulnerability. inActiveList—this operator has only one operand. Its values are selected in the Key fields field and are compared with the entries in the active list selected from the Active List drop-down list. inContextTable checks whether or not an entry exists in the context table. This operator has only one operand. Its values are selected in the Key fields field and are compared with the values of entries in the context table selected from the drop-down list of context tables. inDictionary—checks whether the specified dictionary contains an entry defined by the key composed with the concatenated values of the selected event fields. inCategory—the asset in the left operand is assigned at least one of the asset categories of the right operand. inActiveDirectoryGroup—the Active Directory account in the left operand belongs to one of the Active Directory groups in the right operand. TIDetect—this operator is used to find events using CyberTrace Threat Intelligence (TI) data. This operator can be used only on events that have completed enrichment with data from CyberTrace Threat Intelligence. In other words, it can only be used in collectors at the destination selection stage and in correlators. If necessary, select the do not match case check box. When this check box is selected, the operator ignores the case of the values. The selection of this check box does not apply to the InSubnet, InActiveList, InCategory or InActiveDirectoryGroup operators. This check box is cleared by default. If you want to add a negative condition, select If not from the If drop-down list. You can add multiple conditions or a group of conditions. If you have added multiple conditions or groups of conditions, choose a search condition (and, or, not) by clicking the AND button. If you want to add existing filters that are selected from the Select filter drop-down list, click the Add filter button. You can view the nested filter settings by clicking the button.

Page top

[Topic 232960]

Tcp type

The tcp type is used for TCP communications.

Basic settings tab

Setting	Description
Name	Required setting. Unique name of the resource. Must contain 1 to 128 Unicode characters.
Tenant	Required setting. The name of the tenant that owns the resource.
Disabled switch	Used when events must not be sent to the destination. By default, sending events is enabled.
Type	Required setting. Destination type, tcp.
URL	Required setting. URL that you want to connect to. Available formats: `<host>:<port>`, `<IPv4>:<port>`, `:<port>`. IPv6 addresses are also supported. When using IPv6 addresses, you must also specify the interface in the `[address%interface]:port` format. For example, `[fe80::5054:ff:fe4d:ba0c%eth0]:4222`).
Description	Resource description: up to 4,000 Unicode characters.

Advanced settings tab

Setting	Description
Compression	You can use Snappy compression. By default, compression is disabled.
Buffer size	Sets the size of the buffer. The default value is 1 KB, and the maximum value is 64 MB.
Timeout	The time (in seconds) to wait for a response from another service or component. The default value is `30`.
Disk buffer size limit	Size of the disk buffer in bytes. The default value is 10 GB.
TLS mode	TLS encryption mode using certificates in pem x509 format. Available values: Disabled means TLS encryption is not used. The default value. Enabled means encryption is used, but certificates are not verified. With verification means encryption is used with verification that the certificate was signed with the KUMA root certificate. The root certificate and key of KUMA are created automatically during program installation and are stored on the KUMA Core server in the folder /opt/kaspersky/kuma/core/certificates/. When using TLS, it is impossible to specify an IP address as a URL.
Delimiter	In the drop-down list, you can select the character to mark the boundary between events. By default, `\n` is used.
Buffer flush interval	Time (in seconds) between sending batches of data to the destination. The default value is `1 second`.
Workers	This field is used to set the number of services processing the queue. By default, this value is equal to the number of vCPUs of the KUMA Core server.
Debug	A drop-down list in which you can specify whether resource logging must be enabled. The default value is Disabled.
Disk buffer disabled	Drop-down list that lets you enable or disable the disk buffer. By default, the disk buffer is enabled. The disk buffer is used if the collector cannot send normalized events to the destination. The amount of allocated disk space is limited by the value of the Disk buffer size limit setting. If the disk space allocated for the disk buffer is exhausted, events are rotated as follows: new events replace the oldest events written to the buffer.
Filter	In this section, you can specify the criteria for identifying events that must be processed by the resource. You can select an existing filter from the drop-down list or create a new filter. Creating a filter in resources In the Filter drop-down list, select Create new. If you want to keep the filter as a separate resource, select the Save filter check box. In this case, you will be able to use the created filter in various services. This check box is cleared by default. If you selected the Save filter check box, enter a name for the created filter resource in the Name field. The name must contain 1 to 128 Unicode characters. In the Conditions settings block, specify the conditions that the events must meet: Click the Add condition button. In the Left operand and Right operand drop-down lists, specify the search parameters. Depending on the data source selected in the Right operand field, you may see fields of additional parameters that you need to use to define the value that will be passed to the filter. For example, when choosing active list you will need to specify the name of the active list, the entry key, and the entry key field. In the operator drop-down list, select the relevant operator. Filter operators =—the left operand equals the right operand. <—the left operand is less than the right operand. <=—the left operand is less than or equal to the right operand. >—the left operand is greater than the right operand. >=—the left operand is greater than or equal to the right operand. inSubnet—the left operand (IP address) is in the subnet of the right operand (subnet). contains—the left operand contains values of the right operand. startsWith—the left operand starts with one of the values of the right operand. endsWith—the left operand ends with one of the values of the right operand. match—the left operand matches the regular expression of the right operand. The RE2 regular expressions are used. hasBit—checks whether the left operand (string or number) contains bits whose positions are listed in the right operand (in a constant or in a list). The value to be checked is converted to binary and processed right to left. Chars are checked whose index is specified as a constant or a list. If the value being checked is a string, then an attempt is made to convert it to integer and process it in the way described above. If the string cannot be converted to a number, the filter returns False. hasVulnerability—checks whether the left operand contains an asset with the vulnerability and vulnerability severity specified in the right operand. If you do not specify the ID and severity of the vulnerability, the filter is triggered if the asset in the event being checked has any vulnerability. inActiveList—this operator has only one operand. Its values are selected in the Key fields field and are compared with the entries in the active list selected from the Active List drop-down list. inContextTable checks whether or not an entry exists in the context table. This operator has only one operand. Its values are selected in the Key fields field and are compared with the values of entries in the context table selected from the drop-down list of context tables. inDictionary—checks whether the specified dictionary contains an entry defined by the key composed with the concatenated values of the selected event fields. inCategory—the asset in the left operand is assigned at least one of the asset categories of the right operand. inActiveDirectoryGroup—the Active Directory account in the left operand belongs to one of the Active Directory groups in the right operand. TIDetect—this operator is used to find events using CyberTrace Threat Intelligence (TI) data. This operator can be used only on events that have completed enrichment with data from CyberTrace Threat Intelligence. In other words, it can only be used in collectors at the destination selection stage and in correlators. If necessary, select the do not match case check box. When this check box is selected, the operator ignores the case of the values. The selection of this check box does not apply to the InSubnet, InActiveList, InCategory or InActiveDirectoryGroup operators. This check box is cleared by default. If you want to add a negative condition, select If not from the If drop-down list. You can add multiple conditions or a group of conditions. If you have added multiple conditions or groups of conditions, choose a search condition (and, or, not) by clicking the AND button. If you want to add existing filters that are selected from the Select filter drop-down list, click the Add filter button. You can view the nested filter settings by clicking the button.

Page top

[Topic 232961]

Http type

The http type is used for HTTP communications.

Basic settings tab

Setting	Description
Name	Required setting. Unique name of the resource. Must contain 1 to 128 Unicode characters.
Tenant	Required setting. The name of the tenant that owns the resource.
Disabled switch	Used when events must not be sent to the destination. By default, sending events is enabled.
Type	Required setting. Destination type, http.
URL	Required setting. URL that you want to connect to. Available formats: `<host>:<port>`, `<IPv4>:<port>`, `:<port>`. IPv6 addresses are also supported, however, when you use them, you must specify the interface as well: `[address%interface]:port`. Example: `[fe80::5054:ff:fe4d:ba0c%eth0]:4222`).
Authorization	Type of authorization when connecting to the specified URL Possible values: disabled is the default value. plain: if this option is selected, you must indicate the secret containing user account credentials for authorization when connecting to the connector. Add secret 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. If you want to add a new secret, click the button on the right of the Secret list. The Secret window opens. In the Name field, enter the name that will be used to display the secret in the list of available secrets. In the User and Password fields, enter the credentials of the user account that the Agent will use to connect to the connector. If necessary, add any other information about the secret in the Description field. Click the Save button. The secret will be added and displayed in the Secret list.
Description	Resource description: up to 4,000 Unicode characters.

Advanced settings tab

Setting	Description
Compression	You can use Snappy compression. By default, compression is disabled.
Buffer size	Sets the size of the buffer. The default value is 1 KB, and the maximum value is 64 MB.
Timeout	The time (in seconds) to wait for a response from another service or component. The default value is `30`.
Disk buffer size limit	Size of the disk buffer in bytes. The default value is 10 GB.
TLS mode	Use of TLS encryption. Available values: Disabled (default) means TLS encryption is not used. Enabled means encryption is used, but the certificate is not verified. With verification means encryption is used with verification that the certificate was signed with the KUMA root certificate. The root certificate and key of KUMA are created automatically during program installation and are stored on the KUMA Core server in the folder /opt/kaspersky/kuma/core/certificates/. Custom CA means encryption is used with verification that the certificate was signed by a Certificate Authority. The secret containing the certificate is selected from the Custom CA drop-down list, which is displayed when this option is selected. Creating a certificate signed by a Certificate Authority To use this TLS mode, you must do the following on the KUMA Core server (OpenSSL commands are used in the examples below): Create the key that will be used by the Certificate Authority. Example command: `openssl genrsa -out ca.key 2048` Generate a certificate for the key that was just created. Example command: `openssl req -new -x509 -days 365 -key ca.key -subj "/CN=<common host name of Certificate Authority>" -out ca.crt` Create a private key and a request to have it signed by the Certificate Authority. Example command: `openssl req -newkey rsa:2048 -nodes -keyout server.key -subj "/CN=<common host name of KUMA server>" -out server.csr` Create a certificate signed by the Certificate Authority. The subjectAltName must include the domain names or IP addresses of the server for which the certificate is being created. Example command: `openssl x509 -req -extfile <(printf "subjectAltName=DNS:domain1.ru,DNS:domain2.com,IP:192.168.0.1") -days 365 -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt` The obtained `server.crt` certificate should be uploaded in the KUMA web interface as a certificate-type secret, which should then be selected from the Custom CA drop-down list. When using TLS, it is impossible to specify an IP address as a URL.
URL selection policy	From the drop-down list, you can select the method of deciding which URL to send events to if multiple URLs are specified. Available values: Any. Events are sent to one of the available URLs as long as this URL receives events. If the connection is broken (for example, the receiving node is disconnected) a different URL will be selected as the events destination. Prefer first. Events are sent to the first URL in the list of added addresses. If it becomes unavailable, events are sent to the next available node in sequence. When the first URL becomes available again, events start to be sent to it again. Round robin. Packets with events will be evenly distributed among available URLs from the list. Because packets are sent either on a destination buffer overflow or on the flush timer, this URL selection policy does not guarantee an equal distribution of events to destinations.
Delimiter	In the drop-down list, you can select the character to mark the boundary between events. By default, \n is used.
Path	The path that must be added for the URL request. For example, if you specify the path `/input` and enter `10.10.10.10` for the URL, requests for `10.10.10.10/input` will be sent from the destination.
Buffer flush interval	Time (in seconds) between sending batches of data to the destination. The default value is `1 second`.
Workers	The number of services that are processing the queue. By default, this value is equal to the number of vCPUs of the KUMA Core server.
Health check path	The URL for sending requests to obtain health information about the system that the destination resource is connecting to.
Health check timeout	Frequency of the health check in seconds.
Health Check Disabled	Check box that disables the health check.
Debug	A drop-down list in which you can specify whether resource logging must be enabled. The default value is Disabled.
Disk buffer disabled	Drop-down list that lets you enable or disable the disk buffer. By default, the disk buffer is enabled. The disk buffer is used if the collector cannot send normalized events to the destination. The amount of allocated disk space is limited by the value of the Disk buffer size limit setting. If the disk space allocated for the disk buffer is exhausted, events are rotated as follows: new events replace the oldest events written to the buffer.
Filter	In the Filter section, you can specify the criteria for identifying events that must be processed by the resource. You can select an existing filter from the drop-down list or create a new filter. Creating a filter in resources In the Filter drop-down list, select Create new. If you want to keep the filter as a separate resource, select the Save filter check box. In this case, you will be able to use the created filter in various services. This check box is cleared by default. If you selected the Save filter check box, enter a name for the created filter resource in the Name field. The name must contain 1 to 128 Unicode characters. In the Conditions settings block, specify the conditions that the events must meet: Click the Add condition button. In the Left operand and Right operand drop-down lists, specify the search parameters. Depending on the data source selected in the Right operand field, you may see fields of additional parameters that you need to use to define the value that will be passed to the filter. For example, when choosing active list you will need to specify the name of the active list, the entry key, and the entry key field. In the operator drop-down list, select the relevant operator. Filter operators =—the left operand equals the right operand. <—the left operand is less than the right operand. <=—the left operand is less than or equal to the right operand. >—the left operand is greater than the right operand. >=—the left operand is greater than or equal to the right operand. inSubnet—the left operand (IP address) is in the subnet of the right operand (subnet). contains—the left operand contains values of the right operand. startsWith—the left operand starts with one of the values of the right operand. endsWith—the left operand ends with one of the values of the right operand. match—the left operand matches the regular expression of the right operand. The RE2 regular expressions are used. hasBit—checks whether the left operand (string or number) contains bits whose positions are listed in the right operand (in a constant or in a list). The value to be checked is converted to binary and processed right to left. Chars are checked whose index is specified as a constant or a list. If the value being checked is a string, then an attempt is made to convert it to integer and process it in the way described above. If the string cannot be converted to a number, the filter returns False. hasVulnerability—checks whether the left operand contains an asset with the vulnerability and vulnerability severity specified in the right operand. If you do not specify the ID and severity of the vulnerability, the filter is triggered if the asset in the event being checked has any vulnerability. inActiveList—this operator has only one operand. Its values are selected in the Key fields field and are compared with the entries in the active list selected from the Active List drop-down list. inContextTable checks whether or not an entry exists in the context table. This operator has only one operand. Its values are selected in the Key fields field and are compared with the values of entries in the context table selected from the drop-down list of context tables. inDictionary—checks whether the specified dictionary contains an entry defined by the key composed with the concatenated values of the selected event fields. inCategory—the asset in the left operand is assigned at least one of the asset categories of the right operand. inActiveDirectoryGroup—the Active Directory account in the left operand belongs to one of the Active Directory groups in the right operand. TIDetect—this operator is used to find events using CyberTrace Threat Intelligence (TI) data. This operator can be used only on events that have completed enrichment with data from CyberTrace Threat Intelligence. In other words, it can only be used in collectors at the destination selection stage and in correlators. If necessary, select the do not match case check box. When this check box is selected, the operator ignores the case of the values. The selection of this check box does not apply to the InSubnet, InActiveList, InCategory or InActiveDirectoryGroup operators. This check box is cleared by default. If you want to add a negative condition, select If not from the If drop-down list. You can add multiple conditions or a group of conditions. If you have added multiple conditions or groups of conditions, choose a search condition (and, or, not) by clicking the AND button. If you want to add existing filters that are selected from the Select filter drop-down list, click the Add filter button. You can view the nested filter settings by clicking the button.

Page top

[Topic 232967]

Diode type

The diode type is used to transmit events using a data diode.

Basic settings tab

Setting	Description
Name	Required setting. Unique name of the resource. Must contain 1 to 128 Unicode characters.
Tenant	Required setting. The name of the tenant that owns the resource.
Disabled switch	Used when events must not be sent to the destination. By default, sending events is enabled.
Type	Required setting. Destination type, diode.
Data diode source directory	Required setting. The directory from which the data diode moves events. The path can contain up to 255 Unicode characters. Limitations when using prefixes in paths on Windows servers On Windows servers, absolute paths to directories must be specified. Directories with names matching the following regular expressions cannot be used: `^[a-zA-Z]:\\Program Files` `^[a-zA-Z]:\\Program Files $x86$` `^[a-zA-Z]:\\Windows` `^[a-zA-Z]:\\Program Files\\Kaspersky Lab\\KUMA` Limitations when using prefixes in paths on Linux servers Prefixes that cannot be used when specifying paths to files: /* /bin /boot /dev /etc /home /lib /lib64 /proc /root /run /sys /tmp /usr/* /usr/bin/ /usr/local/* /usr/local/sbin/ /usr/local/bin/ /usr/sbin/ /usr/lib/ /usr/lib64/ /var/* /var/lib/ /var/run/ /opt/kaspersky/kuma/ Files are available at the following paths: /opt/kaspersky/kuma/clickhouse/logs/ /opt/kaspersky/kuma/mongodb/log/ /opt/kaspersky/kuma/victoria-metrics/log/
Temporary directory	Directory in which events are prepared for transmission to the data diode. Events are collected in a file when a timeout (10 seconds by default) or a buffer overflow occurs. The prepared file is moved to the directory specified in the Data diode source directory field. The checksum (SHA-256) of the file contents is used as the name of the file containing events. The temporary directory must be different from the data diode source directory.
Description	Resource description: up to 4,000 Unicode characters.

Advanced settings tab

Setting	Description
Compression	You can use Snappy compression. By default, compression is disabled. This setting must match for the connector and destination resources used to relay events from an isolated network segment via the data diode.
Buffer size	Sets the size of the buffer. The default value is 1 KB, and the maximum value is 64 MB.
Delimiter	In the drop-down list, you can select the character to mark the boundary between events. By default, `\n` is used. This setting must match for the connector and destination resources used to relay events from an isolated network segment via the data diode.
Buffer flush interval	Time (in seconds) between sending batches of data to the destination. The default value is `1 second`.
Workers	This field is used to set the number of services processing the queue. By default, this value is equal to the number of vCPUs of the KUMA Core server.
Debug	A drop-down list in which you can specify whether resource logging must be enabled. The default value is Disabled.
Filter	In the Filter section, you can specify the criteria for identifying events that must be processed by the resource. You can select an existing filter from the drop-down list or create a new filter. Creating a filter in resources In the Filter drop-down list, select Create new. If you want to keep the filter as a separate resource, select the Save filter check box. In this case, you will be able to use the created filter in various services. This check box is cleared by default. If you selected the Save filter check box, enter a name for the created filter resource in the Name field. The name must contain 1 to 128 Unicode characters. In the Conditions settings block, specify the conditions that the events must meet: Click the Add condition button. In the Left operand and Right operand drop-down lists, specify the search parameters. Depending on the data source selected in the Right operand field, you may see fields of additional parameters that you need to use to define the value that will be passed to the filter. For example, when choosing active list you will need to specify the name of the active list, the entry key, and the entry key field. In the operator drop-down list, select the relevant operator. Filter operators =—the left operand equals the right operand. <—the left operand is less than the right operand. <=—the left operand is less than or equal to the right operand. >—the left operand is greater than the right operand. >=—the left operand is greater than or equal to the right operand. inSubnet—the left operand (IP address) is in the subnet of the right operand (subnet). contains—the left operand contains values of the right operand. startsWith—the left operand starts with one of the values of the right operand. endsWith—the left operand ends with one of the values of the right operand. match—the left operand matches the regular expression of the right operand. The RE2 regular expressions are used. hasBit—checks whether the left operand (string or number) contains bits whose positions are listed in the right operand (in a constant or in a list). The value to be checked is converted to binary and processed right to left. Chars are checked whose index is specified as a constant or a list. If the value being checked is a string, then an attempt is made to convert it to integer and process it in the way described above. If the string cannot be converted to a number, the filter returns False. hasVulnerability—checks whether the left operand contains an asset with the vulnerability and vulnerability severity specified in the right operand. If you do not specify the ID and severity of the vulnerability, the filter is triggered if the asset in the event being checked has any vulnerability. inActiveList—this operator has only one operand. Its values are selected in the Key fields field and are compared with the entries in the active list selected from the Active List drop-down list. inContextTable checks whether or not an entry exists in the context table. This operator has only one operand. Its values are selected in the Key fields field and are compared with the values of entries in the context table selected from the drop-down list of context tables. inDictionary—checks whether the specified dictionary contains an entry defined by the key composed with the concatenated values of the selected event fields. inCategory—the asset in the left operand is assigned at least one of the asset categories of the right operand. inActiveDirectoryGroup—the Active Directory account in the left operand belongs to one of the Active Directory groups in the right operand. TIDetect—this operator is used to find events using CyberTrace Threat Intelligence (TI) data. This operator can be used only on events that have completed enrichment with data from CyberTrace Threat Intelligence. In other words, it can only be used in collectors at the destination selection stage and in correlators. If necessary, select the do not match case check box. When this check box is selected, the operator ignores the case of the values. The selection of this check box does not apply to the InSubnet, InActiveList, InCategory or InActiveDirectoryGroup operators. This check box is cleared by default. If you want to add a negative condition, select If not from the If drop-down list. You can add multiple conditions or a group of conditions. If you have added multiple conditions or groups of conditions, choose a search condition (and, or, not) by clicking the AND button. If you want to add existing filters that are selected from the Select filter drop-down list, click the Add filter button. You can view the nested filter settings by clicking the button.

Page top

[Topic 232962]

Kafka type

The kafka type is used for Kafka communications.

Basic settings tab

Setting	Description
Name	Required setting. Unique name of the resource. Must contain 1 to 128 Unicode characters.
Tenant	Required setting. The name of the tenant that owns the resource.
Disabled switch	Used when events must not be sent to the destination. By default, sending events is enabled.
Type	Required setting. Destination type, kafka.
URL	Required setting. URL that you want to connect to. Available formats: `<host>:<port>`, `<IPv4>:<port>`, `:<port>`. IPv6 addresses are also supported, however, when you use them, you must specify the interface as well: `[address%interface]:port`. Example: `[fe80::5054:ff:fe4d:ba0c%eth0]:4222`). You can add multiple addresses using the URL button.
Topic	Required setting. Subject of Kafka messages. Must contain from 1 to 255 of the following characters: a–z, A–Z, 0–9, ".", "_", "-".
Delimiter	Specify a character that defines where one event ends and the other begins. By default, `\n` is used.
Authorization	Type of authorization when connecting to the specified URL Possible values: disabled is the default value. PFX — a certificate must be generated with a private key in PKCS#12 container format in an external Certificate Authority. Then the certificate must be exported from the key store and uploaded to the KUMA web interface as a PFX secret. Add PFX secret If you previously uploaded a PFX certificate, select it from the Secret drop-down list. If no certificate was previously added, the drop-down list shows No data. If you want to add a new certificate, click the button on the right of the Secret list. The Secret window opens. In the Name field, enter the name that will be used to display the secret in the list of available secrets. Click the Upload PFX button to select the file containing your previously exported certificate with a private key in PKCS#12 container format. In the Password field, enter the certificate security password that was set in the Certificate Export Wizard. Click the Save button. The certificate will be added and displayed in the Secret list. plain — you must indicate the secret containing user account credentials for authorization when connecting to the connector. Add secret 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. If you want to add a new secret, click the button on the right of the Secret list. The Secret window opens. In the Name field, enter the name that will be used to display the secret in the list of available secrets. In the User and Password fields, enter the credentials of the user account that the Agent will use to connect to the connector. If necessary, add any other information about the secret in the Description field. Click the Save button. The secret will be added and displayed in the Secret list.
Description	Resource description: up to 4,000 Unicode characters.

Advanced settings tab

Setting	Description
Buffer size	Sets the size of the buffer. The default value is 1 KB, and the maximum value is 64 MB.
Timeout	The time (in seconds) to wait for a response from another service or component. The default value is `30`.
Disk buffer size limit	Size of the disk buffer in bytes. The default value is 10 GB.
TLS mode	Use of TLS encryption. Available values: Disabled (default) means TLS encryption is not used. Enabled means encryption is used, but the certificate is not verified. With verification means encryption is used with verification that the certificate was signed with the KUMA root certificate. The root certificate and key of KUMA are created automatically during program installation and are stored on the KUMA Core server in the folder /opt/kaspersky/kuma/core/certificates/. Custom CA means encryption is used with verification that the certificate was signed by a Certificate Authority. The secret containing the certificate is selected from the Custom CA drop-down list, which is displayed when this option is selected. Creating a certificate signed by a Certificate Authority To use this TLS mode, you must do the following on the KUMA Core server (OpenSSL commands are used in the examples below): Create the key that will be used by the Certificate Authority. Example command: `openssl genrsa -out ca.key 2048` Generate a certificate for the key that was just created. Example command: `openssl req -new -x509 -days 365 -key ca.key -subj "/CN=<common host name of Certificate Authority>" -out ca.crt` Create a private key and a request to have it signed by the Certificate Authority. Example command: `openssl req -newkey rsa:2048 -nodes -keyout server.key -subj "/CN=<common host name of KUMA server>" -out server.csr` Create a certificate signed by the Certificate Authority. The subjectAltName must include the domain names or IP addresses of the server for which the certificate is being created. Example command: `openssl x509 -req -extfile <(printf "subjectAltName=DNS:domain1.ru,DNS:domain2.com,IP:192.168.0.1") -days 365 -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt` The obtained `server.crt` certificate should be uploaded in the KUMA web interface as a certificate-type secret, which should then be selected from the Custom CA drop-down list. When using TLS, it is impossible to specify an IP address as a URL.
Delimiter	In the drop-down list, you can select the character to mark the boundary between events. By default, `\n` is used.
Buffer flush interval	Time (in seconds) between sending batches of data to the destination. The default value is `1 second`.
Workers	This field is used to set the number of services processing the queue. By default, this value is equal to the number of vCPUs of the KUMA Core server.
Debug	A drop-down list in which you can specify whether resource logging must be enabled. The default value is Disabled.
Disk buffer disabled	Drop-down list that lets you enable or disable the disk buffer. By default, the disk buffer is enabled. The disk buffer is used if the collector cannot send normalized events to the destination. The amount of allocated disk space is limited by the value of the Disk buffer size limit setting. If the disk space allocated for the disk buffer is exhausted, events are rotated as follows: new events replace the oldest events written to the buffer.
Filter	In this section, you can specify the criteria for identifying events that must be processed by the resource. You can select an existing filter from the drop-down list or create a new filter. Creating a filter in resources In the Filter drop-down list, select Create new. If you want to keep the filter as a separate resource, select the Save filter check box. In this case, you will be able to use the created filter in various services. This check box is cleared by default. If you selected the Save filter check box, enter a name for the created filter resource in the Name field. The name must contain 1 to 128 Unicode characters. In the Conditions settings block, specify the conditions that the events must meet: Click the Add condition button. In the Left operand and Right operand drop-down lists, specify the search parameters. Depending on the data source selected in the Right operand field, you may see fields of additional parameters that you need to use to define the value that will be passed to the filter. For example, when choosing active list you will need to specify the name of the active list, the entry key, and the entry key field. In the operator drop-down list, select the relevant operator. Filter operators =—the left operand equals the right operand. <—the left operand is less than the right operand. <=—the left operand is less than or equal to the right operand. >—the left operand is greater than the right operand. >=—the left operand is greater than or equal to the right operand. inSubnet—the left operand (IP address) is in the subnet of the right operand (subnet). contains—the left operand contains values of the right operand. startsWith—the left operand starts with one of the values of the right operand. endsWith—the left operand ends with one of the values of the right operand. match—the left operand matches the regular expression of the right operand. The RE2 regular expressions are used. hasBit—checks whether the left operand (string or number) contains bits whose positions are listed in the right operand (in a constant or in a list). The value to be checked is converted to binary and processed right to left. Chars are checked whose index is specified as a constant or a list. If the value being checked is a string, then an attempt is made to convert it to integer and process it in the way described above. If the string cannot be converted to a number, the filter returns False. hasVulnerability—checks whether the left operand contains an asset with the vulnerability and vulnerability severity specified in the right operand. If you do not specify the ID and severity of the vulnerability, the filter is triggered if the asset in the event being checked has any vulnerability. inActiveList—this operator has only one operand. Its values are selected in the Key fields field and are compared with the entries in the active list selected from the Active List drop-down list. inContextTable checks whether or not an entry exists in the context table. This operator has only one operand. Its values are selected in the Key fields field and are compared with the values of entries in the context table selected from the drop-down list of context tables. inDictionary—checks whether the specified dictionary contains an entry defined by the key composed with the concatenated values of the selected event fields. inCategory—the asset in the left operand is assigned at least one of the asset categories of the right operand. inActiveDirectoryGroup—the Active Directory account in the left operand belongs to one of the Active Directory groups in the right operand. TIDetect—this operator is used to find events using CyberTrace Threat Intelligence (TI) data. This operator can be used only on events that have completed enrichment with data from CyberTrace Threat Intelligence. In other words, it can only be used in collectors at the destination selection stage and in correlators. If necessary, select the do not match case check box. When this check box is selected, the operator ignores the case of the values. The selection of this check box does not apply to the InSubnet, InActiveList, InCategory or InActiveDirectoryGroup operators. This check box is cleared by default. If you want to add a negative condition, select If not from the If drop-down list. You can add multiple conditions or a group of conditions. If you have added multiple conditions or groups of conditions, choose a search condition (and, or, not) by clicking the AND button. If you want to add existing filters that are selected from the Select filter drop-down list, click the Add filter button. You can view the nested filter settings by clicking the button.

Page top

[Topic 232965]

File type

The file type is used for writing data to a file.

If you delete a destination of the 'file' type used in a service, that service must be restarted.

Basic settings tab

Setting	Description
Name	Required setting. Unique name of the resource. Must contain 1 to 128 Unicode characters.
Tenant	Required setting. The name of the tenant that owns the resource.
Disabled switch	Used when events must not be sent to the destination. By default, sending events is enabled.
Type	Required setting. Destination type, file.
URL	Required setting. Path to the file to which the events must be written. Limitations when using prefixes in file paths Prefixes that cannot be used when specifying paths to files: /* /bin /boot /dev /etc /home /lib /lib64 /proc /root /run /sys /tmp /usr/* /usr/bin/ /usr/local/* /usr/local/sbin/ /usr/local/bin/ /usr/sbin/ /usr/lib/ /usr/lib64/ /var/* /var/lib/ /var/run/ /opt/kaspersky/kuma/ Files are available at the following paths: /opt/kaspersky/kuma/clickhouse/logs/ /opt/kaspersky/kuma/mongodb/log/ /opt/kaspersky/kuma/victoria-metrics/log/
Description	Resource description: up to 4,000 Unicode characters.

Advanced settings tab

Setting	Description
Buffer size	Sets the size of the buffer. The default value is 1 KB, and the maximum value is 64 MB.
Disk buffer size limit	Size of the disk buffer in bytes. The default value is 10 GB.
Delimiter	In the drop-down list, you can select the character to mark the boundary between events. \n is used by default.
Buffer flush interval	Time (in seconds) between sending batches of data to the destination. The default value is `1 second`.
Number of handlers	This field is used to set the number of services processing the queue. By default, this value is equal to the number of vCPUs of the KUMA Core server.
Debug	A drop-down list in which you can specify whether resource logging must be enabled. The default value is Disabled.
Disk buffer disabled	Drop-down list that lets you enable or disable the disk buffer. By default, the disk buffer is enabled. The disk buffer is used if the collector cannot send normalized events to the destination. The amount of allocated disk space is limited by the value of the Disk buffer size limit setting. If the disk space allocated for the disk buffer is exhausted, events are rotated as follows: new events replace the oldest events written to the buffer.
Filter	In the Filter section, you can specify the criteria for identifying events that must be processed by the resource. You can select an existing filter from the drop-down list or create a new filter. Creating a filter in resources In the Filter drop-down list, select Create new. If you want to keep the filter as a separate resource, select the Save filter check box. In this case, you will be able to use the created filter in various services. This check box is cleared by default. If you selected the Save filter check box, enter a name for the created filter resource in the Name field. The name must contain 1 to 128 Unicode characters. In the Conditions settings block, specify the conditions that the events must meet: Click the Add condition button. In the Left operand and Right operand drop-down lists, specify the search parameters. Depending on the data source selected in the Right operand field, you may see fields of additional parameters that you need to use to define the value that will be passed to the filter. For example, when choosing active list you will need to specify the name of the active list, the entry key, and the entry key field. In the operator drop-down list, select the relevant operator. Filter operators =—the left operand equals the right operand. <—the left operand is less than the right operand. <=—the left operand is less than or equal to the right operand. >—the left operand is greater than the right operand. >=—the left operand is greater than or equal to the right operand. inSubnet—the left operand (IP address) is in the subnet of the right operand (subnet). contains—the left operand contains values of the right operand. startsWith—the left operand starts with one of the values of the right operand. endsWith—the left operand ends with one of the values of the right operand. match—the left operand matches the regular expression of the right operand. The RE2 regular expressions are used. hasBit—checks whether the left operand (string or number) contains bits whose positions are listed in the right operand (in a constant or in a list). The value to be checked is converted to binary and processed right to left. Chars are checked whose index is specified as a constant or a list. If the value being checked is a string, then an attempt is made to convert it to integer and process it in the way described above. If the string cannot be converted to a number, the filter returns False. hasVulnerability—checks whether the left operand contains an asset with the vulnerability and vulnerability severity specified in the right operand. If you do not specify the ID and severity of the vulnerability, the filter is triggered if the asset in the event being checked has any vulnerability. inActiveList—this operator has only one operand. Its values are selected in the Key fields field and are compared with the entries in the active list selected from the Active List drop-down list. inContextTable checks whether or not an entry exists in the context table. This operator has only one operand. Its values are selected in the Key fields field and are compared with the values of entries in the context table selected from the drop-down list of context tables. inDictionary—checks whether the specified dictionary contains an entry defined by the key composed with the concatenated values of the selected event fields. inCategory—the asset in the left operand is assigned at least one of the asset categories of the right operand. inActiveDirectoryGroup—the Active Directory account in the left operand belongs to one of the Active Directory groups in the right operand. TIDetect—this operator is used to find events using CyberTrace Threat Intelligence (TI) data. This operator can be used only on events that have completed enrichment with data from CyberTrace Threat Intelligence. In other words, it can only be used in collectors at the destination selection stage and in correlators. If necessary, select the do not match case check box. When this check box is selected, the operator ignores the case of the values. The selection of this check box does not apply to the InSubnet, InActiveList, InCategory or InActiveDirectoryGroup operators. This check box is cleared by default. If you want to add a negative condition, select If not from the If drop-down list. You can add multiple conditions or a group of conditions. If you have added multiple conditions or groups of conditions, choose a search condition (and, or, not) by clicking the AND button. If you want to add existing filters that are selected from the Select filter drop-down list, click the Add filter button. You can view the nested filter settings by clicking the button.

Page top

[Topic 232973]

Storage type

The storage type is used to transmit data to the storage.

Basic settings tab

Setting	Description
Name	Required setting. Unique name of the resource. Must contain 1 to 128 Unicode characters.
Tenant	Required setting. The name of the tenant that owns the resource.
Disabled switch	Used when events must not be sent to the destination. By default, sending events is enabled.
Type	Required setting. Destination type, storage.
URL	Required setting. URL that you want to connect to. Available formats: `<host>:<port>`, `<IPv4>:<port>`, `:<port>`. IPv6 addresses are also supported, however, when you use them, you must specify the interface as well: `[address%interface]:port`. Example: `[fe80::5054:ff:fe4d:ba0c%eth0]:4222`). You can add multiple addresses using the URL button. The URL field supports search for services by FQDN, IP address, and name. Search string formats: `<Search value>`—search is performed by FQDN, IP addresses, and service names. `<First search value ending in one or more digits>:<second search value>`—the first value is used to search by the service FQDN or IP address, and the second value is used to search by port. `:<value>`—search is performed by port.
Description	Resource description: up to 4,000 Unicode characters.

Advanced settings tab

Setting	Description
Proxy server	Drop-down list for selecting a proxy server.
Buffer size	Sets the size of the buffer. The default value is 1 KB, and the maximum value is 64 MB.
Timeout	The time (in seconds) to wait for a response from another service or component. The default value is `30`.
Disk buffer size limit	Size of the disk buffer in bytes. The default value is 10 GB.
URL selection policy	Drop-down list in which you can select a method for determining which URL to send events to if several URLs have been specified: Any. Events are sent to one of the available URLs as long as this URL receives events. If the connection is broken (for example, the receiving node is disconnected) a different URL will be selected as the events destination. Prefer first. Events are sent to the first URL in the list of added addresses. If it becomes unavailable, events are sent to the next available node in sequence. When the first URL becomes available again, events start to be sent to it again. Round robin. Packets with events will be evenly distributed among available URLs from the list. Because packets are sent either on a destination buffer overflow or on the flush timer, this URL selection policy does not guarantee an equal distribution of events to destinations.
Buffer flush interval	Time (in seconds) between sending batches of data to the destination. The default value is `1 second`.
Workers	This field is used to set the number of services processing the queue. By default, this value is equal to the number of vCPUs of the KUMA Core server.
Health check timeout	Frequency of the health check in seconds.
Debug	A drop-down list in which you can specify whether resource logging must be enabled. The default value is Disabled.
Disk buffer disabled	Drop-down list that lets you enable or disable the disk buffer. By default, the disk buffer is enabled. The disk buffer is used if the collector cannot send normalized events to the destination. The amount of allocated disk space is limited by the value of the Disk buffer size limit setting. If the disk space allocated for the disk buffer is exhausted, events are rotated as follows: new events replace the oldest events written to the buffer.
Filter	In this section, you can specify the criteria for identifying events that must be processed by the resource. You can select an existing filter from the drop-down list or create a new filter. Creating a filter in resources In the Filter drop-down list, select Create new. If you want to keep the filter as a separate resource, select the Save filter check box. In this case, you will be able to use the created filter in various services. This check box is cleared by default. If you selected the Save filter check box, enter a name for the created filter resource in the Name field. The name must contain 1 to 128 Unicode characters. In the Conditions settings block, specify the conditions that the events must meet: Click the Add condition button. In the Left operand and Right operand drop-down lists, specify the search parameters. Depending on the data source selected in the Right operand field, you may see fields of additional parameters that you need to use to define the value that will be passed to the filter. For example, when choosing active list you will need to specify the name of the active list, the entry key, and the entry key field. In the operator drop-down list, select the relevant operator. Filter operators =—the left operand equals the right operand. <—the left operand is less than the right operand. <=—the left operand is less than or equal to the right operand. >—the left operand is greater than the right operand. >=—the left operand is greater than or equal to the right operand. inSubnet—the left operand (IP address) is in the subnet of the right operand (subnet). contains—the left operand contains values of the right operand. startsWith—the left operand starts with one of the values of the right operand. endsWith—the left operand ends with one of the values of the right operand. match—the left operand matches the regular expression of the right operand. The RE2 regular expressions are used. hasBit—checks whether the left operand (string or number) contains bits whose positions are listed in the right operand (in a constant or in a list). The value to be checked is converted to binary and processed right to left. Chars are checked whose index is specified as a constant or a list. If the value being checked is a string, then an attempt is made to convert it to integer and process it in the way described above. If the string cannot be converted to a number, the filter returns False. hasVulnerability—checks whether the left operand contains an asset with the vulnerability and vulnerability severity specified in the right operand. If you do not specify the ID and severity of the vulnerability, the filter is triggered if the asset in the event being checked has any vulnerability. inActiveList—this operator has only one operand. Its values are selected in the Key fields field and are compared with the entries in the active list selected from the Active List drop-down list. inContextTable checks whether or not an entry exists in the context table. This operator has only one operand. Its values are selected in the Key fields field and are compared with the values of entries in the context table selected from the drop-down list of context tables. inDictionary—checks whether the specified dictionary contains an entry defined by the key composed with the concatenated values of the selected event fields. inCategory—the asset in the left operand is assigned at least one of the asset categories of the right operand. inActiveDirectoryGroup—the Active Directory account in the left operand belongs to one of the Active Directory groups in the right operand. TIDetect—this operator is used to find events using CyberTrace Threat Intelligence (TI) data. This operator can be used only on events that have completed enrichment with data from CyberTrace Threat Intelligence. In other words, it can only be used in collectors at the destination selection stage and in correlators. If necessary, select the do not match case check box. When this check box is selected, the operator ignores the case of the values. The selection of this check box does not apply to the InSubnet, InActiveList, InCategory or InActiveDirectoryGroup operators. This check box is cleared by default. If you want to add a negative condition, select If not from the If drop-down list. You can add multiple conditions or a group of conditions. If you have added multiple conditions or groups of conditions, choose a search condition (and, or, not) by clicking the AND button. If you want to add existing filters that are selected from the Select filter drop-down list, click the Add filter button. You can view the nested filter settings by clicking the button.

Page top

[Topic 232976]

Correlator type

The correlator type is used to transmit data to the correlator.

Basic settings tab

Setting	Description
Name	Required setting. Unique name of the resource. Must contain 1 to 128 Unicode characters.
Tenant	Required setting. The name of the tenant that owns the resource.
Disabled switch	Used when events must not be sent to the destination. By default, sending events is enabled.
Type	Required setting. Destination type, correlator.
URL	Required setting. URL that you want to connect to. Available formats: `<host>:<port>`, `<IPv4>:<port>`, `:<port>`. IPv6 addresses are also supported, however, when you use them, you must specify the interface as well: `[address%interface]:port`. Example: `[fe80::5054:ff:fe4d:ba0c%eth0]:4222`). You can add multiple addresses using the URL button. The URL field supports search for services by FQDN, IP address, and name. Search string formats: `<Search value>`—search is performed by FQDN, IP addresses, and service names. `<First search value ending in one or more digits>:<second search value>`—the first value is used to search by the service FQDN or IP address, and the second value is used to search by port. `:<value>`—search is performed by port.
Description	Resource description: up to 4,000 Unicode characters.

Advanced settings tab

Setting	Description
Proxy server	Drop-down list for selecting a proxy server.
Buffer size	Sets the size of the buffer. The default value is 1 KB, and the maximum value is 64 MB.
Timeout	The time (in seconds) to wait for a response from another service or component. The default value is `30`.
Disk buffer size limit	Size of the disk buffer in bytes. The default value is 10 GB.
URL selection policy	Drop-down list in which you can select a method for determining which URL to send events to if several URLs have been specified: Any. Events are sent to one of the available URLs as long as this URL receives events. If the connection is broken (for example, the receiving node is disconnected) a different URL will be selected as the events destination. Prefer first. Events are sent to the first URL in the list of added addresses. If it becomes unavailable, events are sent to the next available node in sequence. When the first URL becomes available again, events start to be sent to it again. Round robin. Packets with events will be evenly distributed among available URLs from the list. Because packets are sent either on a destination buffer overflow or on the flush timer, this URL selection policy does not guarantee an equal distribution of events to destinations.
Buffer flush interval	Time (in seconds) between sending batches of data to the destination. The default value is `1 second`.
Workers	This field is used to set the number of services processing the queue. By default, this value is equal to the number of vCPUs of the KUMA Core server.
Health check timeout	Frequency of the health check in seconds.
Debug	A drop-down list in which you can specify whether resource logging must be enabled. The default value is Disabled.
Disk buffer disabled	Drop-down list that lets you enable or disable the disk buffer. By default, the disk buffer is enabled. The disk buffer is used if the collector cannot send normalized events to the destination. The amount of allocated disk space is limited by the value of the Disk buffer size limit setting. If the disk space allocated for the disk buffer is exhausted, events are rotated as follows: new events replace the oldest events written to the buffer.
Filter	In the Filter section, you can specify the criteria for identifying events that must be processed by the resource. You can select an existing filter from the drop-down list or create a new filter. Creating a filter in resources In the Filter drop-down list, select Create new. If you want to keep the filter as a separate resource, select the Save filter check box. In this case, you will be able to use the created filter in various services. This check box is cleared by default. If you selected the Save filter check box, enter a name for the created filter resource in the Name field. The name must contain 1 to 128 Unicode characters. In the Conditions settings block, specify the conditions that the events must meet: Click the Add condition button. In the Left operand and Right operand drop-down lists, specify the search parameters. Depending on the data source selected in the Right operand field, you may see fields of additional parameters that you need to use to define the value that will be passed to the filter. For example, when choosing active list you will need to specify the name of the active list, the entry key, and the entry key field. In the operator drop-down list, select the relevant operator. Filter operators =—the left operand equals the right operand. <—the left operand is less than the right operand. <=—the left operand is less than or equal to the right operand. >—the left operand is greater than the right operand. >=—the left operand is greater than or equal to the right operand. inSubnet—the left operand (IP address) is in the subnet of the right operand (subnet). contains—the left operand contains values of the right operand. startsWith—the left operand starts with one of the values of the right operand. endsWith—the left operand ends with one of the values of the right operand. match—the left operand matches the regular expression of the right operand. The RE2 regular expressions are used. hasBit—checks whether the left operand (string or number) contains bits whose positions are listed in the right operand (in a constant or in a list). The value to be checked is converted to binary and processed right to left. Chars are checked whose index is specified as a constant or a list. If the value being checked is a string, then an attempt is made to convert it to integer and process it in the way described above. If the string cannot be converted to a number, the filter returns False. hasVulnerability—checks whether the left operand contains an asset with the vulnerability and vulnerability severity specified in the right operand. If you do not specify the ID and severity of the vulnerability, the filter is triggered if the asset in the event being checked has any vulnerability. inActiveList—this operator has only one operand. Its values are selected in the Key fields field and are compared with the entries in the active list selected from the Active List drop-down list. inContextTable checks whether or not an entry exists in the context table. This operator has only one operand. Its values are selected in the Key fields field and are compared with the values of entries in the context table selected from the drop-down list of context tables. inDictionary—checks whether the specified dictionary contains an entry defined by the key composed with the concatenated values of the selected event fields. inCategory—the asset in the left operand is assigned at least one of the asset categories of the right operand. inActiveDirectoryGroup—the Active Directory account in the left operand belongs to one of the Active Directory groups in the right operand. TIDetect—this operator is used to find events using CyberTrace Threat Intelligence (TI) data. This operator can be used only on events that have completed enrichment with data from CyberTrace Threat Intelligence. In other words, it can only be used in collectors at the destination selection stage and in correlators. If necessary, select the do not match case check box. When this check box is selected, the operator ignores the case of the values. The selection of this check box does not apply to the InSubnet, InActiveList, InCategory or InActiveDirectoryGroup operators. This check box is cleared by default. If you want to add a negative condition, select If not from the If drop-down list. You can add multiple conditions or a group of conditions. If you have added multiple conditions or groups of conditions, choose a search condition (and, or, not) by clicking the AND button. If you want to add existing filters that are selected from the Select filter drop-down list, click the Add filter button. You can view the nested filter settings by clicking the button.

Page top

[Topic 250830]

Predefined destinations

Destinations listed in the table below are included in the KUMA distribution kit.

Predefined destinations

Destination name	Description
[OOTB] Correlator	Sends events to a correlator.
[OOTB] Storage	Sends events to storage.

Page top

[Topic 228267]

Working with events

In the Events section of the KUMA web interface, you can inspect events received by the program to investigate security threats or create correlation rules. The events table displays the data received after the SQL query is executed.

Events can be sent to the correlator for a retroscan.

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

In this Help topic

Filtering and searching events

See also:

Normalized event data model

Program architecture

Page top

[Topic 228277]

Filtering and searching events

The Events section of the KUMA web interface does not show any data by default. To view events, you need to define an SQL query in the search field and click the SearchField button. The SQL query can be entered manually or it can be generated using a query builder.

Data aggregation and grouping is supported in SQL queries.

You can add filter conditions to an already generated SQL query in the window for viewing statistics, the events table, and the event details area:

Changing a query from the Statistics window
To change the filtering settings in the Statistics window:
1. Open Statistics details area by using one of the following methods:
  - In the drop-down list in the top right corner of the events table select Statistics.
  - In the events table click any value and in the opened context menu select Statistics.
  The Statistics details area appears in the right part of the web interface window.
2. Open the drop-down list of the relevant parameter and hover your mouse cursor over the necessary value.
3. Use the plus and minus signs to change the filter settings by doing one of the following:
  - If you want the events selection to include only events with the selected value, click the icon.
  - If you want the events selection to exclude all events with the selected value, click the icon.
As a result, the filter settings and the events table will be updated, and the new search query will be displayed in the upper part of the screen.
Changing a query from the events table
To change the filtering settings in the events table:
1. In the Events section of the KUMA web interface, click any event parameter value in the events table.
2. In the opened menu, select one of the following options:
  - If you want the table to show only events with the selected value, select Filter by this value.
  - If you want to exclude all events with the selected value from the table, select Exclude from filter.
As a result, the filter settings and the events table are updated, and the new search query is displayed in the upper part of the screen.
Changing a query from the Event details area
To change the filter settings in the event details area:
1. In the Events section of the KUMA web interface, click the relevant event.
  The Event details area appears in the right part of the window.
2. Change the filter settings by using the plus or minus icons next to the relevant settings:
  - If you want the events selection to include only events with the selected value, click the icon.
  - If you want the events selection to exclude all events with the selected value, click the icon.
As a result, the filter settings and the events table will be updated, and the new search query will be displayed in the upper part of the screen.

After modifying a query, all query parameters, including the added filter conditions, are transferred to the query builder and the search field.

When you switch to the query builder, the parameters of a query entered manually in the search field are not transferred to the builder, so you will need to create your query again. Also, the query created in the builder does not overwrite the query that was entered into the search string until you click the Apply button in the builder window.

In the SQL query input field, you can enable the display of control characters.

You can also filter events by time period. Search results can be automatically updated.

The filter configuration can be saved. Existing filter configurations can be deleted.

Filter functions are available for users regardless of their roles.

When accessing certain event fields with IDs, KUMA returns the corresponding names.

For more details on SQL, refer to the ClickHouse documentation. See also KUMA operator usage and supported functions.

In this section

Selecting Storage

Generating an SQL query using a builder

Manually creating an SQL query

Filtering events by period

Displaying names instead of IDs

Presets

Limiting the complexity of queries in alert investigation mode

Saving and selecting events filter configuration

Deleting event filter configurations

Supported ClickHouse functions

Viewing event detail areas

Exporting events

Configuring the table of events

Refreshing events table

Getting events table statistics

Viewing correlation event details

See also:

Page top

[Topic 217994]

Selecting Storage

Events that are displayed in the Events section of the KUMA web interface are retrieved from storage (from the ClickHouse cluster). Depending on the demands of your company, you may have more than one Storage. However, you can only receive events from one Storage at a time, so you must specify which one you want to use.

To select the Storage you want to receive events from,

In the Events section of the KUMA web interface, open the cluster drop-down list and select the relevant storage cluster.

Now events from the selected storage are displayed in the events table. The name of the selected storage is displayed in the cluster drop-down list.

The cluster drop-down list displays only the clusters of tenants available to the user, and the cluster of the main tenant.

See also:

Manually creating an SQL query

Page top

[Topic 228337]

Generating an SQL query using a builder

In KUMA, you can use a query builder to generate an SQL query for filtering events.

To generate an SQL query using a builder:

In the Events section of the KUMA web interface, click the button.
The filter constructor window opens.
Generate a search query by providing data in the following parameter blocks:
SELECT—event fields that should be returned. The * value is selected by default, which means that all available event fields must be returned. To make viewing the search results easier, select the necessary fields in the drop-down list. In this case, the data only for the selected fields is displayed in the table. Note that Select * increases the duration of the request execution, but eliminates the need to manually indicate the fields in the request.

When selecting an event field, you can use the field on the right of the drop-down list to specify an alias for the column of displayed data, and you can use the right-most drop-down list to select the operation to perform on the data: count, max, min, avg, sum.

If you are using aggregation functions in a query, you cannot customize the events table display, sort events in ascending or descending order, or receive statistics.

When filtering by alert-related events in alert investigation mode, you cannot perform operations on the data of event fields or assign names to the columns of displayed data.
- FROM—data source. Select the events value.
- WHERE—conditions for filtering events.
  Conditions and groups of conditions can be added by using the Add condition and Add group buttons. The AND operator value is selected by default in a group of conditions, but the operator can be changed by clicking on this value. Available values: AND, OR, NOT. The structure of conditions and condition groups can be changed by using the icon to drag and drop expressions.
  
  Adding filter conditions:
  1. In the drop-down list on the left, select the event field that you want to use for filtering.
  2. Select the necessary operator from the middle drop-down list. The available operators depend on the type of value of the selected event field.
  3. Enter the value of the condition. Depending on the selected type of field, you may have to manually enter the value, select it from the drop-down list, or select it on the calendar.
  Filter conditions can be deleted by using the button. Group conditions are deleted using the Delete group button.
- GROUP BY—event fields or aliases to be used for grouping the returned data.
  If you are using data grouping in a query, you cannot customize the events table display, sort events in ascending or descending order, receive statistics, or perform a retroscan.
  
  When filtering by alert-related events in alert investigation mode, you cannot group the returned data.
- ORDER BY—columns used as the basis for sorting the returned data. In the drop-down list on the right, you can select the necessary order: DESC—descending, ASC—ascending.
- LIMIT—number of strings displayed in the table.
  The default value is 250.
  
  If you are filtering events by user-defined period and the number of strings in the search results exceeds the defined value, you can click the Show next records button to display additional strings in the table. This button is not displayed when filtering events by the standard period.
Click Apply.
The current SQL query will be overwritten. The generated SQL query is displayed in the search field.

If you want to reset the builder settings, click the Default query button.

If you want to close the builder without overwriting the existing query, click the button.
Click the button to display the data in the table.

The table will display the search results based on the generated SQL query.

When switching to another section of the web interface, the query generated in the builder is not preserved. If you return to the Events section from another section, the builder will display the default query.

For more details on SQL, refer to the ClickHouse documentation. See also KUMA operator usage and supported functions.

See also:

Generating an SQL query using a builder

Page top

[Topic 228356]

Manually creating an SQL query

You can use the search string to manually create SQL queries of any complexity for filtering events.

To manually generate an SQL query:

Go to the Events section of the KUMA web interface.
An input form opens.
Enter your SQL query into the input field.
Click the button.

You will see a table of events that satisfy the criteria of your query. If necessary, you can filter events by period.

Supported functions and operators

SELECT—event fields that should be returned.
For SELECT fields, the program supports the following functions and operators:
- Aggregation functions: count, avg, max, min, sum.
- Arithmetic operators: +, -, *, /, <, >, =, !=, >=, <=.
  You can combine these functions and operators.
  
  If you are using aggregation functions in a query, you cannot customize the events table display, sort events in ascending or descending order, or receive statistics.
DISTINCT–removes duplicates from the result of a SELECT statement. You must use the following notation: SELECT DISTINCT SourceAddress as Addresses FROM <rest of the query>.
FROM—data source.
When creating a query, you need to specify the events value as the data source.
WHERE—conditions for filtering events.
- AND, OR, NOT, =, !=, >, >=, <, <=
- IN
- BETWEEN
- LIKE
- ILIKE
- inSubnet
- match (the re2 syntax of regular expressions is used in queries, special characters must be shielded with "\")
GROUP BY—event fields or aliases to be used for grouping the returned data.
If you are using data grouping in a query, you cannot customize the events table display, sort events in ascending or descending order, receive statistics, or perform a retroscan.
ORDER BY—columns used as the basis for sorting the returned data.
Possible values:
- DESC—descending order.
- ASC—ascending order.
OFFSET—skip the indicated number of lines before printing the query results output.

LIMIT—number of strings displayed in the table.

The default value is 250.

If you are filtering events by user-defined period and the number of strings in the search results exceeds the defined value, you can click the Show next records button to display additional strings in the table. This button is not displayed when filtering events by the standard period.

Example queries:

SELECT * FROM `events` WHERE Type IN ('Base', 'Audit') ORDER BY Timestamp DESC LIMIT 250
In the events table, all events with the Base and Audit type are sorted by the Timestamp column in descending order. The number of strings that can be displayed in the table is 250.
SELECT * FROM `events` WHERE BytesIn BETWEEN 1000 AND 2000 ORDER BY Timestamp ASC LIMIT 250
All events of the events table for which the BytesIn field contains a value of received traffic in the range from 1,000 to 2,000 bytes are sorted by the Timestamp column in ascending order. The number of strings that can be displayed in the table is 250.
SELECT * FROM `events` WHERE Message LIKE '%ssh:%' ORDER BY Timestamp DESC LIMIT 250
In the events table, all events whose Message field contains data corresponding to the defined %ssh:% template in lowercase are sorted by the Timestamp column in descending order. The number of strings that can be displayed in the table is 250.
SELECT * FROM `events` WHERE inSubnet(DeviceAddress, '00.0.0.0/00') ORDER BY Timestamp DESC LIMIT 250
In the events table, all events for the hosts that are in the 00.0.0.0/00 subnet are sorted by the Timestamp column in descending order. The number of strings that can be displayed in the table is 250.
SELECT * FROM `events` WHERE match(Message, 'ssh.*') ORDER BY Timestamp DESC LIMIT 250
In the events table, all events whose Message field contains text corresponding to the ssh.* template are sorted by the Timestamp column in descending order. The number of strings that can be displayed in the table is 250.
SELECT max(BytesOut) / 1024 FROM `events`
Maximum amount of outbound traffic (KB) for the selected time period.
SELECT count(ID) AS "Count", SourcePort AS "Port" FROM `events` GROUP BY SourcePort ORDER BY Port ASC LIMIT 250
Number of events and port number. Events are grouped by port number and sorted by the Port column in ascending order. The number of strings that can be displayed in the table is 250.

The ID column in the events table is named Count, and the SourcePort column is named Port.

If you want to use a special character in a query, you need to escape this character by placing a backslash (\) character in front of it.

Example:

SELECT * FROM `events` WHERE match(Message, 'ssh:\'connection.*') ORDER BY Timestamp DESC LIMIT 250

In the events table, all events whose Message field contains text corresponding to the ssh: 'connection' template are sorted by the Timestamp column in descending order. The number of strings that can be displayed in the table is 250.

When creating a normalizer for events, you can choose whether to retain the field values of the raw event. The data is stored in the Extra event field. This field is searched for events by using the LIKE operator.

Example:

SELECT * FROM `events` WHERE DeviceAddress = '00.00.00.000' AND Extra LIKE '%"app":"example"%' ORDER BY Timestamp DESC LIMIT 250

In the events table, all events for hosts with the IP address 00.00.00.000 where the example process is running are sorted by the Timestamp column in descending order. The number of strings that can be displayed in the table is 250.

When switching to the query builder, the query parameters that were manually entered into the search string are not transferred to the builder so you will need to create your query again. Also, the query created in the builder does not overwrite the query that was entered into the search string until you click the Apply button in the builder window.

Aliases must not contain spaces.

For more details on SQL, refer to the ClickHouse documentation. See also the supported ClickHouse functions.

See also:

Limiting the complexity of queries in alert investigation mode