[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

• Deep integration with the Kaspersky Endpoint Detection and Response Expert (KEDR Expert). Integration is available only with a Symphony XDR license.
• Added integration with Kaspersky Industrial CyberSecurity for Networks in asset inventory and response scenarios.
• Expanded integration with Kaspersky Security Center.
• Expanded capabilities for an SQL search based on events in storage.
• Expanded capabilities of event collection components (collectors):
  • Added enrichment with information about the region by IP address (GeoIP).
  • Added capability of enrichment from dictionaries (tables) filled in manually in the web interface or via API.
  • Added capability to adjust the time according to the time zone of the event source.
• Added computable variables to cover complex threat detection scenarios during event correlation.
• Added capability to collect events from an isolated segment containing a data diode when there is no possibility of transmitting network UDP packets.
• Added capability to configure custom templates and alert notification rules.
• Expanded analytics tools and added new widgets.
• Added asset audit function.
• Added sFlow traffic telemetry support for Juniper hardware. Similarly to Netflow, event data can be collected without limitations when using a license with an active Netflow 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

    Each collector that uses geographic data event enrichment requires an additional amount of RAM equal to the size of the geographic database.

  • 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

    When importing geographic data, the server requires additional RAM equal to the size of the geographic database.

  • 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

  To connect a data storage system to storage servers, you must use high-speed protocols (for example, Fibre Channel or iSCSI 10G). It is not recommended to connect storage systems using application-layer protocols (for example, NFS or SMB).

  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.

  Ext4 is the recommended file system for ClickHouse cluster servers.

• 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 (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.6
    • Astra Linux Special Edition RUSB.10015-01 (2021-1126SE17 update 1.7.1)
• Installation in virtual environments is supported:
  • VMware 6.5 or later
  • Hyper-V for Windows Server 2012 R2 or later
  • KVM Qumu version 4.2 or later
  • Software package of virtualization tools "Brest" RDTSP.10001-02

Software requirements

The Collector, Correlator, Kernel, and Storage components can be deployed using only Oracle Linux 8.6, or Astra Linux Special Edition (version RUSB.10015-01, 2021-1126SE17 update 1.7.1).

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

Computers used for the KUMA web interface:

• CPU: Intel Core i3 8th generation
• RAM: 8 GB
• Installed Google Chrome browser version 102 or later, or Mozilla Firefox browser version 103 or later.

[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)—Ctrl/Command + Enter.
  • Save a search query—Ctrl/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 or later.
• 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
   • sflow
   • nats
   • kafka
   • http
   • sql
   • file
   • diode
   • 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 filter out events that meet specified conditions. Events that do not meet the filtering conditions will be sent for processing.

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:

   • constants
   • cybertrace
   • dictionaries
   • dns
   • events
   • ldap
   • templates
   • timezone data
   • geographic data

   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), sFlow v5
   • 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 automatically placed in a separate storage space and stored for at least 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 severity 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 severity 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 severity to a certain category of assets, the base events involving these assets will trigger the creation of correlation events with higher severity. This in turn will cascade into higher severity 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. Like parts of an erector set, these components are assembled into resource sets for services that are then used as the basis for creating KUMA services.

[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 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.
• Diode agents are used together with data diodes to receive events from isolated network segments. They are installed to Linux 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 severity to correlation events and alerts based on correlation rule settings. The severity of an alert also depends on the assets related to the processed events because correlation rules take into account the severity of a related asset's category. If the alert or correlation event does not have linked assets with a defined severity or does not have any related assets at all, the severity of this alert or correlation event is equal to the severity of the correlation rule that triggered them. The alert or the correlation event severity is never lower than the severity of the correlation rule that triggered them.

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

Possible severity 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 SELinux module is NOT enabled in the operating system. KUMA and the KUMA installer cannot run at the same time while SELinux is enabled.
• 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:
  • netaddr
  • firewalld

  These packages can be installed using the following commands:

  • pip3 install netaddr
  • yum install firewalld

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:
  • python3-apt
  • curl
  • libcurl4

  These packages can be installed by running the apt install python3-apt curl libcurl4 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 be run from any folder.
• 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.
• Ext4 is the recommended file system for ClickHouse cluster servers.

[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 parameters of the single.inventory.yml: inventory file:
   • 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

[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 ClickHouse 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 a machine that coordinates data replication at the cluster level. There must be at least one machine with this role for the entire cluster. The recommended number of the machines with this role is 3. The number of machines involved in coordinating replication must be an odd number. The keeper and replica roles can be combined in one machine.

     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 238599]

Additional ClickHouse clusters

More than one ClickHouse storage cluster can be added to KUMA. The process of adding a new ClickHouse cluster consists of several steps:

1. Preparing the target machine

   On the target machine, specify the FQDN of the server with the KUMA Core in the /etc/hosts directory.

2. Preparing cluster inventory file

   Depending on the type of installation – local or remote – the inventory file is prepared on the target machine or on KUMA Core machine.

3. Installing additional cluster
4. Creating a storage

When creating storage cluster nodes, verify the network connectivity of the system and open the ports used by the components.

[Topic 238675]

Preparing cluster inventory file

Installation, update, and removal of KUMA components is performed from the directory 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 unarchived installer directory by executing the following command:

   cd kuma-ansible-installer

2. Create an inventory file by copying additional-storage-cluster.inventory.yml.template:

   cp additional-storage-cluster.inventory.yml.template additional-storage-cluster.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.

   • Set the ansible_connection parameter:
     • Specify local if you want to install the cluster locally:

       ansible_connection: local

     • Specify ssh if you want to install the cluster remotely, from a server with KUMA Core installed:

       ansible_connection: ssh

4. In the storage section, specify the full names of the domains of the hosts on which you want to install the cluster nodes in the inventory file. 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.

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

   A ClickHouse 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 a machine that coordinates data replication at the cluster level. There must be at least one machine with this role for the entire cluster. The recommended number of the machines with this role is 3. The number of machines involved in coordinating replication must be an odd number. The keeper and replica roles can be combined in one machine.

   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 create a ClickHouse cluster.

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 238677]

Installing additional cluster

KUMA is installed using the Ansible tool and the YML inventory file.

To install an additional KUMA cluster:

1. On a preconfigured target machine or a machine with the KUMA Core installed (depending on the ansible_connection setting), open the folder with an unpacked installer file.
2. Launch the installer by executing the following command:

   PYTHONPATH="$(pwd)/ansible/site-packages:${PYTHONPATH}" python3 ./ansible/bin/ansible-playbook -i additional-storage-cluster.inventory.yml additional-storage-cluster.playbook.yml

The additional ClickHouse cluster is installed. To write data to the cluster using KUMA, you need to create a storage.

[Topic 239283]

Deleting a cluster

To delete a ClickHouse cluster,

execute the following command:

systemctl stop kuma-storage-<storage ID> && systemctl stop kuma-clickhouse && systemctl disable kuma-storage-<storage ID> && systemctl disable kuma-clickhouse && rm -rf /usr/lib/systemd/system/kuma-storage-<storage ID>.service && rm -rf /usr/lib/systemd/system/kuma-clickhouse.service && systemctl daemon-reload && rm -rf /opt/kaspersky/kuma

The KUMA storage and ClickHouse cluster services are stopped and deleted.

[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 version 2.x over versions 1.5.x or later. 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, you need to clear your browser cache.

If after updating KUMA in the storage logs start appearing errors about suspicious strings, run the following command on the KUMA storage server: touch /opt/kaspersky/kuma/clickhouse/data/flags/force_restore_data && systemctl restart kuma-clickhouse.

[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.

[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

[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.

[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 a key file on the Kaspersky website based on the available activation code.

[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

You can configure integration with selected Kaspersky Security Center servers for one, several, or all KUMA tenants. If Kaspersky Security Center integration is enabled, you can import information about the assets protected by this application, manage assets using tasks, and import events from the Kaspersky Security Center event database.

First, you need to make sure that the relevant Kaspersky Security Center server allows an incoming connection for the server hosting KUMA.

Configuring KUMA integration with Kaspersky Security Center includes the following steps:

1. Creating a user account in the Kaspersky Security Center Administration Console

   The credentials of this account are used when creating a secret to establish a connection with Kaspersky Security Center. The account must be assigned general administrator rights.

   For more details about creating a user account and assigning permissions to a user, please refer to the Kaspersky Security Center Help Guide.

2. Creating a secret of the credentials type for connecting to Kaspersky Security Center
3. Configuring Kaspersky Security Center integration settings
4. Creating a connection to the Kaspersky Security Center server for importing information about assets

   If you want to import information about assets registered on Kaspersky Security Center servers into KUMA, you need to create a separate connection to each Kaspersky Security Center server for each selected tenant.

   If integration is disabled for the tenant or there is no connection to Kaspersky Security Center, an error is displayed in the KUMA web interface when attempting to import information about assets. In this case, the import process does not start.

[Topic 217933]

Configuring Kaspersky Security Center integration settings

To configure the settings for integration with Kaspersky Security Center:

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

   The Kaspersky Security Center integration by tenant window opens.

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

   The Kaspersky Security Center integration window opens.

3. For the Disabled check box, do one of the following:
   • Clear the check box if you want to enable integration with Kaspersky Security Center for this tenant.
   • Select the check box if you want to disable integration with Kaspersky Security Center for this tenant.

   This check box is cleared by default.

4. In the Data refresh interval field, specify the time interval at which KUMA updates data on Kaspersky Security Center devices.

   The interval is specified in hours and must be an integer.

   The default time interval is 12 hours.

5. Click the Save button.

The Kaspersky Security Center integration settings for the selected tenant will be configured.

If the required tenant is not in the list of tenants, you need to add it to the list.

[Topic 232734]

Adding a tenant to the list for Kaspersky Security Center integration

To add a tenant to the list of tenants for integration with Kaspersky Security Center:

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

   The Kaspersky Security Center integration by tenant window opens.

2. Click the Add tenant button.

   The Kaspersky Security Center integration window opens.

3. In the Tenant drop-down list, select the tenant that you need to add.
4. Click the Save button.

The selected tenant will be added to the list of tenants for integration with Kaspersky Security Center.

[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 Kaspersky Security Center integration by tenant window opens.

2. Select the tenant for which you want to create a connection to Kaspersky Security Center.
3. Click the Add connection button and define the values for the following settings:
   • Name (required)—the name of the connection. The name can contain from 1 to 128 Unicode characters.
   • URL (required)—the URL of the Kaspersky Security Center server in hostname:port or IPv4:port format.
   • In the Secret drop-down list, select the secret resource with the Kaspersky Security Center account credentials or create a new secret resource.
     1. Click the button.

        The secret window is displayed.

     2. 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 the account credentials for your Kaspersky Security Center server.
        5. If you want, enter a Description of the secret.
     3. Click Save.

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

   • Disabled—the state of the connection to the selected Kaspersky Security Center server. If the check box is selected, the connection to the selected server is inactive. If this is the case, you cannot use this connection to connect to the Kaspersky Security Center server.

     This check box is cleared by default.

4. If you want KUMA to import only assets that are connected to secondary servers or included in groups:
   1. Click the Load hierarchy button.
   2. Select the check boxes next to the names of the secondary servers and groups from which you want to import asset information.
   3. If you want to import assets only from new groups, select the Import assets from new groups check box.

   If no check boxes are selected, information about all assets of the selected Kaspersky Security Center server is uploaded during the import.

5. Click the Save button.

The connection to the Kaspersky Security Center server is now 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 Kaspersky Security Center integration by tenant window opens.

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

   The Kaspersky Security Center integration 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 Kaspersky Security Center integration by tenant window opens.

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

   The Kaspersky Security Center integration 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

You can connect Kaspersky Security Center assets to KUMA and download database and application module updates to these assets, or run an anti-virus scan on them by using Kaspersky Security Center tasks. Tasks are started in the KUMA web interface.

To run Kaspersky Security Center tasks on assets connected to KUMA, it is recommended to use the following script:

1. Creating a user account in the Kaspersky Security Center Administration Console

   The credentials of this account are used when creating a secret to establish a connection with Kaspersky Security Center, and can be used to create a task.

   For more details about creating a user account and assigning permissions to a user, please refer to the Kaspersky Security Center Help Guide.

2. Creating KUMA tasks in Kaspersky Security Center
3. Configuring KUMA integration with Kaspersky Security Center
4. Importing asset information from Kaspersky Security Center into KUMA
5. Assigning a category to the imported assets

   After import, the assets are automatically placed in the Uncategorized devices group. You can assign one of the existing categories to the imported assets, or create a category and assign it to the assets.

6. Running tasks on assets

   You can manually start tasks in the asset information or configure tasks to start automatically.

[Topic 218009]

Starting Kaspersky Security Center tasks manually

You can manually run the anti-virus database, application module update task, and the anti-virus scan task on Kaspersky Security Center assets connected to KUMA. The assets must have Kaspersky Endpoint Security for Windows or Linux installed.

First, you need to configure the integration of Kaspersky Security Center with KUMA and create tasks in Kaspersky Security Center.

To manually start a Kaspersky Security Center task:

1. In the Assets section of the KUMA web interface, select the asset that was 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, select the Save filter check box.

      In this case, you will be able to use the created filter in various services.

      This check box is cleared by default.

   3. If you selected the Save filter check box, 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.
         • hasBit—checks whether the left operand (string or number) contains bits whose positions are listed in the right operand (in a constant or in a list).
         • hasVulnerability—checks whether the left operand contains an asset with the vulnerability and vulnerability severity specified in the right operand.
         • 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.
         • inDictionary—checks whether the specified dictionary contains an entry defined by the key composed with the concatenated values of the selected event fields.
         • 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 [OOTB] KSC SQL and normalizer [OOTB] 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 [OOTB] KSC SQL connector:
   • In the URL field, specify the server connection address 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 [OOTB] 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 235592]

Kaspersky Endpoint Detection and Response integration

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

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

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

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

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

You can manage response actions only if you have a Kaspersky Symphony XDR license.

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

[Topic 234627]

Importing events from Kaspersky Endpoint Detection and Response

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

Kaspersky Endpoint Detection and Response 4.0 raw events can be imported into KUMA with the help of a Kafka connector.

To import events, you will need to perform actions on the Kaspersky Endpoint Detection and Response side and on the KUMA side.

On the Kaspersky Endpoint Detection and Response side, perform the following actions:

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

   The program component administrator menu is displayed.

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

   The Technical Support Mode confirmation window opens.

5. Confirm that you want to operate the application in Technical Support Mode. To do so, select Yes and press Enter.
6. Run the sudo -i command.
7. In the /etc/sysconfig/apt-services configuration file, in the KAFKA_PORTS field, delete the value 10000.

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

   It is strongly not recommended to use this port for any external connections other than KUMA. To restrict connection on port 10000 to KUMA only, run the command iptables -I INPUT -p tcp! -s KUMA_IP_address --dport 10000 -j DROP.

8. Run the command systemctl restart apt_ipsec.service.
9. In the configuration file /usr/bin/apt-start-sedr-iptables add the value 10000 in the WEB_PORTS field, separated by a comma without a space.
10. Run sudo sh /usr/bin/apt-start-sedr-iptables.

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

On the KUMA side, complete the following steps:

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

   When creating the connector, in the URL field, you will need to specify the <Central Node server IP address>:10000.

3. In the KUMA web interface, create a collector.

   Use the connector created at the previous step as the transport for the collector.

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

[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 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, select the Save filter check box.

          In this case, you will be able to use the created filter in various services.

          This check box is cleared by default.

       3. If you selected the Save filter check box, 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.
             • hasBit—checks whether the left operand (string or number) contains bits whose positions are listed in the right operand (in a constant or in a list).
             • hasVulnerability—checks whether the left operand contains an asset with the vulnerability and vulnerability severity specified in the right operand.
             • 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.
             • inDictionary—checks whether the specified dictionary contains an entry defined by the key composed with the concatenated values of the selected event fields.
             • 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.

[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 info from 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. In KUMA integration settings are available only for general administrators.

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 web interface under Settings → IRP / SOAR.

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, go to Settings → IRP / SOAR.

   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 IRP / SOAR (required)—drop-down list for selecting the KUMA event fields that should be sent to R-Vision IRP.
   • Severity group of settings (required)—used to map KUMA severity values to R-Vision IRP severity 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 version 4.0 user with the Incident Manager role

     

     R-Vision IRP version 5.0 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 version 4.0

     

     API token in R-Vision IRP version 5.0

     

• 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.

     Incidents categories with data from KUMA alerts in R-Vision IRP version 4.0

     

     Incidents categories with data from KUMA alerts in R-Vision IRP version 5.0

     

  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.

     The Alert URL field is not editable in R-Vision IRP version 4.0

     

     The Alert URL field is not editable in R-Vision IRP version 5.0

     

• 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 in R-Vision IRP version 4.0

ALERT_ID field in R-Vision IRP version 5.0

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 in R-Vision IRP version 4.0

ALERT_URL field in R-Vision IRP version 5.0

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 → Common → Collectors, 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. Click Add.
6. On the Organizations tab, select the organization for which you want to add integration with KUMA and select the Default collector and Response collector check boxes.

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.

The connector has been created.

Connector in R-Vision IRP version 4.0

Connector in R-Vision IRP version 5.0

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.

The connector is configured.

Connector in R-Vision IRP version 4.0

Connector in R-Vision IRP version 5.0

[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 version 4.0 playbook rule

R-Vision IRP version 5.0 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 severity.
  • 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 in the KUMA web interface. The LDAP server integration by tenant section shows the tenants for which LDAP connections were created. Tenants can be created or deleted.

If you select a tenant, the LDAP server integration window opens to show a table containing existing LDAP connections. Connections can be created or edited. In this window, you can change the frequency of queries sent to LDAP servers and set the retention period for obsolete data.

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

[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. In the KUMA web interface, open Settings → LDAP server and select the tenant for which you want to enable or disable all LDAP connections.

   The LDAP server integration by tenant window opens.

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

To enable or disable a specific LDAP connection:

1. In the KUMA web interface, open Settings → LDAP server and select the tenant for which you want to enable or disable an LDAP connection.

   The LDAP server integration window opens.

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

[Topic 233077]

Adding a tenant to the LDAP server integration list

To add a tenant to the list of tenants for integration with an LDAP server:

1. Open the KUMA web interface and select Settings → LDAP server.

   The LDAP server integration by tenant window opens.

2. Click the Add tenant button.

   The LDAP server integration window is displayed.

3. In the Tenant drop-down list, select the tenant that you need to add.
4. Click Save.

The selected tenant is added to the LDAP server integration list.

To delete a tenant from the list of tenants for integration with an LDAP server:

1. Open the KUMA web interface and select Settings → LDAP server.

   The LDAP server integration by tenant window is displayed.

2. Select the check box next to the tenant that you need to delete, and click Delete.
3. Confirm deletion of the tenant.

The selected tenant is deleted from the LDAP server integration list.

[Topic 217795]

Creating an LDAP server connection

To create a new LDAP connection to Active Directory:

1. In the KUMA web interface, open Settings → LDAP server.
2. Select or create a tenant for which you want to create a LDAP connection.

   The LDAP server integration by tenant window opens.

3. Click the Add connection button.

   The Connection parameters 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. You must use the certificate of the certification authority that signed the LDAP server certificate. You may not use custom certificates. To add a certificate:
   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 server integration window.

Account information from Active Directory will be requested immediately after the connection is saved, and then it will be updated at the specified frequency.

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 an LDAP server connection

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

To copy an LDAP connection:

1. In the KUMA web interface, open Settings → LDAP server and select the tenant for which you want to copy an LDAP connection.

   The LDAP server integration window opens.

2. Select the relevant connection.
3. In the opened Connection parameters window, click the Duplicate connection button.

   The New Connection window opens. The word copy will be added to the connection name.

4. If necessary, change the relevant settings.
5. Click the Save button.

The new connection is 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 233080]

Changing an LDAP server connection

To change an LDAP server connection:

1. Open the KUMA web interface and select Settings → LDAP server.

   The LDAP server integration by tenant window opens.

2. Select the tenant for which you want to change the LDAP server connection.

   The LDAP server integration window opens.

3. Click the LDAP server connection that you want to change.

   The window with the settings of the selected LDAP server connection opens.

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

The LDAP server connection is changed. Restart the KUMA services that use LDAP server data enrichment for the changes to take effect.

[Topic 233081]

Changing the data update frequency

KUMA queries the LDAP server to update account data. This occurs:

• Immediately after creating a new connection.
• Immediately after changing the settings of an existing connection.
• According to a regular schedule every several hours. Every 12 hours by default.
• Whenever a user creates a task to update account data.

When querying LDAP servers, a task is created in the Task manager section of the KUMA web interface.

To change the schedule of KUMA queries to LDAP servers:

1. In the KUMA web interface, open Settings → LDAP server → LDAP server integration by tenant.
2. Select the relevant tenant.

   The LDAP server integration window opens.

3. In the Data refresh interval field, specify the required frequency in hours. The default value is 12.

The query schedule has been changed.

[Topic 233213]

Changing the data storage period

Received user account data is stored in KUMA for 90 days by default if information about these accounts is no longer received from the Active Directory server. After this period, the data is deleted.

After KUMA account data is deleted, new and existing events are no longer enriched with this information. Account information will also be unavailable in alerts. If you want to view information about accounts throughout the entire period of alert storage, you must set the account data storage period to be longer than the alert storage period.

To change the storage period for the account data:

1. In the KUMA web interface, open Settings → LDAP server → LDAP server integration by tenant.
2. Select the relevant tenant.

   The LDAP server integration window opens.

3. In the Data storage time field, specify the number of days you need to store data received from the LDAP server.

The account data storage period is changed.

[Topic 233094]

Starting account data update tasks

After a connection to an Active Directory server is created, tasks to obtain account data are created automatically. This occurs:

• Immediately after creating a new connection.
• Immediately after changing the settings of an existing connection.
• According to a regular schedule every several hours. Every 12 hours by default. The schedule can be changed.

Account data update tasks can be created manually. You can download data for all connections or for one connection of the required tenant.

To start an account data update task for all LDAP connections of a tenant:

1. In the KUMA web interface, open Settings → LDAP server → LDAP server integration by tenant.
2. Select the relevant tenant.

   The LDAP server integration window opens.

3. Click the Import accounts button.

A task to receive account data from the selected tenant is added to the Task manager section of the KUMA web interface.

To start an account data update task for one LDAP connection of a tenant:

1. In the KUMA web interface, open Settings → LDAP server → LDAP server integration by tenant.
2. Select the relevant tenant.

   The LDAP server integration window opens.

3. Select the relevant LDAP server connection.

   The Connection parameters window opens.

4. Click the Import accounts button.

A task to receive account data from the selected connection of the tenant is added to the Task manager section of the KUMA web interface.

[Topic 217830]

Deleting an LDAP server connection

To delete LDAP connection to Active Directory:

1. In the KUMA web interface, open Settings → LDAP server and select the tenant that owns the relevant LDAP connection.

   The LDAP server integration window opens.

2. Click the LDAP connection that you want to delete and click the Delete button.
3. Confirm deletion of the connection.

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.

You can also check the connection for the previously entered domain controller connection settings.

To check the connection to the domain controller:

1. In the program web interface, select Settings → Domain authorization.
2. In the Test connection settings block, select the relevant secret in the User credentials field.

   If necessary, you can create a new secret by clicking the button or change the settings of an existing secret by clicking the button.

3. Click Test.

A pop-up notification is displayed with the test results. The pop-up notification shows the following message: Connection established. If a connection could not be established, the reason for the lack of connection is displayed.

[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]

RuCERT integration

In the KUMA web interface, you can create a connection to the National Computer Incident Response & Coordination Center 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. For example: https://example.cert.gov.ru/api/v2/
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 → Incidents (2 lines) → All incidents (2 lines). 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 (Incidents) handler is used for processing data. The settings of the 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 Incident (2 lines) 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 233668]

Kaspersky Industrial CyberSecurity for Networks integration

Kaspersky Industrial CyberSecurity for Networks (hereinafter referred to as "KICS for Networks") is an application designed to protect the industrial enterprise infrastructure from information security threats, and to ensure uninterrupted operation. The application analyzes industrial network traffic to identify deviations in the values of process parameters, detect signs of network attacks, and monitor the operation and current state of network devices.

KICS for Networks version 4.0 or later can be integrated with KUMA. After configuring integration, you can perform the following tasks in KUMA:

• Import asset information from KICS for Networks to KUMA.
• Send asset status change commands from KUMA to KICS for Networks.

Unlike KUMA, KICS for Networks refers to assets as devices.

The integration of KICS for Networks and KUMA must be configured in both applications:

1. In KICS for Networks, you need to create a KUMA connector and save the communication data package of this connector.
2. In KUMA, the communication data package of the connector is used to create a connection to KICS for Networks.

The integration described in this section applies to importing asset information. KICS for Networks can also be configured to send events to KUMA. To do so, you need to create a SIEM/Syslog connector in KICS for Networks, and configure a collector on the KUMA side.

[Topic 233670]

Configuring integration in KICS for Networks

The program supports integration with KICS for Networks version 4.0 or later.

It is recommended to configure integration of KICS for Networks and KUMA after ending Process Control rules learning mode. For more details, please refer to the documentation on KICS for Networks.

On the KICS for Networks side, integration configuration consists of creating a KUMA-type connector. In KICS for Networks, connectors are specialized application modules that enable KICS for Networks to exchange data with recipient systems, including KUMA. For more details on creating connectors, please refer to the documentation on KICS for Networks.

When a connector is added to KICS for Networks, a communication data package is automatically created for this connector. This is an encrypted configuration file for connecting to KICS for Networks that is used when configuring integration on the KUMA side.

[Topic 233669]

Configuring integration in KUMA

It is recommended to configure integration of KICS for Networks and KUMA after ending Process Control rules learning mode. For more details, please refer to the documentation on KICS for Networks.

To configure integration with KICS for Networks in KUMA:

1. Open the KUMA web interface and select Settings → Kaspersky Industrial CyberSecurity for Networks.

   The Kaspersky Industrial CyberSecurity for Networks integration by tenant window opens.

2. Select or create a tenant for which you want to create an integration with KICS for Networks.

   The Kaspersky Industrial CyberSecurity for Networks integration window opens.

3. Click the Communication data package field and select the communication data package that was created in KICS for Networks.
4. In the Communication data package password field, enter the password of the communication data package.
5. Select the Enable response check box if you want to change the statuses of KICS for Networks assets by using KUMA response rules.
6. Click Save.

Integration with KICS for Networks is configured in KUMA, and the window shows the IP address of the node where the KICS for Networks connector will be running and its ID.

[Topic 233717]

Enabling and disabling integration with KICS for Networks

To enable or disable KICS for Networks integration for a tenant:

1. In the KUMA web interface, open Settings → Kaspersky Industrial CyberSecurity for Networks and select the tenant for which you want to enable or disable KICS for Networks integration.

   The Kaspersky Industrial CyberSecurity for Networks integration window opens.

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

[Topic 233718]

Changing the data update frequency

KUMA queries KICS for Networks to update its asset information. This occurs:

• Immediately after creating a new integration.
• Immediately after changing the settings of an existing integration.
• According to a regular schedule every several hours. This occurs every 3 hours by default.
• Whenever a user creates a task for updating asset data.

When querying KICS for Networks, a task is created in the Task manager section of the KUMA web interface.

To edit the schedule for importing information about KICS for Networks assets:

1. In the KUMA web interface, open Settings → Kaspersky Industrial CyberSecurity for Networks.
2. Select the relevant tenant.

   The Kaspersky Industrial CyberSecurity for Networks integration window opens.

3. In the Data refresh interval field, specify the required frequency in hours. The default value is 3.

The import schedule has been changed.

[Topic 233699]

Special considerations when importing asset information from KICS for Networks

Importing assets

Assets are imported according to the asset import rules. Only assets with the Authorized and Unauthorized statuses are imported.

KICS for Networks assets are identified by a combination of the following parameters:

• IP address of the KICS for Networks instance with which the integration is configured.
• KICS for Networks connector ID is used to configure the integration.
• ID assigned to the asset (or "device") in the KICS for Networks instance.

Importing vulnerability information

When importing assets, KUMA also receives information about active vulnerabilities in KICS for Networks. If a vulnerability has been flagged as Remediated or Negligible in KICS for Networks, the information about this vulnerability is deleted from KUMA during the next import.

Information about asset vulnerabilities is displayed in the localization language of KICS for Networks in the Asset details window in the Vulnerabilities settings block.

In KICS for Networks, vulnerabilities are referred to as risks and are divided into several types. All types of risks are imported into KUMA.

Imported data storage period

If information about a previously imported asset is no longer received from KICS for Networks, the asset is deleted after 30 days.

[Topic 233750]

Changing the status of a KICS for Networks asset

After configuring integration, you can change the statuses of KICS for Networks assets from KUMA. Statuses can be changed either automatically or manually.

Asset statuses can be changed only if you enabled a response in the settings for connecting to KICS for Networks.

Manually changing the status of a KICS for Networks asset

Users with the General Administrator, Administrator, and Analyst roles in the tenants available to them can manually change the statuses of assets imported from KICS for Networks.

To manually change a KICS for Networks asset status:

1. In the Assets section of the KUMA web interface, click the asset that you want to edit.

   The Asset details area opens in the right part of the window.

2. In the Status in KICS for Networks drop-down list, select the status that you need to assign to the KICS for Networks asset. The Authorized or Unauthorized statuses are available.

The asset status is changed. The new status is displayed in KICS for Networks and in KUMA.

Automatically changing the status of a KICS for Networks asset

Automatic changes to the statuses of KICS for Networks assets are implemented using response rules. The rules must be added to the correlator, which will determine the conditions for triggering these rules.

[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. Like parts of an erector set, these components are assembled into resource sets for services that are then used as the basis for creating KUMA services.

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 becomes 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 basic 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 rules—resources of this type are used in correlators to, for example, execute scripts or launch Kaspersky Security Center tasks when certain conditions are met.
• Notification templates—resources of this type are used when sending notifications about new alerts.
• 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, which 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 credentials) that KUMA needs to interact 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.
• 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]

Operations with resources

To manage KUMA resources, you can create, move, copy, edit, delete, import, and export them. These operations are available for all resources, regardless of the resource type.

KUMA resources reside in folders. You can add, rename, move, or delete resource folders.

[Topic 218051]

Creating, renaming, moving, and deleting resource 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]

Creating, duplicating, moving, editing, and deleting 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 will be created and 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.

The resources will be moved to the new folders.

You can only move resources to folders of the tenant in which the resources were created. Resources cannot be moved to another tenant's folders.

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 will be 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 will be 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 217783]

Correlation rules

Correlation rule resources are used in services of correlators to recognize specific sequences of processed events and to take certain actions after recognition, such as creating correlation events/alerts or interacting with an active list.

The available correlation rule settings depend on the selected type. Types of correlation rules:

• standard—used to find correlations between several events. Resources of this kind can create correlation events.

  This resource kind is used to determine complex correlation patterns. For simpler patterns you should use other correlation rule kinds that require less resources to operate.

• simple—used to create correlation events if a certain event was found.
• operational—used for operations with Active lists. This resource kind cannot create correlation events.

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

If a correlation rule is used in the correlator and an alert was created based on it, any change to the correlation rule resource will not result in a change to the existing alert even if the correlator service is restarted. For example, if the name of a correlation rule is changed, the name of the alert will remain the same. If you close the existing alert, a new alert will be created and it will take into account the changes made to the correlation rule resource.

[Topic 221197]

Standard correlation rules

Standard correlation rules are used to identify complex patterns in processed events.

The search for patterns is conducted by using buckets

The correlation rule resource window contains the following configuration tabs:

• General—used to specify the main settings of the correlation rule resource. On this tab, you can select the type of correlation rule.
• Selectors—used to define the conditions that the processed events must fulfill to trigger the correlation rule. Available parameters vary based on the selected resource type.
• Actions—used to set the triggers that will activate when the conditions configured in the Selectors settings block are fulfilled. The Correlation rule resource must have at least one trigger. Available parameters vary based on the selected resource type.

General tab

• Name (required)—a unique name for this type of resource. Must contain from 1 to 128 Unicode characters.
• Tenant (required)—the tenant that owns the correlation rule.
• Type (required)—a drop-down list for selecting the type of correlation rule. Select standard if you want to create a standard correlation rule.
• Identical fields (required)—the event fields that should be grouped in a Bucket. The hash of the values of the selected fields is used as the Bucket key. If the selector (see below) triggers, the selected fields will be copied to the correlation event.
• Unique fields—event fields that should be sent to the Bucket. If this parameter is set, the Bucket will receive only unique events. The hash of the selected fields' values is used as the Bucket key. If the Correlation rule triggers, the selected fields will be copied to the correlation event.
• Rate limit—maximum number of times a correlation rule can be triggered per second. The default value is 100.

  If correlation rules employing complex logic for pattern detection are not triggered, this may be due to the specific method used to count rule triggers in KUMA. In this case, try to increase the value of Rate limit to 1000000, for example.

• Window, sec (required)—bucket lifetime, in seconds. This timer starts when the Bucket is created (when it receives the first event). The lifetime is not updated, and when it runs out, the On timeout trigger from the Actions group of settings is activated and the bucket is deleted. The On every threshold and On subsequent thresholds triggers can be activated more than once during the lifetime of the bucket.
• Base events keep policy—this drop-down list is used to specify which base events must be stored in the correlation event:
  • first (default value)—this option is used to store the first base event of the event collection that triggered creation of the correlation event.
  • last—this option is used to store the last base event of the event collection that triggered creation of the correlation event.
  • all—this option is used to store all base events of the event collection that triggered creation of the correlation event.
• Priority—base coefficient used to determine the importance of a correlation rule. The default value is Low.
• Order by—in this drop-down list, you can select the event field that will be used by the correlation rule selectors to track situational changes. This could be useful if you want to configure a correlation rule to be triggered when several types of events occur sequentially, for example.
• Description—the description of a resource. Up to 256 Unicode characters.

Selectors tab

There can be multiple selectors in the standard resource kind. You can add selectors by clicking the Add selector button and can remove them by clicking the Delete selector button. Selectors can be moved by using the button.

For each selector, the following two tabs are available: Settings and Local variables.

The Settings tab contains the following settings:

• Alias (required)—unique name of the event group that meets the conditions of the selector. This name is used to identify events in the filter. Must contain from 1 to 128 Unicode characters.
• Selector threshold (event count) (required)—the number of events that must be received by the selector to trigger.
• Filter (required)—used to set the criteria for determining events that should trigger the selector. 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, select the Save filter check box.

     In this case, you will be able to use the created filter in various services.

     This check box is cleared by default.

  3. If you selected the Save filter check box, 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.
        • hasBit—checks whether the left operand (string or number) contains bits whose positions are listed in the right operand (in a constant or in a list).
        • hasVulnerability—checks whether the left operand contains an asset with the vulnerability and vulnerability severity specified in the right operand.
        • 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.
        • inDictionary—checks whether the specified dictionary contains an entry defined by the key composed with the concatenated values of the selected event fields.
        • 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.

  Filtering based on data from the Extra event field

  Conditions for filters based on data from the Extra event field:

  • Condition—If.
  • Left operand—event field.
  • In this event field, you can specify one of the following values:
    • Extra field.
    • Value from the Extra field in the following format:

      Extra.<field name>

      For example, Extra.app.

      A value of this type is specified manually.

    • Value from the array written to the Extra field in the following format:

      Extra.<field name>.<array element>

      For example, Extra.array.0.

      The values in the array are numbered starting from 0.

      A value of this type is specified manually.

  • Operator – =.
  • Right operand—constant.
  • Value—the value by which you need to filter events.
• Recovery—this check box must be selected when the Correlation rule must NOT trigger if a certain number of events are received from the selector. By default, this check box is cleared.

On the Local variables tab, use the Add variable button to declare variables that will be used within the limits of this correlation rule.

Actions tab

There can be multiple triggers in a standard type of resource.

• On first threshold—this trigger activates when the Bucket registers the first triggering of the selector during the lifetime of the Bucket.
• On subsequent thresholds—this trigger activates when the Bucket registers the second and all subsequent triggering of the selector during the lifetime of the Bucket.
• On every threshold—this trigger activates every time the Bucket registers the triggering of the selector.
• On timeout—this trigger activates when the lifetime of the Bucket ends, and is linked to the selector with the Recovery check box selected. In other words, this trigger activates if the situation detected by the correlation rule is not resolved within the defined amount of time.

Every trigger is represented as a group of settings with the following parameters available:

• Output—if this check box is selected, the correlation event will be sent for post-processing: for enrichment, for a response, and to destinations.
• Loop—if this check box is selected, the correlation event will be processed by the current correlation rule resource. This allows hierarchical correlation.

  If both check boxes are selected, the correlation rule will be sent for post-processing first and then to the current correlation rule selectors.

• Do not create alert—if this check box is selected, an alert will not be created when this correlation rule is triggered.
• Active lists update settings group—used to assign the trigger for one or more operations with active lists. You can use the Add active list action and Delete active list action buttons to add or delete operations with active lists, respectively.

  Available settings:

  • Name (required)—this drop-down list is used to select the Active list resources.
  • Operation (required)—this drop-down list is used to select the operation that must be performed:
    • Get—get the Active list entry and write the values of the selected fields into the correlation event.
    • Set—write the values of the selected fields of the correlation event into the Active list by creating a new or updating an existing Active list entry. When the Active list entry is updated, the data is merged and only the specified fields are overwritten.
    • Delete—delete the Active list entry.
  • Key fields (required)—this is the list of event fields used to create the Active list entry. It is also used as the Active list entry key.

    The active list entry key depends on the available fields and does not depend on the order in which they are displayed in the KUMA web interface.

  • Mapping (required for Get and Set operations)—used to map Active list fields with events fields. More than one mapping rule can be set.
    • The left field is used to specify the Active list field.

      The field must not contain special characters or numbers only.

    • The middle drop-down list is used to select event fields.
    • The right field can be used to assign a constant to the Active list field is the Set operation was selected.
• Enrichment settings block—you can update the field values of correlation events by using enrichment rules similar to enrichment rule resources. These enrichment rules are stored in the Correlation rule resource where they were created. It is possible to have more than one enrichment rule. Enrichment rules can be added or deleted by using the Add enrichment or Remove enrichment buttons, respectively.
  • Source kind—you can select the type of enrichment in this drop-down list. Depending on the selected type, you may see advanced settings that will also need to be completed.

    Available types of enrichment:

    • constant

      This type of enrichment is used when a constant needs to be added to an event field. Settings of this type of enrichment:

      • In the Constant field, specify the value that should be added to the event 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.
      • In the Target field drop-down list, select the KUMA event field to which you want to write the data.

    • 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. Settings of this type of enrichment:

      • In the Target field drop-down list, select the KUMA event field to which you want to write the data.
      • In the Source field drop-down list, select the event field whose value will be written 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 – used to convert a value using the regular expression RE2. 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 Micromon value applied to Microsoft-Windows-Sysmon results in 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. Settings of this type of enrichment:

      • Put the Go template into 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}}.

      • In the Target field drop-down list, select the KUMA event field to which you want to write the data.
  • Debug—you can use this drop-down list to enable logging of service operations.
  • Description—the description of a resource. Up to 256 Unicode characters.
  • Filter settings block—lets you select which events will be forwarded for enrichment. Configuration is performed as described above.
• Categorization settings group—used to change the categories of assets indicated in events. There can be several categorization rules. You can add or delete them by using the Add categorization or Remove categorization buttons. Only reactive categories can be added to assets or removed from assets.
  • Operation—this drop-down list is used to select the operation to perform on the category:
    • Add—assign the category to the asset.
    • Delete—unbind the asset from the category.
  • Event field—event field that indicates the asset requiring the operation.
  • Category ID—you can click the button to select the category requiring the operation. Clicking this button opens the Select categories window showing the category tree.

[Topic 221199]

Simple correlation rules

Simple correlation rules are used to define simple sequences of events.

The correlation rule resource window contains the following configuration tabs:

• General—used to specify the main settings of the correlation rule resource. On this tab, you can select the type of correlation rule.
• Selectors—used to define the conditions that the processed events must fulfill to trigger the correlation rule. Available parameters vary based on the selected resource type.
• Actions—used to set the triggers that will activate when the conditions configured in the Selectors settings block are fulfilled. The Correlation rule resource must have at least one trigger. Available parameters vary based on the selected resource type.

General tab

• Name (required)—a unique name for this type of resource. Must contain from 1 to 128 Unicode characters.
• Tenant (required)—the tenant that owns the correlation rule.
• Type (required)—a drop-down list for selecting the type of correlation rule. Select simple if you want to create a simple correlation rule.
• Propagated fields (required)—event fields used for event selection. If the selector (see below) is triggered, these fields will be written to the correlation event.
• Rate limit—maximum number of times a correlation rule can be triggered per second. The default value is 100.

  If correlation rules employing complex logic for pattern detection are not triggered, this may be due to the specific method used to count rule triggers in KUMA. In this case, try to increase the value of Rate limit to 1000000, for example.

• Priority—base coefficient used to determine the importance of a correlation rule. The default value is Low.
• Description—the description of a resource. Up to 256 Unicode characters.

Selectors tab

In a simple-type resource, there can be only one selector for which the Settings and Local variables tabs are available.

The Settings tab contains settings with the Filter settings block:

• Filter (required)—used to set the criteria for determining events that should trigger the selector. 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, select the Save filter check box.

     In this case, you will be able to use the created filter in various services.

     This check box is cleared by default.

  3. If you selected the Save filter check box, 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.
        • hasBit—checks whether the left operand (string or number) contains bits whose positions are listed in the right operand (in a constant or in a list).
        • hasVulnerability—checks whether the left operand contains an asset with the vulnerability and vulnerability severity specified in the right operand.
        • 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.
        • inDictionary—checks whether the specified dictionary contains an entry defined by the key composed with the concatenated values of the selected event fields.
        • 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.

  Filtering based on data from the Extra event field

  Conditions for filters based on data from the Extra event field:

  • Condition—If.
  • Left operand—event field.
  • In this event field, you can specify one of the following values:
    • Extra field.
    • Value from the Extra field in the following format:

      Extra.<field name>

      For example, Extra.app.

      A value of this type is specified manually.

    • Value from the array written to the Extra field in the following format:

      Extra.<field name>.<array element>

      For example, Extra.array.0.

      The values in the array are numbered starting from 0.

      A value of this type is specified manually.

  • Operator – =.
  • Right operand—constant.
  • Value—the value by which you need to filter events.

On the Local variables tab, use the Add variable button to declare variables that will be used within the limits of this correlation rule.

Actions tab

There can be only one trigger in the simple resource kind: On every event. It is activated every time the selector triggers.

Available parameters of the trigger:

• Output—if this check box is selected, the correlation event will be sent for post-processing: for enrichment, for a response, and to destinations.
• Loop—if this check box is selected, the correlation event will be processed by the current correlation rule resource. This allows hierarchical correlation.

  If both check boxes are selected, the correlation rule will be sent for post-processing first and then to the current correlation rule selectors.

• Do not create alert—if this check box is selected, an alert will not be created when this correlation rule is triggered.
• Active lists update settings group—used to assign the trigger for one or more operations with active lists. You can use the Add active list action and Delete active list action buttons to add or delete operations with active lists, respectively.

  Available settings:

  • Name (required)—this drop-down list is used to select the Active list resources.
  • Operation (required)—this drop-down list is used to select the operation that must be performed:
    • Get—get the Active list entry and write the values of the selected fields into the correlation event.
    • Set—write the values of the selected fields of the correlation event into the Active list by creating a new or updating an existing Active list entry. When the Active list entry is updated, the data is merged and only the specified fields are overwritten.
    • Delete—delete the Active list entry.
  • Key fields (required)—this is the list of event fields used to create the Active list entry. It is also used as the Active list entry key.

    The active list entry key depends on the available fields and does not depend on the order in which they are displayed in the KUMA web interface.

  • Mapping (required for Get and Set operations)—used to map Active list fields with events fields. More than one mapping rule can be set.
    • The left field is used to specify the Active list field.

      The field must not contain special characters or numbers only.

    • The middle drop-down list is used to select event fields.
    • The right field can be used to assign a constant to the Active list field is the Set operation was selected.
• Enrichment settings block—you can update the field values of correlation events by using enrichment rules similar to enrichment rule resources. These enrichment rules are stored in the Correlation rule resource where they were created. It is possible to have more than one enrichment rule. Enrichment rules can be added or deleted by using the Add enrichment or Remove enrichment buttons, respectively.
  • Source kind—you can select the type of enrichment in this drop-down list. Depending on the selected type, you may see advanced settings that will also need to be completed.

    Available types of enrichment:

    • constant

      This type of enrichment is used when a constant needs to be added to an event field. Settings of this type of enrichment:

      • In the Constant field, specify the value that should be added to the event 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.
      • In the Target field drop-down list, select the KUMA event field to which you want to write the data.

    • 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. Settings of this type of enrichment:

      • In the Target field drop-down list, select the KUMA event field to which you want to write the data.
      • In the Source field drop-down list, select the event field whose value will be written 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 – used to convert a value using the regular expression RE2. 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 Micromon value applied to Microsoft-Windows-Sysmon results in 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. Settings of this type of enrichment:

      • Put the Go template into 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}}.

      • In the Target field drop-down list, select the KUMA event field to which you want to write the data.
  • Debug—you can use this drop-down list to enable logging of service operations.
  • Description—the description of a resource. Up to 256 Unicode characters.
  • Filter settings block—lets you select which events will be forwarded for enrichment. Configuration is performed as described above.
• Categorization settings group—used to change the categories of assets indicated in events. There can be several categorization rules. You can add or delete them by using the Add categorization or Remove categorization buttons. Only reactive categories can be added to assets or removed from assets.
  • Operation—this drop-down list is used to select the operation to perform on the category:
    • Add—assign the category to the asset.
    • Delete—unbind the asset from the category.
  • Event field—event field that indicates the asset requiring the operation.
  • Category ID—you can click the button to select the category requiring the operation. Clicking this button opens the Select categories window showing the category tree.

[Topic 221203]

Operational correlation rules

Operational correlation rules are used for working with active lists.

The correlation rule resource window contains the following tabs:

• General—used to specify the main settings of the correlation rule resource. On this tab, you can select the type of correlation rule.
• Selectors—used to define the conditions that the processed events must fulfill to trigger the correlation rule. Available parameters vary based on the selected resource type.
• Actions—used to set the triggers that will activate when the conditions configured in the Selectors settings block are fulfilled. The Correlation rule resource must have at least one trigger. Available parameters vary based on the selected resource type.

General tab

• Name (required)—a unique name for this type of resource. Must contain from 1 to 128 Unicode characters.
• Tenant (required)—the tenant that owns the correlation rule.
• Type (required)—a drop-down list for selecting the type of correlation rule. Select operational if you want to create an operational correlation rule.
• Rate limit—maximum number of times a correlation rule can be triggered per second. The default value is 100.

  If correlation rules employing complex logic for pattern detection are not triggered, this may be due to the specific method used to count rule triggers in KUMA. In this case, try to increase the value of Rate limit to 1000000, for example.

• Description—the description of a resource. Up to 256 Unicode characters.

Selectors tab

In an operational-type resource, there can be only one selector for which the Settings and Local variables tabs are available.

The Settings tab contains settings with the Filter settings block:

• Filter (required)—used to set the criteria for determining events that should trigger the selector. 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, select the Save filter check box.

     In this case, you will be able to use the created filter in various services.

     This check box is cleared by default.

  3. If you selected the Save filter check box, 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.
        • hasBit—checks whether the left operand (string or number) contains bits whose positions are listed in the right operand (in a constant or in a list).
        • hasVulnerability—checks whether the left operand contains an asset with the vulnerability and vulnerability severity specified in the right operand.
        • 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.
        • inDictionary—checks whether the specified dictionary contains an entry defined by the key composed with the concatenated values of the selected event fields.
        • 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.

  Filtering based on data from the Extra event field

  Conditions for filters based on data from the Extra event field:

  • Condition—If.
  • Left operand—event field.
  • In this event field, you can specify one of the following values:
    • Extra field.
    • Value from the Extra field in the following format:

      Extra.<field name>

      For example, Extra.app.

      A value of this type is specified manually.

    • Value from the array written to the Extra field in the following format:

      Extra.<field name>.<array element>

      For example, Extra.array.0.

      The values in the array are numbered starting from 0.

      A value of this type is specified manually.

  • Operator – =.
  • Right operand—constant.
  • Value—the value by which you need to filter events.

On the Local variables tab, use the Add variable button to declare variables that will be used within the limits of this correlation rule.

Actions tab

There can be only one trigger in the operational resource kind: On every event. It is activated every time the selector triggers.

Available parameters of the trigger:

• Active lists update settings group—used to assign the trigger for one or more operations with active lists. You can use the Add active list action and Delete active list action buttons to add or delete operations with active lists, respectively.

  Available settings:

  • Name (required)—this drop-down list is used to select the Active list resources.
  • Operation (required)—this drop-down list is used to select the operation that must be performed:
    • Get—get the Active list entry and write the values of the selected fields into the correlation event.
    • Set—write the values of the selected fields of the correlation event into the Active list by creating a new or updating an existing Active list entry. When the Active list entry is updated, the data is merged and only the specified fields are overwritten.
    • Delete—delete the Active list entry.
  • Key fields (required)—this is the list of event fields used to create the Active list entry. It is also used as the Active list entry key.

    The active list entry key depends on the available fields and does not depend on the order in which they are displayed in the KUMA web interface.

  • Mapping (required for Get and Set operations)—used to map Active list fields with events fields. More than one mapping rule can be set.
    • The left field is used to specify the Active list field.

      The field must not contain special characters or numbers only.

    • The middle drop-down list is used to select event fields.
    • The right field can be used to assign a constant to the Active list field is the Set operation was selected.

[Topic 234114]

Variables in correlators

If tracking values in event fields, active lists, or dictionaries is not enough to cover some specific security scenarios, you can use global and local variables. You can use them to take various actions on the values received by the correlators by implementing complex logic for threat detection. Variables can be declared in the correlator (global variables) or in the correlation rule (local variables) by assigning a function to them, then querying them from correlation rules as if they were ordinary event fields and receiving the triggered function result in response.

Usage scope of variables:

• When searching for grouping or unique field values in correlation rules.
• In the correlation rule selectors, in the filters of the conditions under which the correlation rule should be triggered.
• When enriching correlation events. Select Event as the source type.
• When filling active lists with values.

Variables can be queried the same way as event fields by preceding their names with the $ character.

[Topic 234737]

Properties of variables

Local and global variables

The properties of global variables differ from the properties of local variables.

Global variables:

• Global variables are declared at the correlator level and are applied only within the scope of this correlator.
• The global variables of the correlator can be queried from all correlation rules that are specified in it.
• In standard correlation rules, the same global variable can take different values in each selector.
• It is not possible to transfer global variables between different correlators.

Local variables:

• Local variables are declared at the correlation rule level and are applied only within the limits of this rule.
• In standard correlation rules, the scope of a local variable consists of only the selector in which the variable was declared.
• Local variables can be declared in any type of correlation rule.
• Local variables cannot be transferred between rules or selectors.
• A local variable cannot be used as a global variable.

Variables used in various types of correlation rules

• In operational correlation rules, on the Actions tab, you can specify all variables available or declared in this rule.
• In standard correlation rules, on the Actions tab, you can provide only those variables specified in these rules on the General tab, in the Identical fields field.
• In simple correlation rules, on the Actions tab, you can provide only those variables specified in these rules on the General tab, in the Inherited Fields field.

[Topic 234739]

Requirements for variables

When adding a variable function, you must first specify the name of the function, and then list its parameters in parentheses. Basic mathematical operations (addition, subtraction, multiplication, division) are an exception to this requirement. When these operations are used, parentheses are used to designate the severity of the operations.

Requirements for function names:

• Must be unique within the correlator.
• Must contain from 1 to 128 Unicode characters.
• Must not begin with the character $.
• Must be written in camelCase or CamelCase.

Special considerations when specifying functions of variables:

• The sequence of parameters is important.
• Parameters are separated by a comma: ,.
• String parameters are passed in single quotes: '.
• Event field names and variables are specified without quotation marks.
• When querying a variable as a parameter, add the $ character before its name.
• You do not need to add a space between parameters.
• In all functions in which a variable can be used as parameters, nested functions can be created.

[Topic 234740]

Functions of variables

Operations with active lists and dictionaries

"active_list" function

Gets information from the active list regarding the value in the specified column.

You must specify the parameters in the following sequence:

1. Name of the active list
2. Name of the active list column
3. Active list record key

   The name of one or more event fields is used as the record key of the active list.

   Usage example	Result
   active_list('exampleActiveList', 'score', SourceAddress,SourceUserName)	Gets data from exampleActiveList from the SourceAddress,SourceUserName record in the score column.

"table_dict" function

Gets information about the value in the specified column of a dictionary of the table type.

You must specify the parameters in the following sequence:

1. Dictionary name
2. Dictionary column name
3. Dictionary row key

   Usage example	Result
   table_dict('exampleTableDict', 'office', SourceUserName)	Gets data from the exampleTableDict dictionary from the row with the SourceUserName key in the office column.

"dict" function

Gets information about the value in the specified column of a dictionary of the dictionary type.

You must specify the parameters in the following sequence:

1. Dictionary name
2. Dictionary row key

   Usage example	Result
   dict('exampleDictionary', SourceAddress)	Gets data from exampleDictionary from the row with the SourceAddress key.

Operation with rows

"len" function

Returns the number of characters in a string.

A string can be passed as a string, field name or variable.