Integration with other solutions

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

Integration with Kaspersky Security Center

You can create or edit Kaspersky Security Center integration settings in the OSMP console.

In the KUMA Console, you can view the integration with selected Kaspersky Security Center Servers for one, several, or all KUMA tenants. If integration with Kaspersky Security Center is enabled, you can manually import assets, edit the automatic scheduled import interval, view the hierarchy of Kaspersky Security Center Servers, or temporarily disable scheduled import.

Configuring the data refresh interval for Kaspersky Security Center assets

To configure the data refresh interval for asset data from Kaspersky Security Center:

1. In the KUMA Console, select Settings → Kaspersky Security Center.

   This opens the Kaspersky Security Center integration window.

2. In the Tenant drop-down list, select the tenant for which you want to configure data refresh settings.
3. In the Data refresh interval in hours field, specify the time interval at which KUMA updates data about Kaspersky Security Center devices.

   The interval is specified in hours and must be an integer.

   The default time interval is 12 hours.

4. Click the Save button.

Kaspersky Security Center asset data update settings for the selected tenant are configured.

If the tenant you want is missing from the list of tenants, use the OSMP console to add it to the list of tenants.

Scheduled import of Kaspersky Security Center assets

To set up a schedule for importing Kaspersky Security Center assets:

1. In the KUMA Console, select Settings → Kaspersky Security Center.

   This opens the Kaspersky Security Center integration window.

2. Select the tenant for which you want to schedule the import of Kaspersky Security Center assets.

   The Kaspersky Security Center integration window opens.

3. If necessary, clear the Disabled check box to enable integration with Kaspersky Security Center for the selected tenant. This check box is cleared by default.

   If you want to temporarily disable integration with Kaspersky Security Center for the selected tenant, select the Disabled check box. This turns off the scheduled import of Kaspersky Security Center assets.

4. In the Data refresh interval field, specify the time interval at which you want KUMA to update information about Kaspersky Security Center devices.

   The interval is specified in hours and must be an integer.

   The default time interval is 12 hours.

5. Click the Save button.

The specified settings for the scheduled import of Kaspersky Security Center assets for the selected tenant are applied.

Manual import of Kaspersky Security Center assets

To manually import Kaspersky Security Center assets:

1. In the KUMA Console, select Settings → Kaspersky Security Center.

   This opens the Kaspersky Security Center integration window.

2. In the Tenant drop-down list, select the tenant for which you want to manually import Kaspersky Security Center assets.

   The Connection parameters window opens.

3. In the Connection parameters window:
   1. For the Disabled check box, do one of the following:
      • Clear the check box if you want to enable integration with Kaspersky Security Center for the selected tenant.
      • Select the check box if you want to disable integration with Kaspersky Security Center for the selected tenant.

        This check box is cleared by default.

   2. If you want to import assets from new groups created in Kaspersky Security Center, select the Import assets from new groups check box.
4. Click Import KSC assets.
5. Click Save.

Kaspersky Security Center assets for the specified tenant are imported regardless of the configured schedule.

Viewing the hierarchy of Kaspersky Security Center Servers

To view the hierarchy of Kaspersky Security Center Servers:

1. In the KUMA Console, select Settings → Kaspersky Security Center.

   This opens the Kaspersky Security Center integration window.

2. In the Tenant drop-down list, select the tenant for which you want to view the hierarchy.

   The Connection parameters window opens.

3. In the Connection parameters window, click Load hierarchy.

The hierarchy of Kaspersky Security Center Servers for the specified tenant is displayed in the Connection parameters window.

Importing events from the Kaspersky Security Center database

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

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

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

1. Create a copy of the predefined connector.

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

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

To configure the import of events from Kaspersky Security Center:

1. Create a copy of the predefined connector corresponding to the type of database used by Kaspersky Security Center:
   1. In the KUMA 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 Kaspersky Security Center database you are using.

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

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

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

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

      CASE

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

                  ELSE ev.rise_time

              END

          AS endTime,

          CASE

              WHEN ev.registration_time is not NULL

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

                  ELSE ev.registration_time

              END

          AS kscRegistrationTime,

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

          hs.wstrWinName as dHost,

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

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

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

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

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

          serv.wstrWinDomain as kscNtDomain,

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

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

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

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

          CASE

          WHEN virus.tmVirusFoundTime is not NULL

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

                  ELSE ev.registration_time

              END

          AS virusTime,

          virus.wstrObject As filePath,

          virus.wstrVirusName as virusName,

          virus.result_ev as result

      FROM KAV.dbo.ev_event as ev

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

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

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

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

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

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

      where:

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

      Click Save.

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

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

      Click Save.

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

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

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

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

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

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

Kaspersky Endpoint Detection and Response integration

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

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

You can also import events to KUMA and receive information about Kaspersky Endpoint Detection and Response alerts (for more details about alerts, see the Configuring integration with an SIEM system section of the Kaspersky Anti Targeted Attack Platform 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

Importing Kaspersky Endpoint Detection and Response events from hosts using the 'kata/edr' connector involves the following steps:

1. Performing configuration the KUMA side to receive events.

   To do this, in KUMA, you must 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. Accepting the KUMA authorization request on the KEDR side to begin sending events to 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. Log in to the KUMA Console in one of the following ways:
   • In the main menu of the OSMP console, go to Settings → KUMA.
   • In your browser, go to https://kuma.<smp_domain>:7220.
2. Go to Resources→Collectors, select Add collector.
3. 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.
4. At step 2 Transport, do the following:
   • 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 KEDR is deployed in a cluster, you can click Add to add all nodes. KUMA will connect to each specified node in sequence. If KEDR 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 of the secret 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.

        In the KUMA Console, click Upload certificate and select the cert.pem file. Click Upload private key and select the key.pem file. Click Create; the secret is added to the Secret drop-down list is automatically selected.

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

     5. The External ID field contains the ID for external systems. This ID is displayed in the KEDR web interface when authorizing the KUMA server. KUMA generates an ID automatically and the External ID field is automatically pre-populated.
   • If necessary, specify the settings on the Advanced settings tab:
     1. To get detailed information in the collector log, move the Debug toggle switch to the enabled position.
     2. 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. This means that the value configured on the KEDR server as the default is applied (for details, please refer to the 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. The default value is 0. This means that the value configured on the KEDR server as the default is applied (for details, please refer to the KATA Help).

        The KEDR server uses two parameters: the maximum number of events and the events fetch timeout. Events are sent when the specified number of events is collected or the configured time elapses, whichever happens first. If the specified time has elapsed, but the specified number of events has not been collected, the KEDR server sends the events that it already has, without waiting for more.

     5. In the Client timeout field, specify how long KUMA must wait for a response from the KEDR server, in seconds. Default value: 1,800 s; displayed as 0. The client-side limit is specified in the Client timeout field. The Client timeout must be greater than the server value Events fetch timeout to wait for the server's response without interrupting the current event collection task with a new request. If the response from the KEDR server does not arrive in the end, KUMA repeats the request.
     6. In the KEDRQL filter field, specify the conditions for filtering the request. As a result, pre-filtered events are received from KEDR. For details about available filter fields, please refer to the KATA Help.
5. At step 3 "Parsing", click Add event parsing and select "[OOTB] KEDR telemetry" in the Basic event parsing window.
6. 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 KUMA destination host where you want to install the collector.

   Example of a command to install the collector:

   sudo /opt/kaspersky/kuma/kuma collector --core https://<KUMA Core server FQDN>:7210 --id <service ID copied from the KUMA Console> --api.port <port used for communication with the installed component>

   The default fully qualified domain name of the KUMA Core is kuma.<smp_domain>. The port used for connecting to the KUMA Core cannot be changed. The default port number is 7210.

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

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 the KUMA alert

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 clicking 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	>, >=, =, <=, <
             OS	=, like	The "like" operator ensures that the search is not case sensitive.
             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	=, like	The "like" operator ensures that the search is not case sensitive.
             CVE	=, in	The "in" operator lets you specify an array of values.
             Software	=, like
             CII	in	More than one value can be selected.
             Anti-virus databases last updated	>=,<=
             Last update of the information	>=,<=
             Protection last updated	>=,<=
             System last 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	>=,<=

          3. Click the Test conditions button to make sure that the specified filter is correct. When you click the button, the Assets for given conditions window opens 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 (Threat hunting 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.

  CyberTrace console integration is available only if your CyberTrace license includes multi-user feature.

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.

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 Welcome to Kaspersky CyberTrace window opens.

2. In the <select SIEM> drop-down list, select the type of SIEM system from which you want to receive data and click the Next button.

   The Connection Settings window opens.

3. Do the following:
   1. In the Service listens on settings block, select the IP and port option.
   2. In the IP address field, enter 0.0.0.0.
   3. In the Port field, enter the port for receiving events, the default port is 9999.
   4. Under Service sends events to, specify 127.0.0.1 in the IP address or hostname field and in the Port field, specify 9998.

      Leave the default values for everything else.

   5. Click Next.

   The Proxy Settings window opens.

4. If a proxy server is being used in your organization, define the settings for connecting to it. If not, leave all the fields blank and click Next.

   The Licensing Settings window opens.

5. In the Kaspersky CyberTrace license key field, add a license key for CyberTrace.
6. In the Kaspersky Threat Data Feeds certificate field, add a certificate that allows you to download updated data feeds from servers, and click Next.

CyberTrace will be configured.

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

1. In the CyberTrace web interface, select Settings – Service.
2. In the Connection Settings block:
   1. Select the IP and port option.
   2. In the IP address field, enter 0.0.0.0.
   3. In the Port field, specify the port for receiving events, the default port is 9999.
3. In the Web interface settings block, in the IP address or hostname field, enter 127.0.0.1.
4. In the upper toolbar, click Restart the CyberTrace Service.
5. Select Settings – Events format.
6. In the Alert events format field, enter %Date% alert=%Alert%%RecordContext%.
7. In the Detection events format field, enter Category=%Category%|MatchedIndicator=%MatchedIndicator%%RecordContext%.
8. In the Records context format field, enter |%ParamName%=%ParamValue%.
9. In the Actionable fields context format field, enter %ParamName%:%ParamValue%.

CyberTrace will be configured.

After updating CyberTrace configuration you have to restart the CyberTrace server.

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.
   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 click the Add row button to add a string, and can click the button to remove a string.

   9. Use the Debug drop-down list 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

       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. The name must contain 1 to 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, you may see fields of additional parameters that you need to use to define the value that will be passed to the filter. For example, when choosing active list you will need to specify the name of the active list, the entry key, and the entry key field.

          3. In the operator drop-down list, select the relevant operator.

             Filter operators

             • =—the left operand equals the right operand.
             • <—the left operand is less than the right operand.
             • <=—the left operand is less than or equal to the right operand.
             • >—the left operand is greater than the right operand.
             • >=—the left operand is greater than or equal to the right operand.
             • inSubnet—the left operand (IP address) is in the subnet of the right operand (subnet).
             • contains—the left operand contains values of the right operand.
             • startsWith—the left operand starts with one of the values of the right operand.
             • endsWith—the left operand ends with one of the values of the right operand.
             • match—the left operand matches the regular expression of the right operand. The RE2 regular expressions are used.
             • hasBit—checks whether the left operand (string or number) contains bits whose positions are listed in the right operand (in a constant or in a list).

               The value to be checked is converted to binary and processed right to left. Chars are checked whose index is specified as a constant or a list.

               If the value being checked is a string, then an attempt is made to convert it to integer and process it in the way described above. If the string cannot be converted to a number, the filter returns False.

             • hasVulnerability—checks whether the left operand contains an asset with the vulnerability and vulnerability severity specified in the right operand.

               If you do not specify the ID and severity of the vulnerability, the filter is triggered if the asset in the event being checked has any vulnerability.

             • inActiveList—this operator has only one operand. Its values are selected in the Key fields field and are compared with the entries in the active list selected from the Active List drop-down list.
             • 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 necessary, select the do not match case check box. When this check box is selected, the operator ignores the case of the values.

             The selection of this check box does not apply to the InSubnet, InActiveList, InCategory or InActiveDirectoryGroup operators.

             This check box is cleared by default.

          5. If you want to add a negative condition, select If not from the If drop-down list.
          6. You can add multiple conditions or a group of conditions.
       5. If you have added multiple conditions or groups of conditions, choose a search 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 events TI indicator field value from KUMA and searching for it in the CyberTrace in the indicators section. All relevant information will be displayed in the Indicator context section of CyberTrace.

Integrating CyberTrace interface

You can integrate the CyberTrace web interface with 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 the Resources → Secrets section.

   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 the Settings → Kaspersky CyberTrace section.

   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 this, in the Allow hosts section, click Add host and in the field that is displayed, enter the IP or hostname of the device.

   • Use FQDN when logging into the KUMA Console.

     If you are using the Mozilla Firefox browser to manage the console, 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 is 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.

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 the Resources → Secrets section.

   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 KUMA Console, go to the Settings section, and then 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 console and accept the Terms of Use. Otherwise, an error is 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 the Settings → LDAP server section 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 the Settings → LDAP server section 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. In the KUMA Console, select the Settings → LDAP server section.

   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. In the KUMA Console, select the Settings → LDAP server section.

   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 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 over port 389, then it sends an encryption request. If the STARTTLS command ends with an error, the connection is terminated.

     Make sure that port 389 is open. Otherwise, a connection with the domain controller will be impossible.

   • ssl.

     When using SSL, an encrypted connection is immediately established over port 636.

   • insecure.

   When using an encrypted connection, it is impossible to specify an IP address as a URL.

8. If you enabled TLS encryption at the previous step, add a TLS certificate. To do so:
   1. If you previously uploaded a certificate, select it from the Certificate drop-down list.

      If no certificate was previously added, the drop-down list shows No data.

   2. If you want to upload a new certificate, click the button on the right of the Certificate list.

      The Secret window opens.

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

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

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. 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. Open the Settings → LDAP section in the KUMA Console 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. In the KUMA Console, select the Settings → LDAP server section.

   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 the Settings → LDAP server → LDAP server integration by tenant section.
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 the Settings → LDAP server → LDAP server integration by tenant section.
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 the Settings → LDAP server → LDAP server integration by tenant section.
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 the Settings → LDAP server → LDAP server integration by tenant section.
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, go to the Settings → LDAP server section 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.

Kaspersky Industrial CyberSecurity for Networks integration

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

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

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

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

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

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

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

Configuring integration in KICS for Networks

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

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

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

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

Configuring integration in KUMA

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

To configure integration with KICS for Networks in KUMA:

1. In the KUMA Console, select Settings → Kaspersky Industrial CyberSecurity for Networks.

   The Kaspersky Industrial CyberSecurity for Networks integration by tenant window opens.

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

   The Kaspersky Industrial CyberSecurity for Networks integration window opens.

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 for Networks is configured in KUMA, and the window shows the IP address of the node where the KICS for Networks connector will be running and its ID.

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 Settings → Kaspersky Industrial CyberSecurity for Networks and select the tenant for which you want to enable or disable KICS for Networks integration.

   The Kaspersky Industrial CyberSecurity for Networks integration window opens.

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 → Kaspersky Industrial CyberSecurity for Networks section.
2. Select the relevant tenant.

   The Kaspersky Industrial CyberSecurity for Networks integration window opens.

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

To manually change a KICS for Networks asset status:

1. In the KUMA Console, go to the Assets section, and 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 for Networks drop-down list, select the status that you need to assign to the KICS for Networks asset. The Authorized or Unauthorized statuses are available.

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

Automatically changing the status of a KICS for Networks asset

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

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. In the KUMA Console, click the user account name in the lower-left corner of the window and in the menu that is displayed, click Profile.

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

KASAP 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 KASAP and KUMA includes configuring API connection to KASAP. The process takes place in both solutions:

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

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

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

Creating a token

To create a token:

1. Sign in to the KASAP web interface.
2. In the Control panel section, click the Import and synchronization button, 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 KASAP 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 KASAP for API requests:

1. Log in to the KASAP platform console.
2. In the Control panel section, click the Import and synchronization button, and then open the Open API tab.
3. A link for accessing KASAP 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 KASAP:

1. In the KUMA Console, go to the Settings → Kaspersky Automated Security Awareness Platform section.

   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 KASAP:
   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 KASAP.
   3. If necessary, add the secret description in the Description field.
   4. Click Save.
3. In the KASAP Open API URL field, specify the address used by KASAP for API requests.
4. In the KASAP administrator email field, specify the email address of the KASAP 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 KASAP.
6. To disable or enable integration with KASAP, select or clear the Disabled check box.
7. Click Save.

Integration with KASAP 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 KASAP and changing learning groups

After configuring the integration between KASAP and KUMA, the following information from KASAP 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 KASAP:

1. In the KUMA Console, in the Alerts or Incidents section, select the relevant 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 KASAP courses details tab.

The window displays information about the user from KASAP.

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

To change a user learning group in KASAP:

1. In the KUMA Console, in the Alerts or Incidents section, select the relevant 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 KASAP group drop-down list, select the KASAP learning group you want to assign the user to.
4. Click Apply.

The user is moved to the selected KASAP group, the KASAP 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 KASAP 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.
The terms and conditions of premium technical support do not apply to this integration; support requests are processed without a guaranteed response time.

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

Configure Telegram notifications involves the following steps:

1. Creating and configuring a Telegram bot

   A special bot sends notifications about triggered correlation rules. It can send notifications to a private or group Telegram chat.

2. Creating a script for sending notifications

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

3. Configuring notifications in KUMA

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

Creating and configuring a Telegram bot

To create and configure a Telegram bot:

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

   /newbot

4. Enter the name of the bot.
5. Enter the login name of the bot.

   The bot is created. You receive a link to the chat that looks like t.me/<bot login> and a token for contacting the bot.

6. If you want to use the bot in a group chat, and not in private messages, edit privacy settings:
   1. In the BotFather chat, enter the command:

      /mybots

   2. Select the relevant bot from the list.
   3. Click Bot Settings → Group Privacy and select Turn off.

      The bot can now send messages to group chats.

7. To open a chat with the bot you created, use the t.me/<botlogin> link that you obtained at step 5, and click Start.
8. If you want the bot to send private messages to the user:
   1. In the chat with the bot, send any message.
   2. Follow the https://t.me/getmyid_bot link and click Start.
   3. The response contains the Current chat ID. You need this value to configure the sending of messages.
9. If you want the bot to send messages to the group chat:
   1. Add https://t.me/getmyid_bot to the group chat for receiving notifications from KUMA.

      The bot sends a message to the group chat, the message contains the Current chat ID value. You need this value to configure the sending of messages.

   2. Remove the bot from the group.
10. Send a test message through the bot. To do so, paste the following link into the address bar of your browser:

    https://api.telegram.org/bot<token>/sendMessage?chat_id=<chat_id>&text=test

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

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

Creating a script for sending notifications

To create a script:

1. In the console of the server on which the correlator is installed, create a script file and add the following lines to it:

   #!/bin/bash

   set -eu

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

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

   RULE=$1

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

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

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

   #!/bin/bash

   set -eu

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

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

   RULE=$1

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

   PROXY=<address and port of the proxy server>

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

2. Save the script to the correlator directory at /opt/kaspersky/kuma/correlator/<ID of the correlator that must respond to events>/scripts/.

   For information about obtaining the correlator ID, see the Getting service identifier section.

3. Make the 'kuma' user the owner of the file and grant execution rights:

   chown kuma:kuma /opt/kaspersky/kuma/correlator/<ID of the correlator that must respond>/scripts/<script name>.sh

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

Configuring 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.
The terms and conditions of premium technical support do not apply to this integration; support requests are processed without a guaranteed response time.

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

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

Configuring the integration involves the following steps:

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

Configuring integration in UserGate

To configure integration in UserGate:

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

   In the Administrator profile field, select the profile created at step 3.

8. Click Save.
9. In the address bar of your browser, after the address and port of UserGate, add ?features=zone-xml-rpc and press ENTER.
10. Go to the Network → Zones section and for the zone of the interface that you want to use for API interaction, go to the Access Control tab and select the check box next to the XML-RPC for management service.

    If necessary, you can add the IP address of the KUMA correlator whose correlation rules must trigger blocking in UserGate, to the list of allowed addresses.

11. Click Save.

Preparing a script for integration with UserGate

To prepare a script for use:

1. Copy the ID of the correlator whose correlation rules you want to trigger blocking of URL, IP address, or domain name in UserGate:
   1. In the KUMA 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.
The terms and conditions of premium technical support do not apply to this integration; support requests are processed without a guaranteed response time.

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

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

Configuring the integration involves the following steps:

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

Configuring integration in KWTS

To prepare the integration in KWTS:

1. Connect to the KWTS web interface under an administrator account and create a role with permissions to view and create/edit a rule.

   For more details on creating a role, see the Kaspersky Web Traffic Security Help.

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

   You can use a local administrator account instead.

3. In the Rules section, go to the Access tab and click Add rule.
4. In the Action drop-down list, select Block.
5. In the Traffic filtering drop-down list, select the URL value, and in the field on the right, enter a nonexistent or known malicious address.
6. In the Name field, enter the name of the rule.
7. Enable the rule using the Status toggle switch.
8. Click Add.
9. In the KWTS web interface, open the rule you just created.
10. Make a note of the ID value that is displayed at the end of the page address in the browser address bar.

    You must use this value when configuring the response rule in KUMA.

The integration is prepared on the KWTS side.

Preparing a script for integration with KWTS

To prepare a script for use:

1. Copy the ID of the correlator whose correlation rules you want to trigger blocking of URL, IP address, or domain name in KWTS:
   1. In the KUMA 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 and library:

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

3. Place the downloaded script 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.
The terms and conditions of premium technical support do not apply to this integration; support requests are processed without a guaranteed response time.

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

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

Configuring the integration involves the following steps:

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

Configuring integration in KSMG

To prepare the integration in KSMG:

1. Connect to the KSMG web interface under an administrator account and create a role with permissions to view and create/edit a rule.

   For more details on creating a role, see the Kaspersky Secure Mail Gateway Help.

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

   You can use the 'Administrator' local administrator account.

3. In the Rules section, click Create.
4. In the left pane, select the General section.
5. Enable the rule using the Status toggle switch.
6. In the Rule name field, enter the name of the new rule.
7. Under Mode, select one of the message processing options that meets the criteria of this rule.
8. Under Sender on the Email addresses tab, enter a nonexistent or known malicious sender address.
9. Under Recipient on the Email addresses tab, specify the relevant recipients or the "*" character to select all recipients.
10. Click the Save button.
11. In the KSMG web interface, open the rule you just created.
12. Make a note of the ID value that is displayed at the end of the page address in the browser address bar.

    You must use this value when configuring the response rule in KUMA.

The integration is prepared on the KSMG side.

Preparing a script for integration with KSMG

To prepare a script for use:

1. Copy the ID of the correlator whose correlation rules must trigger the blocking of the IP address or email address of the message sender in KSMG:
   1. In the KUMA 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 and library:

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

3. Place the downloaded script 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.

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

   • Administrator or Analyst role.
   • Access to the tenant into which the assets will be imported.
   • Rights to use API requests: GET /assets, GET /tenants, POST/assets/import.
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 Administrator or Analyst role must be assigned to the user account for which the API token is being generated.
  --tenant <tenant name>	Yes	Name of the KUMA tenant in which the assets from the RedCheck report will be imported.
  --vuln-report <full path to the "Vulnerabilities" report>	Yes	"Vulnerabilities" report file in CSV format.
  --inventory-report <full path to the "Inventory" report file>	No	"Inventory" report file in CSV format.
  -v	No	Display extended information about the import of assets.

  Possible errors

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

Configuring receipt of Sendmail events

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

SIEM system

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

Configuring event receiving consists of the following steps:

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

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

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

   You can verify that the Sendmail event source server is correctly configured in the Searching for related events section of the KUMA 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