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. Create a set of resources for the agent in the KUMA web interface.
2. Create an agent service in the KUMA web interface.
3. Install the server portion of the agent to the asset that will forward messages.

A KUMA agent for Windows assets can be created automatically when you create a collector with the wmi or wec 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 a message.

Creating a set of resources for an agent

In the KUMA web interface, an agent service is created based on the set of resources for an agent that unites connectors and destinations.

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

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

   This opens a window for creating an agent with the Base settings tab active.

2. Fill in the settings on the Base settings tab.
   • In the Agent name field, enter a unique name for the created service. The name must contain from 1 to 128 Unicode characters.
   • In the Tenant drop-down list, select the tenant that will own the storage.
   • If you want, select the Debug check box to log service operations.
   • You can optionally add up to 256 Unicode characters describing the service in the Description field.
3. Create a connection for the agent by using the button and switch to the added Connection <number> tab.

   You can delete tabs by using the button.

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

       The agent type is determined by the connector that is used in the agent.

       When using the tcp or upd 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.

   • You can optionally add up to 256 Unicode characters describing the resource in the Description field.

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

5. In the Destinations settings block, add resources of destinations. Agents can forward data only to collectors.
   • If you want to select an existing resource, select it from the drop-down list.
   • If you want to create a new resource, select it in the Create new drop-down list and define its settings.

     Destination settings

     1. Specify the settings on the Basic settings tab:
        • In the Name field, enter a unique name for the destination resource. The name must contain from 1 to 128 Unicode characters.
        • Use the Disabled toggle button to specify whether events will be sent to this destination. By default, sending events is enabled.
        • Select the Type of destination: nats, tcp, http, kafka or file.
        • Indicate the URL where events should be sent.

          You can specify multiple destination URLs using the URL button for all types except nats and file, if your KUMA license includes High Level Availability module.

        • For the nats and kafka types, use the Topic field to specify which topic the data should be written to. The topic name must contain from 1 to 255 Unicode characters.
        • You can optionally add up to 256 Unicode characters describing the resource in the Description field.
     2. If required, define the settings on the Advanced settings tab. The available settings vary based on the selected destination resource type.
        • Compression is a drop-down list where you can enable Snappy compression. By default, compression is disabled.
        • Proxy is a drop-down list for proxy server resource selection.
        • Buffer size field is used to set buffer size (in bytes) for the destination resource. The default value is 1 MB, and the maximum value is 64 MB.
        • Timeout field is used to set the timeout (in seconds) for another service or component response. The default value is 30.
        • Disk buffer size limit field is used to specify the size of the disk buffer in bytes. The default size is 10 GB.
        • Storage ID is a NATS storage identifier.
        • TLS mode is a drop-down list where you can specify the conditions for using TLS encryption:
          • Disabled (default)—do not use TLS encryption.
          • Enabled—encryption is enabled, but without verification.
          • With verification—use encryption with verification that the certificate was signed with the KUMA root certificate. The root certificate and key of KUMA are created automatically during program installation and are stored on the KUMA Core server in the folder /opt/kaspersky/kuma/core/certificates/.

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

        • URL selection policy is a drop-down list in which you can select a method for determining which URL to send events to if several URLs have been specified:
          • Any
          • Prefer first
          • Round robin
        • Delimiter is used to specify the character delimiting the events. By default, \n is used.
        • Path—the file path if the file destination type is selected.
        • Flush interval sets the time (in seconds) between sending data to the destination resource. The default value is 100.
        • Workers—this field is used to set the number of services processing the queue. By default, this value is equal to the number of vCPUs of the KUMA Core server.
        • You can set health checks using the Health check path and Health check timeout fields. You can also disable health checks by selecting the Health Check Disabled check box.
        • Debug—a drop-down list where you can specify whether resource logging should be enabled. By default it is Disabled.
        • The Disk buffer disabled drop-down list is used to enable or disable the use of a disk buffer. By default, the disk buffer is disabled.
        • In the Filter section you can specify conditions to identify events that will be processed by the aggregation rule resource. You can select an existing filter resource from the drop-down list, or select Create new to create a new filter.

          Creating a filter in resources

          1. In the Filter drop-down menu, select Create new.
          2. If you want to keep the filter as a separate resource, set the Save filter toggle switch. This can be useful if you decide to reuse the same filter across different services. The toggle switch is turned off by default.
          3. If you toggle the Save filter switch on, enter a name for the created filter resource in the Name field. The name must contain from 1 to 128 Unicode characters.
          4. In the conditions section, specify the conditions that the events must meet:
             • The Add condition button is used to add filtering conditions. You can select two values (two operands, left and right) and assign the operation you want to perform with the selected values. The result of the operation is either True or False.
               • In the operator drop-down list, select the function to be performed by the filter.

                 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.
                 • inActiveList—this filter 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.
                 • 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.

                 You can use the Match case check box in the Operator drop-down list to choose whether the values passed to the filter should be case sensitive. This check box is cleared by default.

               • In the Left operand and Right operand drop-down lists, select where the data to be filtered will come from. As a result of the selection, Advanced settings will appear. Use them to determine the exact 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.
               • You can use the If drop-down list to choose whether you want to create a negative filter condition.

               Conditions can be deleted using the button.

             • The Add group button is used to add groups of conditions. Operator AND can be switched between AND, OR, and NOT values.

               A condition group can be deleted using the button.

             • Using the Add filter button you can add existing filter resources selected in the Select filter drop-down list to the conditions. You can navigate to a nested filter resource using the button.

               A nested filter can be deleted using the button.

     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.

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

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

Create an agent service in the KUMA web interface.

When a set of resources 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 set of resources 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.

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

Depending on the type of agent, the service is installed to either Linux or Windows assets:

• Installing to Windows:
  • wmi
  • wec
• Installing to Linux:
  • tcp
  • udp
  • nats
  • kafka
  • http
  • file
  • nfs
  • snmp

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.

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/ 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 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

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

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

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

The C:\ProgramData\Kaspersky Lab\KUMA\agent\<Agent ID> folder is created in which the KUMA agent service is installed. 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 test the configuration for errors before installation by running the agent with 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>.

Installing a KUMA agent on Linux assets

To install a KUMA agent to a Linux asset:

1. Log in to the server on which you would like to install the service as the root user.
2. Execute the following command:

   /opt/kaspersky/kuma/kuma agent --core https://<KUMA Core server FQDN>:<port used by <KUMA Core server for internal communication (port 7210 by default)> --id <service ID copied from the KUMA web interface> --wd /opt/kaspersky/kuma/agent/<service ID copied from the KUMA web interface>

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

   When deploying several KUMA services on the same host, during the installation process you must specify unique ports for each component using the --api.port <port> parameter. The following setting values are used by default: --api.port 7221.

The KUMA agent is installed on the Linux asset. The agent forwards data to KUMA, and you can set up a collector to receive this data.

Automatically created agents

When creating a collector with wec or wmi 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.

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 and WEC agents installed on remote machines must also be updated.

To update the agent:

1. Install the new agent on a remote machine.

   The agent has been updated, but no data is coming from it due to an invalid certificate.

2. In the KUMA web interface, under Resources → Active services , reset the certificate of the agent being upgraded.
3. On the remote machine with the installed agent, start the KUMA Windows Agent <service ID> service.

   For more information on Windows services, see the documentation for your version of Windows.

The agent and its certificates have been updated.