[Topic 217694]

About Kaspersky Unified Monitoring and Analysis Platform

Kaspersky Unified Monitoring and Analysis Platform (hereinafter KUMA or "program") is an integrated software solution that includes the following set of functions:

• Receiving, processing, and storing information security events.
• Analysis and correlation of incoming data.
• Search within the obtained events.
• Creation of notifications upon detecting symptoms of information security threats.

The program is built on a microservice architecture. This means that you can create and configure the relevant microservices (hereinafter also "services"), thereby making it possible to use KUMA both as a log management system and as a full-fledged SIEM system. In addition, flexible data streams routing allows you to use third-party services for additional event processing.

[Topic 220925]

What's new

• Added support for hierarchical deployment of independent installations of KUMA.
• Added capabilities for working with an elastic, SQL-like query language when searching the events database.
• Added capability for seamless navigation from dashboard widgets to source events, alerts, and incidents.
• Added support for new SQL connectors that can receive events from the following databases:
  • Oracle
  • Firebird
• Added support for importing information about assets and vulnerabilities from MaxPatrol 8.
• Added support for the Astra Linux Special Edition operating system.
• Added Dashboard-to-TV display mode.
• Improved support for sources that require authorization – added capability for authorization by login/password and by certificate.
• Added support for hot keys.
• Newly added out-of-the-box sources of events: FreeIPA, FortiGate (events in key-value format), Huawei USG – SECLOG and SHELL events, improved normalizers for KSC and CISCO FWSM (Firewall Services Module).

[Topic 217846]

Distribution kit

The distribution kit includes the following files:

• kuma-ansible-installer-<build number>.tar.gz to install KUMA components;
• files containing information about the version (release notes) in Russian and English.

[Topic 217889]

Hardware and software requirements

Recommended hardware requirements

The hardware listed below will ensure an event-processing capacity of 40,000 events per second. This figure depends on the type of parsed events and efficiency of the parser. Consider also that it is more efficient to have more cores than a lower number of cores with higher CPU frequency.

• Servers to install collectors:
  • CPU: Intel or AMD with at least 4 cores (8 threads) and support for the SSE 4.2 instruction set or 8 vCPU (virtual processors).
  • RAM: 16 GB
  • Disk: 500 GB of available disk space mounted on /opt
• Servers to install correlators:
  • CPU: Intel or AMD with at least 4 cores (8 threads) and support for the SSE 4.2 instruction set or 8 vCPU (virtual processors)
  • RAM: 16 GB
  • Disk: 500 GB of available disk space mounted on /opt
• Servers to install the Core:
  • CPU: Intel or AMD with at least 4 cores (8 threads) and support for the SSE 4.2 instruction set or 4 vCPU (virtual processors)
  • RAM: 16 GB
  • Disk: 500 GB of available disk space mounted on /opt
• Servers to install storages:
  • CPU: Intel or AMD with at least 12 cores (24 threads) and support for the SSE 4.2 instruction set or 24 vCPU (virtual processors).

    Support is required for SSE4.2 commands.

  • RAM: 48 GB
  • Disk: 500 GB of available disk space mounted on /opt

  Using SSDs highly improves cluster node indexing and search efficiency.

  Local mounted HDD/SSD are more efficient than external JBODs. RAID 0 is recommended for faster performance, while RAID 10 is recommended for redundancy.

  To increase reliability, it is not recommended to deploy all cluster nodes on a single JBOD or single physical server (if virtual servers are used).

  To increase efficiency, we recommend keeping all servers in a single data center.

• Machines to install Windows agents:
  • Processor: single-core, 1.4 GHz or higher
  • RAM: 512 MB
  • Disk: 1 GB
  • OS:
    • Microsoft Windows 2012
    • Microsoft Windows Server 2012 R2
    • Microsoft Windows Server 2016
    • Microsoft Windows Server 2019
    • Microsoft Windows 10 (20H1, 20H2, 21H1)
• Machines to install Linux agents:
  • Processor: single-core, 1.4 GHz or higher
  • RAM: 512 MB
  • Disk: 1 GB
  • OS:
    • Ubuntu 20.04 LTS, 21.04
    • Oracle Linux version 8.4 or later
    • Astra Linux Special Edition RUSB.10015-01 (update 1.7.1)

Software requirements

Each server that is used to install KUMA services must have one of the following operating systems installed: Astra Linux Special Edition RUSB.10015-01 (update 1.7.1) or Oracle Linux version 8.4 or later.

Network requirements

The network interface bandwidth must be at least 100 Mbps.

For KUMA to be able to process more than 20,000 events per second, ensure a data transfer speed of at least 10 Gbps between ClickHouse nodes.

Additional requirements

For computers used for the KUMA web interface, Google Chrome browser version 93 or later, or Mozilla Firefox browser version 92 or later must be installed.

[Topic 230383]

KUMA interface

The program is managed through the web interface.

The window of the program web interface contains the following items:

• Sections in the left part of the program web interface window
• Tabs in the upper part of the program web interface window for some sections of the program
• Workspace in the lower part of the program web interface window

The workspace displays the information that you choose to view in the sections and on the tabs of the program web interface window. It also contains management elements that you can use to configure how the information is displayed.

While working with the program web interface, you can use hot keys to perform the following actions:

• In all sections: close the window that opens in the right side pane—Esc
• In the Events section:
  • Switch between events in the right side pane—↑ and ↓.
  • Start a search (when focused on the query field)—Command/Control + Enter.
  • Save a search query—Control/Command + S.

[Topic 230384]

Compatibility with other applications

Kaspersky Endpoint Security for Linux

If the components of KUMA and Kaspersky Endpoint Security for Linux are installed on the same server, the report.db directory may grow very large and even take up the entire drive space. To avoid this problem, the following is recommended:

• Upgrade Kaspersky Endpoint Security for Linux to version 11.2.2.5324.
• Add the following directories to general exclusions and to on-demand scan exclusions:
  • /opt/kaspersky/kuma/clickhouse/data/store/
  • /opt/kaspersky/kuma/victoria-metrics/
  • /var/lib/rsyslog/imjournal.state

  For more details on scan exclusions, please refer to the Kaspersky Endpoint Security for Linux Online Help Guide.

[Topic 217958]

Program architecture

The standard program installation includes the following components:

• One or more Collectors that receive messages from event sources and parse, normalize, and, if required, filter and/or aggregate them.
• A Correlator that analyzes normalized events received from Collectors, performs the necessary actions with active lists, and creates alerts in accordance with the correlation rules.
• The Core that includes a graphical interface to monitor and manage the settings of system components.
• The Storage, which contains normalized events and registered incidents.

Events are transmitted between components over optionally encrypted, reliable transport protocols. You can configure load balancing to distribute load between service instances, and it is possible to enable automatic switching to the backup component if the primary one is unavailable. If all components are unavailable, events are saved to the hard disk buffer and sent later. The buffer disk size for temporary event storage can be adjusted.

KUMA architecture

[Topic 217779]

Core

The Core is the central component of KUMA that serves as the foundation upon which all other services and components are built. It provides a graphical user interface that is intended for everyday use by operators/analysts and for configuring the entire system.

The Core allows you to:

• create and configure services, or components, of the program, as well as integrate the necessary software into the system;
• manage program services and user accounts in a centralized way;
• visualize statistical data on the program;
• investigate security threats based on the received events.

[Topic 217762]

Collector

A collector is an application component that receives messages from event sources, processes them, and transmits them to a storage, correlator, and/or third-party services to identify alerts.

For each collector, you need to configure one connector and one normalizer. You can also configure an unlimited number of additional Normalizers, Filters, Enrichment rules, and Aggregation rules. To enable the collector to send normalized events to other services, specific destinations must be added. Normally, two destinations are used: the storage and the correlator.

The collector operation algorithm includes the following steps:

1. Receiving messages from event sources

   To receive messages, you must configure an active or passive connector. The passive connector can only receive messages from the event source, while the active connector can initiate a connection to the event source, such as a database management system.

   Connectors can also vary by type. The choice of connector type depends on the transport protocol for transmitting messages. For example, for an event source that transmits messages over TCP, you must install a TCP type connector.

   The program has the following connector types available:

   • internal
   • tcp
   • udp
   • netflow
   • nats
   • kafka
   • http
   • sql
   • file
   • ftp
   • nfs
   • wmi
   • wec
   • snmp
2. Event parsing and normalization

   Events received by the connector are processed using the parser and normalization rules set by the user. The choice of normalizer depends on the format of the messages received from the event source. For example, you must select a CEF-type root normalizer for a source that sends events in CEF format.

   The following normalizers are available in the program:

   • JSON
   • CEF
   • Regexp
   • Syslog (as per RFC3164 and RFC5424)
   • CSV
   • Key-value
   • XML
   • NetFlow v5
   • NetFlow v9
   • IPFIX (v10)
3. Filtering of normalized events

   You can configure filters that allow you to select only the events that satisfy the specified conditions for further processing. Events that do not meet the filtering conditions are eliminated at this stage and are not processed further.

4. Enrichment and conversion of normalized events

   Enrichment rules let you to supplement event contents with information from internal and external sources. The program has the following enrichment sources:

   • constant
   • cybertrace
   • dictionary
   • dns
   • event
   • ldap
   • template

   Mutation rules let you convert event contents in accordance with the defined criteria. The program has the following conversion methods:

   • lower—converts all characters to lower case.
   • upper—converts all characters to upper case.
   • regexp—extracts a substring using RE2 regular expressions.
   • substring—selects text strings by specified item numbers.
   • replace—replaces text with the entered string.
   • trim—deletes the specified characters.
   • append—adds characters to the end of the field value.
   • prepend—adds characters to the beginning of the field value.
5. Aggregation of normalized events

   You can configure aggregation rules to reduce the number of similar events that are transmitted to the storage and/or the correlator. For example, you can aggregate into one event all messages about network connections transmitted over the same protocol (transport and application layers) between two IP addresses and received during a specified time interval. If aggregation rules are configured, multiple events will be processed and saved as a single event. This helps you reduce the load on the services responsible for further event processing, saves you storage space, and reduces events processed per second (EPS) count.

6. Transmission of normalized events

   After all the processing stages are completed, the event is sent to configured destinations.

[Topic 217784]

Correlator

The Correlator is a program component that analyzes normalized events. Information from active lists and/or dictionaries can be used in the correlation process.

The data obtained by analysis is used to carry out the following tasks:

• Alert detection.
• Notification about detected incidents.
• Active lists content management.
• Sending correlation events to configured destinations.

Event correlation is performed in real time. The operating principle of the correlator is based on an event signature analysis. This means that every event is processed according to the correlation rules set by the user. When the program detects a sequence of events that satisfies the conditions of the correlation rule, it creates a correlation event and sends it to the Storage. The correlation event can also be sent to the correlator for repeated analysis, which allows you to customize the correlation rules so that they are triggered by the results of a previous analysis. Products of one correlation rule can be used by other correlation rules.

You can distribute correlation rules and the active lists they use among correlators, thereby sharing the load between services. In this case, the collectors will send normalized events to all available correlators.

The Correlator operation algorithm has the following steps:

1. Obtaining an event

   The correlator receives a normalized event from the collector or from another service.

2. Applying correlation rules

   You can configure correlation rules so they are triggered based on a single event or a sequence of events. If no alert was detected using the correlation rules, the event processing ends.

3. Responding to an alert

   You can specify actions that the program must perform when an alert is detected. The following actions are available in the program:

   • Event enrichment
   • Operations with active lists
   • Sending notifications
   • Storing correlation event
4. Sending a correlation event

   When the program detects a sequence of events that satisfies the conditions of the correlation rule, it creates a correlation event and sends it to the storage. Event processing by the correlator is now finished.

[Topic 218010]

Storage

A KUMA storage is used to store normalized events so that they can be quickly and continually accessed from KUMA for the purpose of extracting analytical data. Access speed and continuity are ensured through the use of the ClickHouse technology. This means that a storage is a ClickHouse cluster bound to a KUMA storage service.

Storage components: clusters, shards, replicas, and keepers.

When choosing a ClickHouse cluster configuration, consider the specific event storage requirements of your organization. For more information, please refer to the ClickHouse documentation.

In repositories, you can create spaces. The spaces enable to create a data structure in the cluster and, for example, store the events of a certain type together.

[Topic 220211]

Basic entities

This section describes the main entities that KUMA works with.

[Topic 221264]

About tenants

KUMA has a multitenancy mode in which one instance of the KUMA application installed in the infrastructure of the main organization (main tenant) enables isolation of branches (tenants) so that they receive and process their own events.

The system is managed centrally through the main interface while tenants operate independently of each other and have access only to their own resources, services, and settings. Events of tenants are stored separately.

Users can have access to multiple tenants at the same time. You can also select which tenants' data will be displayed in sections of the KUMA web interface.

In KUMA, two tenants are created by default:

• The main tenant contains resources and services related to the main tenant. These resources are available only to the general administrator.
• The shared tenant is where the general administrator can place resources, asset categories, and monitoring policies that users of all tenants will be able to utilize.

[Topic 217693]

About events

Events are instances of the security-related activities of network assets and services that can be detected and recorded. For example, events include login attempts, interactions with a database, and sensor information broadcasts. Each separate event may seem meaningless, but when considered together they form a bigger picture of network activities to help identify security threats. This is the core functionality of KUMA.

KUMA receives events from logs and restructures their information, making the data from different event sources consistent (this process is called normalization). Afterwards, the events are filtered, aggregated, and later sent to the correlator service for analysis and to the Storage for retaining. When KUMA recognizes specific event or a sequences of events, it creates correlation events, that are also analyzed and retained. If an event or sequence of events indicates a potential security threat, KUMA creates an alert. This alert consists of a warning about the threat and all related data that should be investigated by a security officer.

Throughout their life cycle, events undergo conversions and may receive different names. Below is a description of a typical event life cycle:

The first steps are carried out in a collector.

1. Raw event. The original message received by KUMA from an event source using a Connector is called a raw event. This is an unprocessed message and it cannot be used yet by KUMA. To fit into the KUMA pipeline, raw events must be normalized into the KUMA data model. That's what the next stage is for.
2. Normalized event. A normalizer is a set of parsers that maps raw events into KUMA data model. After this conversion, the original message becomes a normalized event and can be used by KUMA for analysis. From here on, only normalized events are used in KUMA. Raw events are no longer used, but they can be kept as a part of normalized events inside the Raw field.

   The program has the following normalizers:

   • JSON
   • CEF
   • Regexp
   • Syslog (as per RFC3164 and RFC5424)
   • CSV/TSV
   • Key-value
   • XML
   • Netflow v5, v9, IPFIX (v10)
   • SQL

   At this point normalized events can already be used for analysis.

3. Event destination. After the Collector service have processed an event, it is ready to be used by other KUMA services and sent to the KUMA Correlator and/or Storage.

The next steps of the event life cycle are completed in the correlator.

Event types:

1. Base event. An event that was normalized.
2. Aggregated event. When dealing with a large number of similar events, you can "merge" them into a single event to save processing time and resources. They act as base events, but In addition to all the parameters of the parent events (events that are "merged"), aggregated events have a counter that shows the number of parent events it represents. Aggregated events also store the time when the first and last parent events were received.
3. Correlation event. When a sequence of events is detected that satisfies the conditions of a correlation rule, the program creates a correlation event. These events can be filtered, enriched, and aggregated. They can also be sent for storage or looped into the Correlator pipeline.
4. Audit event. Audit events are created when certain security-related actions are completed in KUMA. These events are used to ensure system integrity. They are stored at least for 365 days.
5. Monitoring event. These events are used to track changes in the amount of data received by KUMA.

[Topic 217691]

About alerts

In KUMA, an alert is created when a sequence of events is received that triggers a correlation rule. Correlation rules are created by KUMA analysts to check incoming events for possible security threats, so when a correlation rule is triggered, it's a warning there may be some malicious activity happening. Security officers should investigate these alerts and respond if necessary.

KUMA automatically assigns the priority to each alert. This parameter shows how important or numerous the processes are that triggered the correlation rule. Alerts with higher priority should be dealt with first. The priority value is automatically updated when new correlation events are received, but a security officer can also set it manually. In this case, the alert priority is no longer automatically updated.

Alerts have related events linked to them, making alerts enriched with data from these events. KUMA also offers drill down functionality for alert investigations.

You can create incidents based on alerts.

Below is the life cycle of an alert:

1. KUMA creates an alert when a correlation rule is triggered. The alert is updated if the correlation rule is triggered again. Alert is assigned the New status.
2. A security officer assigns the alert to an operator for investigation. The alert status changes to assigned.
3. The operator performs one of the following actions:
   • Close the alert as false a positive (alert status changes to closed).
   • Respond to the threat and close the alert (alert status changes to closed).

Afterwards, the alert is no longer updated with new events and if the correlation rule is triggered again, a new alert is created.

Alert management in KUMA is described in this section.

[Topic 220212]

About incidents

If the nature of the data received by KUMA or the generated correlation events and alerts indicate a possible attack or vulnerability, the symptoms of such an event can be combined into an incident. This allows security experts to analyze threat manifestations in a comprehensive manner and facilitates response.

You can assign a category, type, and priority to incidents, and assign incidents to data protection officers for processing.

Incidents can be exported to RuCERT.

[Topic 217692]

About assets

Assets are network devices registered in KUMA. Assets generate network traffic when they send and receive data. The KUMA program can be configured to track this activity and create baseline events with a clear indication of where the traffic is coming from and where it is going. The event can contain source and destination IP addresses, as well as DNS names. If you register an asset with certain parameters (for example, a specific IP address), this asset is linked to all events that contain this IP address in any of its parameters.

Assets can be divided into logical groups. This helps keep your network structure transparent and gives you additional ways to work with correlation rules. When an event linked to an asset is processed, the category of this asset is also taken into consideration. For example, if you assign high priority to a certain category of assets, the base events involving these assets will trigger the creation of correlation events with higher priority. This in turn will cascade into higher priority alerts and, therefore, a faster response to it.

It is recommended to register network assets in KUMA because their use makes it possible to formulate clear and versatile correlation rules for much more efficient analysis of events.

Asset management in KUMA is described in this section.

[Topic 221640]

About resources

Resources are KUMA components that contain parameters for implementing various functions: for example, establishing a connection with a given web address or converting data according to certain rules. These components, like parts of a constructor set, are assembled into resource sets for services, based on which, in turn, KUMA services are created.

[Topic 221642]

About services

Services are the main components of KUMA that work with events: receiving, processing, analyzing, and storing them. Each service consists of two parts that work together:

• One part of the service is created inside the KUMA web interface based on set of resources for services.
• The second part of the service is installed in the network infrastructure where the KUMA system is deployed as one of its components. The server part of a service can consist of several instances: for example, services of the same agent or storage can be installed on several computers at once.

Parts of services are connected to each other by using the IDs of services.

[Topic 217690]

About agents

KUMA agents are services that are used to forward unprocessed events from servers and workstations to KUMA collectors.

Types of agents:

• Wmi agents are used to receive data from remote Windows machines using Windows Management Instrumentation. They are installed to Windows assets.
• Wec agents are used to receive Windows logs from a local machine using Windows Event Collector. They are installed to Windows assets.
• Tcp agents are used to receive data over the TCP protocol. They are installed to Linux and Windows assets.
• Udp agents are used to receive data over the UDP protocol. They are installed to Linux and Windows assets.
• Nats agents are used for NATS communications. They are installed to Linux and Windows assets.
• Kafka agents are used for Kafka communications. They are installed to Linux and Windows assets.
• Http agents are used for communication over the HTTP protocol. They are installed to Linux and Windows assets.
• File agents are used to get data from a file. They are installed to Linux and Windows assets.
• Ftp agents are used to receive data over the File Transfer Protocol. They are installed to Linux and Windows assets.
• Nfs agents are used to receive data over the Network File System protocol. They are installed to Linux and Windows assets.
• Snmp agents are used to receive data over the Simple Network Management Protocol. They are installed to Linux and Windows assets.

[Topic 217695]

About Priority

Priority reflects the relative importance of security-sensitive activity detected by a KUMA correlator. It shows the order in which multiple alerts should be processed, and indicates whether senior security officers should be involved.

The Correlator automatically assigns priority to correlation events and alerts based on correlation rule settings. The priority of an alert also depends on the assets related to the processed events because correlation rules take into account the priority of a related asset's category. If the alert or correlation event does not have linked assets with a defined priority or does not have any related assets at all, the priority of this alert or correlation event is equal to the priority of the correlation rule that triggered them. The alert or the correlation event priority is never lower than the priority of the correlation rule that triggered them.

Alert priority can be changed manually. The priority of alerts changed manually is no longer automatically updated by correlation rules.

Possible priority values:

• Low
• Medium
• High
• Critical

[Topic 217904]

Installing and removing KUMA

This section described the installation of KUMA. KUMA can be installed on one server to get familiar with the program capabilities. KUMA can also be installed in a production environment.

[Topic 231034]

Program installation requirements

Requirements for program installation in the Oracle Linux operating system

• A disk image for installation is available on the official Oracle site.
• Make sure that Python version 3.6 or later is installed in the operating system.
• Make sure that the pip3 package management system is installed in the operating system.
• Make sure that the netaddr package is installed in the operating system. This package can be installed by running the pip3 install netaddr command.

Requirements for program installation in the Astra Linux Special Edition operating system

• Make sure that Python version 3.6 or later is installed in the operating system.
• Make sure that the pip3 package management system is installed in the operating system.
• Make sure that the following packages are installed in the operating system:
  • python-apt
  • curl
  • libcurl3

  These packages can be installed by running the apt install python-apt curl libcurl3 command.

• Make sure that the following dependent packages are installed in the operating system:
  • netaddr
  • python3-cffi-backend

  These packages can be installed using the following commands:

  • apt install python3-cffi-backend
  • pip3 install netaddr

  If you are planning to query Oracle databases from KUMA, you must install the libaio1 package.

• You must use the sudo pdpl-user -i 63 <user name> command to assign the required permissions to the user who will be running the program installation.

General installation requirements

• The server where the installer is run cannot have the name localhost or localhost.<domain>. The installer can run from any folder, but the RPM packages must be located in the same folder as the kuma-installer file. You can get more information about kuma-installer by running it with the --help parameter.
• Before deploying the program, make sure that the servers where you intend to install the components meet the hardware and software requirements.
• KUMA components are addressed using the fully qualified domain name (FQDN) of the host. Before you install the program, you must ensure that the command hostnamectl status returns the true name of the host FQDN in the Static hostname field.
• It is recommended to use Network Time Protocol (NTP) to synchronize time between servers with KUMA services.

[Topic 217908]

Installing for demo

For demonstration purposes, you can deploy KUMA components on a single server. Prior to installing the program, carefully read the KUMA installation requirements as well as the hardware and system requirements.

The KUMA installation takes place over several stages:

1. Preparing the test machine

   The test machine is used during the program installation process: the installer files are unpacked and run on it.

2. Preparing the target machine

   The program components are installed on the target machines. The test machine can be used as a target one.

3. Preparing an inventory file for demonstration installation

   Create an inventory file describing the network structure of the program components that the installer can use to deploy KUMA.

4. Installing the program for demonstration purposes

   Install the program and get the URL and login credentials for the web interface.

If necessary, the program installed for demonstration purposes can be distributed to different servers for full-fledged operation.

[Topic 222158]

Preparing an inventory file for demonstration installation

Installation, update, and removal of KUMA components is performed from the folder containing the unpacked installer by using the Ansible tool and the user-created inventory file containing a list of the hosts of KUMA components and other parameters. In the case of a demonstration installation, the host will be the same for all components. The inventory file is in the YAML format.

To create an inventory file for a demonstration installation:

1. Go to the KUMA installer folder by executing the following command:

   cd kuma-ansible-installer

2. Create an inventory file by copying the single.inventory.yml.template:

   cp single.inventory.yml.template single.inventory.yml

3. Edit the inventory file parameters:
   • If you want demonstration services to be created during the installation, set the deploy_example_services parameter value to true.

     deploy_example_services: true

     Demonstration services can only be created during the initial installation of KUMA. When updating the system using the same inventory file, no demonstration services will be created.

   • If you are installing KUMA in a production environment and have a separate test machine, set the ansible_connection parameter to ssh:

     ansible_connection: ssh

4. Replace all kuma.example.com lines in the inventory file with the host of the target machine on which you want to install KUMA components.

The inventory file is created. You can install KUMA for demonstration purposes using it.

It is recommended that you not remove the inventory file after installing KUMA:

• If you change this file (for example, add information about a new server for the collector), you can reuse it to update the system with a new component.
• You can use this inventory file to delete KUMA.

[Topic 222159]

Installing the program for demonstration purposes

KUMA is installed using the Ansible tool and the YML inventory file. The installation is performed using the test machine, where all of the KUMA components are installed on the target machines.

To install KUMA for demonstration purposes:

1. On the test machine, open the folder containing the unpacked installer.
2. Place the file with the license key in the folder <installer folder>/roles/kuma/files/.

   The key file must be named license.key.

3. Launch the installer by executing the following command:

   sudo ./install.sh single.inventory.yml

4. Accept the terms of the End User License Agreement.

   If you do not accept the terms of the End User License Agreement, the program will not be installed.

KUMA components are installed on the target machine. The screen will display the URL of the KUMA web interface and the user name and password that must be used to access the web interface.

By default, the KUMA web interface address is https://kuma.example.com:7220.

Default login credentials (after the first login, you must change the password of the admin account):
- user name—admin
- password—mustB3Ch@ng3d!

It is recommended that you save the inventory file used to install the program. It can be used to add components to the system or remove KUMA.

You can later upgrade the demonstration installation to the full one.

[Topic 222160]

Upgrading the demonstration installation

You can upgrade the demonstration installation by installing the program over the installed KUMA using the distributed.inventory.yml template.

Several steps are required to upgrade the demonstration installation:

1. Installing the program

   Specify the host of the demonstration server and place it in the core group when preparing the inventory file.

2. Deleting the demonstration services

   In the KUMA web interface under Resources → Active services copy the IDs for the existing services and delete them.

   Then delete the services from the machine where they were installed by running the command sudo /opt/kaspersky/kuma/kuma <collector/correlator/storage> --id <service ID> --uninstall. Repeat the delete command for each service.

3. Rebuilding services on the right machines

[Topic 217917]

Installing KUMA in production environment

Prior to installing the program, carefully read the KUMA installation requirements as well as the hardware and system requirements. The KUMA installation takes place over several stages:

1. Configuring network access

   Make sure all the necessary ports are open to allow KUMA components to interact with each other based on your organization's security structure.

2. Preparing the test machine

   The test machine is used during the program installation process: the installer files are unpacked and run on it.

3. Preparing the target machines

   The program components are installed on the target machines.

4. Preparing the inventory file

   Create an inventory file describing the network structure of the program components that the installer can use to deploy KUMA.

5. Installing the program

   Install the program and get the URL and login credentials for the web interface.

6. Creating services

   Create services in the KUMA web interface and install them on the target machines intended for them.

[Topic 217770]

Configuring network access

For the program to run correctly, you need to ensure that the KUMA components are able to interact with other components and programs over the network via the protocols and ports specified during the installation of the KUMA components. The table below shows the default network ports values.

Network ports used so KUMA components can interact with each other

Page top

[Topic 222083]

Preparing the test machine

The test machine is used during the program installation process: the installer files are unpacked and run on it.

To prepare the test machine for the KUMA installation:

1. Install an operating system on the test machine and then install the necessary packages.
2. Configure the network interface.

   For convenience, you can use the graphical utility nmtui.

3. Configure the system time to synchronize with the NTP server:
   1. If the machine does not have direct Internet access, edit the /etc/chrony.conf file to replace 2.pool.ntp.org with the name or IP address of your organization's internal NTP server.
   2. Start the system time synchronization service by executing the following command:

      sudo systemctl enable --now chronyd

   3. Wait a few seconds and execute the following command:

      sudo timedatectl | grep 'System clock synchronized'

      If the system time is synchronized correctly, the output will contain the line "System clock synchronized: yes."

4. Generate an SSH key for authentication on the SSH servers of the target machines by executing the following command:

   sudo ssh-keygen -f /root/.ssh/id_rsa -N "" -C kuma-ansible-installer

5. Make sure the test machine has network access to all the target machines by host name and copy the SSH key to each of them by executing the following command:

   sudo ssh-copy-id -i /root/.ssh/id_rsa root@<host name of the test machine>

6. Copy the archive with the KUMA installer to the test machine and unpack it using the following command (about 2 GB of disk space is required):

   sudo tar -xpf kuma-ansible-installer-<version>.tar.gz

The test machine is ready for the KUMA installation.

[Topic 217955]

Preparing the target machine

The program components are installed on the target machines.

To prepare the target machine for the installation of KUMA components:

1. Install an operating system on the test machine and then install the necessary packages.
2. Configure the network interface.

   For convenience, you can use the graphical utility nmtui.

3. Configure the system time to synchronize with the NTP server:
   1. If the machine does not have direct Internet access, edit the /etc/chrony.conf file to replace 2.pool.ntp.org with the name or IP address of your organization's internal NTP server.
   2. Start the system time synchronization service by executing the following command:

      sudo systemctl enable --now chronyd

   3. Wait a few seconds and execute the following command:

      sudo timedatectl | grep 'System clock synchronized'

      If the system time is synchronized correctly, the output will contain the line "System clock synchronized: yes."

4. Specify the host name. It is highly recommended to use the FQDN. For example: kuma-1.mydomain.com.

   You should not change the KUMA host name after installation: this will make it impossible to verify the authenticity of certificates and will disrupt the network communication between the program components.

5. Register the target machine in your organization's DNS zone to allow host names to be translated to IP addresses.

   If your organization does not use a DNS server, you can use the /etc/hosts file for name resolution. The content of the files can be automatically generated for each target machine when installing KUMA.

6. Execute the following command and write down the result:

   hostname -f

   You will need this host name when installing KUMA. The test machine must be able to access the target machine using this name.

The target machine is ready for the installation of KUMA components.

The test machine can be used as a target one. To do so, prepare the test machine, then follow steps 4–6 in the instructions for preparing the target machine.

[Topic 222085]

Preparing the inventory file

Installation, update, and removal of KUMA components is performed from the folder containing the unpacked installer by using the Ansible tool and the user-created inventory file containing a list of the hosts of KUMA components and other parameters. The inventory file is in the YAML format.

To create an inventory file:

1. Go to the KUMA installer folder by executing the following command:

   cd kuma-ansible-installer

2. Create an inventory file by copying the distributed.inventory.yml.template:

   cp distributed.inventory.yml.template distributed.inventory.yml

3. Edit the inventory file parameters:
   • If you want demonstration services to be created during the installation, set the deploy_example_services parameter value to true.

     deploy_example_services: true

     Demonstration services can only be created during the initial installation of KUMA. When updating the system using the same inventory file, no demonstration services will be created.

   • If the machines are not registered in your organization's DNS zone, set the generate_etc_hosts parameter to true, and for each machine in the inventory, replace the ip (0.0.0.0) parameter values with the actual IP addresses.

     generate_etc_hosts: true

     When using this parameter, the installer will automatically add the IP addresses of the machines from the inventory file to the /etc/hosts files on the machines where KUMA components are installed.

   • If you are installing KUMA in a production environment and have a separate test machine, set the ansible_connection parameter to ssh:

     ansible_connection: ssh

4. In the inventory file, specify the host of the target machines on which KUMA components should be installed. If the machines are not registered in the DNS zone of your organization, replace the parameter values ip (0.0.0.0) with the actual IP addresses.

   The hosts are specified in the following sections of the inventory file:

   • core is the section for specifying the host and IP address of the target machine on which KUMA Core will be installed. You may only specify one host in this section.
   • collector is the section for specifying the host and IP address of the target machine on which the collector will be installed. You may specify one of more hosts in this section.
   • correlator is the section for specifying the host and IP address of the target machine on which the correlator will be installed. You may specify one of more hosts in this section.
   • storage is the section for specifying the hosts and IP addresses of the target machines on which storage components will be installed. You may specify one of more hosts in this section.

     Storage components: clusters, shards, replicas, and keepers.

     A cluster is a logical group of machines that possess all accumulated normalized KUMA events. It consists of one or more logical shards.

     A shard is a logical group of machines that possess a specific portion of all normalized events accumulated in the cluster. It consists of one or more replicas. Increasing the number of shards lets you do the following:

     • Accumulate more events by increasing the total number of servers and disk space.
     • Absorb a larger stream of events by distributing the load associated with an influx of new events.
     • Reduce the time taken to search for events by distributing search areas among multiple machines.

     A replica is a machine that is a member of the logical shard and possesses a copy of the data of this shard. If there are multiple replicas, there are multiple copies (data is replicated). Increasing the number of replicas lets you do the following:

     • Improve fault tolerance.
     • Distribute the total load related to data searches among multiple machines (although it's best to increase the number of shards for this purpose).

     A keeper is an optional role of a replica that involves the replica's participation in coordinating data replication throughout the entire cluster. There must be at least one replica with this role for the entire cluster. It is recommended to have 3 keeper replicas. The number of replicas involved in coordinating replication must be an odd number.

     Each machine in the storage section can have the following parameter combinations:

     • shard + replica + keeper
     • shard + replica
     • keeper

     If the shard and replica parameters are specified, the machine is a part of a cluster and helps accumulate and search for normalized KUMA events. If the keeper parameter is additionally specified, the machine also helps coordinate data replication at the cluster-wide level.

     If only keeper is specified, the machine will not accumulate normalized events, but it will participate in coordinating data replication at the cluster-wide level. The keeper parameter values must be unique.

     If several replicas are defined within the same shard, the value of the replica parameter must be unique within this shard.

The inventory file is created. It can be used to install KUMA.

It is recommended that you not remove the inventory file after installing KUMA:

• If you change this file (for example, add information about a new server for the collector), you can reuse it to update the system with a new component.
• You can use this inventory file to delete KUMA.

[Topic 217914]

Installing the program

KUMA is installed using the Ansible tool and the YML inventory file. The installation is performed using the test machine, where all of the KUMA components are installed on the target machines.

To install KUMA:

1. On the test machine, open the folder containing the unpacked installer.
2. Place the file with the license key in the folder <installer folder>/roles/kuma/files/.

   The key file must be named license.key.

3. Launch the installer by executing the following command:

   sudo ./install.sh distributed.inventory.yml

4. Accept the terms of the End User License Agreement.

   If you do not accept the terms of the End User License Agreement, the program will not be installed.

KUMA components are installed on the target machines. The screen will display the URL of the KUMA web interface and the user name and password that must be used to access the web interface.

By default, the KUMA web interface address is https://kuma.example.com:7220.

Default login credentials (after the first login, you must change the password of the admin account):
- user name—admin
- password—mustB3Ch@ng3d!

It is recommended that you save the inventory file used to install the program. It can be used to add components to the system or remove KUMA.

[Topic 217903]

Creating services

KUMA services should be installed only after KUMA deployment is complete. The services can be installed in any order.

When deploying several KUMA services on the same host, you must specify unique ports for each service using the --api.port <port> parameters during installation.

Below is a list of the sections describing how specific services are created:

• Creating a storage
• Creating a correlator
• Creating a collector
• Creating KUMA agents

[Topic 217747]

Changing CA certificate

After KUMA Core is installed, a unique self-signed CA certificate with the matching key is generated. This CA certificate is used to sign all other certificates for internal communication between KUMA components and REST API requests. The CA certificate is stored on the KUMA Core server in the /opt/kaspersky/kuma/core/certificates/ folder.

You can use your company's certificate and key instead of self-signed KUMA CA certificate and key.

Before changing KUMA certificate, make sure to make a backup copy of the previous certificate and key with the names backup_external.cert and backup_external.key.

To change KUMA certificate:

1. Rename your company's certificate and key files to external.cert and external.key.

   Keys must be in PEM format.

2. Place external.cert and external.key to the /opt/kaspersky/kuma/core/certificates/ folder.
3. Restart the kuma-core service by running the sudo systemctl restart kuma-core command.
4. Restart the browser hosting the KUMA web interface.

You company's certificate and key are now used for internal communication between KUMA components and REST API requests.

[Topic 217962]

Delete KUMA

To remove KUMA, use the Ansible tool and the user-generated inventory file.

To remove KUMA:

1. On the test machine, go to the installer folder:

   cd kuma-ansible-installer

2. Execute the following command:

   sudo ./uninstall.sh <inventory file>

KUMA and all of the program data will be removed from the server.

The databases that were used by KUMA (for example, the ClickHouse storage database) and the information they contain must be deleted separately.

[Topic 222156]

Updating previous versions of KUMA

You can install KUMA 1.6.x over versions 1.5.x. To do this, follow the instructions for installing the program in a production environment, and when you reach the stage of preparing the inventory file list the hosts of the already deployed KUMA system in it.

After updating KUMA to version 1.6, event filtering that uses an SQL query containing the inSubnet condition may result in error Code: 441. DB::Exception: Invalid IPv4 value. If this is the case, you must add the directive <cast_ipv4_ipv6_default_on_conversion_error>true</cast_ipv4_ipv6_default_on_conversion_error> in the profiles → default section of the file /opt/kaspersky/kuma/clickhouse/cfg/config.d/users.xml on the storage servers (on each machine of the ClickHouse cluster).

[Topic 217959]

Program licensing

This section covers the main aspects of program licensing.

[Topic 222243]

About the End User License Agreement

The End User License agreement is a legal agreement between you and AO Kaspersky Lab that specifies the conditions under which you can use the program.

Read the terms of the End User License Agreement carefully before using the program for the first time.

You can familiarize yourself with the terms of the End User License Agreement in the following ways:

• During the installation of KUMA.
• By reading the LICENSE document. This document is included in the distribution kit and is located inside the installer in the /kuma-ansible-installer/roles/kuma/files/ folder.

  After the program is deployed, the document is available in the /opt/kaspersky/kuma/LICENSE folder.

You accept the terms of the End User License Agreement by confirming your acceptance of the End User License Agreement during the program installation. If you do not accept the terms of the End User License Agreement, you must cease the installation of the program and must not use the program.

Page top

[Topic 233460]

About the license

A License is a time-limited right to use the program, granted under the terms of the End User License Agreement.

A license entitles you to the following kinds of services:

• Use of the program in accordance with the terms of the End User License Agreement
• Getting technical support

The scope of services and the duration of usage depend on the type of license under which the program was activated.

A license is provided when the program is purchased. When the license expires, the program continues to work but with limited functionality (for example, new resources cannot be created). To continue using KUMA with its full functionality, you need to renew your license.

We recommend that you renew your license no later than its expiration date to ensure maximum protection against cyberthreats.

[Topic 233471]

About the License Certificate

A License Certificate Is a document that is provided to you along with a key file or activation code.

The License Certificate contains the following information about the license being granted:

• License key or order number
• Information about the user who is granted the license
• Information about the program that can be activated under the provided license
• Restriction on the number of licensing units (for example, the number of events that can be processed per second)
• Start date of the license term
• License expiration date or license term
• License type

Page top

[Topic 233462]

About the license key

A license key is a sequence of bits that you can apply to activate and then use the program in accordance with the terms of the End User License Agreement. License keys are generated by Kaspersky specialists.

You can add a license key to the program by applying a key file. The license key is displayed in the program interface as a unique alphanumeric sequence after you add it to the program.

The license key may be blocked by Kaspersky in case the terms of the License Agreement have been violated. If the license key has been blocked, you need to add another one if you want to use the program.

A license key may be active or reserve.

An active license key is the license key currently used by the program. An active license key can be added for a trial or commercial license. The program cannot have more than one active license key.

A reserve license key is the license key that entitles the user to use the program but is not currently in use. The additional license key automatically becomes active when the license associated with the current active license key expires. An additional license key can be added only if an active license key has already been added.

A license key for a trial license can be added as an active license key. A license key for a trial license cannot be added as an additional license key.

Page top

[Topic 233467]

About the key file

The key file is a file named license.key provided to you by Kaspersky. The key file is used to add a license key that activates the program.

You receive a key file at the email address that you provided after purchasing KUMA.

You do not need to connect to Kaspersky activation servers in order to activate the program with a key file.

If the key file has been accidentally deleted, you can restore it. You may need a key file, for example, to register with Kaspersky CompanyAccount.

To restore the key file, you need to do one of the following:

• Contact the license seller.
• Get the key file on the Kaspersky Lab website based on the available activation code.

Page top

[Topic 217709]

Adding a license key to the program web interface

You can add an application license key in the KUMA web interface.

Only users with the Administrator role can add a license key.

To add a license key to the KUMA web interface:

1. Open the KUMA web interface and select Settings → License.

   The window with KUMA license conditions opens.

2. Select the key you want to add:
   • If you want to add the active key, click the Add active license key button.

     This button is not displayed if a license key has already been added to the program. If you want to add an active license key instead of the key that has already been added, the current license key must be deleted.

   • If you want to add the reserve key, click the Add reserve license key button.

     This button is inactive until an active key is added. If you want to add a reserve license key instead of the key that has already been added, the current reserve license key must be deleted.

   The license key file selection window appears on the screen.

3. Select a license file by specifying the path to the folder and the name of the license key file with the KEY extension.

The license key from the selected file will be loaded into the program. Information about the license key is displayed under Settings → License.

[Topic 218040]

Viewing information about an added license key in the program web interface

In the KUMA web interface, you can view information about the added license key. Information about the license key is displayed under Settings → License.

Only users with the Administrator role can view license information.

The License tab window displays the following information about added license keys:

• Expires on—date when the license key expires.
• Days remaining—number of days before the license is expired.
• EPS available—number of events processed per second supported by the license.
• EPS current—current average number of events per second processed by KUMA.
• License key—unique alphanumeric sequence.
• Company—name of the company that purchased the license.
• Client name—name of client who purchased the license.
• Modules—modules available for the license.

[Topic 217963]

Removing a license key in the program web interface

In KUMA, you can remove an added license key from the program (for example, if you need to replace the current license key with a different key). After the license key is removed, the program stops to receive and process events. This functionality will be re-activated the next time you add a license key.

Only users with the administrator role can delete license keys.

To delete an added license key:

1. Open the KUMA web interface and select Settings → License.

   The window with KUMA license conditions opens.

2. Click the icon on the license that you want to delete.

   A confirmation window opens.

3. Confirm deletion of the license key.

The license key will be removed from the program.

[Topic 217927]

Integration with other solutions

In this section, you'll learn how to integrate KUMA with other solutions to enrich its functionality.

[Topic 217923]

Integration with Kaspersky Security Center

Kaspersky Security Center is designed for centralized execution of basic administration and maintenance tasks in an organization's network and provides the administrator access to detailed information about the organization's network security level. KUMA can be integrated with Kaspersky Security Center to receive information about assets. You can also use correlators to send commands to KUMA to create asset-related tasks.

Kaspersky Security Center tasks are functions performed by this program, such as Full computer scan and Database update. For more information about Kaspersky Security Center tasks, please refer to the Kaspersky Security Center Online Help Guide.

[Topic 217952]

Preparing Kaspersky Security Center for integration with KUMA

For Kaspersky Security Center and KUMA to be able to interact with each other you must complete steps below:

• Make sure that Kaspersky Security Center can be reached via UDP from KUMA.
• Create user in Kaspersky Security Center with required permissions.
• Create Kaspersky Security Center tasks covering all assets in all applications connected to Kaspersky Security Center.
• Configure Kaspersky Security Center to send events to KUMA. This step is required if you want to receive information about Kaspersky Security Center tasks in KUMA.

[Topic 217790]

Creating KUMA user in Kaspersky Security Center

To create a user in Kaspersky Security Center for KUMA integration:

1. In the Kaspersky Security Center Administration Console, select the node with the name of the required Administration Server.
2. In the context menu of the Administration Server, select Properties.
3. In the Administration Server properties window, select the Security section.
4. In the Names of groups or users field, click the Internal user button.

   User selection window opens.

5. Click the Add user button and add the user.

   Only the user name and password are required. When the user is created, it will be appear in the User selection window.

6. Select the user you created and click OK.

   The user will be displayed in the Names of groups or users field.

7. Select the user and in the Rights tab of Permissions for web section of the workspace and configure KUMA user rights:
   • Receiving information about assets from Kaspersky Security Center: select the Allow check box in the Basic functionality node next to Read permissions.
   • Starting Kaspersky Endpoint Security tasks for Linux: check the Allow check boxes in the Basic functionality node next to Read and Modify permissions.
   • Starting scan tasks in Kaspersky Endpoint Security for Windows: check the Allow check boxes in the Basic Functionality and Protection Components nodes next to Read and Modify permissions.
   • Starting update tasks in Kaspersky Endpoint Security for Windows: check the Allow check boxes in the Basic functionality and Protection components nodes next to Read and Modify permissions.
8. Click OK.

KUMA user is added to Kaspersky Security Center. It can now be used to create a Kaspersky Security Center connection.

[Topic 217767]

Configuring Kaspersky Security Center to send events to KUMA

If you want to be able to see task related information from Kaspersky Security Center in KUMA, you must configure exporting Kaspersky Security Center events using the CEF format and select event types that must be exported from Kaspersky Security Center.

To export Kaspersky Security Center events to KUMA:

1. In the Kaspersky Security Center console tree, select the Administration Server whose events you want to export.
2. In the workspace of the selected Administration Server, click the Events tab.
3. Click the drop-down arrow next to the Configure notifications and event export link and select Configure export to SIEM system in the drop-down list.
4. The events properties window opens, displaying the Event export section.
5. In the Event export section, specify the following export settings:
   1. Select the Automatically export events to SIEM system database check box.
   2. In the SIEM system drop-down list select ArcSight (CEF format).
   3. In the SIEM system server address field, enter the web address of the KUMA collector server that will be used to receive events from Kaspersky Security Center.
   4. In the SIEM system server port field, enter the port where the KUMA collector server will expect Kaspersky Security Center events.
   5. In the Protocol drop-down list select TCP/IP.
6. Click OK.

Automatic export of Kaspersky Security Center events will be enabled. For more information about exporting events from Kaspersky Security Center to SIEM systems, please refer to the Kaspersky Security Center Online Help Guide.

To select event types for export for each Kaspersky Security Center policy you need:

1. In the console tree of Kaspersky Security Center, select the Policies node.
2. Right-click to open the context menu of the relevant policy and select Properties.
3. In the policy properties window that opens, select the Event configuration section.
4. In the Info tab select the Task started and Task completed event types and click the Properties button.
5. In the event properties window that appears, select the Export to SIEM system using Syslog check box to enable export for the selected events.
6. Click OK to save the changes.
7. In the policy properties window, click OK.

The selected events will be sent to the KUMA over the Syslog protocol. For more information about exporting events from Kaspersky Security Center using the Syslog protocol, please refer to the Kaspersky Security Center Online Help Guide.

You must configure KUMA Collector to be able to receive Kaspersky Security Center events. Events from Kaspersky Security Center have DeviceProduct = SecurityCenter field value, which can be used to search them in KUMA.

Example collector for receiving Kaspersky Security Center events is included to KUMA installation package. It is named [Example] KSC. It consists of the connector that listens for TCP port 5141 and, more importantly, of the normalizer [Example] KSC that can you can use to process Kaspersky Security Center events in your own collectors.

[Topic 217789]

Creating KUMA tasks in Kaspersky Security Center

If you want to start asset-related tasks in Kaspersky Security Center from KUMA, you must create these tasks in Kaspersky Security Center beforehand.

You must create separate tasks for each Kaspersky program that is not compatible with other. For example, create separate tasks for Linux and Windows products or, if you have Kaspersky Endpoint Security for Windows both version 10 and 11, create separate tasks for each of them. For compatible products create tasks for the latest version.

If you have several hierarchically linked Kaspersky Security Center Administration Servers, you should create tasks on the main Administration Server only. Otherwise create tasks on every secondary Kaspersky Security Center Administration Server.

To create Kaspersky Security Center task:

1. In the Kaspersky Security Center console tree, select the administration group for which you want to create a task.
2. In the group workspace, select the Tasks tab.
3. Run the task creation by clicking the Create a task button.

   The New Task Wizard starts.

4. Follow the instructions of the Wizard to create the required task.

   The name of the task must begin with "KUMA ". For example, "KUMA asset virus scan".

Created task will be displayed in the Tasks section of Kaspersky Security Center console tree. These task can be started from KUMA.

[Topic 217933]

Managing Kaspersky Security Center connections

This section describes working with Kaspersky Security Center connections that are required for integrating Kaspersky Security Center and KUMA.

Connections to Kaspersky Security Center are created and managed in the Settings section of the KUMA web interface in the Settings → Kaspersky Security Center tab. The right side of the Settings window of KUMA web interface displays a list of tenants for which Kaspersky Security Center connections are configured. Clicking on a tenant opens a Kaspersky Security Center connections window containing a list of created connections to Kaspersky Security Center. When you click on a connection, a detail pane opens with the parameters of the selected connection. You can create multiple Kaspersky Security Center connections.

To enable or disable integration with Kaspersky Security Center:

1. Open the KUMA web interface and select Settings → Kaspersky Security Center.

   The Connections to Kaspersky Security Center table will appear on the right in the Settings section.

2. Select the tenant for which you want to enable or disable integration with Kaspersky Security Center.

   The Kaspersky Security Center connection table will appear on the right in the Settings section.

3. Enable or disable integration with Kaspersky Security Center:
   • Clear the Disabled check box if you want KUMA to receive information about Kaspersky Security Center assets and send commands to Kaspersky Security Center.
   • Select the Disabled check box if you do not want KUMA to receive information about Kaspersky Security Center assets and send commands to Kaspersky Security Center.

     By default, this check box is cleared.

4. Click Save.

[Topic 217788]

Creating Kaspersky Security Center connection

To create a new Kaspersky Security Center connection:

1. Open the KUMA web interface and select Settings → Kaspersky Security Center.

   The Connections to Kaspersky Security Center table will appear on the right in the Settings section.

2. Select the tenant for which you want to create a connection to Kaspersky Security Center.

   The Kaspersky Security Center connection table will appear on the right in the Settings section.

3. Click the Add KSC connection button and set the parameters as described below:
   • Name (required)—enter the unique name of the Kaspersky Security Center connection. Must contain from 1 to 128 Unicode characters.
   • URL (required)—enter the URL of the Kaspersky Security Center server in the hostname:port or IPv4:port format.
   • Disabled—clear this check box if you want to use this Kaspersky Security Center connection. By default, this check box is cleared.
4. In the Secret drop-down list select the Secret resource with the credentials of the Kaspersky Security Center you need or create a new Secret resource using the plus button.

   Creating resource with Kaspersky Security Center credentials

   Credentials for the Kaspersky Security Center server are stored in the Secret resources.

   To create the Secret resource with Kaspersky Security Center server credentials:

   1. In the Resources section of the KUMA web interface, select Secrets.

      The list of available secrets will be displayed.

   2. On the left in the Secrets window select the tenant in which the connection to Kaspersky Security Center with these credentials will be used.
   3. If required, select the folder where you want to create the secret.
   4. Click the Add secret button to create a new secret. This resource is used to store credentials of the Kaspersky Security Center server.

      The secret window is displayed.

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

      The Kaspersky Security Center server credentials are now saved and can be used in other KUMA resources.

5. Click Save.

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

[Topic 217849]

Editing Kaspersky Security Center connection

To edit a Kaspersky Security Center connection:

1. Open the KUMA web interface and select Settings → Kaspersky Security Center.

   The Connections to Kaspersky Security Center window opens.

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

   The Kaspersky Security Center connection window opens.

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

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

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

The Kaspersky Security Center connection will be changed.

[Topic 217829]

Deleting Kaspersky Security Center connection

To delete a Kaspersky Security Center connection:

1. Open the KUMA web interface and select Settings → Kaspersky Security Center.

   The Connections to Kaspersky Security Center window opens.

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

   The Kaspersky Security Center connection window opens.

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

The Kaspersky Security Center connection will be deleted.

[Topic 218045]

Working with Kaspersky Security Center tasks

After importing information about Kaspersky Security Center assets, you can use tasks to manage these assets. Tasks are started in the KUMA web interface. You can start tasks manually from the Assets section of the program web interface or automatically during the correlation process by using response rules.

For more details on Kaspersky Security Center tasks, please refer to the Kaspersky Security Center Help Guide.

In the KUMA web interface, you can start only those Kaspersky Security Center tasks whose names begin with <kuma> (not case sensitive).

[Topic 218009]

Starting Kaspersky Security Center tasks manually

To manually start a Kaspersky Security Center task:

1. In the Assets section of the KUMA web interface, select the assets that were imported from Kaspersky Security Center.

   The Asset details window opens.

2. Click the KSC response button.

   This button is displayed if the connection to the Kaspersky Security Center that owns the selected asset is enabled.

3. In the opened Select task window, select the check boxes next to the tasks that you want to start, and click the Start button.

Kaspersky Security Center starts the selected tasks.

Some types of tasks are available only for certain assets.

You can obtain vulnerability and software information only for assets running a Windows operating system.

[Topic 218008]

Starting Kaspersky Security Center tasks automatically

Kaspersky Security Center tasks can be started automatically by Correlators. When certain conditions are met, the correlator activates response rules that contain the list of Kaspersky Security Center tasks to start and identify the relevant assets.

To configure Response resource that can be used by Correlators to start Kaspersky Security Center task automatically:

1. In the KUMA web interface, select Resources → Response.
2. Click the Add response button and set parameters as described below:
   • In the Name field enter the resource name that will let you identify it.
   • In the Type drop-down list, select ksctasks (Kaspersky Security Center tasks).
   • In the Kaspersky Security Center task drop-down list, select the tasks that must be run when the correlator linked to this response resource is triggered.

     You can select several tasks. When a response is activated, it picks only the first task from the list of the selected tasks that match the relevant asset. The rest of the matching tasks are disregarded. If you want to start multiple tasks based on one condition, you need to create multiple response rules.

   • Under Event field, select the event fields that will trigger the correlators. Possible values:
     • SourceAssetID
     • DestinationAssetID
     • DeviceAssetID
3. If necessary, in the Workers field specify the number of response processes that can be run simultaneously.
4. If necessary, use the Filter settings block to specify the conditions under which events will be processed by the created resource. You can select an existing filter resource from the drop-down list or create a new filter.

   Creating a filter in resources

   1. In the Filter drop-down list, select Create new.
   2. If you want to keep the filter as a separate resource, set the Save filter toggle switch.

      In this case, you will be able to use the created filter in various 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 settings block, specify the conditions that the events must meet:
      1. Click the Add condition button.
      2. In the Left operand and Right operand drop-down lists, specify the search parameters.

         Depending on the data source selected in the Right operand field, you may see fields of additional parameters that you need to use to define the value that will be passed to the filter. For example, when choosing active list you will need to specify the name of the active list, the entry key, and the entry key field.

      3. In the operator drop-down list, select the relevant operator.

         Filter operators

         • = – the left operand equals the right operand.
         • <—the left operand is less than the right operand.
         • <=—the left operand is less than or equal to the right operand.
         • >—the left operand is greater than the right operand.
         • >=—the left operand is greater than or equal to the right operand.
         • inSubnet—the left operand (IP address) is in the subnet of the right operand (subnet).
         • contains—the left operand contains values of the right operand.
         • startsWith—the left operand starts with one of the values of the right operand.
         • endsWith—the left operand ends with one of the values of the right operand.
         • match—the left operand matches the regular expression of the right operand. The RE2 regular expressions are used.
         • inActiveList—this operator has only one operand. Its values are selected in the Key fields field and are compared with the entries in the active list selected from the Active List drop-down list.
         • inCategory—the asset in the left operand is assigned at least one of the asset categories of the right operand.
         • inActiveDirectoryGroup—the Active Directory account in the left operand belongs to one of the Active Directory groups in the right operand.
         • TIDetect—this operator is used to find events using CyberTrace Threat Intelligence (TI) data. This operator can be used only on events that have completed enrichment with data from CyberTrace Threat Intelligence. In other words, it can only be used in collectors at the destination selection stage and in correlators.
      4. If necessary, select the do not match case check box. When this check box is selected, the operator ignores the case of the values.

         The selection of this check box does not apply to the InSubnet, InActiveList, InCategory or InActiveDirectoryGroup operators.

         This check box is cleared by default.

      5. If you want to add a negative condition, select If not from the If drop-down list.
      6. You can add multiple conditions or a group of conditions.
   5. If you have added multiple conditions or groups of conditions, choose a search condition (and, or, not) by clicking the AND button.
   6. If you want to add existing filters that are selected from the Select filter drop-down list, click the Add filter button.

      You can view the nested filter settings by clicking the button.

5. Click Save.

The Response resource is created. It can now be linked to a Correlator that would trigger it, starting a Kaspersky Security Center task as a result.

[Topic 217753]

Checking the status of Kaspersky Security Center tasks

In the KUMA web interface, you can check whether a Kaspersky Security Center task was started or whether a search for events owned by the collector listening for Kaspersky Security Center events was completed.

To check the status of Kaspersky Security Center tasks:

1. In KUMA, select Resources → Active services.
2. Select the collector that is configured to receive events from the Kaspersky Security Center server and click the Go to Events button.

A new browser tab will open in the Events section of KUMA. The table displays events from the Kaspersky Security Center server. The status of the tasks can be seen in the Name column.

Kaspersky Security Center event fields:

• Name—status or type of the task.
• Message—message about the task or event.
• FlexString<number>Label—name of the attribute received from Kaspersky Security Center. For example, FlexString1Label=TaskName.
• FlexString<number>—value of the FlexString<number>Label attribute. For example, FlexString1=Download updates.
• DeviceCustomNumber<number>Label—name of the attribute related to the task state. For example, DeviceCustomNumber1Label=TaskOldState.
• DeviceCustomNumber<number>—value related to the task state. For example, DeviceCustomNumber1=1 means the task is executing.
• DeviceCustomString<number>Label—name of the attribute related to the detected vulnerability: for example, a virus name, affected application.
• DeviceCustomString<number>—value related to the detected vulnerability. For example, the attribute-value pairs DeviceCustomString1Label=VirusName and DeviceCustomString1=EICAR-Test-File mean that the EICAR test virus was detected.

[Topic 222247]

Importing events from the Kaspersky Security Center database

In KUMA, you can receive events directly from the Kaspersky Security Center SQL database. Events are received by using a collector, which utilizes the provided resources of the connector [Example] KSC SQL and normalizer [Example] KSC from SQL.

To create a collector to receive Kaspersky Security Center events:

1. Start the Collector Installation Wizard in one of the following ways:
   • In the KUMA web interface, in the Resources section, click Add event source.
   • In the KUMA web interface in the Resources → Collectors section click Add collector.
2. At step 2 of the Installation Wizard, select the [Example] KSC SQL connector:
   • In the URL field, specify the server connection string in the following format:

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

     where:

     • user—user account with public and db_datareader rights to the required database.
     • password—user account password.
     • kscdb.example.com:1433—address and port of the database server.
     • KAV—name of the database.
   • In the Query field, specify a database query based on the need to receive certain events.

     An example of a query to the Kaspersky Security Center SQL database

     SELECT ev.event_id AS externalId, ev.severity AS severity, ev.task_display_name AS taskDisplayName,

             ev.product_name AS product_name, ev.product_version AS product_version,

              ev.event_type As deviceEventClassId, ev.event_type_display_name As event_subcode, ev.descr As msg,

     CASE

             WHEN ev.rise_time is not NULL THEN DATEADD(hour,DATEDIFF(hour,GETUTCDATE(),GETDATE()),ev.rise_time )

                 ELSE ev.rise_time

             END

         AS endTime,

         CASE

             WHEN ev.registration_time is not NULL

                 THEN DATEADD(hour,DATEDIFF(hour,GETUTCDATE(),GETDATE()),ev.registration_time )

                 ELSE ev.registration_time

             END

         AS kscRegistrationTime,

         cast(ev.par7 as varchar(4000)) as sourceUserName,

         hs.wstrWinName as dHost,

         hs.wstrWinDomain as strNtDom, serv.wstrWinName As kscName,

             CAST(hs.nIp / 256 / 256 / 256 % 256 AS VARCHAR) + '.' +

         CAST(hs.nIp / 256 / 256 % 256 AS VARCHAR) + '.' +

         CAST(hs.nIp / 256 % 256 AS VARCHAR) + '.' +

         CAST(hs.nIp % 256 AS VARCHAR) AS sourceAddress,

         serv.wstrWinDomain as kscNtDomain,

             CAST(serv.nIp / 256 / 256 / 256 % 256 AS VARCHAR) + '.' +

         CAST(serv.nIp / 256 / 256 % 256 AS VARCHAR) + '.' +

         CAST(serv.nIp / 256 % 256 AS VARCHAR) + '.' +

         CAST(serv.nIp % 256 AS VARCHAR) AS kscIP,

         CASE

         WHEN virus.tmVirusFoundTime is not NULL

                 THEN DATEADD(hour,DATEDIFF(hour,GETUTCDATE(),GETDATE()),virus.tmVirusFoundTime )

                 ELSE ev.registration_time

             END

         AS virusTime,

         virus.wstrObject As filePath,

         virus.wstrVirusName as virusName,

         virus.result_ev as result

     FROM KAV.dbo.ev_event as ev

     LEFT JOIN KAV.dbo.v_akpub_host as hs ON ev.nHostId = hs.nId

     INNER JOIN KAV.dbo.v_akpub_host As serv ON serv.nId = 1

     Left Join KAV.dbo.rpt_viract_index as Virus on ev.event_id = virus.nEventVirus

     where registration_time >= DATEADD(minute, -191, GetDate())

3. At step 3 of the Installation Wizard, select the [Example] KSC from SQL normalizer.
4. Specify other parameters in accordance with your collector requirements.

Upon completion of the Wizard, a collector service is created in the KUMA web interface. You can use this collector service to import events from the SQL database of Kaspersky Security Center.

[Topic 217924]

Integration with Kaspersky CyberTrace

Kaspersky CyberTrace (hereinafter CyberTrace) is a tool that integrates threat data streams with SIEM solutions. It provides users with instant access to analytics data, increasing their awareness of security decisions.

You can integrate CyberTrace with KUMA in one of the following ways:

• Integrate CyberTrace indicator search feature to enrich KUMA events with information from CyberTrace data streams.
• Integrate the entire CyberTrace web interface into KUMA to get full access to CyberTrace.

  CyberTrace web interface integration is available only if your CyberTrace license includes multi-user feature.

[Topic 217921]

Integrating CyberTrace indicator search

Integration of the CyberTrace indicator search function includes the following steps:

1. Configuring CyberTrace to receive and process KUMA requests.

   You can configure the integration with KUMA immediately after installing CyberTrace in the Quick Start Wizard or later in the CyberTrace web interface.

2. Creating an event enrichment rule in KUMA.

After completing all stages of integration, you need to restart the collector responsible for receiving events that you want to enrich with information from CyberTrace.

[Topic 217768]

Configuring the CyberTrace to receive and process requests.

You can configure CyberTrace to receive and process requests from KUMA immediately after its installation in the Quick Start Wizard or later in the program web interface.

To configure CyberTrace to receive and process requests in the Quick Start Wizard:

1. Wait for the CyberTrace Quick Start Wizard to start after the program is installed.

   The Welcome to Kaspersky CyberTrace window opens.

2. In the <select SIEM> drop-down list, select the type of SIEM system from which you want to receive data and click the Next button.

   The Connection Settings window opens.

3. Do the following:
   1. In the Service listens on settings block, select the IP and port option.
   2. In the IP address field, enter 0.0.0.0.
   3. In the Port field, enter 9999.
   4. In the IP address or hostname field below, specify 127.0.0.1.

      Leave the default values for everything else.

   5. Click Next.

   The Proxy Settings window opens.

4. If a proxy server is being used in your organization, define the settings for connecting to it. If not, leave all the fields blank and click Next.

   The Licensing Settings window opens.

5. In the Kaspersky CyberTrace license key field, add a license key for CyberTrace.
6. In the Kaspersky Threat Data Feeds certificate field, add a certificate that allows you to download updated data feeds from servers, and click Next.

CyberTrace will be configured.

To configure CyberTrace to receive and process requests in the program web interface:

1. In the CyberTrace web interface window, select Settings – Service.
2. In the Connection Settings block:
   1. Select the IP and port option.
   2. In the IP address field, enter 0.0.0.0.
   3. In the Port field, enter 9999.
3. In the Web interface settings block, in the IP address or hostname field, enter 127.0.0.1.
4. In the upper toolbar, click Restart Feed Service.
5. Select Settings – Events format.
6. In the Alert events format field, enter %Date% alert=%Alert%%RecordContext%.
7. In the Detection events format field, enter Category=%Category%|MatchedIndicator=%MatchedIndicator%%RecordContext%.
8. In the Records context format field, enter |%ParamName%=%ParamValue%.
9. In the Actionable fields context format field, enter %ParamName%:%ParamValue%.

CyberTrace will be configured.

After updating CyberTrace configuration you have to restart the CyberTrace server.

[Topic 217808]

Creating event Enrichment rules

To create event enrichment rules:

1. In the KUMA web interface, open Resources → Enrichment rules. In the left part of the window, select or create a folder for the new resource.

   The list of available enrichment rules will be displayed.

2. Click the Add enrichment rule button to create a new resource.

   The enrichment rule window will be displayed.

3. Enter the rule configuration parameters:
   1. In the Name field, enter a unique name for this type of resource. The name must contain from 1 to 128 Unicode characters.
   2. In the Tenant drop-down list, select the tenant that will own this resource.
   3. In the Source kind drop-down list, select cybertrace.
   4. Specify the URL of the CyberTrace server to which you want to connect. For example, example.domain.com:9999.
   5. If necessary, use the Number of connections field to specify the maximum number of connections to the CyberTrace server that can be simultaneously established by KUMA. By default, this value is equal to the number of vCPUs of the KUMA Core server.
   6. In the RPS field, enter the number of requests to the CyberTrace server per second that KUMA can make. The default value is 1000.
   7. In the Timeout field, specify the maximum number of seconds KUMA should wait for a response from the CyberTrace server. Until a response is received or the time expires, the event is not sent to the Correlator. If a response is received before the timeout, it is added to the TI field of the event and the event processing continues. The default value is 30.
   8. In the Mapping settings block, you must specify the fields of events to be checked via CyberTrace, and define the rules for mapping fields of KUMA events to CyberTrace indicator types:
      • In the KUMA field column, select the field whose value must be sent to CyberTrace.
      • In the CyberTrace indicator column, select the CyberTrace indicator type for every field you selected:
        • ip
        • url
        • hash

      You must provide at least one string to the table. You can use the Add row button to add a string, and can use the button to remove a string.

   9. Use the Debug drop-down list to indicate whether or not to enable logging of service operations. Logging is disabled by default.
   10. If necessary, in the Description field, add up to 256 Unicode characters describing the resource.
   11. In the Filter section, you can specify conditions to identify events that will be processed by the enrichment 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 list, select Create new.
       2. If you want to keep the filter as a separate resource, set the Save filter toggle switch.

          In this case, you will be able to use the created filter in various 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 settings block, specify the conditions that the events must meet:
          1. Click the Add condition button.
          2. In the Left operand and Right operand drop-down lists, specify the search parameters.

             Depending on the data source selected in the Right operand field, you may see fields of additional parameters that you need to use to define the value that will be passed to the filter. For example, when choosing active list you will need to specify the name of the active list, the entry key, and the entry key field.

          3. In the operator drop-down list, select the relevant operator.

             Filter operators

             • = – the left operand equals the right operand.
             • <—the left operand is less than the right operand.
             • <=—the left operand is less than or equal to the right operand.
             • >—the left operand is greater than the right operand.
             • >=—the left operand is greater than or equal to the right operand.
             • inSubnet—the left operand (IP address) is in the subnet of the right operand (subnet).
             • contains—the left operand contains values of the right operand.
             • startsWith—the left operand starts with one of the values of the right operand.
             • endsWith—the left operand ends with one of the values of the right operand.
             • match—the left operand matches the regular expression of the right operand. The RE2 regular expressions are used.
             • inActiveList—this operator has only one operand. Its values are selected in the Key fields field and are compared with the entries in the active list selected from the Active List drop-down list.
             • inCategory—the asset in the left operand is assigned at least one of the asset categories of the right operand.
             • inActiveDirectoryGroup—the Active Directory account in the left operand belongs to one of the Active Directory groups in the right operand.
             • TIDetect—this operator is used to find events using CyberTrace Threat Intelligence (TI) data. This operator can be used only on events that have completed enrichment with data from CyberTrace Threat Intelligence. In other words, it can only be used in collectors at the destination selection stage and in correlators.
          4. If necessary, select the do not match case check box. When this check box is selected, the operator ignores the case of the values.

             The selection of this check box does not apply to the InSubnet, InActiveList, InCategory or InActiveDirectoryGroup operators.

             This check box is cleared by default.

          5. If you want to add a negative condition, select If not from the If drop-down list.
          6. You can add multiple conditions or a group of conditions.
       5. If you have added multiple conditions or groups of conditions, choose a search condition (and, or, not) by clicking the AND button.
       6. If you want to add existing filters that are selected from the Select filter drop-down list, click the Add filter button.

          You can view the nested filter settings by clicking the button.

4. Click Save.

A new enrichment rule will be created.

CyberTrace indicator search integration is now configured. You can now add the created enrichment rule to a collector. You must restart KUMA collectors to apply the new settings.

If any of the CyberTrace fields in the events details area contains "[{" or "}]" values, it means that information from CyberTrace data feed was processed incorrectly and it's possible that some of the data is not displayed. You can get all data feed information by copying the events TI indicator field value from KUMA and searching for it in the CyberTrace in the indicators section. All relevant information will be displayed in the Indicator context section of CyberTrace.

[Topic 217922]

Integrating CyberTrace interface

You can integrate the CyberTrace web interface into the KUMA web interface. When this integration is enabled, the KUMA web interface will show a CyberTrace section that provides access to the CyberTrace web interface. Integration is configured under Settings → Kaspersky CyberTrace in the KUMA web interface.

To integrate the CyberTrace web interface in KUMA:

1. In the KUMA web interface, open Resources → Secrets.

   The list of available secrets will be displayed.

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

   The secret window is displayed.

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

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

5. In the KUMA web interface, open Settings → Kaspersky CyberTrace.

   The window with CyberTrace integration parameters opens.

6. Make the necessary changes to the following parameters:
   • Disabled—clear this check box if you want to integrate the CyberTrace web interface into the KUMA web interface.
   • Host (required)—enter the URL of the CyberTrace server in hostname:port format.
   • Port (required)—enter the port of the CyberTrace server.
7. In the Secret drop-down list select the Secret resource you created before.
8. Click Save.

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

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

To configure data to be displayed in the CyberTrace section:

1. In the browser's address bar, enter the FQDN of the KUMA web interface with port number 7222 as follows: https://kuma.example.com:7222. It is not recommended to specify an IP address as the server address.

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

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

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

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

Data will be displayed in this section.

Updating CyberTrace deny list (Internal TI)

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

To update CyberTrace Internal TI:

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

   The context menu opens.

2. Select Add to Internal TI of CyberTrace.

The selected object is now added to the CyberTrace denylist.

[Topic 217925]

Integration with Kaspersky Threat Intelligence Portal

The Kaspersky Threat Intelligence Portal combines all of Kaspersky's knowledge about cyberthreats and how they're related into a single, powerful web service. When integrated with KUMA, it helps KUMA users to make faster and better-informed decisions, providing them with data about URLs, domains, IP addresses, WHOIS / DNS data.

Access to the Kaspersky Threat Intelligence Portal is provided based on a fee. License certificates are created by Kaspersky experts. To obtain a certificate for Kaspersky Threat Intelligence Portal, contact your Technical Account Manager.

[Topic 217900]

Initializing integration

To integrate Kaspersky Threat Intelligence Portal into KUMA:

1. In the KUMA web interface, open Resources → Secrets.

   The list of available secrets will be displayed.

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

   The secret window is displayed.

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

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

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

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

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

   The list of available connections will be displayed.

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

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

9. If required, select the Proxy resource in the Proxy drop-down list.
10. Click Save.

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

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

[Topic 217967]

Requesting information from Kaspersky Threat Intelligence Portal

To request information from Kaspersky Threat Intelligence Portal:

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

   The Threat Lookup enrichment area opens in the right part of the screen.

2. Select check boxes next to the data types you want to request.

   If neither check box is selected, all information types are requested.

3. In the Maximum number of records in each data group field enter the number of entries per selected information type you want to receive. The default value is 10.
4. Click Request.

A ktl task has been created. When it is completed, events are enriched with data from Kaspersky Threat Intelligence Portal which can be viewed from the events table, Alert window, or correlation event window.

Page top

[Topic 218041]

Viewing information from Kaspersky Threat Intelligence Portal

To view information from Kaspersky Threat Intelligence Portal:

Open the event details area from the events table, alert window, or correlation event window and click the link on a domain, web address, IP address, or file hash for which you previously requested information from Kaspersky Threat Intelligence Portal.

The event details area opens in the right part of the screen with data from Kaspersky Threat Intelligence Portal; the time when it was received is indicated at the bottom of the screen.

Information received from Kaspersky Threat Intelligence Portal is cached. If you click a domain, web address, IP address, or file hash in the event details pane for which KUMA has information available, the data from Kaspersky Threat Intelligence Portal opens, with the time it was received indicated at the bottom, instead of the Threat Lookup enrichment window. You can update the data.

[Topic 218026]

Updating information from Kaspersky Threat Intelligence Portal

To update information, received from Kaspersky Threat Intelligence Portal:

1. Open the event details area from the events table, alert window, or correlation event window and click the link on a domain, web address, IP address, or file hash for which you previously requested information from Kaspersky Threat Intelligence Portal.
2. Click Update in the event details area containing the data received from the Kaspersky Threat Intelligence Portal.

   The Threat Lookup enrichment area opens in the right part of the screen.

3. Select the check boxes next to the types of information you want to request.

   If neither check box is selected, all information types are requested.

4. In the Maximum number of records in each data group field enter the number of entries per selected information type you want to receive. The default value is 10.
5. Click Update.

   The KTL task is created and the new data received from Kaspersky Threat Intelligence Portal is requested.

6. Close the Threat Lookup enrichment window and the details area with KTL information.
7. Open the event details area from the events table, Alert window or correlation event window and click the link on a domain, URL, IP address, or file hash for which you updated Kaspersky Threat Intelligence Portal information and select Show information in Threat Lookup.

The event details area opens on the right with data from Kaspersky Threat Intelligence Portal, indicating the time when it was received on the bottom of the screen.

[Topic 217928]

Integration with R-Vision Incident Response Platform

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

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

Integration of R-Vision IRP and KUMA is configured in both applications.

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

[Topic 224436]

Configuring integration in KUMA

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

Integration in KUMA is configured in the Settings → R-Vision Incident Response Platform section of the KUMA web interface.

To configure integration with R-Vision IRP:

1. In the KUMA web interface, open Resources → Secrets.

   The list of available secrets will be displayed.

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

   The secret window is displayed.

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

      You can obtain the token in the R-Vision IRP web interface under Settings → General → API.

   5. If required, add the secret description in the Description field. The description must contain from 1 to 256 Unicode characters.
4. Click Save.

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

5. In the KUMA web interface, open Settings → R-Vision.

   The window containing R-Vision IRP integration settings opens.

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

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

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

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

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

[Topic 224437]

Configuring integration in R-Vision IRP

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

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

Configuring integration with KUMA consists of the following steps:

• Configuring R-Vision IRP user role
  1. Assign the Incident manager system role to the R-Vision IRP user utilized for integration. The role is assigned when a user is selected in the R-Vision IRP web interface in the Settings → General → System users section. The role is added in the System Roles block of settings.

     R-Vision IRP user with the Incident Manager role

     

  2. Make sure that the API token of the R-Vision IRP user utilized for integration is indicated in the secret in the KUMA web interface. The token is displayed in the R-Vision IRP web interface under Settings → General → API.

     API token in R-Vision IRP

     

• Configuring R-Vision IRP incident fields and KUMA alerts fields
  1. Add the ALERT_ID and ALERT_URL incident fields.
  2. Configure the category of R-Vision IRP incidents created based on KUMA alerts. You can do this in the R-Vision IRP web interface, in the Settings → Incident management → Incident categories section. Add a new incident category or edit an existing incident category by indicating the previously created Alert ID and Alert URL incident fields in the Category fields settings block. The Alert ID field can be hidden.

     Categories of incidents containing data from KUMA alerts

     

  3. Block editing of previously created Alert ID and Alert URL incident fields. In the R-Vision IRP web interface, under Settings → Incident management → Presentation, select the category of R-Vision IRP incidents that will be created based on KUMA alerts and put a lock icon next to the Alert ID and Alert URL incident fields.

     Alert URL field unavailable for editing

     

• Creating R-Vision IRP collector and connector
  1. Create an R-Vision IRP collector to interact with KUMA.
  2. Create and configure an R-Vision IRP connector to send API requests to close KUMA alerts.
• Creating a rule to close a KUMA alert

  Create a rule for sending KUMA alert closing request when R-Vision IRP incident is closed.

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

[Topic 225573]

Adding the ALERT_ID and ALERT_URL incident fields

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

1. In the R-Vision IRP web interface, under Settings → Incident management → Incident fields, select the No group fields group.
2. Click the plus icon in the right part of the screen.

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

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

ALERT_ID field added to R-Vision IRP incident.

ALERT_ID field

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

1. In the R-Vision IRP web interface, under Settings → Incident management → Incident fields, select the No group fields group.
2. Click the plus icon in the right part of the screen.

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

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

ALERT_URL field added to R-Vision IRP incident.

ALERT_URL field

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

[Topic 225575]

Creating R-Vision IRP collector

To create R-Vision IRP collector:

1. In the R-Vision IRP web interface, under Settings → Asset Management → System components, click the plus icon.
2. Specify the collector name in the Name field (for example, Main collector).
3. In the Collector address field, enter the IP address or hostname where the R-Vision IRP is installed (example: 127.0.0.1).
4. In the Port field type 3001.
5. Select Default collector and Use for reaction check boxes.
6. Click Add.

R-Vision IRP collector created.

[Topic 225576]

Creating connector in R-Vision IRP

To create connector in R-Vision IRP:

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

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

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

   Bearer <KUMA General administrator token>

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

R-Vision IRP connector is created.

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

To configure API queries in R-Vision IRP:

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

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

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

     The token of the KUMA general administrator can be obtained in the KUMA web interface under Settings → Users.

5. On the BODY → Raw tab type contents of the API request body:

   {

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

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

   }

6. Click Save.

R-Vision IRP connector is configured.

[Topic 225579]

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

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

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

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

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

   Connector added to the rule.

6. Click Add.

A rule for sending KUMA alert closing request when R-Vision IRP incident created.

R-Vision IRP playbook rule

[Topic 224487]

Managing alerts using R-Vision IRP

After integration of KUMA and R-Vision IRP is configured, data on KUMA alerts is received in R-Vision IRP. Any change to alert settings in KUMA is reflected in R-Vision IRP. Any change in the statuses of alerts in KUMA or R-Vision IRP (except closing an alert) is also reflected in the other system.

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

• Forward cyberthreat data from KUMA to R-Vision IRP

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

  The following information about a KUMA alert is forwarded to R-Vision IRP:

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

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

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

• Close incident in R-Vision IRP

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

• Open a previously closed incident

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

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

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

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

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

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

[Topic 217926]

Integration with Active Directory

You can integrate KUMA with the Active Directory services that are being used in your organization.

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

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

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

[Topic 221426]

Connecting over LDAP

LDAP connections are created and managed under Settings → LDAP server connections in the KUMA web interface. The LDAP server connections table shows the tenants for which LDAP connections were created. When a tenant is selected, the connections with LDAP servers created for it are displayed.

To add a tenant to the LDAP server connections section:

1. In the KUMA web interface, under Settings → LDAP server connections, click Add.
2. In the LDAP connections window, in the Tenant drop-down list, select the relevant tenant and click Save.

The tenant will be added and displayed in the LDAP server connections table.

If you select a tenant, the LDAP connections window opens to show a table containing existing LDAP connections. Connections can be created or selected for editing.

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

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

Imported Active Directory attributes

In the Data storage time field, you can specify how many days KUMA will store information received from LDAP after such information stops being received from the Active Directory server.

[Topic 221481]

Enabling and disabling LDAP integration

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

To enable or disable all LDAP connections of a tenant:

1. Open Settings → LDAP server connections in the KUMA web interface and select the tenant for which you want to enable or disable all LDAP connections.

   The LDAP connections window opens.

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

To enable or disable a specific LDAP connection:

1. Open Settings → LDAP server connections in the KUMA web interface and select the tenant for which you want to enable or disable an LDAP connection.

   The LDAP connections window opens.

2. Select the relevant connection and either select or clear the Disabled check box in the opened window.
3. Click Save.

[Topic 217795]

Creating a connection

To create a new LDAP connection to Active Directory:

1. Open the Settings → LDAP server connections section in the KUMA web interface.
2. Select the tenant for which you want to create a connection to LDAP.

   The LDAP connections window opens.

3. Click the Add LDAP connection button.

   The LDAP connection window opens.

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

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

   2. If you want to create a new secret, click the button.

      The Secret window opens.

   3. In the Name (required) field, enter the name of the resource. This name can contain from 1 to 128 Unicode characters.
   4. In the User and Password (required) fields, enter the account credentials for connecting to the Active Directory server.

      You can enter the user name in one of the following formats: <user name>@<domain> or <domain><user name>.

   5. In the Description field, you can enter up to 256 Unicode characters to describe the resource.
   6. Click the Save button.
5. In the Name (required) field, enter the unique name of the LDAP connection.

   Must contain from 1 to 128 Unicode characters.

6. In the URL (required) field, enter the address of the domain controller in the format <hostname or IP address of server>:<port>.

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

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

     When the

     startTLS

     Text exchange protocol enhancement that lets you create an encrypted connection (TLS or SSL) directly over an ordinary TCP connection instead of opening a separate port for the encrypted connection.

     Text exchange protocol enhancement that lets you create an encrypted connection (TLS or SSL) directly over an ordinary TCP connection instead of opening a separate port for the encrypted connection.

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

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

   • ssl.

     When using SSL, an encrypted connection is immediately established over port 636.

   • insecure.

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

8. If you enabled TLS encryption at the previous step, add a TLS certificate. To do so:
   1. If you previously uploaded a certificate, select it from the Certificate drop-down list.

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

   2. If you want to upload a new certificate, click the button on the right of the Certificate list.

      The Secret window opens.

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

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

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

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

10. In the Search base (Base DN) field, enter the base distinguished name of the directory in which you need to run the search query.
11. Select the Disabled check box if you do not want to use this LDAP connection.

    This check box is cleared by default.

12. Click the Save button.

The LDAP connection to Active Directory will be created and displayed in the LDAP connection window.

Account information from Active Directory will be requested in 12 hours. To make the data available right away, restart the KUMA Core server. Account information is updated every 12 hours.

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

[Topic 231112]

Creating a copy of a connection

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

To copy an LDAP connection:

1. Open Settings → LDAP in the KUMA web interface and select the tenant for which you want to copy an LDAP connection.

   The LDAP connections window opens.

2. Select the relevant connection.
3. In the opened LDAP connection window, click the Duplicate settings button.

   The New Connection window opens.

4. If you want to change the connection settings, you can enter the necessary changes for one or more settings.
5. Click the Save button.

A copy of the connection will be created.

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

[Topic 217830]

Removing a connection

To delete LDAP connection to Active Directory:

1. Open Settings → LDAP server connections in the KUMA web interface and select the tenant that owns the relevant LDAP connection.

   The LDAP connections window opens.

2. Click the LDAP connection you want to delete and click the Delete button.

The LDAP connection to Active Directory will be deleted.

[Topic 221427]

Authorization with domain accounts

To enable users to complete authorization in the KUMA web interface using their own domain account credentials, you must complete the following configuration steps.

1. Enable domain authorization if it is disabled.

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

2. Configure a connection to the domain controller.

   You can connect only to one domain.

3. Add groups of user roles.

   You can specify an Active Directory group for each KUMA role. After completing authorization using their own domain accounts, users from this group will obtain access to the KUMA web interface in accordance with their defined role.

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

If you completed all the configuration steps but the user is unable to use their domain account for authorization in the KUMA web interface, it is recommended to check the configuration for the following issues:

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

[Topic 221428]

Enabling and disabling domain authorization

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

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

1. In the program web interface, select Settings → Domain authorization.
2. Do one of the following:
   • If you want to disable domain authorization, select the Disabled check box in the upper part of the workspace.
   • If you want to enable domain authorization, clear the Disabled check box in the upper part of the workspace.
3. Click the Save button.

Domain authorization will be enabled or disabled based on your selection.

[Topic 221429]

Configuring a connection to the domain controller

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

To configure a connection to an Active Directory domain controller.

1. In the program web interface, select Settings → Domain authorization.
2. In the Connection settings block, in the Base DN field, enter the DistinguishedName of the root record to search for access groups in the Active Directory catalog service.
3. In the URL field, indicate the address of the domain controller in the format <hostname or IP address of server>:<port>.

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

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

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

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

   • ssl.

     When using SSL, an encrypted connection is immediately established over port 636.

   • insecure.

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

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

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

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

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

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

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

7. If you want to configure domain authorization for a user with the KUMA general administrator role, specify the DistinguishedName of the Active Directory group containing the user in the General administrators group field.

   If a user matches two groups in the same tenant, the role with the least privileges will be used.

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

8. Click the Save button.

A connection with the Active Directory domain controller is now configured. For domain authorization to work, you must also add group of KUMA user roles.

[Topic 221430]

Adding groups of user roles

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

To add groups of user roles:

1. In the program web interface, select Settings → Domain authorization.
2. In the Role groups settings block, click the Add role groups button.
3. In the Tenant drop-down list, select the tenant of the users for whom you want to configure domain authorization.
4. In the fields for the following roles, specify the DistinguishedName of the Active Directory group whose users must have the capability to complete authorization with their domain accounts:
   • Operator.
   • Analyst.
   • Administrator.

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

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

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

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

After the first authorization of the user, information about them is displayed under Settings → Users. The Login and Password fields received from Active Directory will be unavailable for editing. The user role will also be unavailable for editing. To edit a role, you will have to change the user role groups. Changes to a role are applied after the next authorization of the user. The user will continue to operate under the old role until the current session expires.

If the user name or email address is changed in the Active Directory account properties, these changes will need to be manually entered into the KUMA account.

[Topic 221777]

Integration with RuCERT

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

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

To create a connection to RuCERT:

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

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

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

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

   Available company business sectors

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

KUMA is now integrated with RuCERT. Now you can export incidents to it.

[Topic 232020]

Integration with Security Vision Incident Response Platform

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

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

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

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

Working with Security Vision IRP incidents

Security Vision IRP incidents generated from KUMA alert data can be viewed in Security Vision IRP under Инциденты (Incidents) → Инциденты (2 линии) (Incidents (2 line)) → Все инциденты (2 линии) (All incidents (2 line)). Events related to KUMA alerts are logged in each Security Vision IRP incident. Imported events can be viewed on the Response tab.

KUMA alert imported as Security Vision IRP incident

[Topic 232289]

Configuring integration in KUMA

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

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

To generate a token in your account profile:

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

   The User window with your user account parameters opens.

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

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

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

[Topic 232073]

Configuring integration in Security Vision IRP

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

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

[Topic 232293]

Importing and configuring a connector

Adding a connector in Security Vision IRP

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

To import a Kaspersky KUMA connector into Security Vision IRP:

1. In Security Vision IRP, open Settings → Connectors → Connectors.

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

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

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

Configuring a connector for a connection to KUMA

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

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

1. In Security Vision IRP, open Settings → Connectors → Connectors.

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

2. Select the Kaspersky KUMA connector.

   The general settings of the connector will be displayed.

3. Under Параметры коннектора (Connector settings), click the Редактировать (Edit) button.

   The connector configuration will be displayed.

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

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

Security Vision IRP connector settings

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

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

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

To configure a command to receive alert information from KUMA:

1. In Security Vision IRP, open Settings → Connectors → Connectors.

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

2. Select the Kaspersky KUMA connector.

   The general settings of the connector will be displayed.

3. Click the +Команда (+Command) button.

   The command creation window opens.

4. Specify the command settings for receiving alerts:
   • In the Наименование (Name) field, enter the command name: Получение инцидентов (Receive incidents).
   • In the Тип запроса (Request type) drop-down list, select GET.
   • In the Вызываемый метод (Called method) field, enter API request to search for alerts: api/v1/alerts/?withEvents&status=new
   • Under Заголовки запроса (Request headers), in the Название (Name) field, indicate authorization. In the Значение (Value) field, indicate Bearer <token>.
   • In the Тип контента (Content type) drop-down list, select application/json.
5. Save the command and close the window.

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

To configure a command to close KUMA alerts:

1. In Security Vision IRP, open Settings → Connectors → Connectors.

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

2. Select the Kaspersky KUMA connector.

   The general settings of the connector will be displayed.

3. Click the +Команда (+Command) button.

   The command creation window will be displayed.

4. Specify the command settings for receiving alerts:
   • In the Наименование (Name) field, enter the command name: Закрытие инцидента (Close incident).
   • In the Тип запроса (Request type) drop-down list, select POST.
   • In the Вызываемый метод (Called method) field, enter API request to close an alert: api/v1/alerts/close
   • In the Запрос (Request) field, enter the contents of the API request to be sent: {"id":"<Alert ID>","reason":"responded"}

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

   • Under Заголовки запроса (Request headers), in the Название (Name) field, indicate authorization. In the Значение (Value) field, indicate Bearer <token>.
   • In the Тип контента (Content type) drop-down list, select application/json.
5. Save the command and close the window.

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

Creating commands in Security Vision IRP

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

[Topic 232323]

Configuring the handler, schedule, and worker process

Security Vision IRP handler

The Security Vision IRP handler receives KUMA alert data from the Security Vision IRP connector and creates Security Vision IRP incidents based on this data. A predefined KUMA (Инциденты) (KUMA (Incidents)) handler is used for processing data. The settings of the KUMA (Инциденты) (KUMA (Incidents)) handler are available in Security Vision IRP under Настройки (Settings) → Обработка событий (Event processing) → Обработчики событий (Event handlers):

• The rules for processing KUMA alerts can be viewed in the handler settings on the Нормализация (Normalization) tab.
• The available actions when creating new objects can be viewed in the handler settings on the Действия (Actions) tab for creating objects of the Инцидент (2 линии) (Incident (2 line)) type.

Handler run schedule

The connector and handler are started according to a predefined KUMA schedule. This schedule can be configured in Security Vision IRP under Настройки (Settings) → Обработка событий (Event processing) → Расписание (Schedule):

• In the Настройки коннектора (Connector settings) block, you can configure the settings for starting the connector.
• In the Настройки обработки (Handler settings) block, you can configure the settings for starting the handler.

Security Vision IRP worker process

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

[Topic 217687]

KUMA resources

Resources are KUMA components that contain parameters for implementing various functions: for example, establishing a connection with a given web address or converting data according to certain rules. These components, like parts of a constructor set, are assembled into resource sets for services, based on which, in turn, KUMA services are created.

Resources are contained in the Resources section, Resources block of KUMA web interface. The following resource types are available:

• Correlation rules—resources of this type contain rules for identifying event patterns that indicate threats. If the conditions specified in these resources are met, a correlation event is generated.
• Normalizers—resources of this type contain rules for converting incoming events into the format used by KUMA. After processing in the normalizer, the "raw" event is normalized and can be processed by other KUMA resources and services.
• Connectors—resources of this type contain settings for establishing network connections.
• Aggregation rules—resources of this type contain rules for combining several base events of the same type into one aggregation event.
• Enrichment rules—resources of this type contain rules for supplementing events with information from third-party sources.
• Destinations—resources of this type contain settings for forwarding events to a destination for further processing or storage.
• Filters—resources of this type contain conditions for rejecting or selecting individual events from the stream of events.
• Response—resources of this type are used in correlators to run scripts or start Kaspersky Security Center tasks when certain conditions are met.
• Active lists—resources of this type are used by correlators for dynamic data processing when analyzing events according to correlation rules.
• Dictionaries—resources of this type are used to store keys and their values that may be required by other KUMA resources and services.
• Proxies—resources of this type contain settings for using proxy servers.
• Secrets—resources of this type are used to securely store confidential information (such as account credentials) that KUMA needs for interaction with external services.

When you click on a resource type, a window opens displaying a table with the available resources of this type. The resource table contains the following columns:

• Name—the name of a resource. Can be used to search for resources and sort them.
• Time updated—the date and time of the last update of a resource. Can be used to sort resources.
• Created by—the name of the user who created a resource.
• Description—the description of a resource.

Resources can be organized into folders. On the left side of each window, the folder structure is displayed, where the number and names of the root folders correspond to the tenants created in KUMA. When a folder is selected, the resources it contains are displayed as a table in the right pane of the window.

Resources can be created, edited, copied, moved from one folder to another, and deleted. Resources can also be exported and imported.

[Topic 217971]

Resources tools

This section contains information on tools that are available in KUMA to organize resources and work with them.

[Topic 218051]

Working with resources folders

You can create, rename, move and delete folders.

To create a folder:

1. Select the folder in the tree where the new folder is required.
2. Click the Add folder button.

The folder will be created.

To rename a folder:

1. Locate required folder in the folder structure.
2. Hover over the name of the folder.

   The icon will appear near the name of the folder.

3. Open the drop-down list and select Rename.

   The folder name will become active for editing.

4. Enter the new folder name and press ENTER.

   The folder name cannot be empty.

The folder will be renamed.

To move a folder,

Drag and drop the folder to a required place in folder structure by clicking its name.

Folders cannot be dragged from one tenant to another.

To delete a folder:

1. Locate required folder in the folder structure.
2. Hover over the name of the folder.

   The icon will appear near the name of the folder.

3. Open the drop-down list and select Delete.

   The conformation window appears.

4. Click OK.

The folder will be deleted.

The program does not delete folders that contain files or subfolders.

[Topic 218050]

Working with resources

You can create, move, copy, edit, and delete resources.

To create the resource:

1. In the Resources → <resource type> section, select or create a folder where you want to add the new resource.

   Root folders correspond to tenants. For a resource to be available to a specific tenant, it must be created in the folder of that tenant.

2. Click the Add <resource type> button.

   The window for configuring the selected resource type opens. The available configuration parameters depend on the resource type.

3. Enter a unique resource name in the Name field.
4. Specify the required parameters (marked with a red asterisk).
5. If necessary, specify the optional parameters (not required).
6. Click Save.

The resource has been created and is available for use in services and other resources.

To move the resource to a new folder:

1. In the Resources → <resource type> section, find the required resource in the folder structure.
2. Select the check box near the resource you want to move. You can select multiple resources.

   The icon appears near the selected resources.

3. Use the icon to drag and drop resources to the required folder.

Resources are located in new folders. Resources cannot be dragged between folders of different tenants.

To copy the resource:

1. In the Resources → <resource type> section, find the required resource in the folder structure.
2. Select the check box next to the resource that you want to copy and click Duplicate.

   A window opens with the settings of the resource that you have selected for copying. The available configuration parameters depend on the resource type.

   The <selected resource name> - copy value is displayed in the Name field.

3. Make the necessary changes to the parameters.
4. Enter a unique name in the Name field.
5. Click Save.

The copy of the resource is created.

To edit the resource:

1. In the Resources → <resource type> section, find the required resource in the folder structure.
2. Select the resource.

   A window with the settings of the selected resource opens. The available configuration parameters depend on the resource type.

3. Make the necessary changes to the parameters.
4. Click Save.

The resource will be updated. If this resource is used in a service, restart the service to apply the new settings.

To delete the resource:

1. In the Resources → <resource type> section, find the required resource in the folder structure.
2. Select the check box next to the resource that you want to delete and click Delete.

   A confirmation window opens.

3. Click OK.

The resource has been deleted.

[Topic 217870]

Exporting and importing resources

You can export and import resources.

To export resources:

1. In the Resources section → <resource type> click the icon .
2. In the drop-down list, select Export resources.

   The Export resources window opens with the tree of all available resources.

3. In the Password field enter the password that must be used to protect exported data.
4. In the Tenant drop-down list, select the tenant whose resources you want to export.
5. Check boxes near the resources you want to export.

   If selected resources are linked to other resources, linked resources will be exported, too.

6. Click the Export button.

The resources in a password-protected file are saved on your computer using your browser settings. The Secret resources are exported blank.

To import resources:

1. Open the drop-down list and select Import resources.

   The Resource import window opens.

2. In the Password field enter the password for the file you want to import.
3. In the Tenant drop-down list, select the tenant that will own the imported resources.
4. Click the Select file button and locate the file with the resources you want to import.

   In the Resource import window the tree of all available resources in the selected file is displayed.

5. Select resources you want to import.
6. Click the Import button.
7. Resolve conflicts (see below) between imported and existing resources if they appear. Read more about resource conflicts below.
   1. If the name of any of the imported resource matches the name of the already existing resource, the Conflicts window opens with the table where the kind and the name of conflicting resources are displayed. Resolve displayed conflicts:
      • If you want to replace the existing resource with a new one, click Replace.

        Click Replace all to replace all existing conflicting resources.

      • If you want to leave the existing resource, click Skip.

        Click Skip all to keep all existing resources.

   2. Click the Resolve button.

The resources are imported to KUMA. The Secret resources are imported blank.

About conflict resolving

When resources are imported to KUMA, the program compares them with the existing resources, checking their name, kind, and guid (or identifier) parameters:

• If an imported resource's name and kind parameters match those of the existing one, the imported resource's name is automatically changed.
• If identifiers of two resources match, a conflict appears that must be resolved by the user. This could happen when you import resources to the same KUMA server from which they were exported.

When resolving a conflict you can choose either to replace existing resource with the imported one or to keep exiting resource, skipping the imported one.

Some resources are linked (for example, the Connector resource requires the Connection resource); such resources are exported and imported together. If during the import a conflict occurs and you choose to replace existing resource with a new one, it would mean that all the other resources linked to the one being replaced are going to be automatically replaced with the imported resources, even if you chose to Skip any of them.

During import, all resources are imported into one tenant even if they belonged to different tenants during export (for example, if an associated resource was in a shared tenant).

[Topic 217776]

Connectors

Connector resources are used to establish connections between KUMA services, network assets, and/or other services. The settings of connectors are displayed on two tabs: Basic settings and Advanced settings. The available settings depend on the selected type of connector:

• internal
• tcp
• udp
• netflow
• nats
• kafka
• http
• sql
• file
• ftp
• nfs
• wmi
• wec
• snmp

For these resources, you can enable the display of control characters in all input fields except the Description field.

If you change the kind of connector from wec to wmi in an already created collector, there may be errors receiving events. If you want to make this type of change to the connector kind, you must create a new WMI connector with the necessary settings and connect it to the collector instead of the WEC connector.

[Topic 220738]

Internal type

The internal type is used for establishing connections between the KUMA services.

Available settings:

• Basic settings tab:
  • Name (required)—a unique name for this type of resource. Must contain from 1 to 128 Unicode characters.
  • Tenant (required)—name of the tenant that owns the resource.
  • Type (required)—connector type.
  • URL (required)—URL that you need to connect to. Available formats: hostname:port, IPv4:port, IPv6:port, :port.
  • Description—up to 256 Unicode characters describing the resource.
• Advanced settings tab:
  • Proxy—a drop-down list where you can select a proxy server resource.
  • Debug—a drop-down list where you can specify whether resource logging should be enabled. By default it is Disabled.

[Topic 220739]

Tcp type

The tcp type is used for TCP communications It is available for Windows and Linux Agents.

Available settings:

• Basic settings tab:
  • Name (required)—a unique name for this type of resource. Must contain from 1 to 128 Unicode characters.
  • Tenant (required)—name of the tenant that owns the resource.
  • Type (required)—connector type.
  • URL (required)—URL that you need to connect to. Available formats: hostname:port, IPv4:port, IPv6:port, :port.
  • Delimiter is used to specify a character representing the delimiter between events. By default, \n is used.
  • Description—up to 256 Unicode characters describing the resource.
• Advanced settings tab:
  • Buffer size is used to set a buffer size for the connector. The default value is 1 MB, and the maximum value is 64 MB.
  • Character encoding setting specifies character encoding. The default value is UTF-8.
  • TLS mode specifies whether TLS encryption is used:
    • 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.

  • Compression—you can use Snappy compression. By default, compression is disabled.
  • Debug—a drop-down list where you can specify whether resource logging should be enabled. By default it is Disabled.

[Topic 220740]

Udp type

The udp type is used for UDP communications. It is available for Windows and Linux Agents.

Available settings:

• Basic settings tab:
  • Name (required)—a unique name for this type of resource. Must contain from 1 to 128 Unicode characters.
  • Tenant (required)—name of the tenant that owns the resource.
  • Type (required)—connector type.
  • URL (required)—URL that you need to connect to. Available formats: hostname:port, IPv4:port, IPv6:port, :port.
  • Delimiter is used to specify a character representing the delimiter between events. By default, \n is used.
  • Description—up to 256 Unicode characters describing the resource.
• Advanced settings tab:
  • Buffer size is used to set a buffer size for the connector. The default value is 16 KB, and the maximum value is 64 KB.
  • Workers—used to set worker count for the connector. The default value is 1.
  • Character encoding setting specifies character encoding. The default value is UTF-8.
  • Compression—you can use Snappy compression. By default, compression is disabled.
  • Debug—a drop-down list where you can specify whether resource logging should be enabled. By default it is Disabled.

[Topic 220741]

Netflow type

The netflow is used for establishing NetFlow connections.

Available settings:

• Basic settings tab:
  • Name (required)—a unique name for this type of resource. Must contain from 1 to 128 Unicode characters.
  • Tenant (required)—name of the tenant that owns the resource.
  • Type (required)—connector type.
  • URL (required)—URL that you need to connect to.
  • Description—up to 256 Unicode characters describing the resource.
• Advanced settings tab:
  • Buffer size is used to set a buffer size for the connector. The default value is 16 KB, and the maximum value is 64 KB.
  • Workers—used to set worker count for the connector. The default value is 1.
  • Character encoding setting specifies character encoding. The default value is UTF-8.
  • Debug—a drop-down list where you can specify whether resource logging should be enabled. By default it is Disabled.

[Topic 220742]

Nats type

The nats type is used for NATS communications It is available for Windows and Linux Agents.

Available settings:

• Basic settings tab:
  • Name (required)—a unique name for this type of resource. Must contain from 1 to 128 Unicode characters.
  • Tenant (required)—name of the tenant that owns the resource.
  • Type (required)—connector type.
  • URL (required)—URL that you need to connect to.
  • Topic (required)—the topic for NATS messages. Must contain from 1 to 255 Unicode characters.
  • Delimiter is used to specify a character representing the delimiter between events. By default, \n is used.
  • Description—up to 256 Unicode characters describing the resource.
• Advanced settings tab:
  • Buffer size is used to set a buffer size for the connector. The default value is 16 KB, and the maximum value is 64 KB.
  • GroupID—the GroupID parameter for NATS messages. Must contain from 1 to 255 Unicode characters. The default value is io.nats.
  • Workers—used to set worker count for the connector. The default value is 1.
  • Character encoding setting specifies character encoding. The default value is UTF-8.
  • Storage ID is a NATS storage identifier.
  • TLS mode specifies whether TLS encryption is used:
    • Disabled (default)—do not use TLS encryption.
    • Enabled—use encryption without certificate 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/.
    • Custom CA—use encryption with verification that the certificate was signed by a Certificate Authority. The secret containing the certificate is selected from the Custom CA drop-down list, which is displayed when this option is selected.

      Creating a certificate signed by a Certificate Authority

      To use this TLS mode, you must do the following on the KUMA Core server (OpenSSL commands are used in the examples below):

      1. Create the key that will be used by the Certificate Authority.

         Example command: openssl genrsa -out ca.key 2048

      2. Generate a certificate for the key that was just created.

         Example command: openssl req -new -x509 -days 365 -key ca.key -subj "/CN=<common host name of Certificate Authority>" -out ca.crt

      3. Create a private key and a request to have it signed by the Certificate Authority.

         Example command: openssl req -newkey rsa:2048 -nodes -keyout server.key -subj "/CN=common host name of KUMA server>" -out server.csr

      4. Create a certificate signed by the Certificate Authority. The subjectAltName must include the domain names or IP addresses of the server for which the certificate is being created.

         Example command: openssl x509 -req -extfile <(printf "subjectAltName=DNS:domain1.ru,DNS:domain2.com,IP:192.168.0.1") -days 365 -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt

      5. The obtained server.crt certificate should be uploaded in the KUMA web interface as a certificate-type secret, which should then be selected from the Custom CA drop-down list.

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

  • Compression—you can use Snappy compression. By default, compression is disabled.
  • Debug—a drop-down list where you can specify whether resource logging should be enabled. By default it is Disabled.

[Topic 220744]

Kafka type

The kafka type is used for Kafka communications It is available for Windows and Linux Agents.

Available settings:

• Basic settings tab:
  • Name (required)—a unique name for this type of resource. Must contain from 1 to 128 Unicode characters.
  • Tenant (required)—name of the tenant that owns the resource.
  • Type (required)—connector type.
  • URL—URL that you need to connect to. Available formats: hostname:port, IPv4:port, IPv6:port.
  • Topic—subject of Kafka messages. Must contain from 1 to 255 of the following characters: a–z, A–Z, 0–9, ".", "_", "-".
  • Authorization—requirement for Agents to complete authorization when connecting to the connector:
    • disabled (by default).
    • PFX.

      When this option is selected, a certificate must be generated with a private key in PKCS#12 container format in an external Certificate Authority. Then the certificate must be exported from the key store and uploaded to the KUMA web interface as a PFX secret.

      Add PFX secret

      1. If you previously uploaded a PFX certificate, select it from the Secret drop-down list.

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

      2. If you want to add a new certificate, click the button on the right of the Secret list.

         The Secret window opens.

      3. In the Name field, enter the name that will be used to display the secret in the list of available secrets.
      4. Click the Upload PFX button to select the file containing your previously exported certificate with a private key in PKCS#12 container format.
      5. In the Password field, enter the certificate security password that was set in the Certificate Export Wizard.
      6. Click the Save button.

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

    • plain.

      If this option is selected, you must indicate the secret containing user account credentials for authorization when connecting to the connector.

      Add secret

      1. If you previously created a secret, select it from the Secret drop-down list.

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

      2. If you want to add a new secret, click the button on the right of the Secret list.

         The Secret window opens.

      3. In the Name field, enter the name that will be used to display the secret in the list of available secrets.
      4. In the User and Password fields, enter the credentials of the user account that the Agent will use to connect to the connector.
      5. If necessary, add any other information about the secret in the Description field.
      6. Click the Save button.

      The secret will be added and displayed in the Secret list.

  • GroupID—the GroupID parameter for Kafka messages. Must contain from 1 to 255 of the following characters: a–z, A–Z, 0–9, ".", "_", "-".
  • Description—up to 256 Unicode characters describing the resource.
• Advanced settings tab:
  • Delimiter is used to specify a character representing the delimiter between events. By default, \n is used.
  • Character encoding setting specifies character encoding. The default value is UTF-8.
  • TLS mode specifies whether TLS encryption is used:
    • Disabled (default)—do not use TLS encryption.
    • Enabled—use encryption without certificate 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/.
    • Custom CA—use encryption with verification that the certificate was signed by a Certificate Authority. The secret containing the certificate is selected from the Custom CA drop-down list, which is displayed when this option is selected.

      Creating a certificate signed by a Certificate Authority

      To use this TLS mode, you must do the following on the KUMA Core server (OpenSSL commands are used in the examples below):

      1. Create the key that will be used by the Certificate Authority.

         Example command: openssl genrsa -out ca.key 2048

      2. Generate a certificate for the key that was just created.

         Example command: openssl req -new -x509 -days 365 -key ca.key -subj "/CN=<common host name of Certificate Authority>" -out ca.crt

      3. Create a private key and a request to have it signed by the Certificate Authority.

         Example command: openssl req -newkey rsa:2048 -nodes -keyout server.key -subj "/CN=common host name of KUMA server>" -out server.csr

      4. Create a certificate signed by the Certificate Authority. The subjectAltName must include the domain names or IP addresses of the server for which the certificate is being created.

         Example command: openssl x509 -req -extfile <(printf "subjectAltName=DNS:domain1.ru,DNS:domain2.com,IP:192.168.0.1") -days 365 -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt

      5. The obtained server.crt certificate should be uploaded in the KUMA web interface as a certificate-type secret, which should then be selected from the Custom CA drop-down list.

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

  • Debug—a drop-down list where you can specify whether resource logging should be enabled. By default it is Disabled.

[Topic 220745]

Http type

The http type is used for HTTP communications It is available for Windows and Linux Agents.

Available settings:

• Basic settings tab:
  • Name (required)—a unique name for this type of resource. Must contain from 1 to 128 Unicode characters.
  • Tenant (required)—name of the tenant that owns the resource.
  • Type (required)—connector type.
  • URL (required)—URL that you need to connect to. Available formats: hostname:port, IPv4:port, IPv6:port, :port.
  • Delimiter is used to specify a character representing the delimiter between events. By default, \n is used.
  • Description—up to 256 Unicode characters describing the resource.
• Advanced settings tab:
  • Character encoding setting specifies character encoding. The default value is UTF-8.
  • TLS mode specifies whether TLS encryption is used:
    • 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.

  • Proxy—a drop-down list where you can select a proxy server resource.
  • Debug—a drop-down list where you can specify whether resource logging should be enabled. By default it is Disabled.

[Topic 220746]

Sql type

The sql is used for SQL communications. Connector settings are divided into three blocks:

• General connector settings.
• Settings of a specific SQL connection. One connector may have more than one of these connections.
• Advanced settings of a connector.

General connector settings

General connector settings are located on the Main settings tab:

• Name (required)—a unique name for this type of resource. Must contain from 1 to 128 Unicode characters.
• Tenant (required)—name of the tenant that owns the resource.
• Type (required)—connector type.
• Default query (required)—field for an SQL query that is common to all connections of the connector.
• Poll interval, sec - time between SQL queries in seconds. The default value is 10 seconds.
• Description—up to 256 Unicode characters describing the resource.

If an individual connection (see below) has its own defined query and/or query interval, this connection will use the values specifically defined for its own query and/or query interval.

Settings of a specific SQL connection

General connector settings are located on the Main settings tab. You can create multiple connections in one connector by using the Add connection button to add new ones. You can delete connections by using the button.

Connection settings:

• URL (required)—drop-down list for selecting the secret resource that stores a list of query strings for SQL connections. The string format depends on the specific database (see the supported SQL types below).

  When creating connections, strings containing account credentials with special characters may be incorrectly processed. If a connection is not being created even though you are sure that your settings are correct, enter the special characters in percent encoding.

  Codes of special characters

  !	#	$	%	&	'	(	)	*	+
  %21	%23	%24	%25	%26	%27	%28	%29	%2A	%2B
  ,	/	:	;	=	?	@	[	]	\
  %2C	%2F	%3A	%3B	%3D	%3F	%40	%5B	%5D	%5C

  The following special characters are not supported in passwords used to access SQL databases: space, [, ], :, /, #, %, \.

  Available formats for server addresses: hostname:port, IPv4:port, IPv6:port.

  If required, a secret can be created in the connector creation window using the button. The selected secret can be changed by clicking on the button.

• Identity column (required)—name of the column that will serve as the identity column.
• Identity seed (required)—identity column value that will be used to determine the specific line to start reading data from the SQL table.
• Query—field for SQL queries. If a query is indicated for a specific connection in a connector, this query will be used instead of the query specified in the Default query field.
• Poll interval, sec - time between SQL queries in seconds. Dafault value – 10 seconds. If a query interval is indicated for a specific connection in a connector, this interval will be used instead of the connector's general query interval.

One SQL connection is defined by using the URL, Identity column, and Identity seed parameters. The last line where data was read from the SQL table is saved in the KUMA collector that generated the query sent to the SQL database. This allows the program to start from the last read line when reading data from the SQL table. The ID of the last read line does not change when a different URL or query is indicated in the connector. To change the starting line where data acquisition from the SQL table will begin, you must change the value of the Identity seed and/or Identity column fields.

Advanced settings of a connector

Additional connector settings are located on the Advanced settings tab:

• Character encoding setting specifies character encoding. The default value is UTF-8.

  KUMA can process SQL responses in UTF-8 character encoding. Either ensure that the SQL server sends messages in UTF-8 or use the Character encoding drop-down list in the Connector settings to convert incoming messages to UTF-8.

• Debug—a drop-down list where you can specify whether resource logging should be enabled. By default it is Disabled.

Supported SQL types and their specific usage features

The UNION operator is not supported by the SQL Connector resources.

The following SQL types are supported:

• MSSQL

  Example URLs:

  • sqlserver://{user}:{password}@{server:port}/{instance_name}?database={database} – (recommended option)
  • sqlserver://{user}:{password}@{server}?database={database}

  The characters @p1 are used as a placeholder in the SQL query.

  If you need to connect using domain account credentials, specify the account name in <domain>%5C<user> format. For example: sqlserver://domain%5Cuser:password@ksc.example.com:1433/SQLEXPRESS?database=KAV.

• MySQL

  Example URL: mysql://{user}:{password}@tcp({server}:{port})/{database}

  The character ? is used as a placeholder in the SQL query.

• PostgreSQL

  Example URL: postgres://{user}:{password}@{server}/{database}?sslmode=disable

  The characters $1 are used as a placeholder in the SQL query.

• CockroachDB

  Example URL: postgres://{user}:{password}@{server}:{port}/{database}?sslmode=disable

  The characters $1 are used as a placeholder in the SQL query.

• SQLite3

  Example URL: sqlite3://file:{file_path}

  A question mark (?) is used as a placeholder in the SQL query.

• Oracle DB

  Example URL: oracle://{user}/{password}@{server}:{port}/{service_name}

  Easy Connect syntax is used. The characters :val are used as a placeholder in the SQL query.

  When querying the Oracle DB, if the initial value of the ID is in datetime format, the Oracle to_timestamp_tz function should be used to add the date conversion to the SQL query. For example, select * from connections where login_time > to_timestamp_tz(:val, 'YYYY-MM-DD"T"HH24:MI:SSTZH:TZM'). In this example, Connections is the Oracle DB table and the :val variable is taken from the Identity seed field, therefore it must be indicated in a format with the timezone (for example, 2021-01-01T00:10:00+03:00).

  To access the Oracle DB, the libaio1 package must be installed.

• Firebird SQL

  Example URL: firebirdsql://{user}:{password}@{server}:{port}/{database}

  A question mark (?) is used as a placeholder in the SQL query.

A sequential request for database information is supported in SQL queries. For example, if you type select * from <name of data table> where id > <placeholder> in the Query field, the Identity seed field value will be used as the placeholder value the first time you query the table. In addition, the service that utilizes the SQL connector saves the ID of the last read entry, and the ID of this entry will be used as the placeholder value in the next query to the database.

Examples of SQL requests

[Topic 220748]

File type

The file type is used to retrieve data from any text file. One string in a file is considered to be one event. Strings delimiter: \n. This type of connector is available for Linux Agents.

Available settings:

• Basic settings tab:
  • Name (required)—a unique name for this type of resource. Must contain from 1 to 128 Unicode characters.
  • Tenant (required)—name of the tenant that owns the resource.
  • Type (required)—connector type.
  • URL (required)—full path to the file that you need to interact with. For example, /var/log/*som?[1-9].log.

    File and folder mask templates

    Masks:

    • '*'—matches any sequence of characters.
    • '[' [ '^' ] { range of characters } ']'—class of characters (should not be left blank).
    • '?'—matches any single character.
    • c—matches the c character (c != '*', '?', '\\', '[').
    • '\\' c—matches the c character.

    Ranges of characters:

    • c—matches the c character (c != '\\', '-', ']').
    • '\\' c—matches the c character.
    • lo '-' hi—matches the c character for lo <= c <= hi.

    Examples:

    • /var/log/*som?[1-9].log
    • /mnt/dns_logs/*/dns.log
    • /mnt/proxy/access*.log

    Limitations when using prefixes in file paths

    Prefixes that cannot be used when specifying paths to files:

    • /*
    • /bin
    • /boot
    • /dev
    • /etc
    • /home
    • /lib
    • /lib64
    • /proc
    • /root
    • /run
    • /sys
    • /tmp
    • /usr/*
    • /usr/bin/
    • /usr/local/*
    • /usr/local/sbin/
    • /usr/local/bin/
    • /usr/sbin/
    • /usr/lib/
    • /usr/lib64/
    • /var/*
    • /var/lib/
    • /var/run/
    • /opt/kaspersky/kuma/

    Files are available at the following paths:

    • /opt/kaspersky/kuma/clickhouse/logs/
    • /opt/kaspersky/kuma/mongodb/log/
    • /opt/kaspersky/kuma/victoria-metrics/log/
  • Description—up to 256 Unicode characters describing the resource.
• Advanced settings tab:
  • Character encoding setting specifies character encoding. The default value is UTF-8.
  • Debug—a drop-down list where you can specify whether resource logging should be enabled. By default it is Disabled.

[Topic 220749]

Ftp type

The ftp type is used to receive data using the File Transfer Protocol. It is available for Windows and Linux Agents.

Available settings:

• Basic settings tab:
  • Name (required)—a unique name for this type of resource. Must contain from 1 to 128 Unicode characters.
  • Tenant (required)—name of the tenant that owns the resource.
  • Type (required)—connector type.
  • URL (required)—actual URL of the file or file mask beginning with 'ftp://'. For a file mask, you can use * ? [...].

    File mask templates

    Masks:

    • '*'—matches any sequence of characters.
    • '[' [ '^' ] { range of characters } ']'—class of characters (should not be left blank).
    • '?'—matches any single character.
    • c—matches the c character (c != '*', '?', '\\', '[').
    • '\\' c—matches the c character.

    Ranges of characters:

    • c—matches the c character (c != '\\', '-', ']').
    • '\\' c—matches the c character.
    • lo '-' hi—matches the c character for lo <= c <= hi.

    Examples:

    • /var/log/*som?[1-9].log
    • /mnt/dns_logs/*/dns.log
    • /mnt/proxy/access*.log

    If the URL does not include the FTP server port, port 21 is inserted.

  • Description—up to 256 Unicode characters describing the resource.
• Advanced settings tab:
  • Character encoding setting specifies character encoding. The default value is UTF-8.
  • Compression—you can use Snappy compression. By default, compression is disabled.
  • Debug—a drop-down list where you can specify whether resource logging should be enabled. By default it is Disabled.

[Topic 220750]

Nfs type

The nfs type is used to receive data using the Network File System protocol. It is available for Windows and Linux Agents.

Available settings:

• Basic settings tab:
  • Name (required)—a unique name for this type of resource. Must contain from 1 to 128 Unicode characters.
  • Tenant (required)—name of the tenant that owns the resource.
  • Type (required)—connector type.
  • URL (required)—path to the remote folder in the format nfs://host/path.
  • Query (required)—a mask used to filter files containing events. Use of masks is acceptable "*","?","[...]".
  • Poll interval, sec—polling interval. The time interval after which files are re-read from the remote system. The value is specified in seconds. The default value is 0.
  • Description—up to 256 Unicode characters describing the resource.
• Advanced settings tab:
  • Character encoding setting specifies character encoding. The default value is UTF-8.
  • Compression—you can use Snappy compression. By default, compression is disabled.
  • Debug—a drop-down list where you can specify whether resource logging should be enabled. By default it is Disabled.

[Topic 220751]

Wmi type

The wmi type is used to obtain data using Windows Management Instrumentation. It is available for Windows Agents.

Available settings:

• Basic settings tab:
  • Name (required)—a unique name for this type of resource. Must contain from 1 to 128 Unicode characters.
  • Tenant (required)—name of the tenant that owns the resource.
  • Type (required)—connector type.
  • URL (required)—URL of the collector being created, for example: kuma-collector.example.com:7221.

    The creation of a collector for receiving data using Windows Management Instrumentation results in the automatic creation of an agent that will receive the necessary data on the remote machine and forward that data to the collector service. In the URL, you must specify the address of this collector. The URL is known in advance if you already know on which server you plan to install the service. However, this field can also be filled after the Installation Wizard is finished by copying the URL data from the Resources → Active services section.

  • Description—up to 256 Unicode characters describing the resource.
  • Default credentials—drop-down list that does not require any value to be selected. The account credentials used to connect to hosts must be provided in the Remote hosts table (see below).

    Selecting a secret from the Default credentials drop-down list will cause the connector to work incorrectly.

  • The Remote hosts table lists the remote Windows assets that you can connect to. Available columns:
    • Host (required) is the IP address or domain name of the asset from which you want to receive data. For example, "machine-1.example.com".
    • Domain (required)—name of the domain in which the remote device resides. For example, "example.com"
    • Log type—drop-down list to select the name of the Windows logs that you need to retrieve. By default, only preconfigured logs are displayed in the list, but you can add custom logs to the list by typing their name in the Windows logs field and then pressing ENTER. KUMA service and resource configurations may require additional changes in order to process custom logs correctly.

      Logs that are available by default:

      • Application
      • ForwardedEvents
      • Security
      • System
      • HardwareEvents
    • Secret—account credentials for accessing a remote Windows asset with permissions to read the logs. The login in the secret resource must be specified without the domain. The domain value for accessing the host is taken from the Domain column of the Remote hosts table.

      You can select the secret resource from the drop-down list or create one using the button. The selected secret can be changed by clicking on the button.

• Advanced settings tab:
  • Character encoding setting specifies character encoding. The default value is UTF-8.
  • Compression—you can use Snappy compression. By default, compression is disabled.
  • Debug—a drop-down list where you can specify whether resource logging should be enabled. By default it is Disabled.

Receiving events from a remote machine

Conditions for receiving events from a remote Windows machine hosting a KUMA agent:

• To start the KUMA agent on the remote machine, you must use an account with the Log on as a service permissions.
• To receive events from the KUMA agent, you must use an account with Event Log Readers permissions. For domain servers, one such user account can be created so that a group policy can be used to distribute its rights to read logs to all servers and workstations in the domain.
• TCP ports 135, 445, and 49152-65535 must be opened on the remote Windows machines.
• You need to launch the following services on the remote machines:
  • Remote Procedure Call (RPC)
  • RPC Endpoint Mapper

[Topic 220752]

Wec type

The wec type is used to receive data using the Windows Event Collector. It is available for Windows Agents.

To start the KUMA agent on the remote machine, you must use an account with the Log on as a service permissions.

To receive events, you must use an account with Event Log Readers permissions. For domain servers, one such user account can be created so that a group policy can be used to distribute its rights to read logs to all servers and workstations in the domain.

Available settings:

• Basic settings tab:
  • Name (required)—a unique name for this type of resource. Must contain from 1 to 128 Unicode characters.
  • Tenant (required)—name of the tenant that owns the resource.
  • Type (required)—connector type.
  • URL (required)—URL of the collector being created, for example: kuma-collector.example.com:7221.

    The creation of a collector for receiving data using Windows Event Collector results in the automatic creation of an agent that will receive the necessary data on the remote machine and forward that data to the collector service. In the URL, you must specify the address of this collector. The URL is known in advance if you already know on which server you plan to install the service. However, this field can also be filled after the Installation Wizard is finished by copying the URL data from the Resources → Active services section.

  • Description—up to 256 Unicode characters describing the resource.
  • Windows logs (required)—Select the names of the Windows logs you want to retrieve from this drop-down list. By default, only preconfigured logs are displayed in the list, but you can add custom logs to the list by typing their name in the Windows logs field and then pressing ENTER. KUMA service and resource configurations may require additional changes in order to process custom logs correctly.

    Preconfigured logs:

    • Application
    • ForwardedEvents
    • Security
    • System
    • HardwareEvents
• Advanced settings tab:
  • Character encoding setting specifies character encoding. The default value is UTF-8.
  • Compression—you can use Snappy compression. By default, compression is disabled.
  • Debug—a drop-down list where you can specify whether resource logging should be enabled. By default it is Disabled.

[Topic 220753]

Snmp type

The snmp type is used to receive data using the Simple Network Management Protocol. It is available for Windows and Linux Agents. Supported protocol versions:

• snmpV1
• snmpV2
• snmpV3

Available settings:

• Basic settings tab:
  • Name (required)—a unique name for this type of resource. Must contain from 1 to 128 Unicode characters.
  • Tenant (required)—name of the tenant that owns the resource.
  • Type (required)—connector type.
  • SNMP version (required)—This drop-down list allows you to select the version of the protocol to use.
  • Host (required)—hostname or its IP address. Available formats: hostname, IPv4, IPv6.
  • Port (required)—port for connecting to the host. Typically 161 or 162 are used.

  The SNMP version, Host and Port settings define one connection to a SNMP resource. You can create several such connections in one connector by adding new ones using the SNMP resource button. You can delete connections by using the button.

  • Secret (required) is a drop-down list to select the secret resource which stores the credentials for connecting via the Simple Network Management Protocol. The secret type must match the SNMP version. If required, a secret can be created in the connector creation window using the button. The selected secret can be changed by clicking on the button.
  • In the Source data table you can specify the rules for naming the received data, according to which OIDs, object identifiers, will be converted into keys with which the normalizer can interact. Available table columns:
    • Parameter name (required)—an arbitrary name for the data type. For example, "Site name" or "Site uptime".
    • OID (required)—a unique identifier that determines where to look for the required data at the event source. For example, "1.3.6.1.2.1.1.5".
    • Key (required)—a unique identifier returned in response to a request to the asset with the value of the requested setting. For example, "sysName". This key can be accessed when normalizing data.
  • Description—up to 256 Unicode characters describing the resource.
• Advanced settings tab:
  • Character encoding setting specifies character encoding. The default value is UTF-8.
  • Compression—you can use Snappy compression. By default, compression is disabled.
  • Debug—a drop-down list where you can specify whether resource logging should be enabled. By default it is Disabled.

[Topic 217942]

Normalizers

Normalizer resources are used to convert raw events of various formats so that they conform to the KUMA event data model. This turns them into normalized events that can be processed by other KUMA resources and services.

A normalizer resource consists of the main normalizer and optional extra normalizers. Data is transmitted through a tree-like structure of normalizers depending on the defined conditions, which lets you configure complex logic for processing events.

A normalizer resource is created in several steps:

1. Creating the main normalizer

   The main normalizer is created by using the Add event parsing button. Entry of normalizer settings is finished by clicking OK.

   The main normalizer that you created will be displayed as a dark circle. Clicking on the circle will open the normalizer options for editing. When you hover over the circle, a plus sign is displayed. Click it to add more normalizers.

2. Creating conditions for using an extra normalizer

   Clicking on the normalizer plus sign opens the Add normalizer to normalization scheme window in which you can specify the conditions that will cause data to be forwarded to the new normalizer.

3. Creating an extra normalizer

   When the previous step is finished, a window will open for creating an extra normalizer. Entry of normalizer settings is finished by clicking OK.

   The extra normalizer you created is displayed as a dark block that indicates the conditions under which this normalizer will be used (see step 2). The conditions can be changed by moving your mouse cursor over the extra normalizer and clicking the button showing the pencil image.

   If you hover the mouse pointer over the extra normalizer, a plus button appears, which you can use to create a new extra normalizer. To delete a normalizer, use the button with the trash icon.

   If you need to create more normalizers, repeat steps 2 and 3.

4. Completing creation of a normalizer resource

   Normalizer resource creation is finished by clicking the Save button.

For these resources, you can enable the display of control characters in all input fields except the Description field.

If you modify or delete conversions in the normalizer resource within the existing set of resources for the collector, the changes in the normalizer are not saved and the resource may become corrupted. If you need to modify conversions in a normalizer that is already part of a service, the changes must be made directly to the resource under Resources → Normalizers in the web interface.

[Topic 221932]

Normalizer settings

The normalizer window contains two tabs: Normalization scheme and Enrichment.

Normalization scheme

This tab is used to specify the main settings of the normalizer and to define the rules for converting events into KUMA format.

Available settings:

• Name (required)—the name of the normalizer. Must contain from 1 to 128 Unicode characters. The name of the main normalizer will be used as the name of the normalizer resource.
• Tenant (required)—name of the tenant that owns the resource.

  This setting is not available for extra normalizers.

• Parsing method (required)—drop-down list for selecting the type of incoming events. Depending on your choice, you can use the preconfigured rules for matching event fields or set your own rules. When you select some parsing methods, additional parameter fields required for filling in may become available.

  Available parsing methods:

  • json

    This parsing method is used to process JSON data.

  • cef

    This parsing method is used to process CEF data.

    When choosing this method, you can use the preconfigured rules for converting events to the KUMA format by clicking the Apply default mapping button.

  • regexp

    This parsing method is used to create custom rules for processing JSON data.

    In the Normalization parameter block field, add a regular expression (RE2 syntax) with named capture groups. The name of a group and its value will be interpreted as the field and the value of the raw event, which can be converted into an event field in KUMA format.

    To add event handling rules:

    1. Copy an example of the data you want to process to the Event examples field. This is an optional but recommended step.
    2. In the Normalization parameter block field add a regular expression with named capture groups in RE2 syntax, for example "(?P<name>regexp)".

       You can add multiple regular expressions by using the Add regular expression button. If you need to remove the regular expression, use the button.

    3. Click the Copy field names to the mapping table button.

       Capture group names are displayed in the KUMA field column of the Mapping table. Now you can select the corresponding KUMA field in the column next to each capture group. Otherwise, if you named the capture groups in accordance with the CEF format, you can use the automatic CEF mapping by selecting the Use CEF syntax for normalization check box.

    Event handling rules were added.

  • syslog

    This parsing method is used to process data in syslog format.

    When choosing this method, you can use the preconfigured rules for converting events to the KUMA format by clicking the Apply default mapping button.

  • csv

    This parsing method is used to create custom rules for processing CSV data.

    When choosing this method, you must specify one of the possible delimiters for values in the Delimiter field:

    • \n (used by default)
    • \t
    • \0
  • kv

    This parsing method is used to process data in key-value pair format.

    If you select this method, you must provide values in the following required fields:

    • Pair delimiter—specify a character that will serve as a delimiter for key-value pairs. By default, the line feed character is used, although you can specify any one-character (1 byte) value, provided that the character is not the same as the value delimiter.
    • Value delimiter—specify a character that will serve as a delimiter between the key and the value. By default, the "=" character is used, however, you can specify any one-character (1 byte) value, provided that the character is not the same as the delimiter of key-value pairs.
  • xml

    This parsing method is used to process XML data.

    When this method is selected in the parameter block XML Attributes you can specify the key attributes to be extracted from tags. If an XML structure has several attributes with different values in the same tag, you can indicate the necessary value by specifying its key in the Source column of the Mapping table.

    To add key XML attributes,

    Click the Add field button, and in the window that appears, specify the path to the required attribute.

    You can add more than one attribute. Attributes can be removed one at a time using the cross icon or all at once using the Reset button.

    If XML key attributes are not specified, then in the course of field mapping the unique path to the XML value will be represented by a sequence of tags.

  • netflow5

    This parsing method is used to process data in the NetFlow v5 format.

    When choosing this method, you can use the preconfigured rules for converting events to the KUMA format by clicking the Apply default mapping button.

    In mapping rules, the protocol type for netflow is not indicated in the fields of KUMA events by default. When parsing data in NetFlow format on the Enrichment normalizer tab, you should create a constant data enrichment rule that adds the netflow value to the DeviceProduct target field.

  • netflow9

    This parsing method is used to process data in the NetFlow v9 format.

    When choosing this method, you can use the preconfigured rules for converting events to the KUMA format by clicking the Apply default mapping button.

    In mapping rules, the protocol type for netflow is not indicated in the fields of KUMA events by default. When parsing data in NetFlow format on the Enrichment normalizer tab, you should create a constant data enrichment rule that adds the netflow value to the DeviceProduct target field.

  • ipfix

    This parsing method is used to process IPFIX data.

    When choosing this method, you can use the preconfigured rules for converting events to the KUMA format by clicking the Apply default mapping button.

    In mapping rules, the protocol type for netflow is not indicated in the fields of KUMA events by default. When parsing data in NetFlow format on the Enrichment normalizer tab, you should create a constant data enrichment rule that adds the netflow value to the DeviceProduct target field.

  • sql

    This parsing method is used to process SQL data.

• Keep raw log (required)—in this drop-down list, you can indicate whether you need to store the original raw event in the newly created normalized event. Available values:
  • Never—do not save the raw event This is the default setting.
  • Only errors—save the raw event in the Raw field of the normalized event if errors occurred when parsing it. This value is convenient to use when debugging a service. In this case, every time an event has a non-empty Raw field, you know there was a problem.

    If fields containing the names *Address or *Date* do not comply with normalization rules, these fields are ignored. No normalization error will occur, and the values of the fields will not show up in the Raw field of the normalized event even if Keep raw log → Only errors was indicated.

  • Always—always save the raw event in the Raw field of the normalized event.

  This setting is not available for extra normalizers.

• Save extra fields (required)—in this drop-down list, you can choose whether you need to save fields of the original event in the normalized event if no mapping rules have been configured for them (see below). The data is stored in the Extra event field. By default, fields are not saved.
• Description—up to 256 Unicode characters describing the resource.

  This setting is not available for extra normalizers.

• Event examples—in this field, you can provide an example of data that you want to process. Event examples can also be loaded from a TSV, CSV, or TXT file by using the Load from file button.
• Mapping settings block—here you can configure mapping of original event fields to fields of the event in KUMA format:
  • Source—column for the names of the original event fields that you want to convert into KUMA event fields.

    Clicking the button next to the field names in the Source column opens the Conversion window, in which you can use the Add conversion button to create rules for modifying the original data before they are written to the KUMA event fields.

    Available conversions

    Conversions are changes that can be applied to a value before it gets written to the event field. The conversion type is selected from a drop-down list.

    Available conversions:

    • lower—is used to make all characters of the value lowercase
    • upper—is used to make all characters of the value uppercase
    • regexp—is used to apply a RE2 regular expression to the value. When this conversion type is selected, the field appears where regular expression should be added.
    • substring—is used to extract characters in the position range specified in the Start and End fields. These fields appear when this conversion type is selected.
    • replace—is used to replace specified character sequence with the other character sequence. When this type of conversion is selected, new fields appear:
      • Replace chars—in this field you can specify the character sequence that should be replaced.
      • With chars—in this field you can specify the characters sequence should be used instead of replaced characters.
    • trim—used to simultaneously remove the characters specified in the Chars field from the leading and end positions of the value. The field appears when this type of conversion is selected. For example, a trim conversion with the value Micromon for the value Microsoft-Windows-Sismon results in the value soft-Windows-Sys.
    • append is used to add the characters specified in the Constant field to the end of the event field value. The field appears when this type of conversion is selected.
    • prepend—used to prepend the characters specified in the Constant field to the start of the event field value. The field appears when this type of conversion is selected.
    • replace with regexp—is used to replace RE2 regular expression results with the character sequence.
      • Expression—in this field you can specify the regular expression which results that should be replaced.
      • With chars—in this field you can specify the characters sequence should be used instead of replaced characters.
  • KUMA field—drop-down list for selecting the required fields of KUMA events. You can search for fields by entering their names in the field.
  • Label—in this column, you can add a unique custom label to event fields that begin with DeviceCustom*.

  New table rows can be added by using the Add row button. Rows can be deleted individually using the button or all at once using the Clear all button.

  If you have loaded data into the Event examples field, the table will have an Examples column containing examples of values carried over from the raw event field to the KUMA event field.

Enrichment

This tab is used to add additional data to fields of a normalized event by using enrichment rules similar to the rules in enrichment rule resources. These enrichment rules are stored in the normalizer resource where they were created. There can be more than one enrichment rule. Enrichments are created by using the Add enrichment button.

Settings available in the enrichment rule settings block:

• Source kind (required)—drop-down list for selecting the type of enrichment. Depending on the selected type, you may see advanced settings that will also need to be completed.

  Available Enrichment rule source types:

  • constant

    This type of enrichment is used when a constant needs to be added to an event field.

    When choosing this type, you must specify the value to add to the event field in the Constant field. The value should not be longer than 255 Unicode characters. If you leave this field blank, the existing event field value will be cleared.

  • dictionary

    This type of enrichment is used if you need to add a value from the dictionary to the event field.

    When this type is selected in the Dictionary name drop-down list, you must select the dictionary that will provide the values. In the Key fields settings block, you must use the Add field button to select the event fields whose values will be used for dictionary entry selection.

  • event

    This type of enrichment is used when you need to write a value from another event field to the current event field.

    When this type is selected in the Source field drop-down list, you must select the event field from where the value will be copied to the target field. Clicking the button opens the Conversion window in which you can, using the Add conversion button, create rules for modifying the original data before writing them to the KUMA event fields.

    Available conversions

    Conversions are changes that can be applied to a value before it gets written to the event field. The conversion type is selected from a drop-down list.

    Available conversions:

    • lower—is used to make all characters of the value lowercase
    • upper—is used to make all characters of the value uppercase
    • regexp—is used to apply a RE2 regular expression to the value. When this conversion type is selected, the field appears where regular expression should be added.
    • substring—is used to extract characters in the position range specified in the Start and End fields. These fields appear when this conversion type is selected.
    • replace—is used to replace specified character sequence with the other character sequence. When this type of conversion is selected, new fields appear:
      • Replace chars—in this field you can specify the character sequence that should be replaced.
      • With chars—in this field you can specify the characters sequence should be used instead of replaced characters.
    • trim—used to simultaneously remove the characters specified in the Chars field from the leading and end positions of the value. The field appears when this type of conversion is selected. For example, a trim conversion with the value Micromon for the value Microsoft-Windows-Sismon results in the value soft-Windows-Sys.
    • append is used to add the characters specified in the Constant field to the end of the event field value. The field appears when this type of conversion is selected.
    • prepend—used to prepend the characters specified in the Constant field to the start of the event field value. The field appears when this type of conversion is selected.
    • replace with regexp—is used to replace RE2 regular expression results with the character sequence.
      • Expression—in this field you can specify the regular expression which results that should be replaced.
      • With chars—in this field you can specify the characters sequence should be used instead of replaced characters.
  • template

    This type of enrichment is used when you need to write a value obtained by processing Go templates into the event field.

    When this type is selected, a Go template must be specified in the Template field.

    Event field names are passed in the {{.EventField}} format, where EventField is the name of the event field from which the value must be passed to the script.

    Example: Attack on {{.DestinationAddress}} from {{.SourceAddress}}

• Target field (required)—drop-down list for selecting the KUMA event field that should receive the data.

[Topic 221934]

Condition for forwarding data to an extra normalizer

The Add normalizer to normalization scheme window is used to specify the conditions under which the data will be sent to an extra normalizer.

Available settings:

• Fields to pass into normalizer—used to indicate event fields in case you want to send only events with specific fields to the extra normalizer.

  If you leave this field blank, the full event will be sent to the extra normalizer for processing.

• Use normalizer for events with specific event field values—used to indicate event fields if you want the extra normalizer to receive only events in which specific values are assigned to certain fields. The value is specified in the Condition value field.

  The data processed by these conditions can be preconverted by clicking the button. This opens the Conversion window, in which you can use the Add conversion button to create rules for modifying the original data before it is written to the KUMA event fields.

  Available conversions

  Conversions are changes that can be applied to a value before it gets written to the event field. The conversion type is selected from a drop-down list.

  Available conversions:

  • lower—is used to make all characters of the value lowercase
  • upper—is used to make all characters of the value uppercase
  • regexp—is used to apply a RE2 regular expression to the value. When this conversion type is selected, the field appears where regular expression should be added.
  • substring—is used to extract characters in the position range specified in the Start and End fields. These fields appear when this conversion type is selected.
  • replace—is used to replace specified character sequence with the other character sequence. When this type of conversion is selected, new fields appear:
    • Replace chars—in this field you can specify the character sequence that should be replaced.
    • With chars—in this field you can specify the characters sequence should be used instead of replaced characters.
  • trim—used to simultaneously remove the characters specified in the Chars field from the leading and end positions of the value. The field appears when this type of conversion is selected. For example, a trim conversion with the value Micromon for the value Microsoft-Windows-Sismon results in the value soft-Windows-Sys.
  • append is used to add the characters specified in the Constant field to the end of the event field value. The field appears when this type of conversion is selected.
  • prepend—used to prepend the characters specified in the Constant field to the start of the event field value. The field appears when this type of conversion is selected.
  • replace with regexp—is used to replace RE2 regular expression results with the character sequence.
    • Expression—in this field you can specify the regular expression which results that should be replaced.
    • With chars—in this field you can specify the characters sequence should be used instead of replaced characters.

[Topic 222424]

Preset normalizers

The normalizers listed in the table below are included in the KUMA kit.

Page top

[Topic 217880]

Filters

Filter resources are used to select events based on user-defined conditions.

This is not true only when filters are used in the collector service, in which the filters select all events that DO NOT satisfy filter conditions.

Filters can be used in collector services, enrichment rule resources, aggregation rule resources, response rule resources, correlation rule resources, and destination resources either as separate filter resources or as built-in filters stored in the service or resource where they were created.

For these resources, you can enable the display of control characters in all input fields except the Description field.

Available settings for filter resources:

• Name (required)—a unique name for this type of resource. Must contain from 1 to 128 Unicode characters. Inline filters are created in other resources or services and do not have names.
• Tenant (required)—name of the tenant that owns the resource.
• Conditions settings block—here you can formulate filtering criteria by creating filter conditions and groups of filters, and by adding existing filter resources.

  You can use the Add group button to add a group of filters. Group operators can be switched between AND, OR, and NOT. Groups, conditions, and existing filter resources can be added to groups of filters.

  You can use the Add filter button to add an existing filter resource, which should be selected in the Select filter drop-down list.

  You can use the Add condition button to add a string containing fields for identifying the condition (see below).

  Conditions, groups, and filters can be deleted by using the button.

Settings of conditions:

• When (required)—in this drop-down list, you can specify whether or not to use the inverted function of the operator.
• Left operand and Right operand (required)—used to specify the values that the operator will process. The available types depend on the selected operator.

  Operands of filters

  • Event field—used to assign an event field value to the operand. Advanced settings:
    • Event field (required)—this drop-down list is used to select the field from which the value for the operand should be extracted.
  • Active list—used to assign an active list record value to the operand. Advanced settings:
    • Active list (required)—this drop-down list is used to select the active list.
    • Key fields (required)—this is the list of event fields used to create the Active list entry and serve as the Active list entry key.
    • Field (required unless the inActiveList operator is selected)—used to enter the Active list field name from which the value for the operand should be extracted.
  • Dictionary—used to assign a dictionary resource value to the operand. Advanced settings:
    • Dictionary (required)—this drop-down list is used to select the dictionary.
    • Key fields (required)—this is the list of the event fields used to form the dictionary value key.
  • Constant—used to assign a custom value to the operand. Advanced settings:
    • Value (required)—here you enter the constant that you want to assign to the operand.
  • List—used to assign multiple custom values to the operand. Advanced settings:
    • Value (required)—here you enter the list of constants that you want to assign to the operand. When you type the value in the field and press ENTER, the value is added to the list and you can enter a new value.
  • TI—used to read the CyberTrace threat intelligence (TI) data from the events. Advanced settings:
    • Feed (required)—this field is used to specify the CyberTrace threat category.
    • Key fields (required)—this drop-down list is used to select the event field containing the CyberTrace threat indicators.
    • Field (required)—this field is used to specify the CyberTrace feed field containing the threat indicators.
• Operator (required)—used to select the condition operator.

  In this drop-down list, you can select the do not match case check box if the operator should ignore the case of values. This check box is ignored if the InSubnet, InActiveList, InCategory, and InActiveDirectoryGroup operators are selected. This check box is cleared by default.

  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 operator has only one operand. Its values are selected in the Key fields field and are compared with the entries in the active list selected from the Active List drop-down list.
  • 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.