Importing Kaspersky Endpoint Detection and Response events using the kata/edr connector
Importing Kaspersky Endpoint Detection and Response events from hosts using the 'kata/edr' connector involves the following steps:
- Performing configuration the KUMA side to receive events.
To do this, in KUMA, you must create and install a collector with the 'kata/edr' connector or edit an existing collector, then save the modified settings and restart the collector.
- Accepting the KUMA authorization request on the KEDR side to begin sending events to KUMA.
As a result, the integration is configured and KEDR events start arriving in KUMA.
Creating a collector for receiving events from KEDR
To create a collector for receiving events from KEDR:
- Log in to the KUMA Console. You can do so in one of the following ways:
- In the main menu of the OSMP console, go to Settings → KUMA.
- In your browser, go to
https://kuma.<smp_domain>:7220
.
- Go to Resources→Collectors, select Add collector.
- 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.
- At step 2 "Transport", do the following:
- On the Basic settings tab:
- In the Connector field, select Create or start typing the name of the connector if you want to use a previously created connector.
- 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.
- In the URL field, specify the address for connecting to the KEDR server in the following <
name or IP address of the host
>:<connection port, 443 by default
> format. If KEDR is deployed in a cluster, you can click Add to add all nodes. KUMA will connect to each specified node in sequence. If KEDR is installed in a distributed configuration, on the KUMA side, you must configure a separate collector for each KEDR server. - In the Secret field, select Create to create a new secret. This opens the Create secret window; in that window, specify the name of the secret and click Generate and download a certificate and private encryption key.
As a result, the certificate.zip archive is downloaded to the browser's Downloads folder; the archive contains the 'key.pem' key file and the 'cert.pem' certificate file. Unpack the archive.
In the KUMA Console, click Upload certificate and select the cert.pem file. Click Upload private key and select the key.pem file. Click Create; the secret is added to the Secret drop-down list is automatically selected.
You can also select the created secret from the Secret list. KUMA uses the selected secret to connect to KEDR.
- The External ID field contains the ID for external systems. This ID is displayed in the KEDR web interface when authorizing the KUMA server. KUMA generates an ID automatically and the External ID field is automatically pre-populated.
- If necessary, specify the settings on the Advanced settings tab:
- To get detailed information in the collector log, move the Debug toggle switch to the enabled position.
- 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.
- Specify the maximum Number of events per one request to KEDR. The default value is 0. This means that the value configured on the KEDR server as the default is applied (for details, please refer to the KATA Help). You can specify an arbitrary value that must not exceed the value on the KEDR side. If the value you specify exceeds the value of the Maximum number of events setting specified on the KEDR server, the KUMA collector log will display the error "Bad Request: max_events N is greater than the allowed value".
- 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 value configured on the KEDR server as the default is applied (for details, please refer to the KATA Help).
The KEDR server uses two parameters: the maximum number of events and the events fetch timeout. Events are sent when the specified number of events is collected or the configured time elapses, whichever happens first. If the specified time has elapsed, but the specified number of events has not been collected, the KEDR server sends the events that it already has, without waiting for more.
- In the Client timeout field, specify how long KUMA must wait for a response from the KEDR server, in seconds. Default value: 1,800 s; displayed as 0. The client-side limit is specified in the Client timeout field. The Client timeout must be greater than the server value Events fetch timeout to wait for the server's response without interrupting the current event collection task with a new request. If the response from the KEDR server does not arrive in the end, KUMA repeats the request.
- 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.
- On the Basic settings tab:
- At step 3 "Parsing", click Add event parsing and select "[ООТВ] KEDR telemetry" in the Basic event parsing window.
- To finish creating the collector in the web interface, click Create and save service. Then copy the collector installation command from the web interface and run this installation command on the command line on the KUMA destination host where you want to install the collector.
Example of a command to install the collector:
sudo /opt/kaspersky/kuma/kuma collector --core https://<KUMA Core server FQDN>:7210 --id <service ID copied from the KUMA Console> --api.port <port used for communication with the installed component>
The default fully qualified domain name of the KUMA Core is
kuma.<smp_domain>
. The port used for connecting to the KUMA Core cannot be changed. The default port number is 7210.If you were editing an existing collector, click Save and restart services.
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.