[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

• Multitenancy support is added for managed security service providers (MSSP) and enterprises. This allows multi-divisional organizations and service providers to detect and prioritize threats for multiple branches from a single unified environment, and to close access to other branch offices' data by creating tenants based on event sources. By assigning roles to users in each tenant, the KUMA general administrator can precisely configure which information individual users are allowed to see, create or edit.
• KUMA user authentication using Microsoft Active Directory is supported. Roles for Active Directory users can be configured for each tenant separately.
• KUMA includes a package of standard correlation rules developed by Kaspersky specialists. All rules are aligned with the MITRE ATTACK matrix and can be used as a basis for the development of custom rules for threat monitoring. Please be aware that correlation rules must be tested and adjusted to work correctly in specific environments.
• Incident management capabilities have been significantly expanded. These KUMA capabilities help investigate security incidents, determine their root causes, and coordinate joint work among several analysts.
  • Incident cards are added. Analysts can create incidents either from scratch or from one or several alerts. An incident is created when there is more than just a suspicion of a security incident, i. e. when there is also confirmatory evidence. The incident card provides a single place to collect all of the signs of an incident: suspicious alerts or other data (such as information about affected assets and users).
  • Integration with RuCERT (Russian National Coordinating Center for Computer Incidents) infrastructure is provided to make informing RuCERT about incidents easier for users who are required to do so as part of their compliance obligations.
  • An "Incidents Overview" out-of-the-box Dashboard layout is added.
  • Incidents categorization is supported.
  • Flexible grouping of alerts and incidents is added to reduce the load on analysts. It allows you to precisely configure criteria for auto-consolidation of correlation events and alerts and of alerts and incidents.
• Event source status monitoring is added to promptly notify administrators about any issues that could interrupt or significantly reduce the flow of data coming from event sources. After configuring the expected minimum number of events in the monitoring policy and assigning this policy to the event source, the users indicated in the policy settings will receive notifications about deviations from the specified settings.
• Support for new connectors is implemented to ingest events over the following protocols.
  • WMI (via RPC)—allows receipt of Windows Events from remote computers using RPC methods. Comparing with WEC, which allows ingesting Windows Events only from local computer or from WEC-server where Agent is installed, WMI can be named “agent-less” approach.
  • SNMP versions 1, 2 and 3 allow actively requesting data over the SNMP protocol.
  • NFS allows obtaining events from files stored in an NFS shared folder.
  • FTP allows obtaining events from files accessible over the FTP protocol.
• Automatic asset categorization (dynamic categorization) is supported. Thanks to proactive categorization, KUMA users can define criteria for each category (for example, include assets running Windows that are located in subnet 10.10.0.0/16). At the same time, reactive categorization allows changing asset categories based on correlation. As previously, dynamic categories can be taken into account during correlation and alerts triage.
• KUMA Core data full backup is supported to improve KUMA resiliency.
• HTTP Rest API is added to help manage assets and active lists.
• KUMA agent functionality is significantly improved. Now it support all connectors supported in KUMA (previously only WEC connector was supported) and can be uses for events routing.
• Upgrading from versions 1.0 and 1.1 is supported. Resources (correlation rules, normalizers etc) will be saved during the upgrade. Contact Kaspersky specialists for assistance with transferring accumulated data (events and alerts) during the upgrade.
• Installation wizards for connecting event sources and creating correlators are added. They simplify these processes and prevent potential errors. Wizards will guide KUMA user through all necessary steps and interactively helps to check the settings.

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

Distribution kit of KUMA version certified by the state authorities of Russian Federation

[Topic 217889]

Hardware and software requirements

Recommended hardware requirements

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

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

    Support is required for SSE4.2 commands.

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

  Using SSDs highly improves cluster node indexing and search efficiency.

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

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

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

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

Software requirements

Each server used to install KUMA services must have the Oracle Linux 8.4 operating system installed.

Network requirements

The network interface bandwidth must be at least 100 Mbps.

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

Additional requirements

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

[Topic 217958]

Program architecture

The standard program installation includes the following components:

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

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

KUMA architecture

[Topic 217779]

Core

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

The Core allows you to:

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

[Topic 217762]

Collector

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

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

The collector operation algorithm includes the following steps:

1. Receiving messages from event sources

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

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

   The program has the following connector types available:

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

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

   The following normalizers are available in the program:

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

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

4. Enrichment and mutation of normalized events

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

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

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

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

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

6. Transmission of normalized events

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

[Topic 217784]

Correlator

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

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

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

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

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

The Correlator operation algorithm has the following steps:

1. Obtaining an event

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

2. Applying correlation rules

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

3. Responding to an alert

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

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

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

[Topic 218010]

Storage

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

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

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

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

[Topic 220211]

Basic entities

This section describes the main entities that KUMA works with.

[Topic 221264]

About tenants

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

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

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

In KUMA, two tenants are created by default:

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

[Topic 217693]

About events

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

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

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

The first steps are carried out in a collector.

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

   The program has the following normalizers:

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

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

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

The next event life cycle steps 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 happen in KUMA; these events are used to ensure system integrity. They are stored at least for 365 days.
5. Monitoring event. These events are used to track changes in the amount of data received by KUMA.

[Topic 217691]

About alerts

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

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

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

You can create incidents based on alerts.

Below is the life cycle of an alert:

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

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

Alert management in KUMA is described in this section.

[Topic 220212]

About incidents

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

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

Incidents can be exported to RuCERT.

[Topic 217692]

About assets

Assets are network devices registered in KUMA. Network 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 particular IP address), a connection is formed between this asset and all events that contain this IP 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 with an asset is processed, the category of this asset is taken into consideration. For example, if you assign high priority to a certain category of assets, base events involving these assets will trigger creation of correlation events with higher priority. This in turn will cascade into higher priority alerts and, therefore, a faster response to it.

It is worth having assets registered in KUMA because using them makes it possible to formulate clear and versatile correlation rules for much more efficient event analysis.

Asset management in KUMA is described in this section.

[Topic 221640]

About resources

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

[Topic 221642]

About services

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

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

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

[Topic 217690]

About agents

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

Types of agents:

• Wmi agents are used to receive data from remote Windows machines using Windows Management Instrumentation. They are installed to Windows assets.
• Wec agents are used to receive Windows logs from a local machine using Windows Event Collector. They are installed to Windows assets.
• Tcp agents are used to receive data over the TCP protocol. They are installed to Linux assets.
• Udp agents are used to receive data over the UDP protocol. They are installed to Linux assets.
• Nats agents are used for NATS communications. They are installed to Linux assets.
• Kafka agents are used for Kafka communications. They are installed to Linux assets.
• Http agents are used for communication over the HTTP protocol. They are installed to Linux 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 assets.
• Nfs agents are used to receive data over the Network File System protocol. They are installed to Linux assets.
• Snmp agents are used to receive data over the Simple Network Management Protocol. 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 priority to correlation events and alerts based on correlation rule settings. The priority of an alert also depends on the assets related to the processed events because correlation rules take into account the priority of a related asset's category. If the alert or correlation event does not have linked assets with a defined priority or does not have any related assets at all, the priority of this alert or correlation event is equal to the priority of the correlation rule that triggered them. The alert or the correlation event priority is never lower than the priority of the correlation rule that triggered them.

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

Possible priority values:

• Low
• Medium
• High
• Critical

[Topic 217904]

Installing and removing KUMA

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

[Topic 217908]

Installing for demo

For demonstration purposes, you can deploy KUMA components on a single server.

The server where the installer is run cannot have the name localhost or localhost.<domain>. The installer can run from any folder, but the RPM packages must be located in the same folder as the kuma-installer file. You can get more information about kuma-installer by running it with the --help parameter.

Before deploying the program, make sure that the servers where you intend to install the components meet the hardware and software requirements.

KUMA components are addressed using the fully qualified domain name (FQDN) of the host. Before you install the program, you must ensure that the command hostnamectl status returns the true name of the host FQDN in the Static hostname field.

It is recommended to use Network Time Protocol (NTP) to synchronize time between servers with KUMA services.

The KUMA installation takes place over several stages:

1. Preparing the source machine

   The source 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 source 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.

Before installing KUMA version certified by the state authorities of Russian Federation, the files from both Distribution kit disks must be unpacked into a kuma-ansible-installer folder.

To create an inventory file for a demonstration installation:

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

   cd kuma-ansible-installer

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

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

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

     deploy_example_services: true

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

   • If you are installing KUMA in a production environment and have a separate source 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 source machine, where all of the KUMA components are installed on the target machines.

Root privileges are required to run the installer.

To install KUMA for demonstration purposes:

1. On the source machine, log in to the OS as the root user and go to the folder with the unpacked installer.
2. Place the file with the license key in the folder <installer folder>/roles/kuma/files/.
3. Launch the installer by executing the following command:

   ./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 using the command /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

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.

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 source machine

   The source 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 source machine

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

To prepare the source machine for the KUMA installation:

1. Install Oracle Linux 8.4 by selecting the Server installation option. A disk image for installation is available on the official Oracle site.
2. Log in to the operating system as the root user.
3. Configure the network interface.

   For convenience, you can use the graphical utility nmtui.

4. 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:

      systemctl enable --now chronyd

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

      timedatectl | grep 'System clock synchronized'

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

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

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

6. Make sure the source 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:

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

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

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

   Before installing KUMA version certified by the state authorities of Russian Federation, the files from both Distribution kit disks must be unpacked into a kuma-ansible-installer folder.

The source 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 Oracle Linux 8.4 by selecting the Server installation option. A disk image for installation is available on the official Oracle site.
2. Log in to the operating system as the root user.
3. Configure the network interface.

   For convenience, you can use the graphical utility nmtui.

4. 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:

      systemctl enable --now chronyd

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

      timedatectl | grep 'System clock synchronized'

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

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

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

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

   hostname -f

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

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

The source machine can be used as a target one. To do this, prepare the source machine, and then follow steps 5–7 in the instructions for preparing the target machine.

[Topic 222085]

Preparing the inventory file

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

Before installing KUMA version certified by the state authorities of Russian Federation, the files from both Distribution kit disks must be unpacked into a kuma-ansible-installer folder.

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 source machine, set the ansible_connection parameter to ssh:

     ansible_connection: ssh

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Topic 217914]

Installing the program

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

Root privileges are required to run the installer.

To install KUMA:

1. On the source machine, log in to the OS as the root user and go to the folder with the unpacked installer.
2. Place the file with the license key in the folder <installer folder>/roles/kuma/files/.
3. Launch the installer by executing the following command:

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

Root privileges are required to change KUMA components configuration.

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 systemctl restart kuma-core command.
4. Restart the browser hosting the KUMA web interface.

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

[Topic 217962]

Delete KUMA

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

To remove KUMA:

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

   cd kuma-ansible-installer

2. Execute the following command:

   ./uninstall.sh <inventory file>

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

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

[Topic 222156]

Updating previous versions of KUMA

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

During the update, the accumulated events are not transferred from the old version of the program to the new one.

The old services for collectors and correlators in the new program are displayed in the Other section when setting destination points.

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

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.

The following types of licenses exist:

• Trial - a free license intended for evaluation purposes.

  The trial license is valid for a short term only. Upon expiration of the trial license, KUMA will stop functioning. To continue using the program, you need to purchase a commercial license.

  With a trial license you can activate the program only once.

• Commercial - a paid license provided when purchasing the program.

  When the commercial license expires, the program will still be operational, but with limited functionality (for example, updating the KUMA databases will not be available). To continue using KUMA in full functionality mode, you need to renew your commercial license.

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

[Topic 73976]

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
• Maximum number of licensing units (for example, assets on which the program can be used under the provided license)
• Start date of the license term
• License expiration date or license term
• License type

[Topic 69295]

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 in one of the following ways: apply a key file or enter an activation code. 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 an active one or an additional, or a reserve, one.

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.

An additional, or reserve, license key is a 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 69431]

About the key file

A key file is a file with the .key extension 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 when you bought KUMA or ordered the trial version of KUMA.

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

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

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

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

[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 not active until the main 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.

For an added license keys, the License tab window displays the following information:

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

[Topic 217963]

Removing a license key in the program web interface

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

Only users with the administrator role can delete license keys.

To delete an added license key:

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

   The window with KUMA license conditions opens.

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

   A confirmation window opens.

3. Confirm deletion of the license key.

The license key will be removed from the program.

[Topic 217927]

Integration with other solutions

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

[Topic 217923]

Integration with Kaspersky Security Center

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

Kaspersky Security Center tasks are functions performed by this program, such as Full computer scan and Database update. For more information about Kaspersky Security Center tasks see Kaspersky Security Center online help.

[Topic 217952]

Preparing Kaspersky Security Center for integration with KUMA

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

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

[Topic 217790]

Creating KUMA user in Kaspersky Security Center

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

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

   User selection window opens.

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

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

6. Select the user you created and click OK.

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

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

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

[Topic 217767]

Configuring Kaspersky Security Center to send events to KUMA

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

To export Kaspersky Security Center events to KUMA:

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

Automatic export of Kaspersky Security Center events will be enabled. For more information about exporting events from Kaspersky Security Center to SIEM systems, see Kaspersky Security Center online help.

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

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

The selected events will be sent to the KUMA over the Syslog protocol. For more information about exporting events from Kaspersky Security Center using Syslog protocol see Kaspersky Security Center online help.

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

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

[Topic 217789]

Creating KUMA tasks in Kaspersky Security Center

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

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

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

To create Kaspersky Security Center task :

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

   The New Task Wizard starts.

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

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

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

[Topic 217933]

Managing Kaspersky Security Center connections

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

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

To enable or disable integration with Kaspersky Security Center:

1. Open the KUMA web interface and select the Settings section.
2. In the left part of the Settings section, select the Settings → KSC tab.

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

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

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

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

     By default, this check box is cleared.

5. Click Save.

[Topic 217788]

Creating Kaspersky Security Center connection

To create a new Kaspersky Security Center connection:

1. Open the KUMA web interface and select the Settings section.
2. In the left part of the Settings section, select the Settings → KSC tab.

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

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

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

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

   Creating resource with Kaspersky Security Center credentials

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

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

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

      The list of available secrets will be displayed.

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

      The secret window is displayed.

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

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

6. Click Save.

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

[Topic 217849]

Editing Kaspersky Security Center connection

To edit a Kaspersky Security Center connection:

1. Open the KUMA web interface and select the Settings section.
2. In the left part of the Settings section, select the Settings → KSC tab.

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

3. Select the tenant for which you want to change the connection to Kaspersky Security Center.

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

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

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

5. Make the necessary changes to the parameters:
   • Name (required)—enter the unique name of the Kaspersky Security Center connection. Must contain from 1 to 128 Unicode characters.
   • URL (required)—enter the URL of the Kaspersky Security Center server in the hostname:port or IPv4:port format.
   • Secret (required)—select the Secret resource with required Kaspersky Security Center credentials.
   • Disabled—select this check box if you do not want to use this Kaspersky Security Center connection. By default, this check box is cleared.
6. Click Save.

The Kaspersky Security Center connection has been modified.

[Topic 217829]

Deleting Kaspersky Security Center connection

To delete a Kaspersky Security Center connection:

1. Open the KUMA web interface and select the Settings section.
2. In the left part of the Settings section, select the Settings → KSC tab.

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

3. Select the tenant for which you want to delete the connection to Kaspersky Security Center.

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

4. Click the Kaspersky Security Center connection you want to delete and click the Delete button.

The Kaspersky Security Center connection has been deleted.

[Topic 218045]

Working with Kaspersky Security Center tasks

If you configured Kaspersky Security Center for KUMA integration and connecting KUMA to Kaspersky Security Center, you can start Kaspersky Security Center tasks from KUMA. You can do this manually from the Assets section of the web interface or automatically by using response rules during the correlation process.

[Topic 218009]

Starting Kaspersky Security Center tasks manually

To start Kaspersky Security Center task manually:

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

   The Asset details area opens in the right part of the window with the Start KSC Task button below.

2. Click the Start KSC Task button.

   The Select KSC Task window opens.

3. Select the tasks you want to run and click Start.

Kaspersky Security Center starts selected tasks for the selected assets.

Some types of tasks are available only for certain assets. You can get vulnerability and software information only for assets with 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 define 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, open 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 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 several tasks on one condition, you must create several Responses.

   • In the Event field select the fields of the event that triggered the Correlator, where the assets for which the task must be run are defined. Possible values:
     • SourceAssetID
     • DestinationAssetID
     • DeviceAssetID
3. In the Filter section, you can specify the conditions to define events that will be processed by the created resource. You can select an existing filter resource from the drop-down list, or select Create new to create a new filter.

   Creating a filter in resources

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

          Filter operators

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

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

        • In the Left operand and Right operand drop-down lists, select where the data to be filtered will come from. As a result of the selection, Advanced settings will appear. Use them to determine the exact value that will be passed to the filter. For example, when choosing active list you will need to specify the name of the active list, the entry key and the entry key field.
        • You can use the If drop-down list to choose whether you want to create a negative filter condition.

        Conditions can be deleted using the button.

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

        A condition group can be deleted using the button.

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

        A nested filter can be deleted using the button.

4. If necessary, in the Workers field specify the number of response processes that can be run simultaneously.
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 task:

1. Sign in to the KUMA web interface.
2. Open the Resources section → Active services.
3. Select the collector that is configured to receive events from the Kaspersky Security Center server and click the Go to Events button.

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

Kaspersky Security Center event fields:

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

[Topic 222247]

Importing events from the Kaspersky Security Center database

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

To create a collector to receive Kaspersky Security Center events:

Follow the instructions under Creating a collector to select the preconfigured resources in the Installation Wizard:

• At step 2 of the Installation Wizard, select the [Example] KSC SQL connector:
  • In the URL field, specify the server connection string in the following format:

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

    where:

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

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

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

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

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

    CASE

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

                ELSE ev.rise_time

            END

        AS endTime,

        CASE

            WHEN ev.registration_time is not NULL

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

                ELSE ev.registration_time

            END

        AS kscRegistrationTime,

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

        hs.wstrWinName as dHost,

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

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

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

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

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

        serv.wstrWinDomain as kscNtDomain,

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

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

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

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

        CASE

        WHEN virus.tmVirusFoundTime is not NULL

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

                ELSE ev.registration_time

            END

        AS virusTime,

        virus.wstrObject As filePath,

        virus.wstrVirusName as virusName,

        virus.result_ev as result

    FROM KAV.dbo.ev_event as ev

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

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

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

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

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

[Topic 217924]

Integration with Kaspersky CyberTrace

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

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

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

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

[Topic 217921]

Integrating CyberTrace indicator search

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

1. Configuring CyberTrace to receive and process KUMA requests.

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

2. Creating an event enrichment rule in KUMA.

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

[Topic 217768]

Configuring the CyberTrace to receive and process requests.

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

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

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

   The Welcome to Kaspersky CyberTrace window opens.

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

   The Connection Settings window opens.

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

      Leave the default values for everything else.

   5. Click Next.

   The Proxy Settings window opens.

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

   The Licensing Settings window opens.

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

CyberTrace will be configured.

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

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

CyberTrace will be configured.

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

[Topic 217808]

Creating event Enrichment rules

To create event enrichment rules:

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

   The list of available enrichment rules will be displayed.

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

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

              Filter operators

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

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

            • In the Left operand and Right operand drop-down lists, select where the data to be filtered will come from. As a result of the selection, Advanced settings will appear. Use them to determine the exact value that will be passed to the filter. For example, when choosing active list you will need to specify the name of the active list, the entry key and the entry key field.
            • You can use the If drop-down list to choose whether you want to create a negative filter condition.

            Conditions can be deleted using the button.

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

            A condition group can be deleted using the button.

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

            A nested filter can be deleted using the button.

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 → 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 → 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, IPv4, or IPv6 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, data is not displayed in the CyberTrace section. You have to configure the display of data.

To configure data to be displayed in the CyberTrace section:

1. In the browser's address bar, enter the URL of the KUMA web interface with port number 7222: https://kuma.example.com:7222.

   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 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 KTL 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 KTL 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 had 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 KTL 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 had 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 KTL 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 new data is requested received from Kaspersky Threat Intelligence Portal.

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

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.

KUMA alert and R-Vision IRP incident fields mapping when transferring data via API

[Topic 224436]

Configuring integration in KUMA

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

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

To configure integration with R-Vision IRP:

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

   The list of available secrets will be displayed.

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

   The secret window is displayed.

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

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

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

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

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

   The window containing R-Vision IRP integration settings opens.

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

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

   • URL (required)—URL of the R-Vision IRP server host.
   • ID field (required)—name of the R-Vision IRP field where the ID of KUMA alert must be written.
   • URL field (required)—name of the R-Vision IRP field where the link for accessing the KUMA alert should be written.
   • Company—company name (when working with multiple customers).
   • Category (required)—category of R-Vision IRP incident that is created after KUMA alert is received.
   • Event columns (required)—a drop-down list for selecting KUMA event fields that should be sent to R-Vision IRP.
   • Priority group of settings (required)—used to map KUMA priority values to R-Vision IRP priority values.
7. Click Save.

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

[Topic 224437]

Configuring integration in R-Vision IRP

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

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

Configuring integration with KUMA consists of the following steps:

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

     R-Vision IRP user with the Incident Manager role

     

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

     API token in R-Vision IRP

     

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

     Categories of incidents containing data from KUMA alerts

     

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

     Alert URL field unavailable for editing

     

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

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

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

[Topic 225573]

Adding the ALERT_ID and ALERT_URL incident fields

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

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

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

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

ALERT_ID field added to R-Vision IRP incident.

ALERT_ID field

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

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

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

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

ALERT_URL field added to R-Vision IRP incident.

ALERT_URL field

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

[Topic 225575]

Creating R-Vision IRP collector

To create R-Vision IRP collector:

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

R-Vision IRP collector created.

[Topic 225576]

Creating connector in R-Vision IRP

To create connector in R-Vision IRP:

1. In the R-Vision IRP web interface, under Settings → Incident management → Connectors, click the plus icon.
2. In the Type drop-down list, select REST.
3. Specify the connector name in the Name field (example: 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.

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

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

R-Vision IRP connector is created.

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

To configure API queries in R-Vision IRP:

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

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

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

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

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

   {

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

       “Reason”:”<comment to add to KUMA alert when it is closed. For example, "Responded to alert from R-Vision">"

   }

6. Click Save.

R-Vision IRP connector is configured.

[Topic 225579]

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

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

1. In the R-Vision IRP web interface, under Settings → Incident management → Response playbooks, click the plus icon.
2. In the Title 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 and in the window that opens select the connector that should be run when the rule is triggered:
   1. In the Connector drop-down list select previously created connector.
   2. Click Add.

   Connector added to the rule.

6. Click Add.

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

R-Vision IRP playbook rule

[Topic 224487]

Managing alerts using R-Vision IRP

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

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

• Forward cyberthreat data from KUMA to R-Vision IRP

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

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

  • ID.
  • Name.
  • Status.
  • Date of the first event related to the alert.
  • Date of the last detection related to the alert.
  • User account name or email address of the security officer assigned to process the alert.
  • Alert priority.
  • Category of the R-Vision IRP incident corresponding to the KUMA alert.
  • Hierarchical list of events related to the alert.
  • List of devices (internal and external) related to the alert.
  • 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 Active Directory services that are 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 in the KUMA web interface. The LDAP table shows the tenants for which LDAP connections were created. The connections are displayed when a tenant is selected.

To add a tenant to the LDAP section:

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

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

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

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

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

Imported Active Directory attributes

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

[Topic 221481]

Enabling and disabling LDAP integration

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

To enable or disable all LDAP connections of a tenant:

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

   The LDAP connections window opens.

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

To enable or disable a specific LDAP connection:

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

   The LDAP connections window opens.

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

[Topic 217795]

Creating a connection

To create a new LDAP connection to Active Directory:

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

   The LDAP connections window opens.

3. Click the Add LDAP connection button.

   The LDAP connection window opens.

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

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

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

      The Secret window opens.

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

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

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

   Must contain from 1 to 128 Unicode characters.

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

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

7. In the TLS mode select whether you want to use TLS encryption for domain controllers connection. When using an encrypted connection, it is impossible to specify an IP address as a URL.
8. If you enabled TLS encryption at the previous step, add a TLS certificate. To do so:
   1. If you previously uploaded a certificate, select it from the Certificate drop-down list.
   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 amount 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. If necessary in the RPS field, enter the number of requests per second in cron format. By default, the information is requested once per day.
11. If necessary in the Filter field, specify an LDAP filter. For example, “(&(sAMAccountType=805306368)(!(userAccountControl:1.2.840.113556.1.4.803:=2))”.

    sAMAccountType = 805306368 filter is required. If it is missing in the user filter expression, it will be added to the Active Directory request automatically.

12. In the Base DN field, enter the base distinguished name of the directory where the search request should be performed.
13. If necessary in the Size limit per request field, enter the maximum size of the request.
14. Select the Disabled check box if you do not want to use this LDAP connection.

    This check box is cleared by default.

15. Click the Save button.

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

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

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

[Topic 217830]

Removing a connection

To delete LDAP connection to Active Directory:

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

   The LDAP connections window opens.

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

The LDAP connection to Active Directory will be deleted.

[Topic 221427]

Authorizing 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 → Active directory.
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 → Active directory.
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. In the TLS mode select whether you want to use TLS encryption for domain controllers connection. 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. To do so:
   1. 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.

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

      The Secret window opens.

   3. In the Name field, enter the name that will be 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. 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 amount 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 administrator 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 filters for KUMA user roles.

[Topic 221430]

Adding user role filters

You can fill in filters only for those roles that require configuration of domain authorization. You can leave the rest of the fields empty.

To add user role filters:

1. In the program web interface, select Settings → Active directory.
2. In the Role filters settings block, click the Add role filters 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.

   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.

User role filters are 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 filters. Changes to a role are applied after the next authorization of the user. The user will continue to operate under the old role until the current session expires.

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

[Topic 221777]

Integration with RuCERT

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

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

To create a connection to RuCERT:

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

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

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

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

   Available company business sectors

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

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

[Topic 217687]

KUMA resources

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

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

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

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

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

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

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

[Topic 217971]

Resources tools

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

[Topic 218051]

Working with resources folders

You can create, rename, move and delete folders.

To create a folder:

Select the folder in the tree where the new folder is required.

Click the Add folder button.

A new folder is 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 is 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 is deleted. It is not possible to delete a folder with files or subfolders.

[Topic 218050]

Working with resources

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

To create the resource:

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

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

2. Click the Add <resource type> button.

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

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

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

To move the resource to a new folder:

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

   The icon appears near the selected resources.

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

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

To copy the resource:

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

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

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

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

The copy of the resource is created.

To edit the resource:

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

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

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

The resource will be updated. If this resource is used in a service, the service must be restarted to use the new configuration.

To delete the resource:

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

   A confirmation window opens.

3. Click OK.

The resource has been deleted.

[Topic 217870]

Exporting and importing resources

You can export and import resources.

To export resources:

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

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

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

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

6. Click the Export button.

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

To import resources:

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

   The Resource import window opens.

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

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

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

        Click Replace all to replace all existing conflicting resources.

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

        Click Skip all to keep all existing resources.

   2. Click the Resolve button.

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

About conflict resolving

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

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

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

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

[Topic 217776]

Connectors

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

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

[Topic 217942]

Normalizers

Normalizer resources are used to convert raw events of various formats so that they conform to the KUMA event data model. This turns them into normalized events that can be processed by other KUMA resources and services.

A normalizer resource consists of the main normalizer and optional extra normalizers. Data is transmitted through a tree-like structure of normalizers depending on the defined conditions, which lets you configure complex logic for processing events.

A normalizer resource is created in several steps:

1. Creating the main normalizer

   The main normalizer is created by using the Add event parsing button. Entry of normalizer settings is finished by clicking OK.

   The main normalizer that you created will be displayed as a dark circle. Clicking on the circle will open the normalizer options for editing. When you hover over the circle, a plus sign is displayed. Click it to add more normalizers.

2. Creating conditions for using an extra normalizer

   Clicking on the normalizer plus sign opens the Add normalizer to normalization scheme window in which you can specify the conditions that will cause data to be forwarded to the new normalizer.

3. Creating an extra normalizer

   When the previous step is finished, a window will open for creating an extra normalizer. Entry of normalizer settings is finished by clicking OK.

   The extra normalizer you created is displayed as a dark block that indicates the conditions under which this normalizer will be used (see step 2). The conditions can be changed by moving your mouse cursor over the extra normalizer and clicking the button showing the pencil image.

   If you hover the mouse pointer over the extra normalizer, a plus button appears, which you can use to create a new extra normalizer. To delete a normalizer, use the button with the trash icon.

   If you need to create more normalizers, repeat steps 2 and 3.

4. Completing creation of a normalizer resource

   Normalizer resource creation is finished by clicking the Save button.

[Topic 221932]

Normalizer settings

The normalizer window contains two tabs: Normalization scheme and Enrichment.

Normalization scheme

This tab is used to specify the main settings of the normalizer and to define the rules for converting events into KUMA format.

Available settings:

• Name (required)—the name of the normalizer. Must contain from 1 to 128 Unicode characters. The name of the main normalizer will be used as the name of the normalizer resource.
• Tenant (required)—name of the tenant that owns the resource.

  This setting is not available for extra normalizers.

• Parsing method (required)—drop-down list for selecting the type of incoming events. Depending on your choice, you can use the preconfigured rules for matching event fields or set your own rules. When you select some parsing methods, additional parameter fields required for filling in may become available.

  Available parsing methods:

  • json

    This parsing method is used to process JSON data.

  • cef

    This parsing method is used to process CEF data.

    When choosing this method, you can use the preconfigured rules for converting events to the KUMA format by clicking the Apply default mapping button.

  • regexp

    This parsing method is used to create custom rules for processing JSON data.

    In the Normalization parameter block field, add a regular expression (RE2 syntax) with named capture groups. The name of a group and its value will be interpreted as the field and the value of the raw event, which can be converted into an event field in KUMA format.

    To add event handling rules:

    1. Copy an example of the data you want to process to the Event examples field. This is an optional but recommended step.
    2. In the Normalization parameter block field add a regular expression with named capture groups in RE2 syntax, for example "(?P<name>regexp)".

       You can add multiple regular expressions by using the Add regular expression button. If you need to remove the regular expression, use the button.

    3. Click the Copy field names to the mapping table button.

       Capture group names are displayed in the KUMA field column of the Mapping table. Now you can select the corresponding KUMA field in the column next to each capture group. Otherwise, if you named the capture groups in accordance with the CEF format, you can use the automatic CEF mapping by selecting the Use CEF syntax for normalization check box.

    Event handling rules were added.

  • syslog

    This parsing method is used to process data in syslog format.

    When choosing this method, you can use the preconfigured rules for converting events to the KUMA format by clicking the Apply default mapping button.

  • csv

    This parsing method is used to create custom rules for processing CSV data.

    When choosing this method, you must specify one of the possible delimiters for values in the Delimiter field:

    • \ n (used by default)
    • \t
    • \0
  • kv

    This parsing method is used to process data in key-value pair format.

    If you select this method, you must provide values in the following required fields:

    • Pair delimiter—specify a character that will serve as a delimiter for key-value pairs. By default, the line feed character is used, although you can specify any one-character (1 byte) value, provided that the character is not the same as the value delimiter.
    • Value delimiter—specify a character that will serve as a delimiter between the key and the value. By default, the "=" character is used, however, you can specify any one-character (1 byte) value, provided that the character is not the same as the delimiter of key-value pairs.
  • xml

    This parsing method is used to process XML data.

    When this method is selected in the parameter block XML Attributes you can specify the key attributes to be extracted from tags. If an XML structure has several attributes with different values in the same tag, you can indicate the necessary value by specifying its key in the Source column of the Mapping table.

    To add key XML attributes,

    Click the Add field button, and in the window that appears, specify the path to the required attribute.

    You can add more than one attribute. Attributes can be removed one at a time using the cross icon or all at once using the Reset button.

    If XML key attributes are not specified, then in the course of field mapping the unique path to the XML value will be represented by a sequence of tags.

  • netflow5

    This parsing method is used to process data in the NetFlow v5 format.

    When choosing this method, you can use the preconfigured rules for converting events to the KUMA format by clicking the Apply default mapping button.

    In mapping rules, the protocol type for netflow is not indicated in the fields of KUMA events by default. When parsing data in NetFlow format on the Enrichment normalizer tab, you should create a constant data enrichment rule that adds the netflow value to the DeviceProduct target field.

  • netflow9

    This parsing method is used to process data in the NetFlow v9 format.

    When choosing this method, you can use the preconfigured rules for converting events to the KUMA format by clicking the Apply default mapping button.

    In mapping rules, the protocol type for netflow is not indicated in the fields of KUMA events by default. When parsing data in NetFlow format on the Enrichment normalizer tab, you should create a constant data enrichment rule that adds the netflow value to the DeviceProduct target field.

  • ipfix

    This parsing method is used to process IPFIX data.

    When choosing this method, you can use the preconfigured rules for converting events to the KUMA format by clicking the Apply default mapping button.

    In mapping rules, the protocol type for netflow is not indicated in the fields of KUMA events by default. When parsing data in NetFlow format on the Enrichment normalizer tab, you should create a constant data enrichment rule that adds the netflow value to the DeviceProduct target field.

  • sql

    This parsing method is used to process SQL data.

• Keep raw log (required)—in this drop-down list, you can indicate whether you need to store the original raw event in the newly created normalized event. Available values:
  • Never—do not save the raw event This is the default setting.
  • Only errors—save the raw event in the Raw field of the normalized event if errors occurred when parsing it. This value is convenient to use when debugging a service: in this case, every time an event has a non-empty Raw field, you know there was a problem.

    If fields containing the names *Address or *Date* do not comply with normalization rules, these fields are ignored. No normalization error will occur, and the values of the fields will not show up in the Raw field of the normalized event even if Keep raw log → Only errors was indicated.

  • Always—always save the raw event in the Raw field of the normalized event.

  This setting is not available for extra normalizers.

• Save extra fields (required)—in this drop-down list, you can choose whether you need to save fields of the original event in the normalized event if no mapping rules have been configured for them (see below). The data is stored in the Extra event field. By default, fields are not saved.
• Description—up to 256 Unicode characters describing the resource.

  This setting is not available for extra normalizers.

• Event examples—in this field, you can provide an example of data that you want to process. Event examples can also be loaded from a TSV, CSV, or TXT file by using the Load from file button.
• Mapping settings block—here you can configure mapping of original event fields to fields of the event in KUMA format:
  • Source—column for the names of the original event fields that you want to convert into KUMA event fields.

    Clicking the button next to the field names in the Source column opens the Conversion window, in which you can use the Add conversion button to create rules for modifying the original data before they are written to the KUMA event fields.

    Available conversions

    Conversions are changes that can be applied to a value before it gets written to the event field. The conversion type is selected from a drop-down list.

    Available conversions:

    • lower—is used to make all characters of the value lowercase
    • upper—is used to make all characters of the value uppercase
    • regexp—is used to apply a RE2 regular expression to the value. When this conversion type is selected, the field appears where regular expression should be added.
    • substring—is used to delete characters in the position range specified in the Start and the 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 is used to remove the characters specified in the Chars field from trailing positions of the value. The field appears when this type of conversion is selected.
    • append is used to add the characters specified in the Constant field to the end of the event field value. The field appears when this type of conversion is selected.
    • prepend—used to prepend the characters specified in the Constant field to the start of the event field value. The field appears when this type of conversion is selected.
    • replace with regexp—is used to replace RE2 regular expression results with the character sequence.
      • Expression—in this field you can specify the regular expression which results that should be replaced.
      • With chars—in this field you can specify the characters sequence should be used instead of replaced characters.
  • KUMA field—drop-down list for selecting the required fields of KUMA events. You can search for fields by entering their names in the field.
  • Label—in this column, you can add a unique custom label to event fields that begin with DeviceCustom*.

  New table rows can be added by using the Add row button. Rows can be deleted individually using the button or all at once using the Clear all button.

  If you have loaded data into the Event examples field, the table will have an Examples column containing examples of values carried over from the raw event field to the KUMA event field.

Enrichment

This tab is used to add additional data to fields of a normalized event by using enrichment rules similar to the rules in enrichment rule resources. These enrichment rules are stored in the normalizer resource where they were created. There can be more than one enrichment rule. Enrichments are created by using the Add enrichment button.

Settings available in the enrichment rule settings block:

• Source kind (required)—drop-down list for selecting the type of enrichment. Depending on the selected type, you may see advanced settings that will also need to be completed.

  Available Enrichment rule source types:

  • constant

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

    When choosing this type, you must specify the value to add to the event field in the Constant field. The value should not be longer than 255 Unicode characters. If you leave this field blank, the existing event field value will be cleared.

  • dictionary

    This type of enrichment is used if you need to add a value from dictionary.

    When this type is selected in the Dictionary name drop-down list, you must select the dictionary that will provide the values. In the Key fields settings block, you must use the Add field button to select the event fields whose values will be used for dictionary entry selection.

  • event

    This type of enrichment is used when you need to write a value from another event field to the current event field.

    When this type is selected in the Source field drop-down list, you must select the event field from where the value will be copied to the target field. Clicking the button opens the Conversion window in which you can, using the Add conversion button, create rules for modifying the original data before writing them to the KUMA event fields.

    Available conversions

    Conversions are changes that can be applied to a value before it gets written to the event field. The conversion type is selected from a drop-down list.

    Available conversions:

    • lower—is used to make all characters of the value lowercase
    • upper—is used to make all characters of the value uppercase
    • regexp—is used to apply a RE2 regular expression to the value. When this conversion type is selected, the field appears where regular expression should be added.
    • substring—is used to delete characters in the position range specified in the Start and the 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 is used to remove the characters specified in the Chars field from trailing positions of the value. The field appears when this type of conversion is selected.
    • append is used to add the characters specified in the Constant field to the end of the event field value. The field appears when this type of conversion is selected.
    • prepend—used to prepend the characters specified in the Constant field to the start of the event field value. The field appears when this type of conversion is selected.
    • replace with regexp—is used to replace RE2 regular expression results with the character sequence.
      • Expression—in this field you can specify the regular expression which results that should be replaced.
      • With chars—in this field you can specify the characters sequence should be used instead of replaced characters.
  • template

    This type of enrichment is used when you need to write a value obtained by processing Go templates into the event field.

    When this type is selected, a Go template must be specified in the Template field.

    Event field names are passed in the {{.EventField}} format, where EventField is the name of the event field from which the value must be passed to the script.

    Example: Attack on {{.DestinationAddress}} from {{.SourceAddress}}

• Target field (required)—drop-down list for selecting the KUMA event field that should receive the data.

[Topic 221934]

Condition for forwarding data to an extra normalizer

The Add normalizer to normalization scheme window is used to specify the conditions under which the data will be sent to an extra normalizer.

Available settings:

• Fields to pass into normalizer—used to indicate event fields in case you want to send only events with specific fields to the extra normalizer. Leave the field empty if you want to send all data to the extra normalizer.
• Use normalizer for events with specific event field values—used to indicate event fields if you want the extra normalizer to receive only events in which specific values are assigned to certain fields. The value is specified in the Condition value field.

  The data processed by these conditions can be preconverted by clicking the button. This opens the Conversion window, in which you can use the Add conversion button to create rules for modifying the original data before it is written to the KUMA event fields.

  Available conversions

  Conversions are changes that can be applied to a value before it gets written to the event field. The conversion type is selected from a drop-down list.

  Available conversions:

  • lower—is used to make all characters of the value lowercase
  • upper—is used to make all characters of the value uppercase
  • regexp—is used to apply a RE2 regular expression to the value. When this conversion type is selected, the field appears where regular expression should be added.
  • substring—is used to delete characters in the position range specified in the Start and the 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 is used to remove the characters specified in the Chars field from trailing positions of the value. The field appears when this type of conversion is selected.
  • append is used to add the characters specified in the Constant field to the end of the event field value. The field appears when this type of conversion is selected.
  • prepend—used to prepend the characters specified in the Constant field to the start of the event field value. The field appears when this type of conversion is selected.
  • replace with regexp—is used to replace RE2 regular expression results with the character sequence.
    • Expression—in this field you can specify the regular expression which results that should be replaced.
    • With chars—in this field you can specify the characters sequence should be used instead of replaced characters.

[Topic 222424]

Preset normalizers

The normalizers listed in the table below are included in the KUMA kit.

[Topic 217880]

Filters

Filter resources are used to select events based on user-defined conditions.

This is not true only when filters are used in the collector service, in which the filters select all events that DO NOT satisfy filter conditions.

Filters can be used in collector services, enrichment rule resources, aggregation rule resources, response rule resources, correlation rule resources, and destination resources either as separate filter resources or as built-in filters stored in the service or resource where they were created.

Available settings for filter resources:

• Name (required)—a unique name for this type of resource. Must contain from 1 to 128 Unicode characters. Inline filters are created in other resources or services and do not have names.
• Tenant (required)—name of the tenant that owns the resource.
• Conditions settings block—here you can formulate filtering criteria by creating filter conditions and groups of filters, and by adding existing filter resources.

  You can use the Add group button to add a group of filters. Group operators can be switched between AND, OR, and NOT. Groups, conditions, and existing filter resources can be added to groups of filters.

  You can use the Add filter button to add an existing filter resource, which should be selected in the Select filter drop-down list.

  You can use the Add condition button to add a string containing fields for identifying the condition (see below).

  Conditions, groups, and filters can be deleted by using the button.

Settings of conditions:

• If (required)—in this drop-down list, you can specify whether or not to use the inverted function of the operator.
• Left operand and Right operand (required)—used to specify the values that the operator will process. The available types depend on the selected operator.

  Operands of filters

  • Event field—used to assign an event field value to the operand. Advanced settings:
    • Event field (required)—this drop-down list is used to select the field from which the value for the operand should be extracted.
  • Active list—used to assign an active list record value to the operand. Advanced settings:
    • Active list (required)—this drop-down list is used to select the active list.
    • Key fields (required)—this is the list of event fields used to create the Active list entry and serve as the Active list entry key.
    • Event field (required unless the inActiveList operator is selected)—used to enter the name of the active list field from which the value for the operand should be extracted.
  • Dictionary—used to assign a dictionary resource value to the operand. Advanced settings:
    • Name (required)—this drop-down list is used to select the Dictionary.
    • Key fields (required)—this is the list of the event fields used to form the Dictionary value key.
  • Constant—used to assign a custom value to the operand. Advanced settings:
    • Value (required)—here you enter the constant you want to assign to the operand.
  • List—used to assign multiple custom values to the operand. Advanced settings:
    • Value (required)—here you enter the list of constants you want to assign to the operand. When you type the value in the field and press ENTER, the value is added to the list and you can enter a new value.
  • TI—used to read the CyberTrace threat intelligence (TI) data from the events. Advanced settings:
    • Feed (required)—this field is used to specify the CyberTrace threat category.
    • Key fields (required)—this drop-down list is used to select the event field containing the CyberTrace threat indicators.
    • Field (required)—this field is used to specify the CyberTrace feed field containing the threat indicators.
• Operator (required)—used to select the condition operator.

  In this drop-down list, you can select the Ignore case check box if the operator should ignore the case of values. This check box is ignored if the InSubnet, InActiveList, InCategory, and InActiveDirectoryGroup operators are selected.

  Filter operators

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

The available operand kinds depends on whether the operand is left (L) or right (R).

Available operand kinds for left (L) and right (R) operands

[Topic 217863]

Enrichment rules

Enrichment rule resources are used to update the event fields.

Available Enrichment rule resource parameters:

• Name (required)—a unique name for this type of resource. Must contain from 1 to 128 Unicode characters.
• Tenant (required)—name of the tenant that owns the resource.
• Source kind (required)—drop-down list for selecting the type of incoming events. Depending on the selected type, you may see the following additional settings:
  • constant

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

    When choosing this type, you must specify the value to add to the event field in the Constant field. The value should not be longer than 255 Unicode characters. If you leave this field blank, the existing event field value will be cleared.

  • dictionary

    This type of enrichment is used if you need to add a value from dictionary.

    When this type is selected in the Dictionary name drop-down list, you must select the dictionary that will provide the values. In the Key fields settings block, you must use the Add field button to select the event fields whose values will be used for dictionary entry selection.

  • event

    This type of enrichment is used when you need to write a value from another event field to the current event field.

    When this type is selected in the Source field drop-down list, you must select the event field from where the value will be copied to the target field.

    In the Conversion settings block, you can create rules for modifying the original data before it is written to the KUMA event fields. The conversion type can be selected from the drop-down list. You can use the Add conversion and Delete buttons to add or delete a conversion, respectively. The order of conversions is important.

    Available conversions

    Conversions are changes that can be applied to a value before it gets written to the event field. The conversion type is selected from a drop-down list.

    Available conversions:

    • lower—is used to make all characters of the value lowercase
    • upper—is used to make all characters of the value uppercase
    • regexp—is used to apply a RE2 regular expression to the value. When this conversion type is selected, the field appears where regular expression should be added.
    • substring—is used to delete characters in the position range specified in the Start and the 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 is used to remove the characters specified in the Chars field from trailing positions of the value. The field appears when this type of conversion is selected.
    • append is used to add the characters specified in the Constant field to the end of the event field value. The field appears when this type of conversion is selected.
    • prepend—used to prepend the characters specified in the Constant field to the start of the event field value. The field appears when this type of conversion is selected.
    • replace with regexp—is used to replace RE2 regular expression results with the character sequence.
      • Expression—in this field you can specify the regular expression which results that should be replaced.
      • With chars—in this field you can specify the characters sequence should be used instead of replaced characters.
  • template

    This type of enrichment is used when you need to write a value obtained by processing Go templates into the event field.

    When this type is selected, a Go template must be specified in the Template field.

    Event field names are passed in the {{.EventField}} format, where EventField is the name of the event field from which the value must be passed to the script.

    Example: Attack on {{.DestinationAddress}} from {{.SourceAddress}}

  • dns

    This type of enrichment is used to send requests to a private network DNS server to convert IP addresses into domain names or vice versa.

    Available settings:

    • URL—in this field, you can specify the URL of a DNS server to which you want to send requests. You can use the Add URL button to specify multiple URLs.
    • RPS—maximum number of requests sent to the server per second. The default value is 1000.
    • Workers—maximum number of requests per one point in time. The default value is 1.
    • Max tasks—maximum number of simultaneously fulfilled requests. By default, this value is equal to the number of vCPUs of the KUMA Core server.
    • Cache TTL—the lifetime of the values stored in the cache. The default value is 60.
    • Cache disabled—you can use this drop-down list to enable or disable caching. Caching is enabled by default.
  • cybertrace

    This type of enrichment is used to add information from CyberTrace data streams to event fields.

    Available settings:

    • URL (required)—in this field, you can specify the URL of a CyberTrace server to which you want to send requests.
    • Number of connections—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.
    • RPS—maximum number of requests sent to the server per second. The default value is 1000.
    • Timeout—amount of time to wait for a response from the CyberTrace server, in seconds. The default value is 30.
    • Mapping (required)—this settings block contains the mapping table for mapping KUMA event fields to CyberTrace indicator types. The KUMA fields column shows the names of KUMA event fields, and the CyberTrace indicator column shows the types of CyberTrace indicators.

      Available types of CyberTrace indicators:

      • ip
      • url
      • hash

      In the mapping table, you must provide at least one string. You can use the New line button to add a string, and can use the button to remove a string.

• Debug—you can use this drop-down list to enable logging of service operations. Logging is disabled by default.
• Description—up to 256 Unicode characters describing the resource.
• Filter—settings block in which you can specify the conditions for identifying events that will be processed by the aggregation rule resource. You can select an existing filter resource from the drop-down list, or select Create new to create a new filter.

  Creating a filter in resources

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

         Filter operators

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

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

       • In the Left operand and Right operand drop-down lists, select where the data to be filtered will come from. As a result of the selection, Advanced settings will appear. Use them to determine the exact value that will be passed to the filter. For example, when choosing active list you will need to specify the name of the active list, the entry key and the entry key field.
       • You can use the If drop-down list to choose whether you want to create a negative filter condition.

       Conditions can be deleted using the button.

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

       A condition group can be deleted using the button.

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

       A nested filter can be deleted using the button.

[Topic 217722]

Aggregation rules

Aggregation rule resources are used to group repeated events into aggregation events.

Available settings:

• Name (required)—a unique name for this type of resource. Must contain from 1 to 128 Unicode characters.
• Tenant (required)—name of the tenant that owns the resource.
• Threshold—the number of events that should be received before the aggregation rule is triggered and the events are aggregated. The default value is 100.
• Lifetime (required)—time period (in seconds) during which events are received for aggregation. On the timeout, the aggregation rule is triggered and a new event is created. The default value is 60.
• Description—up to 256 Unicode characters describing the resource.
• Identical fields (required)—in this drop-down list you can select fields that should be used to group events for aggregation.
• Unique fields—in this drop-down list you can select the fields that will disqualify events from aggregation even if their Identical fields parameter match the aggregation rule condition.
• Sum fields—in this drop-down list, you can select the fields whose values should be summed during aggregation.
• Filter—settings block in which you can specify the conditions for identifying events that will be processed by the aggregation rule resource. You can select an existing filter resource from the drop-down list, or select Create new to create a new filter.

  In aggregation rule resources, do not use filters with the TI operand or the TIDetect and inActiveDirectoyGroup operators. The Active Directory fields for which you can use the inActiveDirectoyGroup operator will appear during the enrichment stage (after aggregation rules are executed).

  Creating a filter in resources

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

         Filter operators

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

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

       • In the Left operand and Right operand drop-down lists, select where the data to be filtered will come from. As a result of the selection, Advanced settings will appear. Use them to determine the exact value that will be passed to the filter. For example, when choosing active list you will need to specify the name of the active list, the entry key and the entry key field.
       • You can use the If drop-down list to choose whether you want to create a negative filter condition.

       Conditions can be deleted using the button.

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

       A condition group can be deleted using the button.

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

       A nested filter can be deleted using the button.

[Topic 217842]

Destinations

Destination resources are used to receive events and then forward them to other services. The settings of destinations are configured on two tabs: Basic settings and Advanced settings. The available settings depend on the selected type of destination.

Basic settings

• Name (required)—a unique name for this type of resource. Must contain from 1 to 128 Unicode characters.
• Tenant (required)—name of the tenant that owns the resource.
• Disabled toggle switch—used if you do not need to send events to a destination. By default, sending events is enabled.
• Type (required)—drop-down list for selecting the type of destination:
  • nats—used for NATS communications.
  • tcp—used for communications over TCP.
  • http—used for HTTP communications.
  • kafka—used for Kafka communications.
  • file—used for writing to a file.
  • storage—used to transmit data to the storage.
  • correlator—used to transmit data to the correlator.
• URL (required)—URL where events should be sent. The port must be specified together with the URL. For example: hostname:port.

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

  If you have selected storage or correlator as the destination type, the URL field can be populated automatically using the Copy service URL drop-down list that displays active services of the selected type.

• Topic (required)—setting for the types of destinations: nats and kafka. The topic that data should be written to. The topic name must contain from 1 to 255 Unicode characters.
• Description—up to 256 Unicode characters describing the resource.

Advanced settings

• Compression is a drop-down list where you can enable Snappy compression. By default, compression is disabled.
• Proxy is a drop-down list for proxy server resource selection.
• Buffer size field is used to set buffer size (in bytes) for the destination resource. The default value is 1 MB, and the maximum value is 64 MB.
• Timeout field is used to set the timeout (in seconds) for another service or component response. The default value is 30.
• Disk buffer size limit field is used to specify the size of the disk buffer in bytes. The default size is 10 GB.
• Storage ID is a NATS storage identifier.
  • TLS mode specifies whether TLS encryption is used:
    • Disabled (default)—do not use TLS encryption.
    • Enabled—use encryption without certificate verification.
    • With verification—use encryption with verification that the certificate was signed with the KUMA root certificate. The root certificate and key of KUMA are created automatically during program installation and are stored on the KUMA Core server in the folder /opt/kaspersky/kuma/core/certificates/.

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

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

  Creating a filter in resources

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

         Filter operators

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

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

       • In the Left operand and Right operand drop-down lists, select where the data to be filtered will come from. As a result of the selection, Advanced settings will appear. Use them to determine the exact value that will be passed to the filter. For example, when choosing active list you will need to specify the name of the active list, the entry key and the entry key field.
       • You can use the If drop-down list to choose whether you want to create a negative filter condition.

       Conditions can be deleted using the button.

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

       A condition group can be deleted using the button.

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

       A nested filter can be deleted using the button.

[Topic 217843]

Dictionaries

Dictionary resources are key-value stores that can be used by other KUMA resources and services. The stored information is displayed in the table.

Available settings:

• Name (required)—a unique name for this type of resource. Must contain from 1 to 128 Unicode characters.
• Tenant (required)—name of the tenant that owns the resource.
• Description—you can add up to 256 Unicode characters describing the resource.
• Values settings block—contains a table of Key–Value pairs. You can click the Blank fields button to add new strings to the table or click the button to remove strings from the table.

You can also import or export dictionary information in the CSV format using the Import CSV or Export CSV links.

Importing CSV

You can import information into the dictionary in CSV format {KEY},{VALUE}\n, where:

• {KEY}—unique key for both CSV file and the dictionary, where the CSV is being imported to.
• ,—comma delimiter.
• {VALUE}—key value.

When CSV file is imported, the name of the dictionary is changed to reflect the name of the imported file. Imported keys and values are added to the dictionary. You can import data to the Dictionary multiple times.

Exporting CSV

You can export information from the dictionary in CSV format {KEY},{VALUE}\n, where:

• {KEY}—unique key for both CSV file and the dictionary, where the CSV is being imported to.
• Comma is used as a delimiter.
• {VALUE}—key value.

If the key or value contain comma or quotation mark characters (, and "), they are enclosed in quotation marks ("). Also, quotation mark character (") is shielded with additional quotation mark (").

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

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

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 duration 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.
• 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 parameters are available:

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

         Filter operators

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

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

       • In the Left operand and Right operand drop-down lists, select where the data to be filtered will come from. As a result of the selection, Advanced settings will appear. Use them to determine the exact value that will be passed to the filter. For example, when choosing active list you will need to specify the name of the active list, the entry key and the entry key field.
       • You can use the If drop-down list to choose whether you want to create a negative filter condition.

       Conditions can be deleted using the button.

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

       A condition group can be deleted using the button.

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

       A nested filter can be deleted using the button.

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

If more than one selector is added to the correlation rule resource, the Join filter settings block becomes available. This filter is used to compare the fields of different events. The Join filter is configured by using the Filter drop-down list as described above.

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 group of settings—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.
  • 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 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.
  • Type of source—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.

      When choosing this type, you must specify the value to add to the event field in the Constant field. The value should not be longer than 255 Unicode characters. If you leave this field blank, the existing event field value will be cleared.

    • dictionary

      This type of enrichment is used if you need to add a value from dictionary.

      When this type is selected in the Dictionary name drop-down list, you must select the dictionary that will provide the values. In the Key fields settings block, you must use the Add field button to select the event fields whose values will be used for dictionary entry selection.

    • event

      This type of enrichment is used when you need to write a value from another event field to the current event field.

      When this type is selected in the Source field drop-down list, you must select the event field from where the value will be copied to the target field. Clicking the button opens the Conversion window in which you can, using the Add conversion button, create rules for modifying the original data before writing them to the KUMA event fields.

      Available conversions

      Conversions are changes that can be applied to a value before it gets written to the event field. The conversion type is selected from a drop-down list.

      Available conversions:

      • lower—is used to make all characters of the value lowercase
      • upper—is used to make all characters of the value uppercase
      • regexp—is used to apply a RE2 regular expression to the value. When this conversion type is selected, the field appears where regular expression should be added.
      • substring—is used to delete characters in the position range specified in the Start and the 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 is used to remove the characters specified in the Chars field from trailing positions of the value. The field appears when this type of conversion is selected.
      • append is used to add the characters specified in the Constant field to the end of the event field value. The field appears when this type of conversion is selected.
      • prepend—used to prepend the characters specified in the Constant field to the start of the event field value. The field appears when this type of conversion is selected.
      • replace with regexp—is used to replace RE2 regular expression results with the character sequence.
        • Expression—in this field you can specify the regular expression which results that should be replaced.
        • With chars—in this field you can specify the characters sequence should be used instead of replaced characters.
    • template

      This type of enrichment is used when you need to write a value obtained by processing Go templates into the event field.

      When this type is selected, a Go template must be specified in the Template field.

      Event field names are passed in the {{.EventField}} format, where EventField is the name of the event field from which the value must be passed to the script.

      Example: Attack on {{.DestinationAddress}} from {{.SourceAddress}}

  • Target field—in this drop-down list, you can select the KUMA event field that should receive 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.
• 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.
• 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

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

         Filter operators

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

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

       • In the Left operand and Right operand drop-down lists, select where the data to be filtered will come from. As a result of the selection, Advanced settings will appear. Use them to determine the exact value that will be passed to the filter. For example, when choosing active list you will need to specify the name of the active list, the entry key and the entry key field.
       • You can use the If drop-down list to choose whether you want to create a negative filter condition.

       Conditions can be deleted using the button.

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

       A condition group can be deleted using the button.

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

       A nested filter can be deleted using the button.

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 group of settings—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.
  • 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 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.
  • Type of source—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.

      When choosing this type, you must specify the value to add to the event field in the Constant field. The value should not be longer than 255 Unicode characters. If you leave this field blank, the existing event field value will be cleared.

    • dictionary

      This type of enrichment is used if you need to add a value from dictionary.

      When this type is selected in the Dictionary name drop-down list, you must select the dictionary that will provide the values. In the Key fields settings block, you must use the Add field button to select the event fields whose values will be used for dictionary entry selection.

    • event

      This type of enrichment is used when you need to write a value from another event field to the current event field.

      When this type is selected in the Source field drop-down list, you must select the event field from where the value will be copied to the target field. Clicking the button opens the Conversion window in which you can, using the Add conversion button, create rules for modifying the original data before writing them to the KUMA event fields.

      Available conversions

      Conversions are changes that can be applied to a value before it gets written to the event field. The conversion type is selected from a drop-down list.

      Available conversions:

      • lower—is used to make all characters of the value lowercase
      • upper—is used to make all characters of the value uppercase
      • regexp—is used to apply a RE2 regular expression to the value. When this conversion type is selected, the field appears where regular expression should be added.
      • substring—is used to delete characters in the position range specified in the Start and the 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 is used to remove the characters specified in the Chars field from trailing positions of the value. The field appears when this type of conversion is selected.
      • append is used to add the characters specified in the Constant field to the end of the event field value. The field appears when this type of conversion is selected.
      • prepend—used to prepend the characters specified in the Constant field to the start of the event field value. The field appears when this type of conversion is selected.
      • replace with regexp—is used to replace RE2 regular expression results with the character sequence.
        • Expression—in this field you can specify the regular expression which results that should be replaced.
        • With chars—in this field you can specify the characters sequence should be used instead of replaced characters.
    • template

      This type of enrichment is used when you need to write a value obtained by processing Go templates into the event field.

      When this type is selected, a Go template must be specified in the Template field.

      Event field names are passed in the {{.EventField}} format, where EventField is the name of the event field from which the value must be passed to the script.

      Example: Attack on {{.DestinationAddress}} from {{.SourceAddress}}

  • Target field—in this drop-down list, you can select the KUMA event field that should receive 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 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 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

There can be one selector in an operational resource. Only the Filter settings block is available in selector:

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

         Filter operators

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

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

       • In the Left operand and Right operand drop-down lists, select where the data to be filtered will come from. As a result of the selection, Advanced settings will appear. Use them to determine the exact value that will be passed to the filter. For example, when choosing active list you will need to specify the name of the active list, the entry key and the entry key field.
       • You can use the If drop-down list to choose whether you want to create a negative filter condition.

       Conditions can be deleted using the button.

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

       A condition group can be deleted using the button.

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

       A nested filter can be deleted using the button.

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 group of settings—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 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 217707]

Active lists

Active list resources are dynamically updated data containers used by the KUMA correlators to read and write information when analyzing events according to correlation rules.

Available active list resource settings:

• ID—identifier selected Active list. This setting is displayed for active lists that have been created. You can copy this value by using the button.
• Name (required)—a unique name for this type of resource. Must contain from 1 to 128 Unicode characters.
• Tenant (required)—name of the tenant that owns the resource.
• TTL—time to live parameter of entries stored in the Active list, in seconds. The default value is 0. The maximum time to live is 31536000 (one year). When the time to live expires, the entry is deleted, and an event is generated for deleting the entry from the active list (see below).
• Description—you can add up to 256 Unicode characters describing the resource.