Kaspersky Unified Monitoring and Analysis Platform

Contents

[Topic 217927]

Integration with Kaspersky Security Center

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

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

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

  1. Creating a user account in the Kaspersky Security Center Administration Console

    The credentials of this account are used when creating a secret to establish a connection with Kaspersky Security Center. Different tasks may require different access rights.

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

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

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

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

In this section

Configuring Kaspersky Security Center integration settings

Adding a tenant to the list for Kaspersky Security Center integration

Creating Kaspersky Security Center connection

Editing Kaspersky Security Center connection

Deleting Kaspersky Security Center connection

Importing events from the Kaspersky Security Center database

Page top
[Topic 217923]

Configuring Kaspersky Security Center integration settings

To configure the settings for integration with Kaspersky Security Center:

  1. Open the KUMA web interface and select SettingsKaspersky Security Center.

    The Kaspersky Security Center integration by tenant window opens.

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

    The Kaspersky Security Center integration window opens.

  3. 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 this tenant.
    • Select the check box if you want to disable integration with Kaspersky Security Center for this tenant.

    This check box is cleared by default.

  4. In the Data refresh interval field, specify the time interval at which KUMA updates data on 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 Kaspersky Security Center integration settings for the selected tenant will be configured.

If the required tenant is not in the list of tenants, you need to add it to the list.

Page top
[Topic 217933]

Adding a tenant to the list for Kaspersky Security Center integration

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

  1. Open the KUMA web interface and select SettingsKaspersky Security Center.

    The Kaspersky Security Center integration by tenant window opens.

  2. Click the Add tenant button.

    The Kaspersky Security Center integration window opens.

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

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

Page top
[Topic 232734]

Creating Kaspersky Security Center connection

To create a new Kaspersky Security Center connection:

  1. Open the KUMA web interface and select SettingsKaspersky Security Center.

    The Kaspersky Security Center integration by tenant window opens.

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

        The secret window is displayed.

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

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

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

      This check box is cleared by default.

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

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

  5. Click the Save button.

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

Page top
[Topic 217788]

Editing Kaspersky Security Center connection

To edit a Kaspersky Security Center connection:

  1. Open the KUMA web interface and select SettingsKaspersky Security Center.

    The Kaspersky Security Center integration by tenant window opens.

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

    The Kaspersky Security Center integration window opens.

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

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

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

The Kaspersky Security Center connection will be changed.

Page top
[Topic 217849]

Deleting Kaspersky Security Center connection

To delete a Kaspersky Security Center connection:

  1. Open the KUMA web interface and select SettingsKaspersky Security Center.

    The Kaspersky Security Center integration by tenant window opens.

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

    The Kaspersky Security Center integration window opens.

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

The Kaspersky Security Center connection will be deleted.

Page top
[Topic 217829]

Importing events from the Kaspersky Security Center database

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

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

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

  1. Create a copy of the predefined connector.

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

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

To configure the import of events from Kaspersky Security Center:

  1. Create a copy of the predefined connector corresponding to the type of database used by Kaspersky Security Center:
    1. In the KUMA web interface, in the ResourcesConnectors 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 edit-pencil in the line of the secret that you are using.
    4. This opens the Secret window; in that window, in the URL field, specify the server connection address in the following format:

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

      where:

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

      Click Save.

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

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

      Click Save.

  2. Install the collector in the web interface:
    1. Start the Collector Installation Wizard in one of the following ways:
      • In the KUMA web interface, in the Resources section, click Add event source.
      • In the KUMA web interface in the ResourcesCollectors 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.

Page top
[Topic 222247]

Kaspersky Endpoint Detection and Response integration

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

You can configure KUMA integration with Kaspersky Endpoint Detection and Response 4.1 and 5.0 to manage threat response actions on assets connected to Kaspersky Endpoint Detection and Response servers, and on 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, see the Configuring integration with an SIEM system section of the Kaspersky Anti Targeted Attack Platform online help).

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

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

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

In this section

Importing events from Kaspersky Endpoint Detection and Response

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

Page top
[Topic 235592]

Importing events from Kaspersky Endpoint Detection and Response

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, and 5.0 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.

    It is strongly not recommended to use this port for any external connections other than KUMA. To restrict connections over port 10000 only for KUMA, run the following command:

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

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

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

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

In KUMA:

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

    When creating a connector, specify the following parameters:

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

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

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

Importing events from Kaspersky Endpoint Detection and Response 5.0

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

  • Import of events is available only for the non-fault-tolerant 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 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}'

  7. Run the following commands:

    kata-firewall stop

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

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

In KUMA:

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

    When creating a connector, specify the following parameters:

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

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

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

Page top
[Topic 234627]

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

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

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

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

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

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

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

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

  1. Creating a correlator.

    Select the [OOTB] KATA Alert correlation rule.

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

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

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

To add a category:

  1. In the KUMA web interface, select the Assets section.
  2. On the All assets tab, expand the list of tenant categories by clicking the button filter-plus 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 parent-category and select a parent category for the category you are creating.

      Selected category appears in Parent fields.

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

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

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

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

          2. In the Conditions settings block, specify the filter for matching assets to attach to an asset category.

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

            Categorization filter operands and operators

            Operand

            Operators

            Comment

            Build number

            >, >=, =, <=, <

             

            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. Use the Test conditions button to make sure that the specified filter is correct. When you click the button, you should see the Assets for given conditions window containing a list of assets that satisfy the search conditions.
        • Reactive—the category will be filled with assets by using correlation rules.
  5. Click the Save button.

To add an asset:

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

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

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

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

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

Step 2. Adding a correlation rule

To add a correlation rule:

  1. In the KUMA web interface, select the Resources section.
  2. Select Correlation rules and click the Create correlation rule button.
  3. On the General tab, define 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 SelectorsSettings tab, define 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 parent-category 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, define 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 required, select one of the following values from the Debug drop-down list:
      • Enabled.

        If this is selected, the application will log information relating to the operation of the resource to the log.

      • Disabled.

        If this is selected, information relating to the operation of the resource will not be logged.

  6. Click the Save button.

Step 3. Creating a correlator

You need to launch the correlator installation wizard. At step 3 of the wizard, you are required to select the correlation rule that you added by following this guide.

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

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

Page top
[Topic 239080]

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:

In this section

Integrating CyberTrace indicator search

Integrating CyberTrace interface

Page top
[Topic 217924]

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.

By default, KUMA does not test the connection with CyberTrace.

If you want to test the integration with CyberTrace and make sure that event enrichment is working, you can follow the steps of the following example or adapt the example to your situation. The example shows an integration test, which performs enrichment and shows that the event contains the specified test URL.

To run the test:

  1. Create a test enrichment rule with parameters listed in the table below.

    Setting

    Value

    Name

    Test CT enrichment

    Tenant

    Shared

    Source kind

    CyberTrace

    URL

    <URL of the cybertrace server to which you want to send requests>:9999

    Mapping

    KUMA field: RequestURL

    CyberTrace indicator: url

    Debug

    Enabled

  1. Create a test collector with the following parameters:

    At step 2 Transport, specify the http connector.

    At step 3 Parsing, specify the normalizer and select the json parsing method, set the mapping of the RequestUrl – RequestUrl fields.

    At step 6 Enrichment, specify the 'Test CT enrichment' rule.

    At step 7 Routing, specify the storage where events must be sent.

  2. Click Create and save service.

    A complete command for installing the collector is displayed in the window.

  3. Click Copy to copy the command to the clipboard and run the command on the command line. Wait for the command to complete, return to the KUMA web interface, and click Save collector.

    A test collector is created and the test enrichment rule is linked to the collector.

  4. Use the command line interface to send a request to the collector, which will trigger an event, which will then be enriched with the test URL http://fakess123bn.nu. For example:

    curl --request POST \
      --url http://<ID of the host where the collector is installed>:<port of the collector>/input \
      --header 'Content-Type: application/json' \
      --data '{"RequestUrl":"http://fakess123bn.nu"}'

  5. Go to the KUMA Events section and run the following query to filter event output and find the enriched event:

    SELECT * FROM `events` WHERE RequestUrl = 'http://fakess123bn.nu' ORDER BY Timestamp DESC LIMIT 250

    Result:

    Enrichment is successful, the event now has a RequestURL field with the http://fakess123bn.nu value, as well as a TI indicator and indicator category with CyberTrace data.

If the test did not result in enrichment, for example, if the TI indicator is missing, we recommend to do the following:

  1. Check the settings of the collector and enrichment rules.
  2. Download the collector logs using the following command and look for errors in the logs:

    tail -f /opt/kaspersky/kuma/collector/<collector ID>/log/collector

In this section

Configuring CyberTrace to receive and process requests

Creating event Enrichment rules

Page top
[Topic 217921]

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 window, select SettingsService.
  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 SettingsEvents 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.

Page top
[Topic 217768]

Creating event Enrichment rules

To create event enrichment rules:

  1. In the KUMA web interface, open the ResourcesEnrichment 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 1,000.
    7. In the Timeout field, specify the maximum number of seconds KUMA should wait for a response from the CyberTrace server. Until a response is received or the time expires, the event is not sent to the Correlator. If a response is received before the timeout, it is added to the TI field of the event and the event processing continues. The default value is 30.
    8. In the Mapping settings block, you must specify the fields of events to be checked via CyberTrace, and define the rules for mapping fields of KUMA events to CyberTrace indicator types:
      • In the KUMA field column, select the field whose value must be sent to CyberTrace.
      • In the CyberTrace indicator column, select the CyberTrace indicator type for every field you selected:
        • ip
        • url
        • hash

      You must provide at least one string to the table. You can use the Add row button to add a string, and can use the cross 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.
          • inContextTable checks whether or not an entry exists in the context table. This operator has only one operand. Its values are selected in the Key fields field and are compared with the values of entries in the context table selected from the drop-down list of context tables.
          • inDictionary—checks whether the specified dictionary contains an entry defined by the key composed with the concatenated values of the selected event fields.
          • inCategory—the asset in the left operand is assigned at least one of the asset categories of the right operand.
          • inActiveDirectoryGroup—the Active Directory account in the left operand belongs to one of the Active Directory groups in the right operand.
          • TIDetect—this operator is used to find events using CyberTrace Threat Intelligence (TI) data. This operator can be used only on events that have completed enrichment with data from CyberTrace Threat Intelligence. In other words, it can only be used in collectors at the destination selection stage and in correlators.
        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 edit-grey 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.

Page top
[Topic 217808]

Integrating CyberTrace interface

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

To integrate the CyberTrace web interface in KUMA:

  1. In the KUMA web interface, open ResourcesSecrets.

    The list of available secrets will be displayed.

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

    The secret window is displayed.

  3. Enter information about the secret:
    1. In the Name field, choose a name for the added secret. The name must contain 1 to 128 Unicode characters.
    2. In the Tenant drop-down list, select the tenant that will own this resource.
    3. In the Type drop-down list, select credentials.
    4. In the User and Password fields, enter credentials for your CyberTrace server.
    5. If necessary, in the Description field, add up to 4,000 Unicode characters describing the resource.
  4. Click Save.

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

  5. In the KUMA web interface, open SettingsKaspersky CyberTrace.

    The window with CyberTrace integration parameters opens.

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

      To do this, in the Allow hosts section, click Add host and in the field that is displayed,

      on which the KUMA web interface is deployed.

      enter the IP or hostname of the device

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

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

  9. Click Save.

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

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

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

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

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

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

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

Data will be displayed in this section.

Updating CyberTrace deny list (Internal TI)

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

To update CyberTrace Internal TI:

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

    The context menu opens.

  2. Select Add to Internal TI of CyberTrace.

The selected object is now added to the CyberTrace denylist.

Page top
[Topic 217922]

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.

In this Help topic

Initializing integration

Requesting information from Kaspersky Threat Intelligence Portal

Viewing information from Kaspersky Threat Intelligence Portal

Updating information from Kaspersky Threat Intelligence Portal

Page top
[Topic 217925]

Initializing integration

To integrate Kaspersky Threat Intelligence Portal into KUMA:

  1. In the KUMA web interface, open ResourcesSecrets.

    The list of available secrets will be displayed.

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

    The secret window is displayed.

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

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

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

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

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

    The list of available connections will be displayed.

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

    You can create a new secret by clicking the button with the plus sign. The created secret will be saved in the ResourcesSecrets section.

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

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

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

Page top
[Topic 217900]

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.

Page top
[Topic 217967]

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.

Page top
[Topic 218041]

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.

Page top
[Topic 218026]

Integration with R-Vision Security Orchestration, Automation and Response

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

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

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

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

KUMA alert field

R-Vision SOAR incident field

FirstSeen

detection

priority

level

correlationRuleName

description

events

(as a JSON file)

files

In this section

Configuring integration in KUMA

Configuring integration in R-Vision SOAR

Managing alerts using R-Vision SOAR

Page top
[Topic 217928]

Configuring integration in KUMA

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

Integration in KUMA is configured in the web interface under SettingsIRP / SOAR.

To configure integration with R-Vision SOAR:

  1. In the KUMA web interface, open ResourcesSecrets.

    The list of available secrets will be displayed.

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

    The secret window is displayed.

  3. Enter information about the secret:
    1. In the Name field, enter a name for the added secret. The name must contain 1 to 128 Unicode characters.
    2. In the Tenant drop-down list, select the tenant that will own the created resource.
    3. In the Type drop-down list, select token.
    4. In the Token field, enter your R-Vision SOAR API token.

      You can obtain the token in the R-Vision SOAR web interface under SettingsGeneralAPI.

    5. If necessary, in the Description field, add up to 4,000 Unicode characters describing the secret.
  4. Click Save.

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

  5. In the KUMA web interface, go to SettingsIRP / SOAR.

    The window containing R-Vision SOAR integration settings opens.

  6. Make the necessary changes to the following parameters:
    • Disabled—select this check box if you want to disable R-Vision SOAR integration with KUMA.
    • In the Secret drop-down list, select the previously created secret.

      You can create a new secret by clicking the button with the plus sign. The created secret will be saved in the ResourcesSecrets section.

    • URL (required)—URL of the R-Vision SOAR server host.
    • Field name where KUMA alert IDs must be placed (required)—name of the R-Vision SOAR field where the ID of the KUMA alert must be written.
    • Field name where KUMA alert URLs must be placed (required)—name of the R-Vision SOAR field where the link for accessing the KUMA alert should be written.
    • Category (required)—category of R-Vision SOAR incident that is created after KUMA alert is received.
    • KUMA event fields that must be sent to IRP / SOAR (required)—drop-down list for selecting the KUMA event fields that should be sent to R-Vision SOAR.
    • Severity group of settings (required)—used to map KUMA severity values to R-Vision SOAR severity values.
  7. Click Save.

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

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

Page top
[Topic 224436]

Configuring integration in R-Vision SOAR

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

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

Configuring integration with KUMA consists of the following steps:

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

In this section

Adding the ALERT_ID and ALERT_URL incident fields

Creating a collector in R-Vision SOAR

Creating connector in R-Vision SOAR

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

Page top
[Topic 224437]

Adding the ALERT_ID and ALERT_URL incident fields

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

  1. In the R-Vision SOAR web interface, under SettingsIncident managementIncident fields, select the No group group of fields.
  2. Click the plus icon in the right part of the screen.

    The right part of the screen will display the settings area for the incident field you are creating.

  3. In the Title field, enter the name of the field (for example: Alert ID).
  4. In the Type drop-down list, select Text field.
  5. In the Parsing Tag field, enter ALERT_ID.

ALERT_ID field added to R-Vision SOAR incident.

ALERT_ID field in R-Vision SOAR version 4.0

rvision_3

ALERT_ID field in R-Vision SOAR version 5.0

rvision_3_v5

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

  1. In the R-Vision SOAR web interface, under SettingsIncident managementIncident fields, select the No group group of fields.
  2. Click the plus icon in the right part of the screen.

    The right part of the screen will display the settings area for the incident field you are creating.

  3. In the Title field, enter the name of the field (for example: Alert URL).
  4. In the Type drop-down list, select Text field.
  5. In the Parsing Tag field, enter ALERT_URL.
  6. Select the Display links and Display URL as links check boxes.

ALERT_URL field added to R-Vision SOAR incident.

ALERT_URL field in R-Vision SOAR version 4.0

rvision_5

ALERT_URL field in R-Vision SOAR version 5.0

rvision_5_v5

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

Page top
[Topic 225573]

Creating a collector in R-Vision SOAR

To create a collector in R-Vision SOAR:

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

The R-Vision SOAR collector is created.

Page top
[Topic 225575]

Creating connector in R-Vision SOAR

To create connector in R-Vision SOAR:

  1. In the R-Vision SOAR web interface, under SettingsIncident managementConnectors, click the plus icon.
  2. In the Type drop-down list, select REST.
  3. In the Name field, specify the connector name, such as KUMA.
  4. In the URL field type API request to close an alert in the format <KUMA Core server FQDN>:<Port used for API requests (7223 by default)>/api/v1/alerts/close.

    Example: https://kuma-example.com:7223/api/v1/alerts/close

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

    Bearer <KUMA General administrator token>

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

The connector has been created.

Connector in R-Vision SOAR version 4.0

rvision_7

Connector in R-Vision SOAR version 5.0

rvision_7_v5

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

To configure API queries in R-Vision SOAR:

  1. In the R-Vision SOAR web interface, under SettingsIncident managementConnectors, open for editing the newly created connector.
  2. In the request type drop-down list, select POST.
  3. In the Params field type API request to close an alert in the format <KUMA Core server FQDN>:<Port used for API requests (7223 by default)>/api/v1/alerts/close.

    Example: https://kuma-example.com:7223/api/v1/alerts/close

  4. On the HEADERS tab add the following keys and values:
    • Key Content-Type; value: application/json.
    • Key Authorization; value: Bearer <KUMA general administrator token>.

      The token of the KUMA general administrator can be obtained in the KUMA web interface under SettingsUsers.

  5. On the BODYRaw tab type contents of the API request body:

    {

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

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

    }

  6. Click Save.

The connector is configured.

Connector in R-Vision SOAR version 4.0

API request header

rvision_7.2

API request body

rvision_7.3

Connector in R-Vision SOAR version 5.0

rvision_7-2_v5

rvision_7.3_v5

Page top
[Topic 225576]

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

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

  1. In the R-Vision SOAR web interface, under SettingsIncident managementResponse playbooks, click the plus icon.
  2. In the Name field, type the name of the rule, for example, Close alert.
  3. In the Group drop-down list select All playbooks.
  4. In the Autostart criteria settings block, click Add and enter the conditions for triggering the rule in the opened window:
    1. In the Type drop-down list, select Field value.
    2. In the Field drop-down list, select Incident status.
    3. Select the Closed status.
    4. Click Add.

    Rule trigger conditions are added. The rule will trigger when an incident is closed.

  5. In the Incident Response Actions settings block, click Add Run connector. In the opened window, select the connector that should be run when the rule is triggered:
    1. In the Connector drop-down list select previously created connector.
    2. Click Add.

    Connector added to the rule.

  6. Click Add.

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

R-Vision IRP version 4.0 playbook rule

rvision_9

R-Vision SOAR version 5.0 playbook rule

rvision_9_v5

Page top
[Topic 225579]

Managing alerts using R-Vision SOAR

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

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

  • Send cyberthreat data from KUMA to R-Vision SOAR

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

    The following information about the KUMA alert is sent to R-Vision SOAR:

    • ID.
    • Name.
    • Status.
    • Date of the first event related to the alert.
    • Date of the last detection related to the alert.
    • User account name or email address of the security officer assigned to process the alert.
    • Alert severity.
    • Category of the R-Vision SOAR incident corresponding to the KUMA alert.
    • Hierarchical list of events related to the alert.
    • List of alert-related assets (internal and external).
    • List of users related to the alert.
    • Alert change log.
    • Link to the alert in KUMA.
  • Investigate cyberthreats in KUMA

    Initial processing of an alert is performed in KUMA. The security officer can update and change any parameters of an alert except its ID and name. Any changes are reflected in the R-Vision SOAR incident card.

    If a cyberthreat turns out to be a false positive and its alert is closed in KUMA, its corresponding incident in R-Vision SOAR is also automatically closed.

  • Close incident in R-Vision SOAR

    After all necessary work is completed on an incident and the course of the investigation is recorded in R-Vision SOAR, the incident is closed. The corresponding KUMA alert is also automatically closed.

  • Open a previously closed incident

    If active monitoring detects that an incident was not completely resolved or if additional information comes up, this incident is re-opened in R-Vision SOAR. However, the alert remains closed in KUMA.

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

    Further analysis is performed in R-Vision SOAR. When the investigation is complete and the incident is closed again in R-Vision SOAR, the status of the corresponding alert in KUMA remains closed.

  • Request additional data from the source system as part of the response playbook or manually

    If additional information is required from KUMA when analyzing incidents in R-Vision SOAR, in R-Vision SOAR, you can create a search request to KUMA (for example, you can request telemetry data, reputation, host information). This request is sent via KUMA REST API and the response is recorded in the R-Vision SOAR incident card for further analysis and reporting.

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

Page top
[Topic 224487]

Integration with Active Directory, Active Directory Federation Services and FreeIPA

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

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

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

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

In this section

Connecting over LDAP

Authentication using domain accounts

Page top
[Topic 217926]

Connecting over LDAP

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

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

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

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

Imported Active Directory attributes

The following account attributes can be requested from Active Directory:

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

In this section

Enabling and disabling LDAP integration

Adding a tenant to the LDAP server integration list

Creating an LDAP server connection

Creating a copy of an LDAP server connection

Changing an LDAP server connection

Changing the data update frequency

Changing the data storage period

Starting account data update tasks

Deleting an LDAP server connection

Page top
[Topic 221426]

Enabling and disabling LDAP integration

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

To enable or disable all LDAP connections of a tenant:

  1. In the KUMA web interface, open SettingsLDAP server and select the tenant for which you want to enable or disable all LDAP connections.

    The LDAP server integration by tenant window opens.

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

To enable or disable a specific LDAP connection:

  1. In the KUMA web interface, open SettingsLDAP server and select the tenant for which you want to enable or disable an LDAP connection.

    The LDAP server integration window opens.

  2. Select the relevant connection and either select or clear the Disabled check box in the opened window.
  3. Click Save.
Page top
[Topic 221481]

Adding a tenant to the LDAP server integration list

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

  1. Open the KUMA web interface and select SettingsLDAP server.

    The LDAP server integration by tenant window opens.

  2. Click the Add tenant button.

    The LDAP server integration window is displayed.

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

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

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

  1. Open the KUMA web interface and select SettingsLDAP server.

    The LDAP server integration by tenant window is displayed.

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

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

Page top
[Topic 233077]

Creating an LDAP server connection

To create a new LDAP connection to Active Directory:

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

    The LDAP server integration by tenant window opens.

  3. Click the Add connection button.

    The Connection parameters window opens.

  4. Add a secret containing the account credentials for connecting to the Active Directory server. To do so:
    1. If you previously added a secret, in the Secret drop-down list, select the existing secret (with the credentials type).

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

    2. If you want to create a new secret, click the AddResource 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

      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 AD_plus button on the right of the Certificate list.

      The Secret window opens.

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

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

  9. In the Timeout in seconds field, indicate the amount of time to wait for a response from the domain controller server.

    If multiple addresses are indicated in the URL field, KUMA will wait the specified number of seconds for a response from the first server. If no response is received during that time, the program will contact the next server, and so on. If none of the indicated servers responds during the specified amount of time, the connection will be terminated with an error.

  10. In the Base DN field, enter the base distinguished name of the directory in which you need to run the search query.
  11. In the Custom AD Account Attributes field, specify the additional attributes that you want to use to enrich events.

    Before configuring event enrichment using custom attributes, make sure that custom attributes are configured in AD.

    To enrich events with accounts using custom attributes:

    1. Add Custom AD Account Attributes in the LDAP connection settings.

      Standard imported attributes from AD cannot be added as custom attributes. For example, if you add the standard accountExpires attribute as a custom attribute, KUMA returns an error when saving the connection settings.

      The following account attributes can be requested from Active Directory:

      • accountExpires
      • badPasswordTime
      • cn
      • 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.

Page top
[Topic 217795]

Creating a copy of an LDAP server connection

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

To copy an LDAP connection:

  1. In the KUMA web interface, open SettingsLDAP server and select the tenant for which you want to copy an LDAP connection.

    The LDAP server integration window opens.

  2. Select the relevant connection.
  3. In the opened Connection parameters window, click the Duplicate connection button.

    The New Connection window opens. The word copy will be added to the connection name.

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

The new connection is created.

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

Page top
[Topic 231112]

Changing an LDAP server connection

To change an LDAP server connection:

  1. Open the KUMA web interface and select SettingsLDAP server.

    The LDAP server integration by tenant window opens.

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

    The LDAP server integration window opens.

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

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

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

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

Page top
[Topic 233080]

Changing the data update frequency

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

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

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

To change the schedule of KUMA queries to LDAP servers:

  1. In the KUMA web interface, open SettingsLDAP serverLDAP server integration by tenant.
  2. Select the relevant tenant.

    The LDAP server integration window opens.

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

The query schedule has been changed.

Page top
[Topic 233081]

Changing the data storage period

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

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

To change the storage period for the account data:

  1. In the KUMA web interface, open SettingsLDAP serverLDAP server integration by tenant.
  2. Select the relevant tenant.

    The LDAP server integration window opens.

  3. In the Data storage time field, specify the number of days you need to store data received from the LDAP server.

The account data storage period is changed.

Page top
[Topic 233213]

Starting account data update tasks

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

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

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

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

  1. In the KUMA web interface, open SettingsLDAP serverLDAP server integration by tenant.
  2. Select the relevant tenant.

    The LDAP server integration window opens.

  3. Click the Import accounts button.

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

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

  1. In the KUMA web interface, open SettingsLDAP serverLDAP server integration by tenant.
  2. Select the relevant tenant.

    The LDAP server integration window opens.

  3. Select the relevant LDAP server connection.

    The Connection parameters window opens.

  4. Click the Import accounts button.

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

Page top
[Topic 233094]

Deleting an LDAP server connection

To delete LDAP connection to Active Directory:

  1. In the KUMA web interface, open SettingsLDAP server and select the tenant that owns the relevant LDAP connection.

    The LDAP server integration window opens.

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

The LDAP connection to Active Directory will be deleted.

Page top
[Topic 217830]

Authentication using domain accounts

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

  1. Enable domain authentication if it is disabled.

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

  2. Configure a connection to the domain controller.

    The following connections are available:

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

    You can connect to one domain only.

  3. Add groups of user roles.

    You can specify a domain group for each KUMA role. After performing authentication using their domain accounts, the users from this group get access to the KUMA web interface in accordance with the specified role.

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

Special considerations for logging in after configuring domain authentication

For successful authentication, the following conditions must be met:

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

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

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

In this section

Enabling and disabling domain authentication

Configuring connection between KUMA and FreeIPA

Configuring connection between KUMA and Active Directory

Configuring connection between KUMA and Active Directory Federation Services

Page top
[Topic 221427]

Enabling and disabling domain authentication

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

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

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

The selected settings are saved and applied.

Page top
[Topic 221428]

Configuring connection between KUMA and FreeIPA

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

To configure a connection to a FreeIPA domain controller:

  1. In the application web interface, select SettingsDomain authorization.
  2. In the Authorization type drop-down list, select FreeIPA.
  3. In the FreeIPA settings block, in the Base DN field, enter the DistinguishedName of the root record to search for access groups in the FreeIPA catalog service. Record format: dc=example,dc=com.
  4. In the URL field, indicate the address of the domain controller in the format <hostname or IP address of server>:<port>.

    In case of server availability issues, you can specify up to three servers with domain controllers by separating them with commas. All of the specified servers must reside in the same domain.

  5. If you want to use TLS encryption for the connection with the domain controller, select one of the following options from the TLS mode drop-down list:
    • startTLS.

      When the startTLS method is used, first it establishes an unencrypted connection over port 389, then it sends an encryption request. If the STARTTLS command ends with an error, the connection is terminated.

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

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

  6. If TLS encryption is enabled, the Secret field becomes required and you must specify a secret of the 'certificate' type in that field. If you previously uploaded a secret, select it from the Secret drop-down list. If necessary, click the AD_plus button to create a new secret of the 'certificate' type and select the secret from the drop-down list.
  7. In the Timeout in seconds field, indicate the amount of time to wait for a response from the domain controller server. The default value is 0.

    If multiple addresses are indicated in the URL field, KUMA waits for the specified number of seconds for a response from the first server. If no response is received during that time, the application contacts the next server. If none of the indicated servers responds during the specified amount of time, the connection will be terminated with an error.

  8. In the Custom integration secret drop-down list, select a secret with the 'credentials' type.

    If you want to upload a new secret of the 'credentials' type, click the AD_plus button on the right of the Custom integration secret drop-down list. This opens the Secret window; in that window, in the Name field, enter the name of the secret that will be displayed in the list after it is saved. In the User field, specify the DistinguishedName in the following format: uid=admin,cn=users,cn=accounts,dc=ipa,dc=test. Enter the Password and click Save.

    The secret is uploaded and becomes available for selection in the Custom integration secret drop-down list.

  9. If you want to configure domain authentication for a user with the KUMA general administrator role, use the General administrators group field to specify the DistinguishedName of the FreeIPA group containing the user.

    If the user belongs to several groups within the same tenant, the role with the least privileges is used.

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

  10. Click the Save button.

A connection with the FreeIPA domain controller is now configured.

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

To check the connection to the domain controller:

  1. In the application web interface, select SettingsDomain authorization.
  2. In the Authorization type drop-down list, select FreeIPA.
  3. In the FreeIPA settings block, select the relevant secret in the User credentials field.

    If necessary, you can create a new secret by clicking the AddSecret button or change the settings of an existing secret by clicking the ChangeSecret button. If integration with FreeIPA is enabled, the secret selection is always reset when the page is loaded.

  4. Click Test.

    After clicking the Test button, the system tests the connection with the domain and returns a notification with the test results. The system does not check if the users can log in or if the user group is configured correctly.

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

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

To add groups of user roles:

  1. In the application web interface, select SettingsDomain authorization.
  2. In the Role groups settings block, click the Add role groups button.
  3. In the Tenant drop-down list, select the tenant of the users for whom you want to configure domain authentication.
  4. In the fields for the following roles, specify the DistinguishedName of the domain group. The users of this domain group must have the capability to perform authentication with their domain accounts:
    • Operator.
    • First line analyst.
    • Analyst.
    • Administrator.

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

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

  5. If necessary, repeat steps 2–4 for each tenant for which you want to configure domain authentication with the following roles: operator, first line analyst, analyst, and tenant administrator.
  6. Click the Save button.

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

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

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

Page top
[Topic 244887]

Configuring connection between KUMA and Active Directory

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

To configure a connection to an Active Directory domain controller:

  1. In the application web interface, select SettingsDomain authorization.
  2. In the Authorization type drop-down list, select AD/ADFS.
  3. In the Active Directory group of settings, in the Base DN field, enter the DistinguishedName of the root record to search for access groups in the Active Directory catalog service.
  4. In the URL field, indicate the address of the domain controller in the format <hostname or IP address of server>:<port>.

    In case of server availability issues, you can specify multiple servers with domain controllers by separating them with commas. All of the specified servers must reside in the same domain.

  5. If you want to use TLS encryption for the connection with the domain controller, select one of the following options from the TLS mode drop-down list:
    • startTLS.

      When the startTLS method is used, first it establishes an unencrypted connection over port 389, then it sends an encryption request. If the STARTTLS command ends with an error, the connection is terminated.

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

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

  6. If you enabled TLS encryption at the previous step, add a TLS certificate:
    • If you previously uploaded a certificate, select it from the Secret drop-down list.

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

    • If you want to upload a new certificate, click the AD_plus button on the right of the Secret list. In the opened window, in the Name field, enter the name that will be displayed in the list of certificates after the certificate is added. Add the file containing the Active Directory certificate (X.509 certificate public keys in Base64 are supported) by clicking the Upload certificate file button. Click the Save button.

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

  7. In the Timeout in seconds field, indicate the amount of time to wait for a response from the domain controller server.

    If multiple addresses are indicated in the URL field, KUMA waits for the specified number of seconds for a response from the first server. If no response is received during that time, the application contacts the next server. If none of the indicated servers responds during the specified amount of time, the connection will be terminated with an error.

  8. To configure domain authentication for a user with the KUMA general administrator role, specify the DistinguishedName of the Active Directory group the user belongs to in the General administrators group field.

    If the user belongs to several groups within the same tenant, the role with the least privileges is used.

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

  9. Click the Save button.

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

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

To check the connection to the domain controller:

  1. In the application web interface, select SettingsDomain authorization.
  2. In the Authorization type drop-down list, select AD/ADFS.
  3. In the Test connection settings block, select the relevant secret in the User credentials field.

    If necessary, you can create a new secret by clicking the AddSecret button or change the settings of an existing secret by clicking the ChangeSecret button.

    The following formats for specifying a user are available in the User field: UserPrincipalName and domain\user.

  4. Click Test.

    After clicking the Test button, the system tests the connection with the domain and returns a notification with the test results. The system does not check if the users can log in or if the user group is configured correctly.

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

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

To add groups of user roles:

  1. In the application web interface, select SettingsDomain authorization.
  2. In the Role groups settings block, click the Add role groups button.
  3. In the Tenant drop-down list, select the tenant of the users for whom you want to configure domain authentication.
  4. In the fields for the following roles, specify the DistinguishedName of the domain group. The users of this domain group must have the capability to perform authentication with their domain accounts:
    • Operator.
    • First line analyst.
    • Analyst.
    • Administrator.

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

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

  5. If necessary, repeat steps 2–4 for each tenant for which you want to configure domain authentication with the following roles: operator, first line analyst, analyst, and tenant administrator.
  6. Click the Save button.

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

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

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

Page top
[Topic 221429]

Configuring connection between KUMA and Active Directory Federation Services

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

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

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

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

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

To configure a connection to an ADFS domain controller:

  1. In the application web interface, select SettingsDomain authorization.
  2. In the Authorization type drop-down list, select AD/ADFS.
  3. In the Active Directory Federation Services settings block, in the Client ID field, enter the KUMA ID from the Client ID field in the ADFS.
  4. In the Relying party identifier field, enter the KUMA ID from the Relying party identifiers field in the ADFS.
  5. Enter the Connect Metadata URI from the Connect Metadata URI field. This parameter consists of the host where the ADFS resides (https://adfs.example.com), and the endpoint setting (/adfs/.well-known/openid-configuration).

    For example, https://adfs.example.com/adfs/.well-known/openid-configuration).

  6. Enter the ADFS redirect URL from the Redirect URL field in the ADFS. The value of the Redirect URL field in the ADFS is defined when the Application group is configured. In the ADFS, you must indicate the KUMA FQDN and the </sso-callback> substring. In KUMA, the URL must be indicated without the substring, for example: https://kuma-example:7220/
  7. If you want to configure domain authentication for a user with the KUMA general administrator role, use the General administrators group field to specify the DistinguishedName of the Active Directory Federation Services group containing the user.

    If the user belongs to several groups within the same tenant, the role with the least privileges is used.

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

  8. Click the Save button.

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

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

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

To add groups of user roles:

  1. In the application web interface, select SettingsDomain authorization.
  2. In the Role groups settings block, click the Add role groups button.
  3. In the Tenant drop-down list, select the tenant of the users for whom you want to configure domain authentication.
  4. In the fields for the following roles, specify the DistinguishedName of the domain group. The users of this domain group must have the capability to perform authentication with their domain accounts:
    • Operator.
    • First line analyst.
    • Analyst.
    • Administrator.

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

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

  5. If necessary, repeat steps 2–4 for each tenant for which you want to configure domain authentication with the following roles: operator, first line analyst, analyst, and tenant administrator.
  6. Click the Save button.

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

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

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

Page top
[Topic 244876]

Configuring connection in Active Directory Federation Services

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

The ADFS role must already be configured on the server.

Creating a new connection group

  1. In Server Manager, in the Tools menu, select ADFS Management.

    In ADFS, select the Application groups section and in the Actions section click Add Application Group.

  2. In the Add Application Group Wizard window that opens, in the Welcome section Name field, specify the name of the new connection group. Example: new-application-group.

    In the Template field, in the Client-Server applications group, select Native application accessing a web API.

    Click Next to proceed to the next step of creating and configuring a connection group.

  3. In the Native application section that opens, the Name and

     Client Identifier

    fields are filled in automatically.

    Specify the value of the Client Identifier field in KUMA, when configuring domain authentication.

    In the

     

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

    Click Next to proceed to the next configuration step.

  4. In the Configure Web API section that opens, in the

    Identifiers

    field add the trusted party ID and click Add. It can be any arbitrary value. Example: test-demo

    Specify the value of the Identifier field in KUMA, in the Relying party identifiers field, when configuring domain authentication.

    Click Next to proceed to the next configuration step.

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

    Click Next to proceed to the next configuration step.

  6. In the Configure Application Permissions section that opens, the Client application field is filled in automatically.

    In the Permitted scopes field, select the check box for the allatclaims and openid options.

    Click Next to proceed to the next configuration step.

  7. In the Summary section that opens, check the settings.

    If the settings are correct and you are ready to add a group, click Next.

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

Adding rules for a connection group

  1. In Server Manager, in the Tools menu, select ADFS Management.

    In ADFS, select the Application groups section and select the required connection group from the list. Example: new-application-group.

  2. In the Application groups window, in the Actions section, click Properties.

    In the new-application-group Properties window that opens, in the Applications section, double-click new-application-group - Web API.

    In the new-application-group - Web API Properties window that opens, open the

    Issuance Transform Rules

    tab and click Add rule.

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

    Click Next to proceed to the next configuration step.

  3. In the Configure Claim Rule section, specify the rule name in the Claim rule name field. Example: rule-name-01.

    In the Attribute store drop-down list, select Active directory.

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

    LDAP Attribute

    Outgoing Claim Type

    User-Principal-Name

    UserPrincipalName

    Display-Name

    displayName

    E-Mail-Addresses

    Mail

    Is-Member-Of-DL

    MemberOf

    Click Finish to complete the configuration.

  4. Go to the new-application-group - Web API Properties window, open the

    Issuance Transform Rules

    tab and click Add rule. In the Add Transform Claim Rule Wizard window that opens, in the Choose Rule Type section, select Send claims using a custom rule from the drop-down list.

    Click Finish to continue the configuration.

  5. In the Configure Claim Rule section, specify the rule name in the Claims rule name field. Example: rule-name-02.

    In the Custom rule field, specify the following settings: 

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

    Click Finish to complete the configuration.

  6. The system proceeds to the new-application-group - Web API Properties window and the Issuance Transform Rules tab.

    To apply the rules, on the Issuance Transform Rules tab that opens, click Apply or OK.

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

Page top
[Topic 245272]

Troubleshooting the Access denied error

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

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

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

  1. Contact Technical support to obtain the adfs_fingerprint_changer_tool binary file.
  2. Place the received adfs_fingerprint_changer_tool binary file in any folder on the host with the KUMA Core. For example, /root/kuma-ansible-installer.
  3. On the host with the KUMA Core, start the command line interpreter and use the cd command to go to the folder containing the adfs_fingerprint_changer_tool file.

    For example, you can enter the following command and press Enter:

    cd /root/kuma-ansible-installer

  4. To grant the permissions to run a binary file and run the binary file, sequentially execute the following commands:

    chmod +x adfs_fingerprint_changer_tool

    ./adfs_fingerprint_changer_tool

To update the certificate thumbprint on a Kubernetes host:

  1. Contact Technical support to obtain the adfs_fingerprint_changer_tool binary file.
  2. Place the received adfs_fingerprint_changer_tool binary file in any folder on the computer of an administrator with access to the Kubernetes cluster and execute the following commands:

    k0s kubectl cp <path to adfs_fingerprint_changer_tool> $(k0s kubectl get pod -l app=core -n kuma -o name | cut -d/ -f2):/tmp/ -c mongodb -n kuma

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

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

Page top
[Topic 245317]

RuCERT integration

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

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

To create a connection to RuCERT:

  1. In the KUMA web interface, open SettingsRuCERT.
  2. In the URL field, enter the URL for accessing RuCERT.
  3. In the Token settings block, create or select an existing secret with the API token that was issued to your organization for a connection to RuCERT:
    • If you already have a secret, you can select it from the drop-down list.
    • If you want to create a new secret:
      1. Click the AddResource button and specify the following settings:
        • Name (required)—unique name of the service you are creating. The name must contain 1 to 128 Unicode characters.
        • Token (required)—token that was issued to your organization for a connection to RuCERT.
        • Description—service description: up to 256 Unicode characters.
      2. Click Save.

      The secret containing the token for connecting to RuCERT will be created. It is saved under ResourcesSecrets and is owned by the main tenant.

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

  4. In the Affected system function drop-down list, select the area of activity of your organization.

    Available company business sectors

    • Nuclear energy
    • Banking and other financial market sectors
    • Mining
    • Federal/municipal government
    • Healthcare
    • Metallurgy
    • Science
    • Defense industry
    • Education
    • Aerospace industry
    • Communication
    • Mass media
    • Fuel and power
    • Transportation
    • Chemical industry
    • Other
  5. In the Company field, indicate the name of your company. This data will be forwarded to RuCERT when incidents are exported.
  6. Use the Location drop-down list to specify where your company is located. This data will be forwarded to RuCERT when incidents are exported.
  7. If necessary, under Proxy, create or select an existing proxy server that must be used when connecting to RuCERT.
  8. Click Save.

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

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

Possible errors

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

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

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

See also:

Interaction with RuCERT

Page top
[Topic 221777]

Integration with Security Vision Incident Response Platform

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

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

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

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

Working with Security Vision IRP incidents

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

KUMA alert imported as Security Vision IRP incident

commandSV

Security Vision IRP incident that was created based on KUMA alert

incidentSV-2

Events from KUMA alert that were imported to Security Vision IRP

In this section

Configuring integration in KUMA

Configuring integration in Security Vision IRP

See also:

About alerts

About events

REST API

Page top
[Topic 232020]

Configuring integration in KUMA

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

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

To generate a token in your account profile:

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

    The User window with your user account parameters opens.

  2. Click the Generate token button.
  3. Copy the generated token displayed in the opened window. This will be required to configure Security Vision IRP.

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

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

See also:

Configuring integration in Security Vision IRP

Page top
[Topic 232289]

Configuring integration in Security Vision IRP

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

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

In this section

Importing and configuring a connector

Configuring the handler, schedule, and worker process

See also:

Configuring integration in KUMA

Page top
[Topic 232073]

Importing and configuring a connector

Adding a connector in Security Vision IRP

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

To import a Kaspersky KUMA connector into Security Vision IRP:

  1. In Security Vision IRP, open SettingsConnectorsConnectors.

    You will see a list of connectors that have been added to Security Vision IRP.

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

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

Configuring a connector for a connection to KUMA

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

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

  1. In Security Vision IRP, open SettingsConnectorsConnectors.

    You will see a list of connectors that have been added to your Security Vision IRP.

  2. Select the Kaspersky KUMA connector.

    The general settings of the connector will be displayed.

  3. Under Connector settings, click the Edit button.

    The connector configuration will be displayed.

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

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

Security Vision IRP connector settings

connectorSV-config

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

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

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

To configure a command to receive alert information from KUMA:

  1. In Security Vision IRP, open SettingsConnectorsConnectors.

    You will see a list of connectors that have been added to Security Vision IRP.

  2. Select the Kaspersky KUMA connector.

    The general settings of the connector will be displayed.

  3. Click the +Command button.

    The command creation window opens.

  4. Specify the command settings for receiving alerts:
    • In the Name field, enter the command name: Receive incidents.
    • In the Request type drop-down list, select GET.
    • In the Called method field, enter the API request to search for alerts:

      api/v1/alerts/?withEvents&status=new

    • Under Request headers, in the Name field, indicate authorization. In the Value field, indicate Bearer <token>.
    • In the Content type drop-down list, select application/json.
  5. Save the command and close the window.

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

To configure a command to close KUMA alerts:

  1. In Security Vision IRP, open SettingsConnectorsConnectors.

    You will see a list of connectors that have been added to Security Vision IRP.

  2. Select the Kaspersky KUMA connector.

    The general settings of the connector will be displayed.

  3. Click the +Command button.

    The command creation window will be displayed.

  4. Specify the command settings for receiving alerts:
    • In the Name field, enter the command name: Close incident.
    • In the Request type drop-down list, select POST.
    • In the Called method field, enter API request to close an alert:

      api/v1/alerts/close

    • In the Request field, enter the contents of the sent API request:

      {"id":"<Alert ID>","reason":"responded"}

      You can create multiple commands for different reasons to close alerts, such as responded, incorrect data, and incorrect correlation rule.

    • Under Request headers, in the Name field, indicate authorization. In the Value field, indicate Bearer <token>.
    • In the Content type drop-down list, select application/json.
  5. Save the command and close the window.

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

Creating commands in Security Vision IRP

commandSV

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

Page top
[Topic 232293]

Configuring the handler, schedule, and worker process

Security Vision IRP handler

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

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

Handler run schedule

The connector and handler are started according to a predefined KUMA schedule. This schedule can be configured in Security Vision IRP under SettingsEvent processingSchedule:

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

Security Vision IRP worker process

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

Page top
[Topic 232323]

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.

In this section

Configuring integration in KICS for Networks

Configuring integration in KUMA

Enabling and disabling integration with KICS for Networks

Changing the data update frequency

Special considerations when importing asset information from KICS for Networks

Changing the status of a KICS for Networks asset

Page top
[Topic 233668]

Configuring integration in KICS for Networks

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

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

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

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

Page top
[Topic 233670]

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. Open the KUMA web interface and select SettingsKaspersky 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.

Page top
[Topic 233669]

Enabling and disabling integration with KICS for Networks

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

  1. In the KUMA web interface, open SettingsKaspersky 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.
Page top
[Topic 233717]

Changing the data update frequency

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

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

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

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

  1. In the KUMA web interface, open SettingsKaspersky Industrial CyberSecurity for Networks.
  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.

See also:

Special considerations when importing asset information from KICS for Networks

Page top
[Topic 233718]

Special considerations when importing asset information from KICS for Networks

Importing assets

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

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

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

Importing vulnerability information

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

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

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

Imported data storage period

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

Page top
[Topic 233699]

Changing the status of a KICS for Networks asset

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

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

Manually changing the status of a KICS for Networks asset

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

To manually change a KICS for Networks asset status:

  1. In the Assets section of the KUMA web interface, click the asset that you want to edit.

    The Asset details area opens in the right part of the window.

  2. In the Status in KICS for Networks drop-down list, select the status that you need to assign to the KICS for Networks asset. The Authorized or Unauthorized statuses are available.

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

Automatically changing the status of a KICS for Networks asset

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

Page top
[Topic 233750]

Kaspersky Automated Security Awareness Platform

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

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

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

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

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

In this section

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

Configuring integration in KUMA

Viewing information about the users from ASAP and changing learning groups

Page top
[Topic 242818]

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

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

Creating a token

To create a token:

  1. Sign in to the ASAP web interface.
  2. In the Control panel section, click 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 ASAP system in the open form. After you close the Get token window, the token is unavailable for viewing. If you close the window without copying the token, you will need to click the New token button again for the system to generate a new token.

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

Getting a link for API requests

To get the link used in ASAP for API requests:

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

Configuring integration in KUMA

To configure KUMA integration with ASAP:

  1. Open the KUMA web interface and select SettingsKaspersky Automated Security Awareness Platform.

    The Kaspersky Automated Security Awareness Platform window opens.

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

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

Page top
[Topic 242823]

Viewing information about the users from ASAP and changing learning groups

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

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

To view data about the user from ASAP:

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

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

  3. Select the ASAP courses details tab.

The window displays information about the user from ASAP.

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

To change a user learning group in ASAP:

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

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

  3. In the Assign ASAP group drop-down list, select the ASAP learning group you want to assign the user to.
  4. Click Apply.

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

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

Page top
[Topic 242830]

Sending notifications to Telegram

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

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

Configure Telegram notifications involves the following steps:

  1. Creating and configuring a Telegram bot

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

  2. Creating a script for sending notifications

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

  3. Configuring notifications in KUMA

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

In this section

Creating and configuring a Telegram bot

Creating a script for sending notifications

Configuring notifications in KUMA

Page top
[Topic 258846]

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

Page top
[Topic 258850]

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

Page top
[Topic 258851]

Configuring sending notifications in KUMA

To configure the sending of KUMA notifications to Telegram:

  1. Create a response rule:
    1. In the KUMA web interface, select the ResourcesResponse 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 ResourcesCorrelators section, select the correlator in whose folder you placed the created script for sending notifications.
    2. In the steps tree, select Response rules.
    3. Click Add.
    4. In the Response rule drop-down list, select the rule added at step 1 of these instructions.
    5. In the steps tree, select Setup validation.
    6. Click the Save and restart services button.
    7. Click the Save button.

Sending notifications about triggered KUMA rules to Telegram is configured.

See also:

Response rules for a custom script

Page top
[Topic 258852]

UserGate integration

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

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

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

Configuring the integration involves the following steps:

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

In this section

Configuring integration in UserGate

Preparing a script for integration with UserGate

Configuring a response rule for integration with UserGate

Page top
[Topic 259114]

Configuring integration in UserGate

To configure integration in UserGate:

  1. Connect to the UserGate web interface under an administrator account.
  2. Go to UserGateAdministratorsAdministrator 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 UserGateAdministrators section, click AddAdd 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 NetworkZones 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.
Page top
[Topic 259137]

Preparing a script for integration with UserGate

To prepare a script for use:

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

Page top
[Topic 259221]

Configuring a response rule for integration with UserGate

To configure a response rule:

  1. Create a response rule:
    1. In the KUMA web interface, select the ResourcesResponse 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 ResourcesCorrelators section, select the correlator that must respond and in whose directory you placed the script.
    2. In the steps tree, select Response rules.
    3. Click Add.
    4. In the Response rule drop-down list, select the rule added at step 1 of these instructions.
    5. In the steps tree, select Setup validation.
    6. Click Save and reload services.
    7. Click the Save button.

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

Page top
[Topic 259222]

Integration with Kaspersky Web Traffic Security

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

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

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

Configuring the integration involves the following steps:

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

In this section

Configuring integration in KWTS

Preparing a script for integration with KWTS

Configuring a response rule for integration with KWTS

Page top
[Topic 259321]

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.

Page top
[Topic 259340]

Preparing a script for integration with KWTS

To prepare a script for use:

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

Page top
[Topic 259341]

Configuring a response rule for integration with KWTS

To configure a response rule:

  1. Create a response rule:
    1. In the KUMA web interface, select the ResourcesResponse 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 ResourcesCorrelators section, select the correlator that must respond and in whose directory you placed the script.
    2. In the steps tree, select Response rules.
    3. Click Add.
    4. In the Response rule drop-down list, select the rule added at step 1 of these instructions.
    5. In the steps tree, select Setup validation.
    6. Click Save and reload services.
    7. Click the Save button.

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

Page top
[Topic 259342]

Integration with Kaspersky Secure Mail Gateway

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

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

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

Configuring the integration involves the following steps:

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

In this section

Configuring integration in KSMG

Preparing a script for integration with KSMG

Configuring a response rule for integration with KSMG

Page top
[Topic 259353]

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.

Page top
[Topic 259354]

Preparing a script for integration with KSMG

To prepare a script for use:

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

Page top
[Topic 259355]

Configuring a response rule for integration with KSMG

To configure a response rule:

  1. Create a response rule:
    1. In the KUMA web interface, select the ResourcesResponse rules section and click Add response rule.
    2. This opens the Create response rule window; in that window, in the Name field, enter the name of the rule.
    3. In the Tenant drop-down list, select the tenant that owns the resource.
    4. In the Type drop-down list, select Run script.
    5. In the Script name field, enter the name of the script, ksmg.py.
    6. In the Script arguments field, specify:
      • --host — address of the KSMG server.
      • --username — name of the user account created in KSMG.

        You can specify the Administrator account.

      • --password — KSMG user account password.
      • --rule_id — ID of the rule created in KSMG.
      • Specify one of the options depending on the type of the object being blocked:
        • --email — specify the field of the KUMA event from which you want to obtain the URL, for example, {{.SourceUserName}}.
        • --ip — specify the field of the KUMA event from which you want to obtain the IP address, for example, {{.SourceAddress}}.
      • --ntlm — specify this option if the KSMG user was created with NTLM authentication.

        Example:

        --host <address> --username <user> --password <pass> --ntlm --rule_id <id> --email {{.SourceUserName}}

    7. In the Conditions section, add conditions corresponding to the correlation rules that when triggered require blocking the IP address or email address of the message sender in KSMG.
    8. Click Save.
  2. Add the response rule to the correlator:
    1. In the ResourcesCorrelators section, select the correlator that must respond and in whose directory you placed the script.
    2. In the steps tree, select Response rules.
    3. Click Add.
    4. In the Response rule drop-down list, select the rule added at step 1 of these instructions.
    5. In the steps tree, select Setup validation.
    6. Click Save and reload services.
    7. Click the Save button.

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

Page top
[Topic 259356]

Importing asset information from RedCheck

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

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

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

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

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

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

  • csv
  • re
  • json
  • requests
  • argparse
  • sys

To import asset information from a RedCheck report:

  1. Generate a network asset scan report in RedCheck in CSV format and copy the report file to the server where the script is located.

    For more details about scan tasks and output file formats, refer to the RedCheck documentation.

  2. Create a file with the token for accessing the KUMA REST API.

    The account for which the token is created must satisfy the following requirements:

  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.

Example:

inventory has been imported for 2 host(s)

software has been imported for 5 host(s)

vulnerabilities has been imported for 4 host(s)

 

Example of extended import information:

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

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

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

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

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

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

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

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

inventory has been imported for 2 host(s)

software has been imported for 1 host(s)

vulnerabilities has been imported for 4 host(s)

The tool works as follows when importing assets:

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

    Flags and commands of redcheck-tool.py

    Flags and commands

    Mandatory

    Description

    --kuma-rest <address and port of the KUMA server>

    Yes

    Port 7223 is used for API requests by default. You can change the port if necessary.

    --token <token>

    Yes

    The value of the option must contain only the token.

    The Administrator or Analyst role must be assigned to the user account for which the API token is being generated.

    --tenant <tenant name>

    Yes

    Name of the KUMA tenant in which the assets from the RedCheck report will be imported.

    --vuln-report <full path to the "Vulnerabilities" report>

    Yes

    "Vulnerabilities" report file in CSV format.

    --inventory-report <full path to the "Inventory" report file>

    No

    "Inventory" report file in CSV format.

    -v

    No

    Display extended information about the import of assets.

    Possible errors

    Error message

    Description

    Tenant %w not found

    The tenant name was not found.

    Tenant search error: Unexpected status Code: %d

    An unexpected HTTP response code was received while searching for the tenant.

    Asset search error: Unexpected status Code: %d

    An unexpected HTTP response code was received while searching for an asset.

    [%w import][error] Host: %w Skipped asset with FQDNlocalhost or IP 127.0.0.1

    When importing inventory/vulnerabilities information, host cfqdn=localhost or ip=127.0.0.1 was skipped.

Page top
[Topic 259370]