Integration with other solutions

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

Integration with Open Single Management Platform

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

First, you need to make sure that the relevant Open Single Management Platform server allows an incoming connection for the server hosting KUMA.

Configuring KUMA integration with Open Single Management Platform includes the following steps:

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

   The credentials of this account are used when creating a secret to establish a connection with Open Single Management Platform. Different tasks may require different access rights.

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

2. Creating a secret of the credentials type for connecting to Open Single Management Platform
3. Configuring Open Single Management Platform integration settings
4. Creating a connection to the Open Single Management Platform server for importing information about assets

   If you want to import information about assets registered on Open Single Management Platform servers into KUMA, you need to create a separate connection to each Open Single Management Platform server for each selected tenant.

   If integration is disabled for the tenant or there is no connection to Open Single Management Platform, an error is displayed in the KUMA Console when attempting to import information about assets. In this case, the import process does not start.

Configuring Open Single Management Platform integration settings

To configure the settings for integration with Open Single Management Platform:

1. Open the web interface of Kaspersky Unified Monitoring and Analysis Platform and select the Settings → Open Single Management Platform section.

   The Open Single Management Platform integration by tenant window opens.

2. Select the tenant for which you want to configure integration with Open Single Management Platform.

   The Open Single Management Platform integration window opens.

3. Enable or disable integration with Open Single Management Platform 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 Open Single Management Platform:
   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 Open Single Management Platform.

5. Click the Save button.

The Open Single Management Platform 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 Open Single Management Platform integration

To add a tenant to the list of tenants for integration with Open Single Management Platform:

1. Open the KUMA web console and select Settings → Open Single Management Platform.

   The Open Single Management Platform integration by tenant appears.

2. Click the Add tenant button.

   The Open Single Management Platform integration window appears.

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 Open Single Management Platform.

Creating Open Single Management Platform connection

To create a new Open Single Management Platform connection:

1. Open the web interface of Kaspersky Unified Monitoring and Analysis Platform and select the Settings → Open Single Management Platform section.

   The Open Single Management Platform integration by tenant window opens.

2. Select the tenant for which you want to create a connection to Open Single Management Platform.
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 Open Single Management Platform server in hostname:port or IPv4:port format.
   • In the Secret drop-down list, select the secret with the Open Single Management Platform account credentials or create a new secret.
     1. Click the button.

        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 Open Single Management Platform account credentials.
        3. In the Type drop-down list, select credentials.
        4. In the User and Password fields, enter credentials for your Open Single Management Platform 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 Open Single Management Platform 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 Open Single Management Platform server.

     This check box is cleared by default.

4. If you want Kaspersky Unified Monitoring and Analysis Platform 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 Open Single Management Platform server is uploaded during the import.

5. Click the Save button.

The connection to the Open Single Management Platform server is now created. You can use it to import asset information from Open Single Management Platform to Kaspersky Unified Monitoring and Analysis Platform or to create tasks related to assets in Open Single Management Platform from Kaspersky Unified Monitoring and Analysis Platform.

Editing Open Single Management Platform connection

To edit a Open Single Management Platform connection:

1. Open the web interface of Kaspersky Unified Monitoring and Analysis Platform and select the Settings → Open Single Management Platform section.

   The Open Single Management Platform integration by tenant window opens.

2. Select the tenant for which you want to configure integration with Open Single Management Platform.

   The Open Single Management Platform integration window opens.

3. Click the Open Single Management Platform connection you want to change.

   The window with the selected Open Single Management Platform connection parameters opens.

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

The Open Single Management Platform connection will be changed.

Deleting Open Single Management Platform connection

To delete a Open Single Management Platform connection:

1. Open the web interface of Kaspersky Unified Monitoring and Analysis Platform and select the Settings → Open Single Management Platform section.

   The Open Single Management Platform integration by tenant window opens.

2. Select the tenant for which you want to configure integration with Open Single Management Platform.

   The Open Single Management Platform integration window opens.

3. Select the Open Single Management Platform connection that you want to delete.
4. Click the Delete button.

The Open Single Management Platform connection will be deleted.

Importing events from the Open Single Management Platform database

In KUMA, you can receive events from the Open Single Management Platform 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 Open Single Management Platform proceeds in stages:

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 Open Single Management Platform:

1. Create a copy of the predefined connector corresponding to the type of database used by Open Single Management Platform:
   1. In the KUMA Console, 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 Open Single Management Platform database you are using.

      An example of a query to the Open Single Management Platform 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 Open Single Management Platform 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 Open Single Management Platform 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 web interface of Kaspersky Unified Monitoring and Analysis Platform, in the Resources section, click Add event source.
      • In the web interface of Kaspersky Unified Monitoring and Analysis Platform, 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 Open Single Management Platform 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 Open Single Management Platform.

You can view Open Single Management Platform 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.1 and 5.0 to manage threat response actions on assets connected to Kaspersky Endpoint Detection and Response servers, and on Open Single Management Platform 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.

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 program component administrator menu is displayed.

3. In the program 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 Console, 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 Console, 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 program component administrator menu is displayed.

3. In the program 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 Console, 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 Console, 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 import Kaspersky Endpoint Detection and Response 5.1 events from hosts using the kata/edr connector:

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", do the following:
   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. Unpack 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 and 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, please 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 will display the error "Bad Request: max_events N is greater than the allowed value".
      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 Events fetch timeout of the server 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 "[ООТВ] KEDR telemetry" 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 the a 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 Console 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 Console 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 Console, 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 Priority 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. In the Conditions settings block, 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 Open Single Management Platform.
             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 Open Single Management Platform 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, see 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, see 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, see 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, see 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, see 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, you should see the Assets for given conditions window containing a list of assets that satisfy the search conditions.
        • 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 Console, 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 Console, 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 field.
      4. In the Event field field, select DeviceProduct.
      5. In the operator field, select =.
      6. In the Right operand field, select constant.
      7. In the value field, enter 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 field.
      4. In the Event field 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 field.
      4. In the Event field 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 program 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 program 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 program 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 Console, 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. In the Mapping settings block, 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, and can use 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. In the Conditions settings block, 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, there may be fields of additional parameters for identifying the value to be passed to the filter. 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 data feed information by copying the TI indicator field value from the KUMA event and searching for this value on the CyberTrace portal 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 Console. When this integration is enabled, the KUMA Console 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 Console.

To integrate the CyberTrace web interface in KUMA:

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

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

     on which the KUMA Console is deployed

     .

   • Use the FQDN when logging into the KUMA Console.

     If you are using the Mozilla Firefox browser to work with the program 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 Console.

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

5. In the browser's address bar, enter the URL of the KUMA Console 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 Console, 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're related into a single 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 Console, 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 Console, 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 which KUMA has information available, the data from Kaspersky Threat Intelligence Portal opens, with the time it was received indicated at the bottom, instead of the Threat Lookup enrichment window. 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.

Connecting over LDAP

LDAP connections are created and managed under Settings → LDAP server in the KUMA Console. 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

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 Console, 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 Console, 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 Console 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 Console 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 Console, open the Settings → LDAP server section.
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).

      The selected secret can be changed by clicking on the button.

   2. If you want to create a new secret, click the button.

      The Secret window opens.

   3. In the Name (required) field, enter the name of the secret containing 1 to 128 Unicode characters.
   4. In the User and Password (required) fields, enter the account credentials for connecting to the Active Directory server.

      You can enter the user name in one of the following formats: <user name>@<domain> or <domain><user name>.

   5. In the Description field, enter a description of up to 4,000 Unicode characters.
   6. Click the Save button.
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.

     method is used, first it establishes an unencrypted connection on 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 button on the right of the Certificate list.

      The Secret window opens.

   3. In the Name field, enter the name that will be displayed in the list of certificates after the certificate is added.
   4. Click the Upload certificate file button to add the file containing the Active Directory certificate. X.509 certificate public keys in Base64 are supported.
   5. If necessary, provide any relevant information about the certificate in the Description field.
   6. Click the Save button.

   The certificate will be uploaded and displayed in the Certificate list.

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 program will contact the next server, and so on. If none of the indicated servers responds during the specified amount of time, the connection will be terminated with an error.

10. In the Base DN field, enter the base distinguished name of the directory where the search request should be performed.
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
       • co
       • company
       • department
       • description
       • displayName
       • distinguishedName
       • division
       • employeeID
       • givenName
       • l
       • lastLogon
       • lastLogonTimestamp
       • Mail
       • mailNickname
       • managedObjects
       • manager
       • memberOf (this attribute can be used for search during correlation)
       • mobile
       • name
       • objectCategory
       • objectGUID (this attribute always requested from Active Directory even if a user doesn't specify it)
       • objectSID
       • physicalDeliveryOfficeName
       • pwdLastSet
       • sAMAccountName
       • sAMAccountType
       • sn
       • streetAddress
       • telephoneNumber
       • title
       • userAccountControl
       • UserPrincipalName
       • whenChanged
       • whenCreated

       After you add custom attributes in the LDAP connection settings, the LDAP attribute to receive drop-down list in the collector automatically includes the new attributes. Custom attributes are identified by a question mark next to the attribute name. If you added the same attribute for multiple domains, the attribute is listed only once in the drop-down list. You can view the domains by moving your cursor over the question mark. Domain names are displayed as links. If you click a link, the domain is automatically added to LDAP accounts mapping if it was not previously added.

       If you deleted a custom attribute in the LDAP connection settings, manually delete the row containing the attribute from the mapping table in the collector. Account attribute information in KUMA is updated each time you import accounts.  

    2. Import accounts.
    3. In the collector, in the LDAP mapping table, define the rules for mapping KUMA fields to LDAP attributes.
    4. Restart the collector.

       After the collector is restarted, KUMA begins enriching events with accounts.

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

Changing an LDAP server connection

To change an LDAP server connection:

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

To change the schedule of KUMA queries to LDAP servers:

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

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

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

Deleting an LDAP server connection

To delete LDAP connection to Active Directory:

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

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

Expand all | Collapse all

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

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

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 program supports integration with KICS for Networks version 4.0 or later.

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

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

To configure integration with KICS/KATA in KUMA:

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

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

1. In the KUMA Console, 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 in the Vulnerabilities settings block.

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

Imported data storage period

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

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 Console, 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 Console, click the name of your user account in the bottom-left corner of the window and click the Profile button in the opened menu.

      The User window with your user account parameters opens.

   2. 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 Console and select Settings → Kaspersky Automated Security Awareness Platform.

   The Kaspersky Automated Security Awareness Platform window opens.

2. In the Secret field click the button to create a secret of the token by entering the token received from ASAP:
   1. In the Name field, enter the name of the secret. Must contain 1 to 128 Unicode characters.
   2. In the Token field, enter the authorization token for API requests to ASAP.
   3. If necessary, add the secret description in the Description field.
   4. Click Save.
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 Console, 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 Console, 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 proceeds in stages:

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 notifications in KUMA

To configure the sending of KUMA notifications to Telegram:

1. Create a response rule:
   1. In the KUMA Console, 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 proceeds in stages:

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 Console, 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 Console, 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 proceeds in stages:

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 Console, 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 Console, 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 proceeds in stages:

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 Console, 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 Console, 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 Console 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 cfqdn=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 the 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 Console.

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