Creating an agent

A KUMA agent consists of two parts: one part is created inside the KUMA web interface, and the second part is installed on a server or on an asset in the network infrastructure.

An agent is created in several steps:

1. Creating a resource set for the agent in the KUMA web interface
2. Creating an agent service in the KUMA web interface
3. Installing the server portion of the agent to the asset that will send events

KUMA agents for Windows devices can be created as follows:

• Manually by creating a set of agent resources and creating an agent service in the KUMA web interface.
• Automatically when creating a collector of the wmi, wec, or etw transport type. Although the set of resources and service of these agents are created in the Collector Installation Wizard, they must still be installed to the asset that will be used to forward an event. In a manually created agent, a connector of the etw type can be used in only one connection. If you configure multiple connections in a manually created etw agent, the status of the etw agent status is green, but events are not transmitted and an error is logged in the etw agent log.

Multiple agents can be installed on a device; the version of all such agents must be the same.

If an older version of the agent is already installed on the device where you want to create an agent, you must first stop the installed agent (remove the agent from a Windows device or restart the agent service on a Linux device), and then you can proceed to create a new agent. However, if the version of the installed agents is the same as the version of the agent that you want to create, stopping the agents is not necessary.

When creating and running an agent whose version is 3.0.1 or later, you must accept the terms and conditions of the End User License Agreement.

Creating a set of resources for an agent

In the KUMA web interface, an agent service is created based on the resource set for an agent that unites connectors and destinations. The agent type is determined by the connector that is used in the agent. The only exception is for agents with a destination of the diode type. These agents are considered to be diode agents.

To create a resource set for an agent in the KUMA web interface:

1. In the KUMA web interface, under Resources → Agents, click Add agent.

   This opens the agent creation window. The left part of the window displays tabs with base settings of the agent and connections. The Base settings tab is active.

2. On the Base settings tab:
   • In the Agent name field, enter a unique name for the created service. The name must contain 1 to 128 Unicode characters.
   • In the Tenant drop-down list, select the tenant that will own the storage.
   • If you want to enable logging of service operations, enable the Debug toggle switch.
   • If you want to view the names of services or addresses of hosts from which the event came, enable the Trace event route toggle switch.

     The Trace event route toggle switch is available if at least one internal destination is specified in the connections. By default, the toggle switch is Disabled.

     When using the tcp, udp, http, wec, wmi, or etw connector type at the normalization stage, IP addresses of the assets from which the events were received are written to the DeviceAddress event field if it is empty.

   • You can optionally add up to 256 Unicode characters describing the service in the Description field.
3. Go to the tab of an existing connection or create a connection by clicking the Add button in the lower part of the left pane, then go to the tab of the newly created connection to edit its settings.

   By default, a connection named Config #1 is created for a new agent. The name of the connection follows the Config #<number> pattern.

   You can create multiple connections for an agent. If necessary, you can manage connections:

   • Rename connections
   • Duplicate connections
   • Delete connections
4. If necessary, in the Name of connection field, rename the connection for your convenience when managing it, for example, to be able to figure out from which connection and from which agent events arrived. If you leave the field blank, a name is assigned following the Config #<number> pattern.

   The name can contain from 1 to 128 characters. The name can contain only letters and numerals and cannot contain special characters. Leading and trailing spaces are removed. When pasting a name into the field from the clipboard, if the text contains a newline, paragraph, or indentation, these characters are replaced with a space. You can reuse a name for multiple connections within the same agent.

   If you have enabled event route tracing, then when viewing event information, the Events section displays the name of the connection from which the event was received.

5. In the Connector group of settings, add a connector:
   • If you want to select an existing connector, select it from the drop-down list.
   • If you want to create a new connector, select Create new in the drop-down list and specify the following settings:
     • Specify the connector name in the Name field. The name must contain 1 to 128 Unicode characters.
     • In the Type drop-down list, select the connector type and specify its settings on the Basic settings and Advanced settings tabs. The available settings depend on the selected type of connector:
       • tcp
       • udp
       • nats-jetstream
       • kafka
       • http
       • file
       • ftp
       • nfs
       • wmi
       • wec
       • snmp
       • etw

       When using the tcp or udp connector type at the normalization stage, IP addresses of the assets from which the events were received will be written in the DeviceAddress event field if it is empty.

       The ability to edit previously created wec, wmi, or etw connections in agents, collectors, and connectors is limited. You can change the connection type from wec to wmi or etw and back, but you cannot change the wec, wmi, or etw connection to any other connection type. When editing other connection types, you cannot select the wec, wmi, or etw types. You can create connections without any restrictions on the types of connectors.

       When adding an (existing or new) wmi, wec, or etw connector for an agent, the TLS mode and Compression settings are not displayed on the agent, but the values of these settings are stored in the agent's configuration. For a new connector, these settings are disabled by default.
       If TLS mode is enabled for an existing connector that is selected in the list, you cannot download the agent configuration file. In this case, to download the configuration file, you must go to the connector resource that is being used on the agent and disable TLS mode.

   The connector is added to the selected connection of the agent's resource set. The created connector is only available in this resource set and is not displayed in the web interface Resources → Connectors section.

6. In the Destinations group of settings, add a destination.
   • If you want to select an existing destination, select it from the drop-down list.
   • If you want to create a new destination, select Create new in the drop-down list and specify the following settings:
     • Specify the destination name in the Name field. The name must contain 1 to 128 Unicode characters.
     • In the Type drop-down list, select the destination type and specify its settings on the Basic settings and Advanced settings tabs. The available settings depend on the selected type of destination:
       • nats-jetstream—used for NATS communications.
       • tcp—used for communications over TCP.
       • http—used for HTTP communications.
       • diode—used to transmit events using a data diode.
       • kafka—used for Kafka communications.
       • file—used for writing to a file.
     • Enable or disable the State toggle switch to enable or disable the sending of events to the destination. This toggle switch is turned on by default.

     The advanced settings for an agent destination (such as TLS mode and compression) must match the advanced destination settings for the collector that you want to link to the agent.

   There can be more than one destination point. You can add them by clicking the Add destination button and can remove them by clicking the button.

7. Repeat steps 3–5 for each agent connection that you want to create.
8. Click Save.

The resource set for the agent is created and displayed under Resources → Agents. Now you can create an agent service in KUMA.

Managing connections for an agent

You can manage the connections created for the agent by renaming, duplicating, or deleting them.

Renaming a connection

By default, the name of a new connection created in a resource set for an agent follows the Connection <number> pattern. For your convenience when managing connections, you can rename them, for example, to make it clear at a glance from which connection and from which agent an event was received.

To rename a connection:

1. In the KUMA web interface, in the Resources → Agents section, create a new agent or click an existing agent in the table.
2. If necessary, create a connection for the agent by clicking the Add button in the lower part of the left pane.
3. Go to the tab of the connection that you want to rename.
4. In the Connection name field, edit the name of the connection.

   The name can contain from 1 to 128 characters. The name can contain only letters and numerals and cannot contain special characters. Leading and trailing spaces are removed. When pasting a name into the field from the clipboard, if the text contains a newline, paragraph, or indentation, these characters are replaced with a space. You can reuse a name for multiple connections within the same agent.

5. Click Save.

The connection is renamed. If you have enabled event route tracing, then when viewing event information, the Events section displays the name of the connection from which the event was received.

Duplicating a connection

If you want to create a connection for an agent based on an existing connection, you can create a copy of the connection with identical settings.

To duplicate a connection:

1. In the KUMA web interface, in the Resources → Agents section, create a new agent or click an existing agent in the table.
2. If necessary, create a connection for the agent by clicking the Add button in the lower part of the left pane.
3. Go to the tab of the connection that you want to duplicate and click the Duplicate button.

A connection is created for the agent with the same settings as the original connection. The new connection is created with one of the following names:

• If the original connection name followed the Connection <number> template, the duplicated connection name also follows this template. The connection is named "Connection <number+1>", where <number> is the number of the last created connection whose name followed the same template.
• If the original connection had been renamed, the new connection gets the same name. You can reuse a name for multiple connections within the same agent.

You can edit the name of the new connection in the Name of connection field on the tab of the connection.

Removing a connection

If the agent has more than one connection, you can delete a connection.

To delete a connection:

1. In the KUMA web interface, in the Resources → Agents section, create a new agent or click an existing agent in the table.
2. If necessary, create a connection for the agent by clicking the Add button in the lower part of the left pane.
3. Go to the tab of the connection that you want to delete and click the Delete button.

You cannot restore a deleted connection, but you can recover the version of the agent in which this connection was previously saved through the change history.

Creating an agent service in the KUMA web interface

When a resource set is created for an agent, you can proceed to create an agent service in KUMA.

To create an agent service in the KUMA web interface:

1. In the KUMA web interface, under Resources → Active services, click Add service.
2. In the opened Choose a service window, select the resource set that was just created for the agent and click Create service.

The agent service is created in the KUMA web interface and is displayed under Resources → Active services. Now agent services must be installed to each asset from which you want to forward data to the collector. A service ID is used during installation.

Installing an agent in a KUMA network infrastructure

When an agent service is created in KUMA, you can proceed to installation of the agent to the network infrastructure assets that will be used to forward data to a collector.

Multiple agents can be installed on a device; the version of all such agents must be the same.

Prior to installation, verify the network connectivity of the system and open the ports used by its components.

Installing a KUMA agent on Linux assets

KUMA agent installed on Linux devices stops when you close the terminal or restart the server. If you do not want to start KUMA agents manually, we recommend installing agents using an application that automatically starts applications whenever the server is restarted, for example, the Supervisor application. If you want to start KUMA agents automatically, specify the automatic start and restart settings in the KUMA configuration file. For more information on configuring automatic starting and restarting, see the official documentation of applications for automatically starting applications.

Example configuration in Supervisor

To install a KUMA agent to a Linux asset:

1. On the Linux device on which you want to install the KUMA agent, create directories for the KUMA configuration file and agents, for example:
   • /opt/kaspersky/kuma
   • /opt/kaspersky/agent
2. Place the KUMA configuration file in the directory created for it. The KUMA configuration file can be found inside the installer in the /kuma-ansible-installer/roles/kuma/files directory.

   Make sure the kuma file has sufficient rights to run.

3. Create the KUMA user:

   sudo useradd --system kuma && usermod -s /usr/bin/false kuma

4. Grant the KUMA user access to the directory with the KUMA configuration file and to all files within the directory:

   sudo chown -R kuma:kuma <path to the directory with the KUMA configuration file>

5. Install the KUMA agent:

   sudo /opt/kaspersky/kuma/kuma agent --core https://<KUMA Core server FQDN>:<port used by KUMA Core for internal communication (port 7210 by default)> --id <service ID copied from the KUMA web interface> --wd <path to the directory that will contain the files of the installed KUMA agent. If this option is not specified, the files will be stored in the directory where the KUMA file is located> [--accept-eula]

   You can install two KUMA agents on the same Linux device. In this case, KUMA agents will work in parallel. When installing the second KUMA agent, you need to specify a separate directory for it using the --wd option.

   To run the agent, you need to accept the End User License Agreement. You can add the --accept-eula option to the command to automatically accept the End User License Agreement during KUMA agent installation. This lets you perform the installation non-interactively. If you do not specify this option, you will need to accept or reject the License Agreement manually during the installation of the KUMA agent.

   Examples of installing the KUMA agent:

   • Installing the KUMA agent without automatically accepting the End User License Agreement:

     sudo /opt/kaspersky/kuma/kuma agent --core https://kuma.example.com:7210 --id XXXX --wd /opt/kaspersky/kuma/agent/XXXX

   • Installing the KUMA agent with automatic acceptance of the End User License Agreement:

     sudo /opt/kaspersky/kuma/kuma agent --core https://kuma.example.com:7210 --id XXXX --wd /opt/kaspersky/kuma/agent/XXXX --accept-eula

   By using the --accept-eula option during the installation of the KUMA agent, you confirm that you agree with and accept the terms and conditions of the End User License Agreement.

6. If you chose KUMA installation with the automatic acceptance of the End User License Agreement and want to read the text of the End User License Agreement, or if the text of the End User License Agreement was not automatically provided to you during the installation process, run the following command:

   ./kuma license --show

The KUMA agent is installed on the Linux device.

You can configure the collector to receive data that the KUMA agent sends to KUMA.

Installing a KUMA agent on Windows assets

Prior to installing a KUMA agent to a Windows asset, the server administrator must create a user account with the EventLogReaders and Log on as a service permissions on the Windows asset. This user account must be used to start the agent.
If you want to run the agent under a local account, you need administrator rights and Log on as a service. If you want to perform the collection remotely and only read logs under a domain account, EventLogReaders rights are sufficient.

To install a KUMA agent to a Windows asset:

1. Copy the kuma.exe file to a folder on the Windows asset. C:\Users\<User name>\Desktop\KUMA folder is recommended for installation.

   The kuma.exe file is located inside the installer in the /kuma-ansible-installer/roles/kuma/files/ directory.

2. Start the Command Prompt on the Windows asset with Administrator privileges and locate the folder containing the kuma.exe file.
3. Execute the following command:

   kuma agent --core https://<fully qualified domain name of the KUMA Core server>:<port used by the KUMA Core server for internal communications (port 7210 by default)> --id <ID of the agent service that was created in KUMA> --user <name of the user account used to run the agent, including the domain> --install [--accept-eula]

   To run the agent, you need to accept the End User License Agreement. You can add the --accept-eula option to the command to automatically accept the End User License Agreement during agent installation. This lets you perform the installation non-interactively. If you do not specify this option, you will need to accept or reject the License Agreement manually during the installation of the KUMA agent.

   Examples:

   • Installing the KUMA agent without automatically accepting the End User License Agreement:

     kuma agent --core https://kuma.example.com:7210 --id XXXXX --user domain\username --install

   • Installing the KUMA agent with automatic acceptance of the End User License Agreement:

     kuma agent --core https://kuma.example.com:7210 --id XXXXX --user domain\username --install --accept-eula

   By using the --accept-eula option during the installation of the KUMA agent, you confirm that you agree with and accept the terms and conditions of the End User License Agreement.

   You can get help information by executing the kuma help agent command.

4. If you started the installation of the agent without automatically accepting the End User License Agreement, during the installation process, you will be prompted to read the text of the End User License Agreement and you will have the opportunity to accept or reject the agreement.
5. If you chose installation with the automatic acceptance of the End User License Agreement and want to read the text of the End User License Agreement, or if the text of the End User License Agreement was not automatically provided to you during the installation process, run the following command:

   kuma.exe license --show

   If you want to accept the End User License Agreement, run the following command and press y:

   kuma.exe license

6. Specify the password for the agent's user in one the following ways:
   • Manually.
   • From a file when installing the agent.

     To avoid entering the password manually, you can add the password to a .TXT file and place the file in the same directory as the executable file of the agent.

     In the command, specify the file containing the password as follows: <name of the password file>.txt. For example, password.txt.

     kuma agent --core https://kuma.example.com:7210 --id XXXXX --user domain\username --install < password.txt

     All data from the password.txt file is redirected to the command as the password, excluding end-of-line characters (\n\r, \n).

     Path for storing the agent folder after installation: C:\ProgramData\Kaspersky Lab\KUMA\agent\${agent_id}.

   If you did not accept the End User License Agreement (EULA) before installing the agent with the < password.txt flag, an error message is displayed saying that the agreement was not accepted.

   You can accept the EULA in the following ways:

   1. In the password file, you can specify the EULA acceptance flag. To achieve this, the file with the password must contain two lines: the first line containing "y", which serves to assert EULA acceptance, and the second line containing the password. For example:

      y

      <password>

      The agent installation command looks like this:

      kuma agent --core https://kuma.example.com:7210 --id XXXXX --user domain\username --install < password.txt

      In this case, you will not need to additionally accept the EULA when installing the agent.

      If the EULA has been accepted before running the command with the password file, the first line in the file is interpreted as the password and the installation is aborted with an Access denied error.

   2. You can accept the EULA and perform a silent installation at the same time by using the --accept-eula flag.

      The agent installation command looks like this:

      kuma agent --core https://kuma.example.com:7210 --id XXXXX --user domain\username --accept-eula --install < password.txt

      Make sure that only the password is specified in the file, on the first line, otherwise an error will occur.

The C:\ProgramData\Kaspersky Lab\KUMA\agent\<agent ID> folder is created and the KUMA agent service is installed in it. The agent forwards Windows events to KUMA, and you can set up a collector to receive them.

When the agent service is installed, it starts automatically. The service is also configured to restart in case of any failures. The agent can be restarted from the KUMA web interface, but only when the service is active. Otherwise, the service needs to be manually restarted on the Windows asset.

Removing a KUMA agent from Windows assets

When configuring services, you can check the configuration for errors before installation by running the agent with the following command:

kuma agent --core https://<fullly qualified domain name of the KUMA Core server>:<port used by the KUMA Core server for internal communications (port 7210 by default)> --id <ID of the agent service that was created in KUMA> --user <name of the user account used to run the agent, including the domain>

Automatically created agents

When creating a collector with wec, wmi, or etw connectors, agents are automatically created for receiving Windows events.

Automatically created agents have the following special conditions:

• Automatically created agents can have only one connection.
• Automatically created agents are displayed under Resources → Agents, and auto created is indicated at the end of their name. Agents can be reviewed or deleted.
• The settings of automatically created agents are defined automatically based on the collector settings from the Connect event sources and Transport sections. You can change the settings only for a collector that has a created agent.
• The description of an automatically created agent is taken from the collector description in the Connect event sources section.
• Debugging of an automatically created agent is enabled and disabled in the Connect event sources section of the collector.
• When deleting a collector with an automatically created agent, you will be prompted to choose whether to delete the collector together with the agent or to just delete the collector. When deleting only the collector, the agent will become available for editing.
• When deleting automatically created agents, the type of collector changes to http, and the connection address is deleted from the URL field of the collector.
• If at least one Windows log name in wec or wmi connector is specified incorrectly, the agent will not receive events from any Windows log listed in the connector. At the same time the agent status will be green. Attempts to receive events will be repeated every 60 seconds, and error messages will be added to the service log.
• If in a connector of the etw type, the session name is specified incorrectly, the wrong provider is specified in the session, or an incorrect method is specified for sending events (to send events correctly, on the Windows Server side, you must specify "Real time" or "File and Real time" mode), events will not arrive from the agent, an error will be recorded in the agent log on Windows, and the status of the agent will be green. At the same time, no attempt will be made to get events every 60 seconds. If you modify session settings on the Windows side, you must restart the etw agent and/or the session for the changes to take effect.

In the KUMA interface, automatically created agents appear at the same time when the collector is created. However, they must still be installed on the asset that will be used to forward a message.

Update agents

When updating KUMA versions, the WMI, WEC, and ETW agents installed on remote machines must also be updated.

To update the agent, use an administrator account and follow these steps:

1. In the KUMA web interface, in the Resources → Active services - Agents section, select the agent that you want to update and copy its ID.

   You need the ID to install the new agent with the same ID after removing the old agent.

2. In Windows, in the Services section, open the agent and click Stop.
3. On the command line, go to the folder where the agent is installed and run the command to remove the agent from the server.

   kuma.exe agent --id <ID of agent service that was created in KUMA> --uninstall

4. Place the new agent in the same folder.
5. On the command line, go to the folder with the new agent and from that folder, run the installation command using the agent ID from step 1.

   kuma agent --core https://<fullly qualified domain name of the KUMA Core server>:<port used by the KUMA Core server for internal communications (port 7210 by default)> --id <ID of the agent service that was created in KUMA> --user <name of the user account used to run the agent, including the domain> --install

6. When when installing the updated agent on a device for the first time, you must confirm the license. During the installation process, you are prompted to read the text of the license and then accept or reject the agreement. If this did not happen automatically, you can use the following command to view the text of the license:

   kuma.exe license --show

   If you want to accept the license agreement, run the command and press y:

   kuma.exe license

The agent is updated.

Transferring events from isolated network segments to KUMA

Data transfer scenario

Data diodes can be used to transfer events from isolated network segments to KUMA. Data transfer is organized as follows:

1. KUMA agent that is Installed on a standalone server, with a diode destination receives events and moves them to a directory from which the data diode will pick up the events.

   The agent accumulates events in a buffer until it overflows or for a user-defined period after the last write to disk. The events are then written to a file in the temporary directory of the agent. The file is moved to the directory processed by the data diode; its name is a combination of the file contents hash (SHA-256) and the file creation time.

2. The data diode moves files from the isolated server directory to the external server directory.
3. A KUMA collector with a diode connector installed on an external server reads and processes events from the files of the directory where the data diode places files.

   After all events are read from a file, it is automatically deleted. Before reading events, the contents of files are verified based on the hash in the file name. If the contents fail verification, the file is deleted.

In the described scenario, the KUMA components are responsible for moving events to a specific directory within the isolated segment and for receiving events from a specific directory in the external network segment. The data diode transfers files containing events from the directory of the isolated network segment to the directory of the external network segment.

For each data source within an isolated network segment, you must create its own KUMA collector and agent, and configure the data diode to work with separate directories.

Configuring KUMA components

Configuring KUMA components for transferring data from isolated network segments consists of the following steps:

1. Creating a collector service in the external network segment.

   At this step, you must create and install a collector to receive and process the files that the data diode will transfer from the isolated network segment. You can use the Collector Installation Wizard to create the collector and all the resources it requires.

   At the Transport step, you must select or create a connector of the diode type. In the connector, you must specify the directory to which the data diode will move files from the isolated network segment.

   The user "kuma" that runs the collector must have read/write/delete permissions in the directory to which the data diode moves data from the isolated network segment.

2. Creating a resource set for a KUMA agent.

   At this step, you must create a resource set for the KUMA agent that will receive events in an isolated network segment and prepare them for transferring to the data diode. The diode agent resource set has the following requirements:

   • The destination in the agent must have the diode type. In this resource, you must specify the directory from which the data diode will move files to the external network segment.
   • You cannot select connectors of the sql or netflow types for the diode agent.
   • TLS mode must be disabled in the connector of the diode agent.
3. Downloading the agent configuration file as JSON file.
   1. The set of agent resources from a diode-type destination must be downloaded as a JSON file.
   2. If secret resources were used in the agent resource set, you must manually add the secret data to the configuration file.
4. Installing the KUMA agent service in the isolated network segment.

   At this step, you must install the agent in an isolated network segment based on the agent configuration file that was created at the previous step. It can be installed to Linux and Windows devices.

Configuring a data diode

The data diode must be configured as follows:

• Data must be transferred atomically from the directory of the isolated server (where the KUMA agent places the data) to the directory of the external server (where the KUMA collector reads the data).
• The transferred files must be deleted from the isolated server.

For information on configuring the data diode, please refer to the documentation for the data diode used in your organization.

Special considerations

When working with isolated network segments, operations with SQL and NetFlow are not supported.

When using the scenario described above, the agent cannot be administered through the KUMA web interface because it resides in an isolated network segment. Such agents are not displayed in the list of active KUMA services.

Diode agent configuration file

A created set of agent resources with a diode-type destination can be downloaded as a configuration file. This file is used when installing the agent in an isolated network segment.

To download the configuration file:

In the KUMA web interface, under Resources → Agents, select the required set of agent resources with a diode destination and click Download config.

The agent settings configuration is downloaded as a JSON file based on the settings of your browser. Secrets used in the agent resource set are downloaded empty. Their IDs are specified in the file in the secrets section. To use a configuration file to install an agent in an isolated network segment, you must manually add secrets to the configuration file (for example, specify the URL and passwords used in the agent connector to receive events).

You must use an access control list (ACL) to configure permissions to access the file on the server where the agent will be installed. File read access must be available to the user account that will run the diode agent.

Below is an example of a diode agent configuration file with a kafka connector.

Description of secret fields

Secret fields

Installing Linux Agent in an isolated network segment

To install a KUMA agent to a Linux device in an isolated network segment:

1. Place the following files on the Linux server in an isolated network segment that will be used by the agent to receive events and from which the data diode will move files to the external network segment:
   • Agent configuration file.

     You must use an access control list (ACL) to configure access permissions for the configuration file so that only the KUMA user will have file read access.

   • Executive file /opt/kaspersky/kuma/kuma (the "kuma" file can located in the installer in the /kuma-ansible-installer/roles/kuma/files/ directory).
2. Execute the following command:

   sudo ./kuma agent --cfg <path to the agent configuration file> --wd <path to the directory where the files of the agent being installed will reside. If this flag is not specified, the files will be stored in the directory where the kuma file is located>

The agent service is installed and running on the server in an isolated network segment. It receives events and relays them to the data diode so that they can be sent to an external network segment.

Installing Windows Agent in an isolated network segment

Prior to installing a KUMA agent to a Windows asset, the server administrator must create a user account with the EventLogReaders and Log on as a service permissions on the Windows asset. This user account must be used to start the agent.

To install a KUMA agent to a Windows device in an isolated network segment:

1. Place the following files on the Window server in an isolated network segment that will be used by the agent to receive events and from which the data diode will move files to the external network segment:
   • Agent configuration file.

     You must use an access control list (ACL) to configure access permissions for the configuration file so that the file can only be read by the user account that will run the agent.

   • Kuma.exe executable file. This file can be found inside the installer in the /kuma-ansible-installer/roles/kuma/files/ directory.

   We recommend using the C:\Users\<user name>\Desktop\KUMA folder.

2. Start the Command Prompt on the Windows asset with Administrator privileges and locate the folder containing the kuma.exe file.
3. Execute the following command:

   kuma.exe agent --cfg <path to the agent configuration file> --user <user name that will run the agent, including the domain> --install

   You can get installer Help information by running the following command:

   kuma.exe help agent

4. Enter the password of the user account used to run the agent.

The C:\Program Files\Kaspersky Lab\KUMA\agent\<Agent ID> folder is created in which the KUMA agent service is installed. The agent moves events to the folder so that they can be processed by the data diode.

When installing the agent, the agent configuration file is moved to the directory C:\Program Files\Kaspersky Lab\KUMA\agent\<agent ID specified in the configuration file>. The kuma.exe file is moved to the C:\Program Files\Kaspersky Lab\KUMA directory.

When installing an agent, its configuration file must not be located in the directory where the agent is installed.

When the agent service is installed, it starts automatically. The service is also configured to restart in case of any failures.

Removing a KUMA agent from Windows assets

When configuring services, you can check the configuration for errors before installation by running the agent with the following command:

kuma.exe agent --cfg <path to agent configuration file>

Transferring events from Windows machines to KUMA

To transfer events from Windows machines to KUMA, a combination of a KUMA agent and a KUMA collector is used. Data transfer is organized as follows:

1. The KUMA agent installed on the machine receives Windows events:
   • Using the WEC connector: the agent receives events arriving at the host under a subscription, as well as the server logs.
   • Using the WMI connector: the agent connects to remote servers specified in the configuration and receives events.
   • Using the ETW connector: the agent connect to the DNS server using the session name and provider specified in the connector settings, and receives events.
2. The agent sends events (without preprocessing) to the KUMA collector specified in the destination.

   You can configure the agent so that different logs are sent to different collectors.

3. The collector receives events from the agent, performs a full event processing cycle, and sends the processed events to the destination.

Receiving events from the WEC agent is recommended when using centralized gathering of events from Windows hosts using Windows Event Forwarding (WEF). The agent must be installed on the server that collects events; it acts as the Windows Event Collector (WEC). We do not recommend installing KUMA agents on every endpoint host from which you want to receive events.

The process of configuring the receipt of events using the WEC Agent is described in detail in the appendix: Configuring receipt of events from Windows devices using KUMA Agent (WEC).

For details about the Windows Event Forwarding technology, please refer to the official Microsoft documentation.

We recommend receiving events using the WMI agent in the following cases:

• If it is not possible to use the WEF technology to implement centralized gathering of events, and at the same time, installation of third-party software (for example, the KUMA agent) on the event source server is prohibited.
• If you need to obtain events from a small number of hosts — no more than 500 hosts per one KUMA agent.

The ETW agent is used only to retrieve events from Windows logs of DNS servers.

For connecting Windows logs as an event source, we recommend using the Add event source wizard. When using a wizard to create a collector with WEC or WMI connectors, agents are automatically created for receiving Windows events. You can also manually create the resources necessary for collecting Windows events.

An agent and a collector for receiving Windows events are created and installed in several stages:

1. Creating a resource set for an agent.

   Agent connector:

   When creating an agent, on the Connection tab, you must create or select a connector of the WEC, WMI, or ETW type.

   If at least one Windows log name in a WEC or WMI connector is specified incorrectly, the agent will receive events from all Windows logs listed in the connector, except the problematic log. At the same time the agent status will be green. Attempts to receive events will be repeated every 60 seconds, and error messages will be added to the service log.

   Agent destination:

   The type of agent destination depends on the data transfer method you use: nats-jetstream, tcp, http, diode, kafka, file.

   You must use the \0 value as the destination separator.

   The advanced settings for the agent destination (such as separator, compression and TLS mode) must match the advanced destination settings for the collector connector that you want to link to the agent.

2. Create an agent service in the KUMA web interface.
3. Installing the KUMA agent on the Windows machine from which you want to receive Windows events.

   Before installation, make sure that the system components have access to the network and open the necessary network ports:

   • Port 7210, TCP: from server with collectors to the Core.
   • Port 7210, TCP: from agent server to the Core.
   • The port configured in the URL field when the connector was created: from the agent server to the server with the collector.
4. Creating and installing KUMA collector.

   When creating a set of collectors, at the Transport step, you must create or select a connector that the collector will use to receive events from the agent. Connector type must match the type of the agent destination.

   The advanced settings of the connector (such as delimiter, compression, and TLS mode) must match the advanced settings of the agent destination that you want to link to the agent.