Kaspersky Endpoint Detection and Response integration

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

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

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

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

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

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

Importing Kaspersky Endpoint Detection and Response events using the kafka connector

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

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

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

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

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

Importing events from Kaspersky Endpoint Detection and Response 4.0 or 4.1

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

In Kaspersky Endpoint Detection and Response:

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

   The program component administrator menu is displayed.

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

   The Technical Support Mode confirmation window opens.

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

   sudo -i

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

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

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

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

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

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

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

In KUMA:

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

   When creating a connector, specify the following parameters:

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

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

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

Importing events from Kaspersky Endpoint Detection and Response 5.0 and 5.1

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

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

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

In Kaspersky Endpoint Detection and Response:

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

   The program component administrator menu is displayed.

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

   The Technical Support Mode confirmation window opens.

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

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

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

7. Run the following commands:

   kata-firewall stop

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

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

In KUMA:

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

   When creating a connector, specify the following parameters:

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

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

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

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

To import Kaspersky Endpoint Detection and Response 5.1 events from hosts using the kata/edr connector:

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

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

Creating a collector for receiving events from KEDR

To create a collector for receiving events from KEDR:

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

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

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

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

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

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

Authorizing KUMA on the KEDR side

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

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

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

Possible errors and solutions

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

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

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

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

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

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

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

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

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

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

1. Creating a correlator.

   Select the [OOTB] KATA Alert correlation rule.

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

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

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

To add a category:

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

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

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

      Selected category appears in Parent fields.

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

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

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

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

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

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

             Categorization filter operands and operators

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

             Using time values

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

             To specify a date and time value:

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

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

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

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

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

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

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

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

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

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

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

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

To add an asset:

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

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

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

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

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

Step 2. Adding a correlation rule

To add a correlation rule:

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

Step 3. Creating a correlator

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

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

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