Integration with other solutions

In this section, you'll learn how to integrate KUMA with other solutions to enrich its functionality.

Integration with Kaspersky Security Center

You can configure integration with selected Kaspersky Security Center servers for one, several, or all KUMA tenants. If Kaspersky Security Center integration is enabled, you can import information about the assets protected by this application, manage assets using tasks, and import events from the Kaspersky Security Center event database.

First, you need to make sure that the relevant Kaspersky Security Center server allows an incoming connection for the server hosting KUMA.

Configuring KUMA integration with Kaspersky Security Center includes the following steps:

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

   The secret (account role in Kaspersky Security Center) for integrating KUMA with Kaspersky Security Center must be created with consideration of how the hierarchy of the Administration Server is organized (availability of virtual servers, server administration features, etc) and types of devices that the Administration Server will manage (OS, type: servers, mobile devices, etc). All these nuances are regulated and configured on the Kaspersky Security Center side.

   The following actions can be performed in KUMA on assets from Kaspersky Security Center:

   • Starting a task of the Update type.
   • Starting a task of the Virus Scan type.
   • Moving assets between Kaspersky Security Center groups.
   • Accepting software updates (to fix a vulnerability of an asset in Kaspersky Security Center).

   To be able to perform the actions listed above, you can use a predefined account in Kaspersky Security Center with the Main Administrator role. In this case, you do not need to add permissions manually.

   You can also use the "Kaspersky Endpoint Security Administrator" predefined role in Kaspersky Security Center, but in that case, you must additionally grant access to the following functionality:

   1. Management of administration groups
   2. Vulnerability and patch management

      Some additional permissions may be required depending on the configuration of Kaspersky Security Center.

   Minimum permissions for integration with Kaspersky Security Center:

   - "Access objects regardless of their ACLs" allows you to import Kaspersky Security Center assets into KUMA.

   - "Management of administration groups" allows you to move assets between groups in Kaspersky Security Center from the KUMA interface.

   - "Basic functionality" allows you to create and run tasks on Kaspersky Endpoint Security hosts.

   For more details about creating a user account and assigning permissions to a user, please refer to the Kaspersky Security Center Help Guide.

2. Creating a secret of the credentials type for connecting to Kaspersky Security Center
3. Configuring Kaspersky Security Center integration settings
4. Creating a connection to the Kaspersky Security Center server for importing information about assets

   If you want to import information about assets registered on Kaspersky Security Center servers into KUMA, you need to create a separate connection to each Kaspersky Security Center server for each selected tenant.

   If integration is disabled for the tenant or there is no connection to Kaspersky Security Center, an error is displayed in the KUMA web interface when attempting to import information about assets. In this case, the import process does not start.

Configuring Kaspersky Security Center integration settings

To configure the settings for integration with Kaspersky Security Center:

1. Open the KUMA web interface and select Settings → Kaspersky Security Center.

   The Kaspersky Security Center integration by tenant window opens.

2. Select the tenant for which you want to configure integration with Kaspersky Security Center.

   The Kaspersky Security Center integration window opens.

3. Enable or disable integration with Kaspersky Security Center for the tenant:
   • If you want to enable integration, clear the Disabled check box.
   • If you want to disable integration, select the Disabled check box.

   This check box is cleared by default.

4. Specify intervals for automatic import of asset information and asset vulnerability information from Kaspersky Security Center:
   1. In the KSC assets, hardware information field, enter the interval in hours for the automatic import of information about the basic attributes of assets (protection status, anti-virus database version, hardware). and must be an integer. The default setting is 1 (1 hour).
   2. In the KSC assets attributes (vulnerabilities, software, owners) field, enter the interval in hours for automatic import of information about other attributes of assets (vulnerabilities, software, owners). and must be an integer. The default setting is 12 (12 hours).

      Importing the information about asset attributes (vulnerabilities, software, owners) may involve downloading a large amount of data, which may take a longer time to complete, we recommend setting a longer interval than for the hardware information import.

   If necessary, you can manually import asset information and asset vulnerability information from Kaspersky Security Center.

5. Click the Save button.

The Kaspersky Security Center integration settings for the selected tenant will be configured.

If the tenant you need is missing from the list of tenants, you need to add the tenant to the list of tenants.

Adding a tenant to the list for Kaspersky Security Center integration

To add a tenant to the list of tenants for integration with Kaspersky Security Center:

1. Open the KUMA web interface and select Settings → Kaspersky Security Center.

   The Kaspersky Security Center integration by tenant window opens.

2. Click the Add tenant button.

   The Kaspersky Security Center integration window opens.

3. In the Tenant drop-down list, select the tenant that you need to add.
4. Click the Save button.

The selected tenant will be added to the list of tenants for integration with Kaspersky Security Center.

Creating Kaspersky Security Center connection

To create a new Kaspersky Security Center connection:

1. Open the KUMA web interface and select Settings → Kaspersky Security Center.

   The Kaspersky Security Center integration by tenant window opens.

2. Select the tenant for which you want to create a connection to Kaspersky Security Center.
3. Click the Add connection button and define the values for the following settings:
   • Name (required)—the name of the connection. The name can contain 1 to 128 Unicode characters.
   • URL (required)—the URL of the Kaspersky Security Center server in hostname:port or IPv4:port format.
   • In the Secret drop-down list, select the secret with the Kaspersky Security Center account credentials or create a new secret.
     1. Click the plus () icon.

        The secret window is displayed.

     2. Enter information about the secret:
        1. In the Name field, choose a name for the added secret.
        2. In the Tenant drop-down list, select the tenant that will own the Kaspersky Security Center account credentials.
        3. In the Type drop-down list, select credentials.
        4. In the User and Password fields, enter the account credentials for your Kaspersky Security Center server.
        5. If you want, enter a Description of the secret.
     3. Click Save.

     You can change the selected secret by clicking .

   • Disabled—the state of the connection to the selected Kaspersky Security Center server. If the check box is selected, the connection to the selected server is inactive. If this is the case, you cannot use this connection to connect to the Kaspersky Security Center server.

     This check box is cleared by default.

4. If you want KUMA to import only assets that are connected to secondary servers or included in groups:
   1. Click the Load hierarchy button.
   2. Select the check boxes next to the names of the secondary servers and groups from which you want to import asset information.
   3. If you want to import assets only from new groups, select the Import assets from new groups check box.

   If no check boxes are selected, information about all assets of the selected Kaspersky Security Center server is uploaded during the import.

5. Click Save.

The connection to the Kaspersky Security Center server is now created. It can be used to import information about assets from Kaspersky Security Center to KUMA and to create asset-related tasks in Kaspersky Security Center from KUMA.

Editing Kaspersky Security Center connection

To edit a Kaspersky Security Center connection:

1. Open the KUMA web interface and select Settings → Kaspersky Security Center.

   The Kaspersky Security Center integration by tenant window opens.

2. Select the tenant for which you want to configure integration with Kaspersky Security Center.

   The Kaspersky Security Center integration window opens.

3. Click the Kaspersky Security Center connection you want to change.

   The window with the selected Kaspersky Security Center connection parameters opens.

4. Make the necessary changes to the settings.
5. Click the Save button.

The Kaspersky Security Center connection will be changed.

Deleting Kaspersky Security Center connection

To delete a Kaspersky Security Center connection:

1. Open the KUMA web interface and select Settings → Kaspersky Security Center.

   The Kaspersky Security Center integration by tenant window opens.

2. Select the tenant for which you want to configure integration with Kaspersky Security Center.

   The Kaspersky Security Center integration window opens.

3. Select the Kaspersky Security Center connection that you want to delete.
4. Click the Delete button.

The Kaspersky Security Center connection will be deleted.

Importing events from the Kaspersky Security Center database

In KUMA, you can receive events from the Kaspersky Security Center SQL database. Events are received using the collector, which uses the following resources:

• Predefined [OOTB] KSC MSSQL, [OOTB] KSC MySQL, or [OOTB] KSC PostgreSQL connector.
• Predefined [OOTB] KSC from SQL normalizer.

Configuring the import of events from Kaspersky Security Center involves the following steps:

1. Create a copy of the predefined connector.

   The settings of the predefined connector are not editable, therefore, to configure the connection to the database server, you must create a copy of the predefined connector.

2. Creating a collector:
   • In the web interface.
   • On the server.

To configure the import of events from Kaspersky Security Center:

1. Create a copy of the predefined connector corresponding to the type of database used by Kaspersky Security Center:
   1. In the KUMA web interface, in the Resources → Connectors section, find the relevant predefined connector in the folder hierarchy, select the check box next to that connector, and click Duplicate.
   2. This opens the Create connector window; in that window, on the Basic settings tab, in the Default query field, if necessary, replace the KAV database name with the name of the Kaspersky Security Center database you are using.

      An example of a query to the Kaspersky Security Center SQL database

      SELECT ev.event_id AS externalId, ev.severity AS severity, ev.task_display_name AS taskDisplayName,

              ev.product_name AS product_name, ev.product_version AS product_version,

               ev.event_type As deviceEventClassId, ev.event_type_display_name As event_subcode, ev.descr As msg,

      CASE

              WHEN ev.rise_time is not NULL THEN DATEADD(hour,DATEDIFF(hour,GETUTCDATE(),GETDATE()),ev.rise_time )

                  ELSE ev.rise_time

              END

          AS endTime,

          CASE

              WHEN ev.registration_time is not NULL

                  THEN DATEADD(hour,DATEDIFF(hour,GETUTCDATE(),GETDATE()),ev.registration_time )

                  ELSE ev.registration_time

              END

          AS kscRegistrationTime,

          cast(ev.par7 as varchar(4000)) as sourceUserName,

          hs.wstrWinName as dHost,

          hs.wstrWinDomain as strNtDom, serv.wstrWinName As kscName,

              CAST(hs.nIp / 256 / 256 / 256 % 256 AS VARCHAR) + '.' +

          CAST(hs.nIp / 256 / 256 % 256 AS VARCHAR) + '.' +

          CAST(hs.nIp / 256 % 256 AS VARCHAR) + '.' +

          CAST(hs.nIp % 256 AS VARCHAR) AS sourceAddress,

          serv.wstrWinDomain as kscNtDomain,

              CAST(serv.nIp / 256 / 256 / 256 % 256 AS VARCHAR) + '.' +

          CAST(serv.nIp / 256 / 256 % 256 AS VARCHAR) + '.' +

          CAST(serv.nIp / 256 % 256 AS VARCHAR) + '.' +

          CAST(serv.nIp % 256 AS VARCHAR) AS kscIP,

          CASE

          WHEN virus.tmVirusFoundTime is not NULL

                  THEN DATEADD(hour,DATEDIFF(hour,GETUTCDATE(),GETDATE()),virus.tmVirusFoundTime )

                  ELSE ev.registration_time

              END

          AS virusTime,

          virus.wstrObject As filePath,

          virus.wstrVirusName as virusName,

          virus.result_ev as result

      FROM KAV.dbo.ev_event as ev

      LEFT JOIN KAV.dbo.v_akpub_host as hs ON ev.nHostId = hs.nId

      INNER JOIN KAV.dbo.v_akpub_host As serv ON serv.nId = 1

      Left Join KAV.dbo.rpt_viract_index as Virus on ev.event_id = virus.nEventVirus

      where registration_time >= DATEADD(minute, -191, GetDate())

   3. Place the cursor in the URL field and in the displayed list, click in the line of the secret that you are using.
   4. This opens the Secret window; in that window, in the URL field, specify the server connection address in the following format:

      sqlserver://user:password@kscdb.example.com:1433/database

      where:

      • user—user account with public and db_datareader rights to the required database.
      • password—user account password.
      • kscdb.example.com:1433—address and port of the database server.
      • database—name of the Kaspersky Security Center database. 'KAV' by default.

      Click Save.

   5. In the Create connector window, in the Connection section, in the Query field, replace the 'KAV' database name with the name of the Kaspersky Security Center database you are using.

      You must do this if you want to use the ID column to which the query refers.

      Click Save.

2. Install the collector in the web interface:
   1. Start the Collector Installation Wizard in one of the following ways:
      • In the KUMA web interface, in the Resources section, click Add event source.
      • In the KUMA web interface in the Resources → Collectors section click Add collector.
   2. At step 1 of the installation wizard, Connect event sources, specify the collector name and select the tenant.
   3. At step 2 of the installation wizard, Transport, select the copy of the connector that you created at step 1.
   4. At step 3 of the installation wizard, Event parsing, on the Parsing schemes tab, click Add event parsing.
   5. This opens the Basic event parsing window; in that window, on the Normalization scheme tab, select [OOTB] KSC from SQL in the Normalizer drop-down list and click OK.
   6. If necessary, specify the other settings in accordance with your requirements for the collector. For the purpose of importing events, editing settings at the remaining steps of the Installation Wizard is optional.
   7. At step 8 of the installation wizard, Setup validation, click Create and save service.

      The lower part of the window displays the command that you must use to install the collector on the server. Copy this command to the clipboard.

   8. Close the Collector Installation Wizard by clicking Save collector.
3. Install the collector on the server.

   To do so, on the server on which you want to receive Kaspersky Security Center events, run the command that you copied to the clipboard after creating the collector in the web interface.

As a result, the collector is installed and can receive events from the SQL database of Kaspersky Security Center.

You can view Kaspersky Security Center events in the Events section of the web interface.

Kaspersky Endpoint Detection and Response integration

Kaspersky Endpoint Detection and Response (hereinafter also referred to as "KEDR") is a functional unit of Kaspersky Anti Targeted Attack Platform that protects assets in an enterprise LAN.

You can configure KUMA integration with Kaspersky Endpoint Detection and Response 4.0 or later to manage threat response actions on assets connected to Kaspersky Endpoint Detection and Response servers, and on Kaspersky Security Center assets. Commands to perform operations are received by the Kaspersky Endpoint Detection and Response server, which then relays those commands to the Kaspersky Endpoint Agent installed on assets.

To manage Kaspersky Endpoint Detection and Response actions on Kaspersky Security Center assets, the fully qualified domain name (FQDN) must be specified for the asset in the system (the "Full device name" field). Otherwise, no response actions can be started.

You can also import events to KUMA and receive information about Kaspersky Endpoint Detection and Response alerts (for more details, see the Configuring integration with an SIEM system section of the Kaspersky Anti Targeted Attack Platform online help).

When KUMA is integrated with Kaspersky Endpoint Detection and Response, you can perform the following operations on Kaspersky Endpoint Detection and Response assets that have Kaspersky Endpoint Agent:

• Manage network isolation of assets.
• Manage prevention rules.
• Start applications.

To get instructions on configuring integration for response action management, contact your account manager or Technical Support.

Importing Kaspersky Endpoint Detection and Response events using the kafka connector

When importing events from Kaspersky Endpoint Detection and Response, telemetry is transmitted in clear text and may be intercepted by an intruder.

Kaspersky Endpoint Detection and Response 4.0, 4.1, 5.0, and 5.1 events can be imported to KUMA using a Kafka connector.

Several limitations are applicable to the import of events from Kaspersky Endpoint Detection and Response 4.0 and 4.1:

• Import of events is available if the KATA and KEDR license keys are used in Kaspersky Endpoint Detection and Response.
• Import of events is not available if the Sensor component installed on a separate server is used as part of Kaspersky Endpoint Detection and Response.

To import events, perform the actions in Kaspersky Endpoint Detection and Response and in KUMA.

Importing events from Kaspersky Endpoint Detection and Response 4.0 or 4.1

To import Kaspersky Endpoint Detection and Response 4.0 or 4.1 events to KUMA:

In Kaspersky Endpoint Detection and Response:

1. Use SSH or a terminal to log in to the management console of the Central Node server from which you want to export events.
2. When prompted by the system, enter the administrator account name and the password that was set during installation of Kaspersky Endpoint Detection and Response.

   The application component administrator menu is displayed.

3. In the application component administrator menu, select Technical Support Mode.
4. Press Enter.

   The Technical Support Mode confirmation window opens.

5. Confirm that you want to operate the application in Technical Support Mode. To do so, select Yes and press Enter.
6. Run the following command:

   sudo -i

7. In the /etc/sysconfig/apt-services configuration file, in the KAFKA_PORTS field, delete the value 10000.

   If Secondary Central Node servers or the Sensor component installed on a separate server are connected to the Central Node server, you need to allow the connection with the server where you modified the configuration file via port 10000.

   We do not recommend using this port for any external connections other than KUMA. To restrict connections over port 10000 only for KUMA, run the following command:

   iptables -I INPUT -p tcp ! -s KUMA_IP_address --dport 10000 -j DROP

8. In the configuration file /usr/bin/apt-start-sedr-iptables add the value 10000 in the WEB_PORTS field, separated by a comma without a space.
9. Run the following command:

   sudo sh /usr/bin/apt-start-sedr-iptables

Preparations for exporting events on the Kaspersky Endpoint Detection and Response side are now complete.

In KUMA:

1. On the KUMA server, add the IP address of the Central Node server in the format <IP address> centralnode to one of the following files:
   • %WINDIR%\System32\drivers\etc\hosts—for Windows.
   • /etc/hosts file—for Linux.
2. In the KUMA web interface, create a connector of the Kafka type.

   When creating a connector, specify the following parameters:

   • In the URL field, specify <Central Node server IP address>:10000.
   • In the Topic field, specify EndpointEnrichedEventsTopic.
   • In the Consumer group field, specify any unique name.
3. In the KUMA web interface, create a collector.

   Use the connector created at the previous step as the transport for the collector. Use "[OOTB] KEDR telemetry" as the normalizer for the collector.

If the collector is successfully created and installed, Kaspersky Endpoint Detection and Response events will be imported into KUMA. You can find and view these events in the events table.

Importing events from Kaspersky Endpoint Detection and Response 5.0 and 5.1

Several limitations apply when importing events from Kaspersky Endpoint Detection and Response 5.0 and 5.1:

• Import of events is available only for the non-high-availability version of Kaspersky Endpoint Detection and Response.
• Import of events is available if the KATA and KEDR license keys are used in Kaspersky Endpoint Detection and Response.
• Import of events is not available if the Sensor component installed on a separate server is used as part of Kaspersky Endpoint Detection and Response.

To import Kaspersky Endpoint Detection and Response 5.0 or 5.1 events to KUMA:

In Kaspersky Endpoint Detection and Response:

1. Use SSH or a terminal to log in to the management console of the Central Node server from which you want to export events.
2. When prompted by the system, enter the administrator account name and the password that was set during installation of Kaspersky Endpoint Detection and Response.

   The application component administrator menu is displayed.

3. In the application component administrator menu, select Technical Support Mode.
4. Press Enter.

   The Technical Support Mode confirmation window opens.

5. Confirm that you want to operate the application in Technical Support Mode. To do so, select Yes and press Enter.
6. In the /usr/local/lib/python3.8/dist-packages/firewall/create_iptables_rules.py configuration file, specify the additional port 10000 for the WEB_PORTS constant:

   WEB_PORTS = f'10000,80,{AppPort.APT_AGENT_PORT},{AppPort.APT_GUI_PORT}'

   You do not need to perform this step for Kaspersky Endpoint Detection and Response 5.1 because the port is specified by default.

7. Run the following commands:

   kata-firewall stop

   kata-firewall start --cluster-subnet <network mask for addressing cluster servers>

Preparations for exporting events on the Kaspersky Endpoint Detection and Response side are now complete.

In KUMA:

1. On the KUMA server, add the IP address of the Central Node server in the format <IP address> kafka.services.external.dyn.kata to one of the following files:
   • %WINDIR%\System32\drivers\etc\hosts—for Windows.
   • /etc/hosts file—for Linux.
2. In the KUMA web interface, create a connector of the Kafka type.

   When creating a connector, specify the following parameters:

   • In the URL field, specify <Central Node server IP address>:10000.
   • In the Topic field, specify EndpointEnrichedEventsTopic.
   • In the Consumer group field, specify any unique name.
3. In the KUMA web interface, create a collector.

   Use the connector created at the previous step as the transport for the collector. It is recommended to use the [OOTB] KEDR telemetry normalizer as the normalizer for the collector.

If the collector is successfully created and installed, Kaspersky Endpoint Detection and Response events will be imported into KUMA. You can find and view these events in the events table.

Importing Kaspersky Endpoint Detection and Response events using the kata/edr connector

To use the kata/edr connector to import events of Kaspersky Endpoint Detection and Response 5.1 or earlier from hosts:

1. Configure event receipt on the KUMA side. To do this, in KUMA, create and install a collector with the 'kata/edr' connector or edit an existing collector, then save the modified settings and restart the collector.
2. On the KEDR side, accept the authorization request from KUMA to begin receiving events in KUMA.

As a result, the integration is configured and KEDR events start arriving in KUMA.

Creating a collector for receiving events from KEDR

To create a collector for receiving events from KEDR:

1. In KUMA → Resources → Collectors, select Add collector.
2. This opens the Create collector window; in that window, at step 1 Connect event sources, specify an arbitrary Collector name and in the drop-down list, select the appropriate Tenant.
3. At step 2 Transport:
   1. On the Basic settings tab:
      1. In the Connector field, select Create or start typing the name of the connector if you want to use a previously created connector.
      2. In the Connector type drop-down list, select the kata/edr connector. After you select the kata/edr connector type, more fields to fill in are displayed.
      3. In the URL field, specify the address for connecting to the KEDR server in the following <name or IP address of the host>:<connection port, 443 by default> format. If the KEDR solution is deployed in a cluster, you can click Add to add all nodes. KUMA will connect to each specified node in sequence. If the KEDR solution is installed in a distributed configuration, on the KUMA side, you must configure a separate collector for each KEDR server.
      4. In the Secret field, select Create to create a new secret. This opens the Create secret window; in that window, specify the Name and click Generate and download a certificate and private encryption key.

         As a result, the certificate.zip archive is downloaded to the browser's Downloads folder; the archive contains the 'key.pem' key file and the 'cert.pem' certificate file. Extract the archive. Click Upload certificate and select the cert.pem file. Click Upload private key and select the key.pem file. Click Create; the secret is added to the Secret drop-down list is automatically selected.

         You can also select the created secret from the Secret list. KUMA uses the selected secret to connect to KEDR.

      5. The External ID field contains the ID for external systems. This ID is displayed in the KEDR web interface when authorizing the KUMA server. KUMA generates an ID automatically and the External ID field is automatically pre-populated.
   2. On the Advanced settings tab:
      1. To get detailed information in the collector log, move the Debug toggle switch to the enabled position.
      2. If necessary, in the Character encoding field, select the encoding of the source data to be converted to UTF-8. We only recommend configuring a conversion if you find invalid characters in the fields of the normalized event. By default, no value is selected.
      3. Specify the maximum Number of events per one request to KEDR. The default value is 0, which means that KUMA uses the value specified on the KEDR server. For details, refer to KATA Help. You can specify an arbitrary value that must not exceed the value on the KEDR side. If the value you specify exceeds the value of the Maximum number of events setting specified on the KEDR server, the KUMA collector log displays the Bad Request: max_events N is greater than the allowed value error.
      4. Fill in the Events fetch timeout field to receive events after a specified period of time. The default value is 0. This means that the default value of the KEDR server is applied. For details, please refer to KATA Help. This field specifies the time after which the KEDR server must send events to KUMA. The KEDR server uses two parameters: the maximum number of events and the events fetch timeout. Events are sent when the specified number of events is collected or the configured time elapses, whichever happens first. If the specified time has elapsed, but the specified number of events has not been collected, the KEDR server sends the events that it already has, without waiting for more.
      5. In the Client timeout field, specify how long KUMA must wait for a response from the KEDR server, in seconds. Default value: 1,800 s; displayed as 0. The client-side limit is specified in the Client timeout field. The Client timeout must be greater than the server's Events fetch timeout to wait for the server's response without interrupting the current event collection task with a new request. If the response from the KEDR server does not arrive in the end, KUMA repeats the request.
      6. In the KEDRQL filter field, specify the conditions for filtering the request. As a result, pre-filtered events are received from KEDR. For details about available filter fields, please refer to the KATA Help.
4. At step 3 Parsing, click Add event parsing and select the "[ООТВ] KEDR telemetry" normalizer in the Basic event parsing window.
5. To finish creating the collector in the web interface, click Create and save service. Then copy the collector installation command from the web interface and run this installation command on the command line on the server where you want to install the collector.

   If you were editing an existing collector, click Save and restart services.

As a result, the collector is created and is ready to send requests; the collector is displayed in the Resources → Active services section with the yellow status until KEDR accepts an authorization request from KUMA.

Authorizing KUMA on the KEDR side

After the collector is created in KUMA, for requests from KUMA to start arriving to KEDR, the KUMA authorization request must be accepted on the KEDR side. With the authorization request accepted, the KUMA collector automatically sends scheduled requests to KEDR and waits for a response. While waiting, the status of the collector is yellow, and after receiving the first response to a request, the status of the collector turns green.

As a result, the integration is configured and you can view events arriving from KEDR in the KUMA → Events section.

The initial request fetches part of the historical events that had occurred before the integration was configured. Current events begin arriving after all of the historical events. If you change the value of the URL setting or the External ID of an existing collector, KEDR treats the next request as an initial request, and after starting the KUMA collector with the modified settings, you will receive part of the historical events all over again. If you do not want to receive historical events, go to the settings of the relevant collector, configure the mapping of the KEDR and KUMA timestamp fields in the normalizer, and specify a filter by timestamp at the 'Event filtering' step of the collector installation wizard — the timestamp of the event must be greater than the timestamp when the collector is started.

Possible errors and solutions

If in the collector log, you see the Conflict: An external system with the following ip and certificate digest already exists. Either delete it or provide a new certificate error, create a new secret with a new certificate in the connector of the collector.

If in the collector log, you see the Continuation token not found error in response to an event request, create a new connector, attach it to the collector and restart the collector; alternatively, create a new secret with a new certificate in the connector of the collector. If you do not want to receive events generated before the error occurred, configure a Timestamp filter in the collector.

Configuring the display of a link to a Kaspersky Endpoint Detection and Response detection in KUMA event details

When Kaspersky Endpoint Detection and Response detections are received, KUMA creates an alert for each detection. You can configure the display of a link to a Kaspersky Endpoint Detection and Response detection in KUMA alert information.

You can configure the display of a detection link if you use only one Central Node server in Kaspersky Endpoint Detection and Response. If Kaspersky Endpoint Detection and Response is used in a distributed solution mode, it is impossible to configure the display of the links to Kaspersky Endpoint Detection and Response detections in KUMA.

To configure the display of a link to a detection in KUMA alert details, you need to complete steps in the Kaspersky Endpoint Detection and Response web interface and KUMA.

In the Kaspersky Endpoint Detection and Response web interface, you need to configure the integration of the application with KUMA as a SIEM system. For details on configuring integration, refer to the Kaspersky Anti Targeted Attack Platform documentation, Configuring integration with a SIEM system section.

Configuring the display of a link in the KUMA web interface includes the following steps:

1. Adding an asset that contains information about the Kaspersky Endpoint Detection and Response Central Node server from which you want to receive detections, and assigning a category to that asset.
2. Creating a correlation rule.
3. Creating a correlator.

You can use a pre-configured correlation rule. In this case configuring the display of a link in the KUMA web interface includes the following steps:

1. Creating a correlator.

   Select the [OOTB] KATA Alert correlation rule.

2. Adding an asset that contains information about the Kaspersky Endpoint Detection and Response Central Node server from which you want to receive detections and assigning a category KATA standAlone to that asset.

Step 1. Adding an asset and assigning a category to it

First, you need to create a category that will be assigned to the asset being added.

To add a category:

1. In the KUMA web interface, select the Assets section.
2. On the All assets tab, expand the category list of the tenant by clicking next to its name.
3. Select the required category or subcategory and click the Add category button.

   The Add category details area appears in the right part of the web interface window.

4. Define the category settings:
   1. In the Name field, enter the name of the category.
   2. In the Parent field, indicate the position of the category within the categories tree hierarchy. To do so, click the button and select a parent category for the category you are creating.

      Selected category appears in Parent fields.

   3. If required, define the values for the following settings:
      • Assign a severity to the category in the Severity drop-down list.

        The specified severity is assigned to correlation events and alerts associated with the asset.

      • If required, add a description for the category in the Description field.
      • In the Categorization kind drop-down list, select how the category will be populated with assets. Depending on your selection, you may need to specify additional settings:
        • Manually—assets can only be manually linked to a category.
        • Active—assets will be assigned to a category at regular intervals if they satisfy the defined filter.
          1. In the Repeat categorization every drop-down list, specify how often assets will be linked to a category. You can select values ranging from once per hour to once per 24 hours.

             You can forcibly start categorization by selecting Start categorization in the category context menu.

          2. Under Conditions, specify the filter for matching assets to attach to an asset category.

             You can add conditions by clicking the Add condition buttons. Groups of conditions can be added by using the Add group buttons. Group operators can be switched between AND, OR, and NOT values.

             Categorization filter operands and operators

             Operand	Operators	Comment
             Build number	=, ilike
             OS	=, ilike	The ilike operator makes the search case-insensitive.
             IP address	inSubnet, inRange	The IP address is indicated in CIDR notation (for example: 192.168.0.0/24). When the inRange operator is selected, you can indicate only addresses from private ranges of IP addresses (for example: 10.0.0.0–10.255.255.255). Both addresses must be in the same range.
             FQDN	=, ilike	The ilike operator makes the search case-insensitive.
             CVE	=, in	The in operator lets you specify an array of CVE (Common Vulnerabilities and Exposures) IDs.
             CVSS	>, >=, =, <=,<	Severity level of CVE vulnerabilities on the asset. The CVSS parameter takes values from 0 to 10. Not applicable to vulnerabilities from Kaspersky Security Center.
             CVE count	>, >=, =, <=, <	The number of unique vulnerabilities with the CVE attribute for the asset. Vulnerabilities without CVEs do not count towards this figure. For categorization by the number of CVEs of a certain severity level, you can use a combined condition. For example: CVE count >= 1 AND CVSS >= 6.5
             Software	=, ilike	Categorization by software installed on the asset. The ilike operator makes the search case-insensitive.
             Software version	=, ilike, in	Categorization by version (build) number of the software installed on the asset. The ilike operator makes the search case-insensitive.
             CII	in	More than one value can be selected.
             KSC group	=, ilike	Categorization by the name of the Kaspersky Security Center administration group in which the asset is placed.
             Anti-virus databases last updated	>=,<=	For categorization, the time is specified as UTC time, and then converted in the KUMA interface to the local time zone set in the browser. You can specify the date and time for this operand in one of the following ways: Select the exact date in the calendar. Select a period relative to the present time in the Relative period list. Enter a value manually: an exact date and time or a relative period, or a combination of both. For details, check the Using time values subsection below. A relative period for repeated categorization takes into account asset information that is current at the time when categorization is started.
             Last update of the information	>=,<=	For categorization, the time is specified as UTC time, and then converted in the KUMA interface to the local time zone set in the browser. You can specify the date and time for this operand in one of the following ways: Select the exact date in the calendar. Select a period relative to the present time in the Relative period list. Enter a value manually: an exact date and time or a relative period, or a combination of both. For details, check the Using time values subsection below. A relative period for repeated categorization takes into account asset information that is up-to-date at the time when categorization is started.
             Protection last updated	>=,<=	For categorization, the time is specified as UTC time, and then converted in the KUMA interface to the local time zone set in the browser. You can specify the date and time for this operand in one of the following ways: Select the exact date in the calendar. Select a period relative to the present time in the Relative period list. Enter a value manually: an exact date and time or a relative period, or a combination of both. For details, check the Using time values subsection below. A relative period for repeated categorization takes into account asset information that is up-to-date at the time when categorization is started.
             System last started	>=,<=	For categorization, the time is specified as UTC time, and then converted in the KUMA interface to the local time zone set in the browser. You can specify the date and time for this operand in one of the following ways: Select the exact date in the calendar. Select a period relative to the present time in the Relative period list. Enter a value manually: an exact date and time or a relative period, or a combination of both. For details, check the Using time values subsection below. A relative period for repeated categorization takes into account asset information that is up-to-date at the time when categorization is started.
             KSC extended status	in	Extended status of the device. More than one value can be selected.
             Real-time protection status	=	Status of Kaspersky applications installed on the managed device.
             Encryption status	=
             Spam protection status	=
             Anti-virus protection status of mail servers	=
             Data Leakage Prevention status	=
             KSC extended status ID	=
             Endpoint Sensor status	=
             Last visible	>=,<=	For categorization, the time is specified as UTC time, and then converted in the KUMA interface to the local time zone set in the browser. You can specify the date and time for this operand in one of the following ways: Select the exact date in the calendar. Select a period relative to the present time in the Relative period list. Enter a value manually: an exact date and time or a relative period, or a combination of both. For details, check the Using time values subsection below. A relative period for repeated categorization takes into account asset information that is up-to-date at the time when categorization is started.
             Score ML	>,>=,=,<=,<	Categorization by asset score assigned by AI services.
             Status	=, in	Categorization by predefined asset statuses assigned by AI services.
             Custom asset field	=, ilike	Categorization by values of custom asset fields.

             Using time values

             Some conditions, for example, Anti-virus databases last updated or System last started, use date and time as the operand value. For these conditions, you can use an exact date and time or a relative period.

             To specify a date and time value:

             1. Select an operand, an operator and click the date field.
             2. Do one of the following:
                • Select the exact date in the calendar.

                  By default, the current time is automatically added to the selected date, with millisecond precision. Changing the date in the calendar does not change the specified time. The date and time are displayed in the time zone of the browser. If necessary, you can edit the date and time in the field.

                • In the Relative period list, select a relative period.

                  The period is calculated relative to the start time of the current categorization and takes into account asset information that is up-to-date at that moment. For example, for the condition Anti-virus databases last updated, you can select 1 hour and the >= operator to periodically link to the category those assets for which the anti-virus databases have not been updated for more than 1 hour before the start of categorization.

                • In the date and time field, enter a value manually.

                  You can enter an exact date and time in the DD.MM.YYYY HH:mm:ss.SSS format for the Russian localization and YYYY-MM-DD HH:mm:ss.SSS for the English localization or a relative period as a formula. You can also combine these methods if necessary.

                  If you do not specify milliseconds when entering the exact date, 000 is substituted automatically.

                  In the relative period formulas, you can use the now parameter for the current date and time and the interval parameterization language: +, -, / (rounding to the nearest), as well as time units: y (year), M (month), w (week), d (day), h (hour), m (minute), s (second).

                  For example, for the Information last updated condition, you can specify the value now-2d with the operator >= operator and the value now-1d with the >= operator to regularly link assets to the category if those assets had information updated during the day before the categorization was started; alternatively, you can specify the value now/w with the <= operator to regularly link assets to the category if those assets had information updated between the beginning of the first day of the current week (00:00:00:000 UTC) and now.

                  KUMA stores time values in UTC, but in the user interface time is converted to the time zone of your browser. This is relevant to the relative periods: Today, Yesterday, This week, and This month. For example, if the time zone in your browser is UTC+3, and you select Today as the period, the category will cover assets from 03:00:00.000 until now, not from 00:00:00.000 until now.

                  If you want to take your time zone into account when selecting a relative period, such as Today, Yesterday, This week, or This month, you need to manually add a time offset in the date and time field by adding or subtracting the correct number of hours. For example, if your browser's time zone is UTC+3 and you want the categorization to cover the Yesterday period, you need to change the value to now-1d/d-3h. If you want the categorization to cover the Today period, change the value to now/d-3h.

          3. Use the Test conditions button to make sure that the specified filter is correct. When you click the button, the Assets for given conditions window containing a list of assets that satisfy the search conditions will be displayed.
        • Reactive—the category will be filled with assets by using correlation rules.
5. Click the Save button.

To add an asset:

1. In the KUMA web interface, select the Assets section.
2. Click the Add asset button.

   The Add asset details area opens in the right part of the window.

3. Define the following asset parameters:
   1. In the Asset name field, enter an asset name.
   2. In the Tenant drop-down list, select the tenant that will own the asset.
   3. In the IP address field, specify the IP address of the Kaspersky Endpoint Detection and Response Central Node server from which you want to receive detections.
   4. In the Categories field, select the category that you added in the previous step.

      If you are using a predefined correlation rule, you need to select the KATA standAlone category.

   5. If required, define the values for the following fields:
      • In the FQDN field, specify the Fully Qualified Domain Name of the Kaspersky Endpoint Detection and Response server.
      • In the MAC address field, specify the MAC address of the Central Node Kaspersky Endpoint Detection and Response Central Node server.
      • In the Owner field, define the name of the asset owner.
4. Click the Save button.

Step 2. Adding a correlation rule

To add a correlation rule:

1. In the KUMA web interface, select the Resources section.
2. Select Correlation rules and click the Create correlation rule button.
3. On the General tab, specify the following settings:
   1. In the Name field, define the rule name.
   2. In the Type drop-down list, select simple.
   3. In the Propagated fields field, add the following fields: DeviceProduct, DeviceAddress, EventOutcome, SourceAssetID, DeviceAssetID.
   4. If required, define the values for the following fields:
      • In the Rate limit field, define the maximum number of times per second that the rule will be triggered.
      • In the Severity field, define the severity of alerts and correlation events that will be created as a result of the rule being triggered.
      • In the Description field, provide any additional information.
4. On the Selectors → Settings tab, specify the following settings:
   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 KATA 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 fields.
      4. In the Event fields field, select DeviceProduct.
      5. In the Operator field, select =.
      6. In the Right operand field, select Constant.
      7. In the value field, enter KATA.
   5. Add a category filter condition:
      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 fields.
      4. In the Event fields field, select DeviceAssetID.
      5. In the Operator field, select inCategory.
      6. In the Right operand field, select Constant.
      7. Click the button.
      8. Select the category in which you placed the Kaspersky Endpoint Detection and Response Central Node server asset.
      9. Click the Save button.
   6. In the Conditions field, click the Add group button.
   7. In the operator field for the group you added, select OR.
   8. Add a condition for filtering by event class identifier:
      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 fields.
      4. In the Event fields field, select DeviceEventClassID.
      5. In the Operator field, select =.
      6. In the Right operand field, select Constant.
      7. In the Value field, enter taaScanning.
   9. Repeat steps 1–7 in F for each of the following event class IDs:
      • file_web.
      • file_mail.
      • file_endpoint.
      • file_external.
      • ids.
      • url_web.
      • url_mail.
      • dns.
      • iocScanningEP.
      • yaraScanningEP.
5. On the Actions tab, specify the following settings:
   1. In the Actions section, open the On every event drop-down list.
   2. Select the Output check box.
   3. In the Enrichment section, click the Add enrichment button.
   4. In the Source kind drop-down list, select Template.
   5. In the Template field, enter https://{{.DeviceAddress}}:8443/katap/#/alerts?id={{.EventOutcome}}.
   6. In the Target field drop-down list, select DeviceExternalID.
   7. If necessary, turn on the Debug toggle switch to log information related to the operation of the resource.
6. Click the Save button.

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

After the correlator is created, a link to these detections will be displayed in the details of alerts created when receiving detections from Kaspersky Endpoint Detection and Response. The link is displayed in the correlation event details (Related events section), in the DeviceExternalID field.

If you want the FQDN of the Kaspersky Endpoint Detection and Response Central Node server to be displayed in the DeviceHostName field, in the detection details, you need to create a DNS record for the server and create a DNS enrichment rule at step 4 of the wizard.

Integration with Kaspersky CyberTrace

Kaspersky CyberTrace (hereinafter CyberTrace) is a tool that integrates threat data streams with SIEM solutions. It provides users with instant access to analytics data, increasing their awareness of security decisions.

You can integrate CyberTrace with KUMA in one of the following ways:

• Integrate CyberTrace indicator search feature to enrich KUMA events with information from CyberTrace data streams.
• Integrate the entire CyberTrace web interface into KUMA to get full access to CyberTrace.

  Integration with the CyberTrace web interface requires the CyberTrace TIP Enterprise license.

Integrating CyberTrace indicator search

To integrate CyberTrace indicator search:

1. Configure CyberTrace to receive and process KUMA requests.

   You can configure the integration with KUMA immediately after installing CyberTrace in the Quick Start Wizard or later in the CyberTrace web interface.

2. Create an event enrichment rule in KUMA.

   In the enrichment rule, you can specify which data from CyberTrace you want to enrich the event with. We recommend selecting cybertrace-http as the source kind.

3. Create a collector to receive events that you want to enrich with CyberTrace data.
4. Link the enrichment rule to the collector.
5. Save and create the service:
   • If you linked the rule to a new collector, click Save and create, copy the collector ID in the opened window and use the copied ID to install the collector on the server using the command line interface.
   • If you linked the rule to an existing collector, click Save and restart services to apply the settings.

   The configuration of the integration of CyberTrace indicator search is complete and KUMA events will be enriched with CyberTrace data.

Example of testing CyberTrace data enrichment.

Configuring CyberTrace to receive and process requests

You can configure CyberTrace to receive and process requests from KUMA immediately after its installation in the Quick Start Wizard or later in the application web interface.

To configure CyberTrace to receive and process requests in the Quick Start Wizard:

1. Wait for the CyberTrace Quick Start Wizard to start after the application is installed.

   The wizard starts at step 1, Welcome to Kaspersky CyberTrace. You can go to the next step of the wizard by clicking Next.

2. At step 2, Proxy settings, if your organization uses a proxy server, enter its connection settings. If your organization does not use a proxy server, leave all fields blank.
3. At step 3, Licensing settings, select the method for adding a license key for CyberTrace: an activation code or a license key file. Depending on the selected method, specify the activation code or upload a license key file.
4. At step 4, Service settings, keep default settings.
5. At step 5, Data management settings:
   1. In the SIEM system drop-down list, select KUMA.
   2. Under Listen on, select the IP and port option.
   3. In the IP address field, enter 0.0.0.0.
   4. In the Port field, enter the port to listen on for events. The default port is 9999.
   5. Under Send detection alerts, in the IP address field, enter 127.0.0.1, and in the Port field, enter 9998.

   Leave the default values for everything else.

6. At step 6, Certificate settings, select Commercial certificate and add a certificate that allows you to download data feeds from update servers.
7. At step 7, Feeds settings, keep default settings.

CyberTrace is configured.

To configure CyberTrace to receive and process requests in the application web interface:

1. In the window of the CyberTrace web interface, switch Data management mode: in the left menu, select System, and then in the displayed menu, select General.
2. Select the Settings → General section.
3. Under Listen on:
   1. Select IP and port.
   2. In the IP address field, enter 0.0.0.0.
   3. In the Port field, enter the port to listen on for events. The default port is 9999.
4. Select the Settings → Service alerts section.
5. In the Service alert format field, enter %Date% alert=%Alert%%RecordContext%.
6. In the Records context format field, enter |%ParamName%=%ParamValue%.
7. Select the Settings → Detection alerts section.
8. In the Alert format field, enter Category=%Category%|MatchedIndicator=%MatchedIndicator%%RecordContext%.
9. On the Context tab, in the Actionable fields field, enter %ParamName%:%ParamValue%.
10. Switch to the System management mode: in the left menu, select General, then in the displayed menu, select System.
11. Select the Settings → Service section.
12. Under Web interface, in the IP address or host name, enter 127.0.0.1.
13. In the upper toolbar, click Restart service.
14. Restart the CyberTrace server.

CyberTrace is configured.

Creating event Enrichment rules

To create event enrichment rules:

1. In the KUMA web interface, open the Resources → Enrichment rules section and in the left part of the window, select or create a folder for the new rule.

   The list of available enrichment rules will be displayed.

2. Click Add enrichment rule to create a new rule.

   The enrichment rule window will be displayed.

3. Enter the rule configuration parameters:
   1. In the Name field, enter a unique name for the rule. The name must contain 1 to 128 Unicode characters.
   2. In the Tenant drop-down list, select the tenant that will own this resource.
   3. In the Source kind drop-down list, select cybertrace-http.
   4. Specify the URL of the CyberTrace server to which you want to connect. For example, example.domain.com:9999.
   5. If necessary, use the Number of connections field to specify the maximum number of connections to the CyberTrace server that can be simultaneously established by KUMA. By default, this value is equal to the number of vCPUs of the KUMA Core server.
   6. In the RPS field, enter the number of requests to the CyberTrace server per second that KUMA can make. The default value is 1000.
   7. In the Timeout field, specify the maximum number of seconds KUMA should wait for a response from the CyberTrace server. Until a response is received or the time expires, the event is not sent to the Correlator. If a response is received before the timeout, it is added to the TI field of the event and the event processing continues. The default value is 30.
   8. Under Mapping, you must specify the fields of events to be checked via CyberTrace, and define the rules for mapping fields of KUMA events to CyberTrace indicator types:
      • In the KUMA field column, select the field whose value must be sent to CyberTrace.
      • In the CyberTrace indicator column, select the CyberTrace indicator type for every field you selected:
        • ip
        • url
        • hash

      You must provide at least one string to the table. You can use the Add row button to add a string, or the button to remove a string.

   9. Use the Debug toggle switch to indicate whether or not to enable logging of service operations. Logging is disabled by default.
   10. If necessary, in the Description field, add up to 4,000 Unicode characters describing the resource.
   11. In the Filter section, you can specify conditions to identify events that will be processed using the enrichment rule. You can select an existing filter from the drop-down list or create a new filter.

       Creating a filter in resources

       To create a filter:

       1. In the Filter drop-down list, select Create new.
       2. 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.
       3. If you selected the Save filter check box, enter a name for the created filter resource in the Name field. Maximum length of the name: 128 Unicode characters.
       4. Under Conditions, specify the conditions that the events must meet:
          1. Click the Add condition button.
          2. 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, fields of additional parameters for identifying the value to be passed to the filter may be displayed. For example, when you select active list, you must specify the name of the active list, the entry key, and the entry key field.
          3. In the operator drop-down list, select an 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.
             • 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.
             • inContextTable—presence of the entry in the specified context table.
             • intersect—presence in the left operand of the list items specified in the right operand.
          4. If you want the operator to be case-insensitive, select the do not match case check box. The selection of this check box does not apply to the InSubnet, InActiveList, InCategory or InActiveDirectoryGroup operators. This check box is cleared by default.
          5. 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.

       5. If you have added multiple conditions or groups of conditions, choose a selection condition (and, or, not) by clicking the AND button.
       6. 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.
4. Click Save.

A new enrichment rule will be created.

CyberTrace indicator search integration is now configured. You can now add the created enrichment rule to a collector. You must restart KUMA collectors to apply the new settings.

If any of the CyberTrace fields in the events details area contains "[{" or "}]" values, it means that information from CyberTrace data feed was processed incorrectly and it's possible that some of the data is not displayed. You can get all information from a data feed by copying value of the TI indicator event field from KUMA and searching for it in CyberTrace in the Indicators section. All information about the found indicator is displayed on the Indicator details page.

Integrating CyberTrace interface

You can integrate the CyberTrace web interface into the KUMA web interface. When this integration is enabled, the KUMA web interface includes a CyberTrace section that provides access to the CyberTrace web interface. You can configure the integration in the Settings → Kaspersky CyberTrace section of the KUMA web interface.

To integrate the CyberTrace web interface in KUMA:

1. In the KUMA web interface, open Resources → Secrets.

   The list of available secrets will be displayed.

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

   The secret window is displayed.

3. Enter information about the secret:
   1. In the Name field, choose 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 this resource.
   3. In the Type drop-down list, select credentials.
   4. In the User and Password fields, enter credentials for your CyberTrace server.
   5. If necessary, in the Description field, add up to 4,000 Unicode characters describing the resource.
4. Click Save.

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

5. In the KUMA web interface, open Settings → Kaspersky CyberTrace.

   The window with CyberTrace integration parameters opens.

6. Make the necessary changes to the following parameters:
   • Disabled—clear this check box if you want to integrate the CyberTrace web interface into the KUMA web interface.
   • Host (required)—enter the address of the CyberTrace server.
   • Port (required)—enter the port of the CyberTrace server; the default port for managing the web interface is 443.
7. In the Secret drop-down list, select the secret you created before.
8. You can configure access to the CyberTrace web interface in the following ways:
   • Use hostname or IP when logging into the KUMA web interface.

     To do this, in the Allow hosts section, click Add host and in the field that is displayed, enter the IP or hostname of the device

     on which the KUMA web interface is deployed.

   • Use the FQDN when logging into the KUMA web interface.

     If you are using the Mozilla Firefox browser to work with the application web interface, the CyberTrace section may fail to display data. In this case, configure the data display (see below).

9. Click Save.

CyberTrace is now integrated with KUMA, and the CyberTrace section is displayed in the KUMA web interface.

To configure the data display in the CyberTrace section when using the FQDN to log in to KUMA in Mozilla Firefox:

1. Clear your browser cache.
2. In the browser's address bar, enter the FQDN of the KUMA web interface with port number 7222 as follows: https://kuma.example.com:7222.

   A window will open to warn you of a potential security threat.

3. Click the Details button.
4. In the lower part of the window, click the Accept risk and continue button.

   An exclusion will be created for the URL of the KUMA web interface.

5. In the browser's address bar, enter the URL of the KUMA web interface with port number 7220.
6. Go to the CyberTrace section.

Data will be displayed in this section.

Updating CyberTrace deny list (Internal TI)

When the CyberTrace web interface is integrated into the KUMA web interface, you can update the CyberTrace denylist or Internal TI with information from KUMA events.

To update CyberTrace Internal TI:

1. Open the event details area from the events table, Alert window, or correlation event window and click the link on a domain, web address, IP address, or file hash.

   The context menu opens.

2. Select Add to Internal TI of CyberTrace.

   A confirmation window opens.

3. If you want to confirm your actions and update the Internal TI with data from KUMA events, click Yes.

The selected object is now added to the CyberTrace denylist.

Integration with Kaspersky Threat Intelligence Portal

The Kaspersky Threat Intelligence Portal combines all of Kaspersky's knowledge about cyberthreats and how they are related to each other into a unified web service. When integrated with KUMA, it helps KUMA users to make faster and better-informed decisions, providing them with data about URLs, domains, IP addresses, WHOIS / DNS data.

Access to the Kaspersky Threat Intelligence Portal is provided based on a fee. License certificates are created by Kaspersky experts. To obtain a certificate for Kaspersky Threat Intelligence Portal, contact your Technical Account Manager.

Initializing integration

To integrate Kaspersky Threat Intelligence Portal into KUMA:

1. In the KUMA web interface, open Resources → Secrets.

   The list of available secrets will be displayed.

2. Click the Add secret button to create a new secret. This resource is used to store credentials of your Kaspersky Threat Intelligence Portal account.

   The secret window is displayed.

3. Enter information about the secret:
   1. In the Name field, choose a name for the added secret.
   2. In the Tenant drop-down list, select the tenant that will own the created resource.
   3. In the Type drop-down list, select ktl.
   4. In the User and Password fields, enter credentials for your Kaspersky Threat Intelligence Portal account.
   5. If you want, enter a Description of the secret.
4. Upload your Kaspersky Threat Intelligence Portal certificate key:
   1. Click the Upload PFX button and select the PFX file with your certificate.

      The name of the selected file appears to the right of the Upload PFX button.

   2. Enter the password to the PFX file in the PFX password field.
5. Click Save.

   The Kaspersky Threat Intelligence Portal account credentials are now saved and can be used in other KUMA resources.

6. In the Settings section of the KUMA web interface, open the Kaspersky Threat Lookup tab.

   The list of available connections will be displayed.

7. Make sure the Disabled check box is cleared.
8. In the Secret drop-down list, select the secret you created before.

   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.

9. If necessary, select a proxy server in the Proxy drop-down list.
10. Click Save.
11. After you save the settings, log in to the web interface and accept the Terms of Use. Otherwise, an error will be returned in the API.
    

The integration process of Kaspersky Threat Intelligence Portal with KUMA is completed.

Once Kaspersky Threat Intelligence Portal and KUMA are integrated, you can request additional information from the event details area about hosts, domains, URLs, IP addresses, and file hashes (MD5, SHA1, SHA256).

Requesting information from Kaspersky Threat Intelligence Portal

To request information from Kaspersky Threat Intelligence Portal:

1. Open the event details area from the events table, alert window, or correlation event window and click the link on a domain, web address, IP address, or file hash.

   The Threat Lookup enrichment area opens in the right part of the screen.

2. Select check boxes next to the data types you want to request.

   If neither check box is selected, all information types are requested.

3. In the Maximum number of records in each data group field enter the number of entries per selected information type you want to receive. The default value is 10.
4. Click Request.

A ktl task has been created. When it is completed, events are enriched with data from Kaspersky Threat Intelligence Portal which can be viewed from the events table, Alert window, or correlation event window.

Viewing information from Kaspersky Threat Intelligence Portal

To view information from Kaspersky Threat Intelligence Portal:

Open the event details area from the events table, alert window, or correlation event window and click the link on a domain, web address, IP address, or file hash for which you previously requested information from Kaspersky Threat Intelligence Portal.

The event details area opens in the right part of the screen with data from Kaspersky Threat Intelligence Portal; the time when it was received is indicated at the bottom of the screen.

Information received from Kaspersky Threat Intelligence Portal is cached. If you click a domain, web address, IP address, or file hash in the event details pane for an event for which KUMA has information available, instead of the Threat Lookup enrichment window, the data from Kaspersky Threat Intelligence Portal is displayed, with the time when it was received indicated. You can update the data.

Updating information from Kaspersky Threat Intelligence Portal

To update information, received from Kaspersky Threat Intelligence Portal:

1. Open the event details area from the events table, alert window, or correlation event window and click the link on a domain, web address, IP address, or file hash for which you previously requested information from Kaspersky Threat Intelligence Portal.
2. Click Update in the event details area containing the data received from the Kaspersky Threat Intelligence Portal.

   The Threat Lookup enrichment area opens in the right part of the screen.

3. Select the check boxes next to the types of information you want to request.

   If neither check box is selected, all information types are requested.

4. In the Maximum number of records in each data group field enter the number of entries per selected information type you want to receive. The default value is 10.
5. Click Update.

   The KTL task is created and the new data received from Kaspersky Threat Intelligence Portal is requested.

6. Close the Threat Lookup enrichment window and the details area with KTL information.
7. Open the event details area from the events table, Alert window or correlation event window and click the link on a domain, URL, IP address, or file hash for which you updated Kaspersky Threat Intelligence Portal information and select Show info from Threat Lookup.

The event details area opens on the right with data from Kaspersky Threat Intelligence Portal, indicating the time when it was received on the bottom of the screen.

Integration with R-Vision Security Orchestration, Automation and Response

R-Vision Security Orchestration, Automation and Response (hereinafter referred to as R-Vision SOAR) 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.

R-Vision SOAR can be integrated with KUMA. When this integration is enabled, the creation of a KUMA alert triggers the creation of an incident in R-Vision SOAR. A KUMA alert and its R-Vision SOAR incident are interdependent. When the status of an incident in R-Vision SOAR is updated, the status of the corresponding KUMA alert is also changed.

Integration of R-Vision SOAR and KUMA is configured in both applications. In KUMA integration settings are available only for general administrators.

Mapping KUMA alert fields to R-Vision SOAR incident fields when transferring data via API

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:

1. In the KUMA web interface, open Resources → Secrets.

   The list of available secrets will be displayed.

2. Click the Add secret button to create a new secret. This resource is used to store token for R-Vision SOAR API requests.

   The secret window is displayed.

3. 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.
4. Click Save.

   The R-Vision SOAR API token is now saved and can be used in other KUMA resources.

5. In the KUMA web interface, go to Settings → IRP / SOAR.

   The window containing R-Vision SOAR integration settings opens.

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

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 under Category fields. 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.

Adding the ALERT_ID and ALERT_URL incident fields

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

1. In the R-Vision SOAR web interface, under Settings → Incident management → Incident fields, select the No group group of fields.
2. 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.

3. In the Title field, enter the name of the field (for example: Alert ID).
4. In the Type drop-down list, select Text field.
5. 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

ALERT_ID field in R-Vision SOAR version 5.0

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

1. In the R-Vision SOAR web interface, under Settings → Incident management → Incident fields, select the No group group of fields.
2. 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.

3. In the Title field, enter the name of the field (for example: Alert URL).
4. In the Type drop-down list, select Text field.
5. In the Parsing Tag field, enter ALERT_URL.
6. 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

ALERT_URL field in R-Vision SOAR version 5.0

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

Creating a collector in R-Vision SOAR

To create a collector in R-Vision SOAR:

1. In the R-Vision SOAR web interface, under Settings → Common → Collectors, click the plus icon.
2. Specify the collector name in the Name field (for example, Main collector).
3. In the Collector address field, enter the IP address or hostname where the R-Vision SOAR is installed (for example, 127.0.0.1).
4. In the Port field type 3001.
5. Click Add.
6. 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.

Creating connector in R-Vision SOAR

To create connector in R-Vision SOAR:

1. In the R-Vision SOAR web interface, under Settings → Incident management → Connectors, click the plus icon.
2. In the Type drop-down list, select REST.
3. In the Name field, specify the connector name, such as KUMA.
4. 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

5. In the Authorization type drop-down list, select Token.
6. In the Auth header field type Authorization.
7. In the Auth value field enter the token of KUMA user with general administrator role in the following format:

   Bearer <KUMA General administrator token>

8. In the Collector drop-down list select previously created collector.
9. Click Save.

The connector has been created.

Connector in R-Vision SOAR version 4.0

Connector in R-Vision SOAR version 5.0

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

To configure API queries in R-Vision SOAR:

1. In the R-Vision SOAR web interface, under Settings → Incident management → Connectors, open for editing the newly created connector.
2. In the request type drop-down list, select POST.
3. 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

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

5. On the BODY → Raw tab, enter the contents of the API request body:

   {

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

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

   }

6. Click Save.

The connector is configured.

Connector in R-Vision SOAR version 4.0

Connector in R-Vision SOAR version 5.0

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:

1. In the R-Vision SOAR web interface, under Settings → Incident management → Response playbooks, click the plus icon.
2. In the Name field, type the name of the rule, for example, Close alert.
3. In the Group drop-down list select All playbooks.
4. Under Autostart criteria, 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.

5. Under Incident Response Actions, 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.

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

R-Vision SOAR version 5.0 playbook rule

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.

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.

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

For details about Active Directory attributes, please refer to the Microsoft documentation.

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:

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

2. Select or clear the Disabled check box.
3. Click Save.

To enable or disable a specific LDAP connection:

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

2. Select the relevant connection and either select or clear the Disabled check box in the opened window.
3. Click Save.

Adding a tenant to the LDAP server integration list

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

1. Open the KUMA web interface and select Settings → LDAP server.

   The LDAP server integration by tenant window opens.

2. Click the Add tenant button.

   The LDAP server integration window is displayed.

3. In the Tenant drop-down list, select the tenant that you need to add.
4. 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:

1. Open the KUMA web interface and select Settings → LDAP server.

   The LDAP server integration by tenant window is displayed.

2. Select the check box next to the tenant that you need to delete, and click Delete.
3. Confirm deletion of the tenant.

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

Creating an LDAP server connection

To create a new LDAP connection to Active Directory:

1. In the KUMA web interface, open Settings → LDAP server.
2. Select or create a tenant for which you want to create a LDAP connection.

   The LDAP server integration by tenant window opens.

3. Click the Add connection button.

   The Connection parameters window opens.

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

      You can change the selected secret by clicking the pencil () icon.

   2. If you want to create a new secret, click the plus () icon.

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

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

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

   • LDAPS.

     When using LDAPS, 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.

8. If you enabled TLS encryption at the previous step, add a TLS certificate. You must use the certificate of the certification authority that signed the LDAP server certificate. You may not use custom certificates. To add a certificate:
   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 plus icon () 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.

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

10. In the Base DN field, enter the base distinguished name of the directory in which you need to run the search query.
11. 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
       • company
       • department
       • displayName
       • distinguishedName
       • division
       • employeeID
       • ipaUniqueID
       • l
       • Mail
       • mailNickname
       • managedObjects
       • manager
       • memberOf (this attribute can be used for search during correlation)
       • mobile
       • objectGUID (this attribute always requested from Active Directory even if a user doesn't specify it)
       • objectSID
       • physicalDeliveryOfficeName
       • 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.

        

12. Select the Disabled check box if you do not want to use this LDAP connection.

    This check box is cleared by default.

13. 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 application does not check whether the port is unique.

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:

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

2. Select the relevant connection.
3. 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.

4. If necessary, change the relevant settings.
5. Click the Save button.

The new connection is created.

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 application does not check whether the port is unique.

Changing an LDAP server connection

To change an LDAP server connection:

1. Open the KUMA web interface and select Settings → LDAP server.

   The LDAP server integration by tenant window opens.

2. Select the tenant for which you want to change the LDAP server connection.

   The LDAP server integration window opens.

3. Click the LDAP server connection that you want to change.

   The window with the settings of the selected LDAP server connection opens.

4. Make the necessary changes to the settings.
5. 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.

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:

1. In the KUMA web interface, open Settings → LDAP server → LDAP server integration by tenant.
2. Select the relevant tenant.

   The LDAP server integration window opens.

3. In the Data refresh interval field, specify the required frequency in hours. The default value is 12.

The query schedule has been changed.

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:

1. In the KUMA web interface, open Settings → LDAP server → LDAP server integration by tenant.
2. Select the relevant tenant.

   The LDAP server integration window opens.

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

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:

1. In the KUMA web interface, open Settings → LDAP server → LDAP server integration by tenant.
2. Select the relevant tenant.

   The LDAP server integration window opens.

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

1. In the KUMA web interface, open Settings → LDAP server → LDAP server integration by tenant.
2. Select the relevant tenant.

   The LDAP server integration window opens.

3. Select the relevant LDAP server connection.

   The Connection parameters window opens.

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

Deleting an LDAP server connection

To delete LDAP connection to Active Directory:

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

2. Click the LDAP connection that you want to delete and click the Delete button.
3. Confirm deletion of the connection.

The LDAP connection to Active Directory will be deleted.

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.

1. Enable domain authentication if it is disabled.

   Domain authorization is enabled by default, but a connection to the domain is not configured.

2. Configure a connection to the domain controller.

   The following connections are available:

   • Active Directory (AD)
   • Active Directory Federation Services (ADFS)
   • FreeIPA

   The AD and ADFS connection settings can be configured at the same time.

   You can connect to one domain only.

3. 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's group matches the specified filter in the following order of precedence of roles in the KUMA web interface: Junior analyst → Tier 1 analyst → Tier 2 analyst → Tenant administrator → General administrator. Upon the first match, the application 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 most privileges is used. If multiple groups are matched for different tenants, the user will be assigned the specified role in each tenant.

   After their first authentication, all domain users gain access to the default space, which is specified in the Spaces permissions section.

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.

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:

1. In the application web interface, select Settings → Domain authorization.
2. In the Authorization type drop-down list, select one of the options:
   • FreeIPA
   • AD/ADFS
3. 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.
4. Click the Save button.

The selected settings are saved and applied.

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:

1. In the application web interface, select Settings → Domain authorization.
2. In the Authorization type drop-down list, select FreeIPA.
3. Under FreeIPA, 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.
4. 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.

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

   • LDAPS.

     When using LDAPS, 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.

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

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

9. 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. Additional roles for the General administrator are automatically activated in KUMA, therefore, you do not need to add them separately.

   In the case when multiple groups are specified for a user in the same tenant, the role with the highest-level permissions is used, with additional roles, if additional roles are assigned.

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

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

1. In the application web interface, select Settings → Domain authorization.
2. In the Authorization type drop-down list, select FreeIPA.
3. Under FreeIPA, 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.

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

1. In the application web interface, select Settings → Domain authorization.
2. Under Administration groups, click Add role groups.
3. In the Tenant drop-down list, select the tenant of the users for whom you want to configure domain authentication. The Shared tenant is displayed in the drop-down list, but you cannot assign a role to it because the only role in the Shared tenant is the Access to shared resources additional role, and additional roles do not participate in domain authentication.
4. In the Selected roles drop-down list, specify the roles for the user. You can select multiple roles. The following values are available:
   • Tenant administrator
   • Tier 2 analyst
   • Tier 1 analyst
   • Junior analyst

   After you select the roles, a group filter field is displayed for each role. In the fields for each role, specify the DistinguishedName of the domain group. The users of this domain group must have the capability to perform authentication with their domain accounts. Group input example: CN=KUMA team,OU=Groups,OU=Clients,DC=test,DC=domain.

   You can define a separate set of role filters for each tenant.

   If no filter is specified for a role, this means that conditions for creating an account through domain authentication are not specified for that role. Authentication with that role is impossible.

   After the first authentication under a domain account, domain user cards are created for users in the Settings → Users section. For a domain user, the ability to change the main role (General administrator, Tenant administrator, Tier 2 analyst, Tier 1 analyst, Junior analyst) is blocked in the user card, while additional roles can be added or removed (Access to CII, Interaction with NCIRCC, Access to shared resources), including management of additional role assignment to tenants. Roles assigned in the Domain authorization section and roles assigned in the user card supplement each other. For the General administrator, additional roles in KUMA are automatically activated, therefore you do not need to add them separately. If the General administrator role was assigned to a domain user, and the General administrator role was subsequently revoked, additional roles must be reassigned in the user card in the Settings → Users section.

   You can specify only one domain group for each role. If you want to specify multiple groups, you must repeat steps 2 to 4 for each group while specifying the same tenant.

5. If necessary, repeat steps 2–4 for each tenant for which you want to configure domain authentication with the following roles: Junior analyst, Tier 1 analyst, Tier 2 analyst, or Tenant administrator.
6. 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.

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:

1. In the application web interface, select Settings → Domain authorization.
2. In the Authorization type drop-down list, select AD/ADFS.
3. 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.
4. 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.

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

   • LDAPS.

     When using LDAPS, 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.

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

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

8. 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. Additional roles for the General administrator are automatically activated in KUMA, therefore you do not need to add them separately.

   In the case when multiple groups are specified for a user in the same tenant, the role with the highest-level permissions is used, with additional roles, if additional roles are assigned.

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

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

1. In the application web interface, select Settings → Domain authorization.
2. In the Authorization type drop-down list, select AD/ADFS.
3. Under Test connection, 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.

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

1. In the application web interface, select Settings → Domain authorization.
2. Under Administration groups, click Add role groups.
3. In the Tenant drop-down list, select the tenant of the users for whom you want to configure domain authentication. The Shared tenant is displayed in the drop-down list, but you cannot assign a role to it because the only role in the Shared tenant is the Access to shared resources additional role, and additional roles do not participate in domain authentication.
4. In the Selected roles drop-down list, specify the roles for the user. You can select multiple roles. The following values are available:
   • Tenant administrator
   • Tier 2 analyst
   • Tier 1 analyst
   • Junior analyst

   After you select the roles, a group filter field is displayed for each role. In the fields for each role, specify the DistinguishedName of the domain group. The users of this domain group must have the capability to perform authentication with their domain accounts. Group input example: CN=KUMA team,OU=Groups,OU=Clients,DC=test,DC=domain.

   You can define a separate set of role filters for each tenant.

   If no filter is specified for a role, this means that conditions for creating an account through domain authentication are not specified for that role. Authentication with that role is impossible.

   After the first authentication under a domain account, domain user cards are created for users in the Settings → Users section. For a domain user, the ability to change the main role (General administrator, Tenant administrator, Tier 2 analyst, Tier 1 analyst, Junior analyst) is blocked in the user card, while additional roles can be added or removed (Access to CII, Interaction with NCIRCC, Access to shared resources), including management of additional role assignment to tenants. Roles assigned in the Domain authorization section and roles assigned in the user card supplement each other. For the General administrator, additional roles in KUMA are automatically activated, therefore you do not need to add them separately. If the General administrator role was assigned to a domain user, and the General administrator role was subsequently revoked, additional roles must be reassigned in the user card in the Settings → Users section.

   You can specify only one domain group for each role. If you want to specify multiple groups, you must repeat steps 2 to 4 for each group while specifying the same tenant.

5. If necessary, repeat steps 2–4 for each tenant for which you want to configure domain authentication with the following roles: Junior analyst, Tier 1 analyst, Tier 2 analyst, or Tenant administrator.
6. 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.

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:

1. In the application web interface, select Settings → Domain authorization.
2. In the Authorization type drop-down list, select AD/ADFS.
3. Under Active Directory Federation Services, in the Client ID field, enter the KUMA ID from the Client ID field in the ADFS.
4. In the Relying party identifier field, enter the KUMA ID from the Relying party identifiers field in the ADFS.
5. 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).

6. 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/
7. 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. Additional roles for the General administrator are automatically activated in KUMA, therefore, you do not need to add them separately.

   In the case when multiple groups are specified for a user in the same tenant, the role with the highest-level rights is used, with additional rights, if additional roles are assigned.

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

8. Click the Save button.

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

If, when trying to log in to KUMA via ADFS, the user gets an Access denied pop-up message, click the Reset certificate button. A new certificate will be generated automatically.

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:

1. In the application web interface, select Settings → Domain authorization.
2. Under Administration groups, click Add role groups.
3. In the Tenant drop-down list, select the tenant of the users for whom you want to configure domain authentication. The Shared tenant is displayed in the drop-down list, but you cannot assign a role to it because the only role in the Shared tenant is the Access to shared resources additional role, and additional roles do not participate in domain authentication.
4. In the Selected roles drop-down list, specify the roles for the user. You can select multiple roles. The following values are available:
   • Tenant administrator
   • Tier 2 analyst
   • Tier 1 analyst
   • Junior analyst

   After you select the roles, a group filter field is displayed for each role. In the fields for each role, specify the DistinguishedName of the domain group. The users of this domain group must have the capability to perform authentication with their domain accounts. Group input example: CN=KUMA team,OU=Groups,OU=Clients,DC=test,DC=domain.

   You can define a separate set of role filters for each tenant.

   If no filter is specified for a role, this means that conditions for creating an account through domain authentication are not specified for that role. Authentication with that role is impossible.

   After the first authentication under a domain account, domain user cards are created for users in the Settings → Users section. For a domain user, the ability to change the main role (General administrator, Tenant administrator, Tier 2 analyst, Tier 1 analyst, Junior analyst) is blocked in the user card, while additional roles can be added or removed (Access to CII, Interaction with NCIRCC, Access to shared resources), including management of additional role assignment to tenants. Roles assigned in the Domain authorization section and roles assigned in the user card supplement each other. For the General administrator, additional roles in KUMA are automatically activated, therefore you do not need to add them separately. If the General administrator role was assigned to a domain user, and the General administrator role was subsequently revoked, additional roles must be reassigned in the user card in the Settings → Users section.

   You can specify only one domain group for each role. If you want to specify multiple groups, you must repeat steps 2 to 4 for each group while specifying the same tenant.

5. If necessary, repeat steps 2–4 for each tenant for which you want to configure domain authentication with the following roles: Junior analyst, Tier 1 analyst, Tier 2 analyst, or Tenant administrator.
6. 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.

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

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

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

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

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

5. In the Apply Access Control Policy section that opens, select the Permit everyone policy value.

   Click Next to proceed to the next configuration step.

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

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

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

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

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

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

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

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

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 has been changed. To fix the error and resume domain authentication, in domain controller connection settings, click the Reset certificate button. A new certificate will be generated automatically.

NCIRCC integration

In the KUMA web interface, you can create a connection to the National Computer Incident Response & Coordination Center Incidents (hereinafter referred to as "NCIRCC"). This will let you export incidents registered by KUMA to NCIRCC. Integration is configured under Settings → NCIRCC in the KUMA web interface. All fields that you fill out in the settings section are automatically sent to the NCIRCC data submission form.

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

To create a connection to NCIRCC:

1. In the KUMA web interface, open Settings → NCIRCC.
2. In the URL field, enter the URL for accessing NCIRCC.
3. Under Token, create or select an existing secret with the API token that was issued to your organization for a connection to NCIRCC:
   • 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 plus () icon and specify the following settings:
        • Name (required)—unique name of the resource 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 NCIRCC.
        • Description—service description: up to 256 Unicode characters.
     2. Click Save.

     The secret containing the token for connecting to NCIRCC will be created. It is saved under Resources → Secrets and is owned by the main tenant.

   You can change the selected secret by clicking the pencil () icon.

4. In the Company scope drop-down list, select the required value.
5. In the Company name field, specify the name of the company for which you are configuring the integration.
6. In the Location drop-down list, specify the location of your company.
7. In the Root CA section of settings, create or select an existing secret:
   • 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 plus () icon and specify the following settings:
        • Name (required)—unique name of the resource you are creating. The name must contain 1 to 128 Unicode characters.
        • Type (required)—the type of secret.
        • Certificate file—click Upload certificate file and select the certificate of the intermediate certification authority that is downloaded and installed on the KUMA Core server.

          Download and install the certificate of the intermediate certification authority.

          To install and trust the certificate of the intermediate certification authority on the KUMA Core server:

          1. Follow the NCIRCC account link. For example, https://lk.cert.gov.ru.
          2. Right-click to call up the View site details context menu to the left of the link in the address bar.
             • If you are using an encrypted connection, in the context menu, select Connection is secure and in the drop-down list under Certificate is valid, click the Show certificate link.
             • If you are using an unencrypted connection, in the menu, click Certificate details.

             Depending on your browser, the position of the menu and the order of items may differ.

          3. In the displayed Certificate Viewer window, under Issued By, in the Common Name (CN) field you can find the name of the certificate that you need. For example, GlobalSign GCC R6 AlphaSSL CA 2023.

             Remember the name of the certificate because you will need to download it at the next step.

          4. Click the https://support.globalsign.com/ca-certificates/intermediate-certificates/alphassl-intermediate-certificates link, find the certificate from step 3, and click "View as BASE64".
          5. Paste the displayed certificate strings into a file and add the file with the certificate strings as the secret in KUMA.
          6. After installing the certificate, restart the KUMA Core server.

          As a result, the certificate is installed and you can proceed with configuring the integration.

        • Description—service description: up to 256 Unicode characters.
     2. Click Save.

     The secret with the certificate of the intermediate certification authority is created. It is saved under Resources → Secrets and is owned by the main tenant.

   You can change the selected secret by clicking the pencil () icon.

8. If necessary, under Proxy, create or select an existing proxy server that must be used when connecting to NCIRCC.
9. Click Save.

KUMA is now integrated with NCIRCC. Now you can export incidents to it. You can click the Test connection button to make sure that a connection with NCIRCC 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 NCIRCC, download and install the certificate of the intermediate certification authority on the KUMA Core server.

Integration with the Security Orchestration Automation and Response Platform (SOAR)

Security Orchestration, Automation and Response Platform (hereinafter referred to as SOAR) 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.

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

• Request information about alerts from KUMA. In SOAR, 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 SOAR vendor to learn more about the methods and conditions for obtaining a Kaspersky KUMA connector.

Managing SOAR incidents

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

KUMA alert imported into SOAR as an incident

Configuring integration in KUMA

To configure KUMA integration with SOAR, 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:

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

2. Click the Generate token button.
3. Copy the generated token displayed in the opened window. You will need it to configure SOAR.

   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 specified in the SOAR connector settings.

Configuring integration in SOAR

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

For more detailed information about configuring SOAR, please refer to the product documentation.

Importing and configuring a connector

Adding a connector to SOAR

Integration of SOAR and KUMA is performed using the Kaspersky KUMA connector. Contact your SOAR vendor to learn more about the methods and conditions for obtaining a Kaspersky KUMA connector.

To import the Kaspersky KUMA connector to SOAR:

1. In SOAR, open the Settings → Connectors → Connectors section.

   A list of connectors added to SOAR is displayed.

2. At the top of the screen, click the import button and select the ZIP archive containing the Kaspersky KUMA connector.

The connector is imported into SOAR 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 SOAR using the Kaspersky KUMA connector:

1. In SOAR, open the Settings → Connectors → Connectors section.

   A list of connectors added to your SOAR is displayed.

2. Select the Kaspersky KUMA connector.

   The general settings of the connector will be displayed.

3. Under Connector settings, click the Edit button.

   The connector configuration will be displayed.

4. In the URL field, specify the address and port of KUMA. For example, kuma.example.com:7223.
5. In the Token field, specify KUMA user API token.

The connection to KUMA is configured in the SOAR connector.

Security Vision IRP connector settings

Configuring commands for interaction with KUMA in the SOAR connector

You can use SOAR to receive information about KUMA alerts (referred to as incidents in SOAR terminology) and send requests to close these alerts. To perform these actions, you need to configure the appropriate commands in the SOAR 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 SOAR and KUMA, you can similarly create your own commands containing other API requests.

To configure a command to receive alert information from KUMA:

1. In SOAR, open the Settings → Connectors → Connectors section.

   A list of connectors added to SOAR is displayed.

2. Select the Kaspersky KUMA connector.

   The general settings of the connector will be displayed.

3. Click the +Command button.

   The command creation window opens.

4. 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.
5. Save the command and close the window.

The connector command is configured. When this command is executed, the SOAR connector queries KUMA for information about all alerts with the New status and all events related to those alerts. The received data is sent to the SOAR processor, which uses it to create SOAR incidents. If new data appears in an alert that has been already imported into SOAR, incident information is updated in SOAR.

To configure a command to close KUMA alerts:

1. In SOAR, open the Settings → Connectors → Connectors section.

   A list of connectors added to SOAR is displayed.

2. Select the Kaspersky KUMA connector.

   The general settings of the connector will be displayed.

3. Click the +Command button.

   The command creation window will be displayed.

4. 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.
5. Save the command and close the window.

The connector command is configured. When this command is executed, the incident is closed in SOAR and the corresponding alert is closed in KUMA.

Creating commands in SOAR

After the SOAR connector is configured, KUMA alerts are sent to the platform as SOAR incidents. Then you need to configure incident handling in SOAR based on the security policies of your organization.

Configuring the handler, schedule, and worker process

SOAR handler

The SOAR handler receives information about KUMA alerts from the SOAR connector and uses the information to create SOAR incidents. A predefined KUMA (Incidents) handler is used for processing data. The settings of the KUMA (Incidents) handler are available in SOAR under Settings → Event processing → Event handlers:

• You can view the rules for processing KUMA alerts in the handler settings on the Normalization tab.
• You can view the actions available when creating new objects 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 SOAR under Settings → Event processing → Schedule:

• Under Connector settings, you can configure the settings for starting the connector.
• Under Handler settings, you can configure the settings for starting the handler.

SOAR workflow

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

Integration with KICS/KATA

Kaspersky Industrial CyberSecurity for Networks (hereinafter referred to as "KICS/KATA") 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/KATA 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/KATA to KUMA.
• Send asset status change commands from KUMA to KICS/KATA.

Unlike KUMA, KICS/KATA refers to assets as devices.

The integration of KICS/KATA and KUMA must be configured in both applications:

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

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

Configuring integration in KICS for Networks

The application 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 KICS for Networks documentation.

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 KICS for Networks documentation.

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.

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 KICS for Networks documentation.

To configure integration with KICS/KATA in KUMA:

1. Open the KUMA web interface and select Settings → Kaspersky Industrial CyberSecurity for Networks.

   This opens the KICS/KATA server integration by tenant window.

2. Select or create a tenant for which you want to create an integration with KICS for Networks.

   This opens the KICS/KATA server integration window.

3. Click the Communication data package field and select the communication data package that was created in KICS for Networks.
4. In the Communication data package password field, enter the password of the communication data package.
5. Select the Enable response check box if you want to change the statuses of KICS for Networks assets by using KUMA response rules.
6. Click Save.

Integration with KICS/KATA is configured in KUMA, and the window displays the IP address of the node where the KICS/KATA connector will be running and its ID.

Enabling and disabling integration with KICS for Networks

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

1. In the KUMA web interface, open the Settings → KICS/KATA section and select the tenant for which you want to enable or disable KICS for Networks integration.

   This opens the KICS/KATA server integration window.

2. Select or clear the Disabled check box.
3. Click Save.

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:

1. In the KUMA web interface, open the Settings → KICS/KATA section.
2. Select the relevant tenant.

   This opens the KICS/KATA server integration window.

3. In the Data refresh interval field, specify the required frequency in hours. The default value is 3.

The import schedule has been changed.

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

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.

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, Tenant administrator, and Tier 2 analyst roles can manually change the statuses of assets imported from KICS for Networks in the tenants available to them.

To manually change a KICS for Networks asset status:

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

2. In the Status in KICS/KATA drop-down list, select the status that you want 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.

Integration with NeuroDAT SIEM IM

NeuroDAT SIEM IM is an information security monitoring system.

You can configure the export of KUMA events to NeuroDAT SIEM IM. Based on incoming events and correlation rules, NeuroDAT SIEM IM automatically generates information security incidents.

To configure integration with NeuroDAT SIEM IM:

1. Connect to the NeuroDAT SIEM IM server over SSH using an account with administrative privileges.
2. Create a backup copy of the /opt/apache-tomcat-<server version>/conf/neurodat/soz_settings.properties configuration file.
3. In the /opt/apache-tomcat-<server version>/conf/neurodat/soz_settings.properties configuration file, edit the following settings as follows:
   • kuma.on=true

     This setting is an attribute of NeuroDAT SIEM IM interaction with KUMA.

   • job_kuma=com.cbi.soz.server.utils.scheduler.KumaIncidentsJob
   • jobDelay_kuma=5000
   • jobPeriod_kuma=60000
4. Save changes of the configuration file.
5. Run the following command to restart the tomcat service:

   sudo systemctl restart tomcat

6. Obtain a token for the user in KUMA. To do so:
   1. Open the KUMA web interface, click the name of your user account in the bottom-left corner of the window and click the Profile button in the opened menu.

      This opens the User window with your user account settings.

   2. Click the Generate token button.

      The New token window opens.

   3. If necessary, set the token expiration date:
      • Select the No expiration date check box.
      • In the Expiration date field, use the calendar to specify the date and time when the created token will expire.
   4. Click the Generate token button.

      The Token field with an automatically generated token is displayed in the user details area. Copy it.

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

   5. Click Save.
7. Log in to NeuroDAT SIEM IM using the 'admin' account or another account that has the Administrator role for the organization you are configuring or the Administrator role for all organizations.
8. In the Administration → Organization structure menu item, select or create an organization that you want to receive incidents from KUMA.
9. On the organization form, do the following:
   1. Select the Configure integration with KUMA check box.
   2. In the KUMA IP address and port field, specify the KUMA API address, for example, https://192.168.58.27:7223/api/v1/.
   3. In the KUMA API key field, specify the user token obtained at step 6.
   4. Save the organization information.

Integration with KUMA is configured.

NeuroDAT SIEM IM tests access to KUMA and, if successful, displays a message about being ready to receive data from KUMA.

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:

1. In ASAP, create an authorization token and obtain an address for API requests.
2. 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.

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:

1. Sign in to the ASAP web interface.
2. In the Control panel section, click Import and synchronization, and then open the Open API tab.
3. 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
4. Click the Generate token button.
5. 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:

1. Sign in to the ASAP web interface.
2. In the Control panel section, click Import and synchronization, and then open the Open API tab.
3. 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.

Configuring integration in KUMA

To configure KUMA integration with ASAP:

1. Open the KUMA web interface and select Settings → Kaspersky Automated Security Awareness Platform.

   The Kaspersky Automated Security Awareness Platform window opens.

2. In the Secret field click the plus () icon 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.
3. In the ASAP Open API URL field, specify the address used by ASAP for API requests.
4. 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.
5. If necessary, in the Proxy drop-down list select the proxy server resource to be used to connect to ASAP.
6. To disable or enable integration with ASAP, select or clear the Disabled check box.
7. 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.

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:

1. In the KUMA web interface, in the Alerts or Incidents section, select the required alert or incident.
2. In the Related users section, click the desired account.

   The Account details window opens on the right side of the screen.

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

1. In the KUMA web interface, in the Alerts or Incidents section, select the required alert or incident.
2. In the Related users section, click the desired account.

   The Account details window opens on the right side of the screen.

3. In the Assign ASAP group drop-down list, select the ASAP learning group you want to assign the user to.
4. 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.

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:

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

2. Creating a script for sending notifications

   You must create a script and save it on the server where the correlator is installed.

3. Configuring notifications in KUMA

   Configure a KUMA response rule that starts a script to send notifications and add this rule to the correlator.

Creating and configuring a Telegram bot

To create and configure a Telegram bot:

1. In the Telegram application, find the BotFather bot and open a chat with it.
2. In the chat, click Start.
3. Create a new bot using the following command:

   /newbot

4. Enter the name of the bot.
5. 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.

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

7. To open a chat with the bot you created, use the t.me/<botlogin> link that you obtained at step 5, and click Start.
8. 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.
9. 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.
10. 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.

Creating a script for sending notifications

To create a script:

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

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

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

Configuring sending notifications in KUMA

To configure the sending of KUMA notifications to Telegram:

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

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:

1. Configuring integration in UserGate
2. Preparing a script for the response rule
3. Configuring the KUMA response rule

Configuring integration in UserGate

To configure integration in UserGate:

1. Connect to the UserGate web interface under an administrator account.
2. Go to UserGate → Administrators → Administrator profiles, and click Add.
3. In the Profile settings window, specify the profile name, for example, API.
4. On the API Permissions tab, add read and write permissions for the following objects:
   • content
   • core
   • firewall
   • nlists
5. Click Save.
6. In the UserGate → Administrators section, click Add → Add local administrator.
7. 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.

8. Click Save.
9. In the address bar of your browser, after the address and port of UserGate, add ?features=zone-xml-rpc and press ENTER.
10. 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.

11. Click Save.

Preparing a script for integration with UserGate

To prepare a script for use:

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

2. Download the script:

   https://box.kaspersky.com/d/2dfd1d677c7547a7ac1e/

3. 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.
4. Place the downloaded script on the KUMA correlator server at the following path: /opt/kaspersky/kuma/correlator/<correlator ID from step 1>/scripts/.
5. 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/

6. Run the following command:

   chmod +x ug.py && chown kuma:kuma ug.py

The script is ready to use.

Configuring a response rule for integration with UserGate

To configure a response rule:

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

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:

1. Configuring integration in KWTS
2. Preparing a script for the response rule
3. Configuring the KUMA response rule

Configuring integration in KWTS

To prepare the integration in KWTS:

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

2. Assign the created role to a user with NTML authentication.

   You can use a local administrator account instead.

3. In the Rules section, go to the Access tab and click Add rule.
4. In the Action drop-down list, select Block.
5. 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.
6. In the Name field, enter the name of the rule.
7. Enable the rule using the Status toggle switch.
8. Click Add.
9. In the KWTS web interface, open the rule you just created.
10. 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.

Preparing a script for integration with KWTS

To prepare a script for use:

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

2. To get the script and the library, please contact Technical Support.
3. Place the script provided by Technical Support on the KUMA correlator server at the following path: /opt/kaspersky/kuma/correlator/<correlator ID from step 1>/scripts/.
4. 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/

5. Run the following command:

   chmod +x kwts.py kwtsWebApiV6.py && chown kuma:kuma kwts.py kwtsWebApiV6.py

The script is ready to use.

Configuring a response rule for integration with KWTS

To configure a response rule:

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

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:

1. Configuring integration in KSMG
2. Preparing a script for the response rule
3. Configuring the KUMA response rule

Configuring integration in KSMG

To prepare the integration in KSMG:

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

2. Assign the created role to a user with NTML authentication.

   You can use the 'Administrator' local administrator account.

3. In the Rules section, click Create.
4. In the left pane, select the General section.
5. Enable the rule using the Status toggle switch.
6. In the Rule name field, enter the name of the new rule.
7. Under Mode, select one of the message processing options that meets the criteria of this rule.
8. Under Sender on the Email addresses tab, enter a nonexistent or known malicious sender address.
9. Under Recipient on the Email addresses tab, specify the relevant recipients or the "*" character to select all recipients.
10. Click the Save button.
11. In the KSMG web interface, open the rule you just created.
12. 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.

Preparing a script for integration with KSMG

To prepare a script for use:

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

2. To get the script and the library, please contact Technical Support.
3. Place the script provided by Technical Support on the KUMA correlator server at the following path: /opt/kaspersky/kuma/correlator/<correlator ID from step 1>/scripts/.
4. 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/

5. Run the following command:

   chmod +x ksmg.py ksmgWebApiV2.py && chown kuma:kuma ksmg.py ksmgWebApiV2.py

The script is ready to use.

Configuring a response rule for integration with KSMG

To configure a response rule:

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

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:

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

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

   • Tenant administrator or Tier 2 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.
3. Download the script:

   https://box.kaspersky.com/d/2dfd1d677c7547a7ac1e/

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

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

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 Tenant administrator or Tier 2 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 with fqdn=localhost or ip=127.0.0.1 was skipped.

Configuring receipt of Sendmail events

You can configure the receipt of Sendmail mail agent events in the KUMA

SIEM system

SIEM system (Security Information and Event Management) is a solution for managing information and events in the organization security system.

Configuring event receiving consists of the following steps:

1. Configuring Sendmail logging.
2. Configuring the event source server.
3. Creating a KUMA collector.

   To receive Sendmail events, use the following values in the Collector Installation Wizard:

   • At the Event parsing step, select the [OOTB] Sendmail syslog normalizer.
   • At the Transport step, select the tcp or udp connector type.
4. Installing KUMA collector.
5. Verifying receipt of Sendmail events in the KUMA collector

   You can verify that the Sendmail event source server is correctly configured in the Searching for related events section of the KUMA web interface.

Configuring Sendmail logging

By default, events of the Sendmail system are logged to syslog.

To make sure that logging is configured correctly:

1. Connect via SSH to the server on which the Sendmail system is installed.
2. Run the following command:

   cat /etc/rsyslog.d/50-default.conf

   The command should return the following string:

   mail.* -/var/log/mail.log

If logging is configured correctly, you can proceed to configuring the export of Sendmail events.

Configuring export of Sendmail events

Events are sent from the Sendmail mail agent server to the KUMA collector using the rsyslog service.

To configure transmission of Sendmail events to the collector:

1. Connect to the server where Sendmail is installed using an account with administrative privileges.
2. In the /etc/rsyslog.d/ directory, create the Sendmail-to-siem.conf file and add the following line to it:

   If $programname contains 'sendmail' then @<<IP address of the collector>:<port of the collector>>

   Example: If $programname contains 'sendmail' then @192.168.1.5:1514

   If you want to send events via TCP, the contents of the file must be as follows:

   If $programname contains 'sendmail' then @@<<IP address of the collector>:<port of the collector>>

3. Create a backup copy of the /etc/rsyslog.conf file.
4. Add the following lines to the /etc/rsyslog.conf configuration file:

   $IncludeConfig /etc/Sendmail-to-siem.conf

   $RepeatedMsgReduction off

5. Save your changes.
6. Restart the rsyslog service by executing the following command:

   sudo systemctl restart rsyslog.service