KL 034.2 Kuma Student Guide en v0.8

KL 034.2: Kaspersky Unified Monitoring and Analysis Platform 2.0.
D
KL 034.2
TE
BU
RI
ST
DI
Kaspersky Unified
RE
Monitoring and
OR
Analysis Platform
ED
PI
2.0.1
CO
BE
TO
T
NO
Student guide
1
KL 034.2: Kaspersky Unified Monitoring and Analysis Platform 2.0.1
D
Table of contents
TE
1. General ................................................................................................................................4
1.1 About SIEM ...................................................................................................................................... 4
BU
Typical SIEM tasks ........................................................................................................................... 5
Use cases ......................................................................................................................................... 6
SIEM key features ............................................................................................................................ 7
RI
1.2 About KUMA ..................................................................................................................................... 8
KUMA operation principles ............................................................................................................... 9
KUMA architecture (simplified) .......................................................................................................10
ST
KUMA configuration principles .......................................................................................................16
Hardware requirements ..................................................................................................................18
Licensing.........................................................................................................................................21
Technical support ............................................................................ Error! Bookmark not defined.
DI
2. Deployment .......................................................................................................................23
Installation requirements ................................................................................................................24
RE
All-in-one installation ......................................................................................................................26
Distributed installation ....................................................................................................................27
Web console ...................................................................................................................................29
Installation results ...........................................................................................................................31
Tenants and system components ..................................................................................................33
Role-based access control model ..................................................................................................34
OR
3. Event collecting and processing ........................................................................................37

3.1 Event collection ..............................................................................................................................38
KUMA services: ports and connections ..........................................................................................38
ED
Collector settings ............................................................................................................................39

Connector .......................................................................................................................................40
Receiving Windows events.............................................................................................................43
Windows agent ...............................................................................................................................44
Linux Agent .....................................................................................................................................51
PI
SQL connector ................................................................................................................................55

3.2 Normalization of events ..................................................................................................................58
CO
KUMA data model ..........................................................................................................................60

Types of normalizers ......................................................................................................................61
Field mapping .................................................................................................................................62
Extra field ........................................................................................................................................63
Converting fields .............................................................................................................................64
Extra normalizers ............................................................................................................................65
BE
3.3 Collector: event processing ............................................................................................................69

Filtering ...........................................................................................................................................69
Aggregation ....................................................................................................................................71
Enrichment .....................................................................................................................................73
TO
Storage spaces and partitions ........................................................................................................79
4. Integrations........................................................................................................................81
4.1 Integration with Kaspersky Security Center ...................................................................................82
4.2 LDAP integration ............................................................................................................................91
T
4.3 Kaspersky Threat Lookup...............................................................................................................98

4.4 Kaspersky CyberTrace .................................................................................................................102
NO
4.5 Kaspersky Endpoint Detection and Response .............................................................................109
1
D
5. Correlation and work with events ...................................................................................111
TE
5.1 Work with events ..........................................................................................................................112
5.2 Correlation ....................................................................................................................................117
Simple correlation rule ..................................................................................................................119
BU
Standard correlation rule ..............................................................................................................123
Variables .......................................................................................................................................134
Active lists .....................................................................................................................................137
Retrospective scanning ................................................................................................................143
RI
6. Response, alerts, reports and monitoring .......................................................................144
6.1 Alerts .............................................................................................................................................145
ST
6.2 Response......................................................................................................................................151
6.3 Dashboard and reports .................................................................................................................156
6.4 Metrics ..........................................................................................................................................162
DI
RE
OR
ED
PI
CO
BE
TO
T
NO
2
D
Acronyms and conventions
TE
Administration Server KSC Administration Server
BU
Central Node Kaspersky Anti Targeted Attack Central Node
Cybersecurity Information Security
DBMS DataBase Management System
RI
EPS Events Per Second
KATA Kaspersky Anti Targeted Attack
ST
KEA Kaspersky Endpoint Agent
KEDR Kaspersky Endpoint Detection and Response
KES Kaspersky Endpoint Security
DI
KICS Kaspersky Industrial CyberSecurity
KSC Kaspersky Security Center
KSWS
KUMA
Network agent
RE
Kaspersky Security for Windows Server
Kaspersky Unified Monitoring and Analysis
KSC Network Agent

OR
SIEM Security Information and Event Management
WEC Windows Event Collector
WMI Windows Management Instrumentation

ED
XDR eXtended Detection and Response

PI
CO
BE
TO
T
NO
3
D
TE
1. General
BU
1.1 About SIEM
RI
This guide covers the Kaspersky Unified Monitoring and Analysis Platform product (or KUMA for short),
ST
version 2.0.1.
The official documentation is available at

https://support.kaspersky.com/help/KUMA/2.0/en-us/217694.htm.
DI
Documentation comes in handy when you need theoretical information; but if you need to solve practical
issues, you’d better consult the lab guide of this course.
RE
Kaspersky Unified Monitoring and Analysis is a SIEM (Security Information and Event Management)
product. Before moving on to Kaspersky Unified Monitoring and Analysis Platform, a few words about
why SIEM systems are needed, what problems they can solve and how they do it.
OR
ED
PI
CO
So, what is SIEM (Security Information and Event Management)? To avoid reinventing the wheel, let us
BE
quote Wikipedia:
“Security information and event management (SIEM) is a subsection within the field of computer security,
where software products and services combine security information management (SIM) and security
event management (SEM). They provide real-time analysis of security alerts generated by applications
TO
and network hardware”.
To put it in a less formal language, SIEM is a system that collects events from the whole corporate
network and helps cybersecurity specialists filter this data stream and automatically or semi-automatically
find indicators of information security incidents.
T
NO
4
KL 034.2: Kaspersky Unified Monitoring and Analysis Platform 2.0.1 1. General
D
Typical SIEM tasks
TE
BU
RI
ST
DI
RE
OR
Events that theoretically can help to detect and investigate an information security incident may be logged
by different systems, have different structure, format, encoding. This can be a Windows event log, Linux
audit event log, SQL database, etc.
ED
One of the primary SIEM tasks is to retrieve all these events from different sources.
Then something has to be done with all these events, because they are not really comparable in their raw
PI
form.
It turns out that the next task of SIEM is to convert them into some normalized form to be able to compare
CO
attributes of different events.
To detect correlations indicative of security incidents in normalized events, a SIEM system groups events
by various attributes and uses a set of correlation rules, conditions and more complex detection
mechanisms.
BE
Correlation allows you to interrelate different events using some (merely any) criteria.
For example, a connection to a computer and a file operation on that computer may be correlated by the
event time if they occur in a short timespan.
TO
Another example is when the proxy server provides information that a file was downloaded; this event can
be associated with an event about a file operation on a computer if their hashsums coincide.
Other functions of a typical SIEM are quite common, and you can find them in various analysis and
management systems:
—
T
Visualize data for analysis and incident investigation

— Notify responsible employees when ‘interesting’ events are detected
— Build reports about the system status and operation results
NO
5
D
Use cases
TE
BU
RI
ST
DI
RE
SIEM systems typically permit configuring flexible conditions to search events for a wide variety of
OR
patterns and correlations. Here are a few simple incident examples that SIEM can find:
— Brute-force attacks when multiple failed login attempts are followed by a successful
authentication. All these events can be correlated by the name of computer where they happen
or by the name of the user whose password is being brute-forced, and if there are many such
events in a short period of time, this is a clear sign of a brute-force attack that a SIEM system
ED
can easily detect

— The use of forged Kerberos tickets for computer authentication in the domain is a Golden Ticket
attack, when an adversary gets hold of the secret key of a service account in Active Directory
and can create a TGT (Ticket Granting Ticket) for any user account in the domain, even non-
PI
existent, and grant it administrative permissions. And then use the TGT to obtain a ticket from
the TGS (Ticket Granting Service), which provides access to domain resources. A possible
detection logic is to monitor the tickets issued by TGT and give a TGS ticket only if a previously
CO
issued TGT ticket is presented. A domain user receives a TGT every 10 hours, so a TGS
request may not immediately follow a TGT request, and it makes sense to store TGT receiving
events for at least 10 hours. KUMA has an out-of-the-box correlation rule that uses a similar
Golden Ticket attack detection mechanism.
— Unprocessed threats when a threat detection event has not been followed by a neutralization
event. If we talk about an endpoint protection application, then detecting something is not a
BE
problem; from the security point of view, we are interested in cases when there was a detection
that was not followed by an event informing that the respective link was blocked or the file
involved was deleted, quarantined or disinfected. You can set some reasonable time interval
(say, 1 hour) and check whether a detection event is followed by another event with the same
threat identifier, file path or file hashsum within this period; if no, then we believe that the
TO
situation requires special attention

— Use of remote access applications. For example, the company has some critical servers or
workstations that are forbidden to connect to using remote access programs such as VNC,
TeamViewer and others. Meaning, SIEM will extract the name or address of the target host from
a connection event and check whether this host is included in the critical list
T
— Privilege escalation control on Linux servers. For example, there is a correlation rule that tracks
all cases of privilege escalation, and if the account that requested privilege escalation is not
NO
included in the allow list, then an incident is recorded
6
D
All these examples demonstrate that in order to detect an incident, the system must take into account
TE
multiple events, which are sometimes significantly separated in time and created by different systems.
These are just a few simple examples of what SIEM can detect. If the correlation rule constructing tools
are flexible and rich enough, detection capabilities are limited only by the analyst's imagination and the
BU
system resources.
SIEM key features
RI
ST
DI
RE
OR
ED
PI
Since a SIEM system potentially works with a huge number of events, it is crucial that it operates
efficiently. Therefore, an important parameter is its throughput, which is usually measured in EPS (Events
Per Second): the number of events that SIEM can process (normalize, enrich, correlate and save to the
CO
storage) per second. That’s the first factor.
Another factor is resource consumption. Obviously, achieving the necessary throughput at the expense of
wild hardware requirements is no good. Customers are not willing to invest fantastic sums into equipment,
they expect good performance with reasonable resources.
BE
Apart from that, the system must be widely scalable, i.e. have no limit on the amount of processed
information.
Another important thing is out-of-the-box functionality. Setting up SIEM from scratch is quite difficult: you
need to study formats of all kinds of logs that you want to collect. Windows events are XML, events from
TO
network equipment are something else (Netflow or syslog), events from security applications are
something entirely different, for example, json, etc. The more data you want to collect from different
sources, the more preparatory work you need to do when studying data formats of these sources. The
customer will obviously not be happy to analyze all these formats and write normalization and correlation
rules manually. Therefore, vendors strive to write as many normalizers for popular systems as possible
and provide them out of the box.
T
The same is true for enrichment rules. There are typical situations where enrichment is appropriate, for
NO
example, adding computer names by IP addresses or querying an external treat intelligence system to
7
D
find out whether hashes, URLs and IP addresses from incoming events are known indicators of
TE
compromise. You can add such enrichment rules out of the box.
And, of course, correlation rules. There are a lot of well-known situations that should be detected
automatically, such as a brute-force attack, network scanning, various techniques from the MITRE
BU
ATT&CK matrix, and so on. It is also reasonable to have out-of-the-box rules for these situations rather
than make the customer create them manually.
The more such resources, the better for the customer.
RI
Of course, it is impossible to cover all customers’ requirements with standard rules and each organization
will have some network topology specifics or special security requirements when it will be necessary to
detect some non-standard things. A customer may need particular correlation or normalization rules.
ST
You can supply this service as an add-on, but if a customer has specialists who would prefer to create
and modify such resources themselves, a simple, intuitive and user-friendly interface of the SIEM system
will greatly simplify their routine.
DI
Kaspersky Unified Monitoring and Analysis Platform has all the characteristics of a good SIEM:
— The microservice architecture provides seamless scalability without bottlenecks: you can deploy
RE
a full-featured demo system on an office workstation; on the other hand, if necessary, the
solution can be deployed in a fault-tolerant and distributed architecture with a throughput of 500
000 events per second or more
— KUMA includes predefined settings for receiving events in standard formats and normalizing
them into a single format (CEF), as well as sample correlation rules. The lists of supported
OR
protocols, incoming data formats and ready-to-use out-of-the-box resources are constantly
supplemented
— All KUMA components are configured in a simple graphical interface that does not require
knowledge of any special markup or programming languages. You can combine KUMA
resources in many different ways to solve a variety of practical tasks
ED
Kaspersky Unified Monitoring and Analysis Platform provides a wide range of capabilities to enrich events
from external sources and close (but optional) integration with Kaspersky ecosystem of products and
services:
PI
— Kaspersky Security Center provides extended information about assets (including their
vulnerabilities) for analysis, and automated incident response
—
CO
Kaspersky Threat Lookup allows you to query the Kaspersky cloud cyberthreat intelligence
database to gain context and detect indicators of compromise
— Kaspersky CyberTrace automates detecting indicators of compromise by querying the local
Threat Intelligence Platform and allows the analyst to add data from events to the local database
of indicators of compromise with a single click
BE
1.2 About KUMA

TO
Let’s proceed from general information about SIEM systems to Kaspersky Unified Monitoring and
Analysis. This section is devoted to its architecture, operation principles, licensing, scaling and technical
support.
T
NO
8
D
KUMA operation principles
TE
BU
RI
ST
DI
RE
OR
Kaspersky Unified Monitoring and Analysis Platform has a modular (microservice) architecture, meaning,
it consists of several services that interact with each other. Almost all of them are implemented as Linux
services and each service is responsible for a specific function:
ED
— Core provides a web interface for administrators and analysts, stores settings of all other
services and acts as a coordination center for the whole platform. The settings are stored in the
local MongoDB database, and all services connect to the core to get their settings
PI
— Collector receives events from external sources and pre-processes them: normalizes (transforms
into a single format), filters, aggregates and enriches with data from external sources
CO
— Correlator processes already normalized events from collectors and applies correlation rules to
discover relationships between the events. Incident alerts are generated as a result of correlation
— Storage contains events and provides search capabilities. Search can be performed either
explicitly through the web interface, or implicitly through a dashboard widget, report or
retroscanning task.
BE
At the technical level, the storage is a ClickHouse cluster that uses the ClickHouse Keeper
component to coordinate interaction between the nodes.
In addition to other services, there are also KUMA agents for Windows and Linux.
—
TO
KUMA agent for Windows is a service installed on Windows computers that collects events
from Windows Event Log and forwards to a collector, which normalizes them and sends to the
correlator and storage
A KUMA agent for Windows can collect events in one of two modes:
— WEC mode, when the agent collects events from the log of the device where it is installed
T
— WMI mode, when a single agent collects Windows events over the network from multiple
devices
NO
9
D
We will describe the process of collecting events from Windows Event Log in detail in one of the
TE
following sections.
— KUMA agent for Linux is a service installed on Linux computers that can read its log file line by
line and forward this data to a collector for further processing in KUMA
BU
Additionally, KUMA agents for Linux and Windows can relay events or split data flows within the system.
An agent forwards an event as it is, without any modifications; therefore, you can configure an agent
service to listen for incoming data, copy it without changing the contents and send a few copies to several
collectors concurrently.
RI
We will study how KUMA agent for Windows works in one of our labs, where we will collect Windows
events via WMI.
ST
KUMA architecture (simplified)
DI
RE
OR
ED
PI
CO
Let us consider data flows in Kaspersky Unified Monitoring and Analysis Platform.
Kaspersky Unified Monitoring and Analysis Platform primarily receives events from external sources. It
BE
supports multiple sources and event formats: NetFlow from network hardware, Windows events, events
from security tools such as Kaspersky Security Center or Kaspersky Anti Targeted Attack Platform and
others.
Kaspersky Unified Monitoring and Analysis Platform can listen for events in different formats on the
TO
specified port or read events from a file, SQL database, or from Kafka or NATS event routing systems.
The list of supported formats, protocols and sources is constantly being updated and is available in the
online help at
https://support.kaspersky.com/help/KUMA/2.0/en-us/217776.htm
Collectors receive events from external sources (alternatively, an active collector can retrieve events from
T
a passive source such as an SQL database). Each collector is implemented as an individual service.
Different types of incoming data require dedicated collectors. But it is best to set up separate collectors
NO
10
D
even for data of the same type (for example, CEF or syslog) that come from different sources. This will
TE
simplify configuration and troubleshooting.
Collectors are installed on a Linux operating system. You can install multiple collectors on a single server,
or allocate a separate server to each collector. When a collector receives data, it converts it into the CEF
BU
format, which is the internal data format in Kaspersky Unified Monitoring and Analysis Platform. The
primary conversion simply maps the values of the fields in the original data format to the Kaspersky
Unified Monitoring and Analysis Platform fields (CEF). When processing events, the collector can modify
data using simple replacement operators or regular expressions.
RI
The collector can also filter data and discard what the administrator or analyst consider to be
uninteresting and undeserving of processing and storage.
ST
The collector can aggregate events, meaning, replace a group of similar events with a single event that
includes the group’s statistical parameters. For example, instead of processing each event about a
connection between two addresses, it can create an event that there were so many connections between
address A and address B during which so much data was sent or received.
DI
Finally, a collector can send requests to external systems to enrich events with data that was missing
from the initial event. In particular, the following requests are supported:
RE
— DNS — to resolve names into IP addresses and vice versa. If the initial event does not include
all the network attributes of a device, the enrichment mechanism can query a DNS server to fill in
the missing attributes
— LDAP — the enrichment mechanism can send requests to a LDAP server and, based on the
event attributes (for example, the user's SID), supplement the event with other information about
OR
this account from Active Directory
— Kaspersky Threat Lookup — a collector can query the cloud cyberthreat intelligence platform
using a hash, address or URL from the event, and if it matches an indicator of compromise,
enrich the event with information about the indicator
— Kaspersky CyberTrace — a collector can query the local cyberthreat intelligence platform in a
ED
similar manner and supplement events with data from matching indicators of compromise
Within the framework of enrichment, the collector can also use the local data of Kaspersky Unified
Monitoring and Analysis Platform. An administrator or analyst can upload data to KUMA as dictionaries
PI
and use them to convert or supplement events. For example, you can use a dictionary to replace or
supplement numerical event codes with text descriptions.
CO
Normalized and enriched events output by the collector are named base events. The collector mirrors
events to send them to internal consumers within the Kaspersky Unified Monitoring and Analysis
Platform: one of the streams goes to the storage to be persistently stored, and the other goes to the
correlator that will apply correlation rules to the events. You can configure storing the initial event along
with the normalized event.
BE
The correlator’s task is to find relationships between events that are important from the security point of
view. For this purpose, the correlator applies correlation rules to the base events. Rules can check if an
event matches some conditions, compare events and respond to specific sequences of events.
When a correlation rule is matched, the correlator creates a correlation event that is linked to the related
base events. When a correlation event appears, alerts are created or updated for security personnel, and
TO
the configured response rules are triggered. For example, you can configure the following responses:
start a task in Kaspersky Security Center or execute a script on the server where the correlator service is
running. Integration with Kaspersky Anti Targeted Attack Platform and Kaspersky Industrial CyberSecurity
for Networks adds other response options, for example, isolate an infected computer.
T
Correlation events can also be enriched with data from dictionaries and external sources. Enriched
correlation events output by the correlator can be sent to its input again or to the storage where they will
NO
be searchable similarly to base events.
11
D
All services exchange data with the core, from which they receive their settings. All changes that we
TE
make in the web interface are stored on the core. When a service starts, it connects to the core to receive
its settings. Few service settings are stored locally: core connection parameters, the certificate and the ID
of the service for which the settings are requested.
BU
In addition to the web interface, the core provides REST API that third-party systems can use to
communicate with KUMA. The API permits you, for example, to download alerts from KUMA to external
systems, search KUMA for events, create/import/export resources, and much more. You can find a
complete list of operations available via the API, their syntax and response codes in the KUMA online
help at https://support.kaspersky.com/help/KUMA/2.0/en-us/217973.htm
RI
Data in KUMA
ST
DI
RE
OR
ED
PI
CO
At different stages of event processing, it makes sense to talk about different types of events in
Kaspersky Unified Monitoring and Analysis Platform:
— At the beginning, collectors receive initial (raw) events
— The collector processes them and outputs normalized events
BE
— Normalized events made from raw events are named base events
— A collector can merge several similar base events into a single event that includes identical and
statistical parameters of the respective base events. Such events are named aggregated
— A correlator processes events by applying correlation rules to them. When a rule is matched, the
TO
correlator creates a so-called correlation event

— Additionally, Kaspersky Unified Monitoring and Analysis services can generate audit events
about their status changes
— There are also monitoring events that show that an event source has stopped generating events
T
or, conversely, the stream has increased abnormally

— Base, aggregated, correlation, audit and monitoring events are all normalized and you can
NO
search the database for events of a particular type
12
D
Services process events in streaming mode in real time and save them to the storage for further analysis,
TE
search or retrospective correlation.
In addition to events, Kaspersky Unified Monitoring and Analysis Platform deals with the following types
of objects:
BU
— Assets represent the organization’s computers. An analyst can organize assets into categories
and then use categories for filtering and correlation. The Kaspersky Unified Monitoring and
Analysis Platform core imports assets from Kaspersky Security Center; you can also create them
manually if necessary
RI
— Accounts — the core imports information about accounts from the specified LDAP server; you
can use this data for filtering and correlation
— Dictionaries contain information in the key-value format or in a table; you can use it to configure
ST
filters or to enrich events. For example, if there are code values in events, you can add a text
description to each code in a dictionary and enrich the events with this test description
— GeoIP — you can upload a database of IP addresses with the respective geographical data
(country, region, city, longitude, latitude) into KUMA
DI
— Settings are organized as so-called resources (connectors, normalizers, filters,
correlation/aggregation/enrichment rules, and others) and are used to configure services
RE
Assets, accounts, all settings and resources are stored on the core server in a local MongoDB database
in JSON format. Alerts, incidents and related copies of events, assets and accounts are also stored in
MongoDB. Meaning, an alert is a kind of container that stores information about all entities associated
with it.
OR
Report templates and dashboard layouts are also stored in MongoDB.
Another database, a VictoriaMetrics time series database, stores Prometheus metrics on the core.
Prometheus is a monitoring system that collects metrics from the specified endpoints. The Grafana
solution visualizes metrics in the KUMA interface.
ED
The last element in this diagram is the storage where our SIEM system sends events. Technically, events
are stored in a ClickHouse database in KUMA. ClickHouse is an open source column-oriented DBMS
developed by Yandex.
PI
CO
BE
TO
T
NO
13
D
Storing data in ClickHouse
TE
BU
RI
ST
DI
RE
OR
Events are stored in a ClickHouse database in KUMA.
At the component level, this is organized as follows: during the KUMA installation, one or more
ClickHouse instances are deployed (let’s focus on a simple case with only one DBMS instance for now),
to which the KUMA system writes incoming events for storage.
ED
The system interacts with the DBMS using a Storage service, which is installed locally on the same
server as the ClickHouse instance. The Storage service transfers data between KUMA and ClickHouse,
meaning, it acts as a connector between KUMA and ClickHouse.
PI
In addition to recording new events to the database, the Storage service also queries the database and
returns the results to the system, for example, when an analyst working with the SIEM manually searches
for events or when a correlator performs retroscanning. The Storage service also removes outdated
events from the ClickHouse database when their retention period expires (this period is also one of the
CO
settings of the storage service).

BE
TO
T
NO
14
D
Storing data in ClickHouse: sharding and replication
TE
BU
RI
ST
DI
RE
OR
The previous figure shows a simplified interaction scheme with a single server, storage service and
database. There can be only one ClickHouse instance in the entire KUMA installation and, accordingly,
only one Storage service.
ED
However, if you want to ensure high availability and fault tolerance for your database with KUMA events,
or if you need to scale your storage horizontally, ClickHouse provides so-called sharding and replication
mechanisms that allow you to build clusters from ClickHouse instances.
PI
First and foremost, we will not scrutinize ClickHouse architecture or capabilities in this course; we just
want to introduce the general concepts necessary for a basic understanding of the principles of KUMA
interaction with the database.
CO
So, data is divided among shards in ClickHouse. Sharding is an approach that involves breaking up a
distributed database into segments (shards). A shard is a mini-cluster that consists of several replicas
and stores some segment of data from our database (or the entire database if there is only one shard).
BE
When new data are written to the database, they are distributed among all shards according to a specific
algorithm. Meaning, when a group of events arrives to the database, some of these events will be
recorded to shard-1; another part, to shard-2; yet another chunk, to shard-3, and so on, depending on
how many shards the ClickHouse cluster has. The data is distributed evenly across all shards to balance
the load and optimize performance.
TO
There can be any number of shards, starting from one; it depends on the database operation conditions,
performance requirements, the amount of data stored, etc. You will be able to add new shards after the
system commissioning if you need to expand the storage. After that, data to be written into the storage
will be distributed between two, three or more shards as they are added.
T
Each shard consists of one or more replicas. A replica within a shard is a copy of the data stored in the
shard. There can be one replica per shard; in this case, the shard is not fault tolerant, and breakdown of a
server with a single replica may mean that all data stored on the shard will be lost. To ensure fault
NO
tolerance, create several replicas per shard.
15
D
In our diagram, each replica rectangle (replica-1, replica-2) represents a separate physical or virtual
TE
server that are combined into 2 shards (shard-1 and shard-2), or in other words we have 4 servers in total
within 2 two-replica shards.
Meaning, a shard is a logical entity, while replicas are servers with ClickHouse installed that are
BU
combined into a cluster in our diagram. When writing data to a cluster, the system decides which shard to
write data to. ClickHouse Keeper services monitor and coordinate tables across the database.
ClickHouse Keeper is a ClickHouse database coordination service for data replication and distributed
querying; it can also be deployed as a cluster.
RI
There must be an odd number of keepers to avoid the split-brain problem: 1, 3 or 5 (typically, 3 keepers
are used). ClickHouse Keeper services can be installed either on separate or on the same servers as the
ST
ClickHouse instances (the latter is the usual practice). But remember that latency is an important
parameter for ClickHouse Keeper, and ClickHouse Keeper and ClickHouse itself may compete for
resources on weak virtual machines; therefore, it is important to allocate adequate resources to
ClickHouse Keeper or install it on a dedicated server; otherwise, cluster nodes may switch to read-only
mode and the whole cluster may malfunction.
DI
For more information about ClickHouse, refer to its official documentation.
KUMA configuration principles

RE
OR
ED
PI
CO
BE
Kaspersky Unified Monitoring and Analysis Platform consists of several interacting services: core,
TO
collector, correlator and storage, and also services of the agent that collects Windows events.
Settings of all services are organized as a set of resources. Each resource defines a particular aspect of
the service's operation, such as connection or listening address and port, filtering conditions, enrichment
rules, names and passwords for authentication in external systems, dictionaries for converting data, and
T
so on.
NO
16
D
Resources are simply sets of parameters that are stored as JSON structures in the core database. When
TE
a service starts, it sends a request to the core service and receives its settings in response. The core
reads its own settings from the database directly.
The advantage of such an organization is that each resource has its clear and specific purpose and a
BU
very small set of parameters.
For example, a connector resource consists of an address, port and protocol; it also describes the low-
level format of data that comes from a source (encoding and delimiter between the events).
RI
A connector is a parameter of a collector configuration; other parameters determine how to normalize an
event (a normalizer resource), which events to discard (filter resources), which events to combine
(aggregation rules) and which events to enrich (enrichment rules). The storage and correlator addresses
ST
(destinations) are also configured as resources.
You can reuse a resource. For example, a filter specified as a resource can be a parameter of several
different correlation rules or even rules of other types (enrichment, aggregation).
DI
Kaspersky Unified Monitoring and Analysis Platform has the following resources:
— Connectors set network parameters for receiving data from external sources or connecting to
external sources; they also describe high-level parameters for parsing events, such as encoding,
RE
delimiter and others. Collectors use connectors to extract raw events
— Normalizers are complex configurations for converting raw events to normalized events. The
normalizer and connector are the main settings of a collector
— Filters are sets of conditions that can be used to filter incoming events, to select events in
OR
correlation rules or to selectively apply enrichment, aggregation or response
— Aggregation rules describe how to replace multiple similar events with a single joint event.
They are used in collectors
— Enrichment rules specify how to add new information fields to events: either by converting
available fields or by requesting data from external systems. Enrichment is used in collectors and
ED
correlators
— Correlation rules — correlators use them to detect correlations. Correlation rules use filters to
pick out events
PI
— Destinations set network parameters for transmitting normalized events. Destinations are used
in collectors and correlators to describe where to send processed events. Usually, a correlator
and the storage act as destinations
CO
— Active lists are dynamically populated key/value sets. Correlation rules populate active lists.
You can use the contents of active lists in filtering conditions (including correlation rules) and to
enrich correlation events. Active lists reside in the correlator’s memory and are only used in
correlators
— Dictionaries are static key/value sets that can be used in filtering conditions and enrichment
BE
rules
— Secrets include user names, passwords and sometimes certificates for authentication in external
systems. They are used in global settings and connection resources
— Responses define how to respond when correlation rules are triggered: run a script or start a
task in Kaspersky Security Center, Kaspersky Anti Targeted Attack Platform or Kaspersky
TO
Industrial CyberSecurity for Networks. Responses are used in correlators

— Notification templates — contents of the message body when notifying about a created alert.
They are configured in global alert settings
— Proxies define proxy server settings for connecting to data sources. They are used in global
T
settings and connection resources

NO
17
D
Formally, services do not pertain to resources, but in reality, services are also a kind of resources that
TE
use other resources.
Hardware requirements
BU
20K EPS and 6-month retention
RI
ST
DI
RE
OR
ED
Kaspersky Unified Monitoring and Analysis Platform is designed to scale flexibly to meet various (even
very high) loads. The main parameter for load estimation is the amount of incoming data, which is usually
PI
measured in events per second (EPS).
During the load tests, Kaspersky Unified Monitoring and Analysis Platform successfully processed a
CO
stream of 500K EPS; and the bottleneck was the speed of the collector’s network interface card rather
than the computing platform.
A single server with 4 CPU cores and 8GB of RAM is recommended for a demonstration. In a production
environment, resource consumption depends on various factors:
BE
— Types of processed events. Events of different formats may require different amount of
resources for normalization and other processing
— The amount and types of correlation rules. The more complex correlations need to be
discovered, the more resources the rules can require. You must be careful and always test rules
before using them in the production environment. Quite often, the same aim can be achieved in
TO
several different ways and testing helps find the most efficient one
A pilot rollout enables you evaluate resources more accurately. However, resource consumption may
change over time as a result of a reconfiguration or adding correlation rules.
To process a 10K EPS stream, it is usually enough to install the core, collector and correlator on a single
T
server and allocate another server for the storage.

NO
18
D
The product team has a sizing guide with approximate server specifications for typical EPS streams in an
TE
infrastructure of an average customer. It describes distributed installations where each server is allocated
for a particular service and specifies how much memory, processor and disk recourses are needed.
The figures show several load examples.
BU
When processing a data stream of 20K EPS if you need to store events for 6 months, it is recommended
to install each service (core, collector, correlator, storage) on a dedicated server. Storage presumes
replication in this case.
RI
In total, you need to allocate 5 servers with appropriate hardware.
ST
DI
RE
OR
ED
PI
CO
To process a data stream of 20K EPS and store events for 12 months, we recommend that you add 2
more storage servers, taking into account replication.
Meaning, you will need to allocate 7 servers with adequate hardware in total.
BE
TO
T
NO
19
D
TE
BU
RI
ST
DI
RE
OR
To process a data stream of 30K EPS and store events for 6 months, we recommend that you allocate 7
servers with appropriate hardware, taking into account replication.
ED

PI
CO
BE
TO
T
NO
20
D
To process a data stream of 50K EPS and store events for 6 months, we recommend that you add
TE
another collector and thus allocate 8 adequate servers in total, taking into account storage replication.
To estimate the resources required for a particular workload, partners should contact their manager at
Kaspersky, and Kaspersky employees can contact the product team.
BU
Licensing
RI
ST
DI
RE
OR
A key is required to activate Kaspersky Unified Monitoring and Analysis Platform. The licensing units are
ED
events per second (EPS). In the next section, we'll talk about where and how these events are counted.
There is a basic license for a specific number of events per second; the minimum number is 500 EPS and
then the number increases by 100: 600, 700, 800 and so on. An activation key can be issued for 1 or 2
years.
PI
Add-on licenses give access to extra functionality in addition to processing the specified number of events
per second. An activation key with High Availability support is required to build a configuration with
CO
redundant collectors or correlators. A NetFlow Support license enables the system to receive and process
NetFlow events without an EPS limit (which is useful for network equipment).
At this writing, the following types of Kaspersky Unified Monitoring and Analysis Platform license keys are
available:
—
BE
KUMA (base)
— KUMA (base) + High Availability
— KUMA (base) + NetFlow
— KUMA (base) + High Availability + NetFlow
It is worth noting that a base license is sufficient for deploying a failover ClickHouse cluster with data
TO
replication.
T
NO
21
D
How and where EPS is counted
TE
BU
RI
ST
DI
RE
OR
All Kaspersky Unified Monitoring and Analysis Platform license keys have a limit on the number of events
processed per second. This number is counted at the collectors’ output, which means that only base and
aggregated events are considered. Therefore, filtering and aggregating helps reduce expenses. The
number of unique events is counted; if they are sent to two destinations (correlator and storage), only one
copy will be counted.
ED
Kaspersky Unified Monitoring and Analysis Platform counts EPS every second and then calculates daily
average, starting with the product launch. If the average daily EPS value exceeds the license limit by
more than 30%, the administrator will be notified by email, and the same notification will appear in the
PI
interface.
Warnings also appear 30 days before a key expires and 7 days before and after the key expires. If a key
is missing or has expired, administrators and analysts will not be able to create, modify or delete
CO
resources and services. Running services will keep going, but if you need to restart something, you will
not be able to start the service without a new license.
BE
TO
T
NO
22
D
TE
BU
RI
ST
DI
RE
OR
ED
PI
CO
BE
TO
T
NO
23
KL 034.2: Kaspersky Unified Monitoring and Analysis Platform 2.0.1 2. Deployment
D
2. Deployment
TE
In this chapter, we will talk about Kaspersky Unified Monitoring and Analysis Platform installation options
BU
and deployment results. This chapter also describes the role-based access model and multitenancy in
Kaspersky Unified Monitoring and Analysis Platform.
Installation requirements
RI
ST
DI
RE
OR
ED
PI
Kaspersky Unified Monitoring and Analysis Platform supports two installation modes:
CO
— All-in-one — when all KUMA services are installed on the same server
— Distributed installation — KUMA services can be installed on separate servers in various
combinations
It is better to evaluate system requirements for a distributed installation based on the results of a pilot
BE
rollout and recommendations of the product team, depending on the intensity of the incoming event
stream. Example values are represented in the previous section.
Kaspersky Unified Monitoring and Analysis Platform services can be installed on physical or virtual
servers.
TO
All services of Kaspersky Unified Monitoring and Analysis Platform are installed on Linux operating
systems. Kaspersky Unified Monitoring and Analysis Platform version 2.0 supports:
— Oracle Linux 8.6 or later

— Astra Linux Special Edition 1.7 or later
T
NO
24
D
An all-in-one installation is intended for demonstration purposes and fits small organizations; the following
TE
configuration is recommended for it:
— Processor with 4 processing cores (if HyperThreading is used, each thread is considered as a
core)
BU
— 8GB of RAM
— 100GB of hard drive space
— 100Mbps network interface
RI
The web interface supports the following browsers:
— Google Chrome 102 or later
— Mozilla Firefox 103 or later
ST
It is recommended to use the XFS file system when preparing the server. Kaspersky Unified Monitoring
and Analysis Platform saves its files into the /opt folder, so we recommend that you make a separate
partition for /opt and allocate all available disk space to it, except 16GB required for the operating system.
DI
The services are addressed using their FQDN within Kaspersky Unified Monitoring and Analysis Platform,
and it is important that you configure a correct name for the server. To verify this, carry out the
hostnamectl status command. By default, all connections between the services are encrypted with
RE
certificates that the Kaspersky Unified Monitoring and Analysis Platform Core issues for the FQDN
addresses of the servers where services (collectors, correlators, storages) run.
More information about system and hardware requirements is available in the online help at
OR
The online help also describes prerequisites. For example, Python 3.6 or higher must be installed in the
system, and SELinux must be disabled.
ED
PI
CO
BE
TO
T
NO
25
D
All-in-one installation
TE
BU
RI
ST
DI
RE
OR
To install KUMA, download the Kaspersky Unified Monitoring and Analysis Platform distribution to the
server and unpack it. The unpacked contents are saved into the kuma-ansible-installer folder.
Then you will need to perform a few simple steps that depend on KUMA installation mode.
ED
For an all-in-one installation:

1. Prepare an Ansible inventory file
Edit the template file included with the distribution: single.inventory.yml. Specify the KUMA
PI
installation parameters in this file. As an all-in-one installation takes place on a single server, you
only need to specify the address of this server for each component (core, storage, collectors and
correlators).
CO
You can also edit the deploy_example_services parameter to specify whether to install out-of-
the-box services automatically. This is a set of 5 collector services with default normalization
rules for popular event sources, a correlator service and a storage service. By default, the value
of the deploy_example_services variable is true.
2. Copy your Kaspersky Unified Monitoring and Analysis key file to the folder /kuma-ansible-
BE
installer/roles/kuma/files/ and rename it license.key. A key file usually has an

alphanumeric name that must be changed to license.key. Otherwise, the installation will return
an error explaining that the license.key file was not found in the installer folder
3. Run the script install.sh with the name of the prepared Ansible yml file as a parameter:
./install.sh single.inventory.yml
TO
4. Then accept the license agreement, after which the script will install all product components
according to the parameters specified in the yml file.
T
NO
26
D
Distributed installation
TE
BU
RI
ST
DI
RE
OR
A distributed installation of Kaspersky Unified Monitoring and Analysis Platform requires several
additional steps in comparison with an all-in-one installation. You need to prepare an ssh key. Step-by-
step instructions are as follows:
1. Generate an ssh key to authenticate the installer on all target hosts. Command example:
ED
ssh-keygen –N “”
2. Copy the public ssh key to all servers where Kaspersky Unified Monitoring and Analysis Platform
components will be installed (core, collector, correlator, storage nodes). Command example:
ssh-copy-id –i /root/.ssh/id_rsa root@<hostname>
PI
3. Prepare an Ansible inventory file for a distributed installation

Edit the template file included with the distribution: distributed.inventory.yml. In the file, specify
CO
the FQDN and IP address of the target server for each component (core, storage, collectors and
correlators).
Pay special attention to the storage section that describes the configuration of the ClickHouse
cluster. Specify where to install replicas, which shard they will belong to and where to deploy
ClickHouse Keeper services.
BE
On our diagram, we have a two-node ClickHouse cluster (kuma-storage1.abc.lab and kuma-

storage2.abc.lab), these are two replicas of a single shard, meaning, a fault-tolerant
configuration. The storage is controlled by ClickHouse Keeper services; there should be an odd
number of them, 3 or 5, in such a configuration. In our example, two ClickHouse Keepers
(keeper: 1 and keeper: 2) are deployed on the ClickHouse cluster nodes and one more
ClickHouse Keeper (keeper: 3) is installed on the core server.
TO
In a production environment, we recommend that you deploy ClickHouse Keeper services to

dedicated servers, because the system response time is important for them.
4. Copy your Kaspersky Unified Monitoring and Analysis key file to the folder /kuma-ansible-
installer/roles/kuma/files/ and rename it license.key
T
5. Run the script install.sh with the name of the prepared Ansible yml file as a parameter:
./install.sh distributed.inventory.yml
NO
27
D
6. Then accept the license agreement, after which the script will connect to other servers, copy files
TE
there, and install components in accordance with the parameters specified in the yml file.
Sharding and replication in ClickHouse
BU
RI
ST
DI
RE
OR
Let's look at the possible configurations of a four-node ClickHouse cluster.
A shard contains a unique piece of data. A replica is a copy of this data piece.
ED
The numbers specified for replicas, shards and keepers in the configuration file are their IDs, not a
quantity. A shard without replicas contains nothing. Each shard must consist of one or more replicas.
The first configuration example: 1 four-replica shard

PI
Advantages: the most reliable way to store data (4 copies)

CO
Drawbacks:
— This amount of stored data copies is rather excessive in most cases
— Since there is only one shard in this configuration, a SELECT query cannot run in parallel on
different nodes
BE
— Additional resources are required for multiple replications of data between all nodes
Second configuration: 4 one-replica shards
Advantages: since there are 4 shards in this configuration, a SELECT query can run in parallel on all
cluster nodes.
TO
Drawbacks: the least reliable way to store data (if a node malfunctions, part of data will be lost).
Third configuration: 2 two-replica shards

T
Takes the best from both previously described configurations. Since there are 2 shards in this
configuration, a SELECT query can run in parallel on both cluster shards.A fairly reliable way to store
NO
data (if a cluster node malfunctions, data will not be lost).
28
D
Web console
TE
BU
RI
ST
DI
RE
OR
The installation takes a few minutes. When it completes, you can manage Kaspersky Unified Monitoring
and Analysis Platform through its web interface at https://<FQDN of the server running the core
service>:7220
ED
After the installation, Kaspersky Unified Monitoring and Analysis Platform has only one administrator
account:
— Username: admin
—
PI
Password: mustB3Ch@ng3d!
We recommend that you change the password as soon as you log on to the web interface. You can also
create other accounts with the administrator, analyst or operator role.
CO
BE
TO
T
NO
29
D
TE
BU
RI
ST
DI
RE
OR
This is the main menu of Kaspersky Unified Monitoring and Analysis Platform. Let's see what is where:
— Dashboard — the monitoring page that contains widgets with various real-time statistics. The
user can configure several layouts with different widgets and switch between them as needed or
have them rotated on a dedicated monitor in TV mode
— Alerts — this is where you deal with correlation alerts
ED
— Incidents — a section for working with incidents. In Kaspersky terms, an incident is a confirmed
alert. You can create an incident from an alert automatically or manually and link several alerts to
it if necessary
PI
— Events — the page for manually searching and analyzing events in the database and for re-
analysis of historical events by retrospectively applying correlation rules
— Assets — the page for managing your organization's computers (assets) where you can import
CO
computers from Kaspersky Security Center, add them manually and organize into categories
— Reports — you can configure the reports’ appearance and generation schedule here. Report
templates consist of the same layouts and widgets as the Dashboard
— Resources — this section consists of two parts:
BE
— Services — this is the page for configuring and managing Kaspersky Unified Monitoring and
Analysis Platform services: collectors, correlators, storage and Windows agents. The Core
service is not displayed here. You can create new service configurations and reload settings
or restart services
— Resources — you can configure resources necessary for service configurations here
TO
— CyberTrace — nested Kaspersky CyberTrace interface; this section appears after you configure
integration with Kaspersky CyberTrace
— Task manager — task results. Tasks include asset importing requests to Kaspersky Security
Center, LDAP account importing requests, Kaspersky Threat Lookup requests, export of events
from the ClickHouse database, retroscanning and some other activities. Tasks are created
T
automatically as a result of specific user actions in the console. On this page, you can see the
created tasks, consult their results or re-run them.
NO
30
D
— Settings — the global settings of Kaspersky Unified Monitoring and Analysis Platform, in
TE
particular, license management, user and role settings, tenant and hierarchy settings, integration
with Kaspersky and third-party solutions and systems, etc.
— Sources status — this section displays the list of sources that send data to collectors; you can
apply policies to sources and monitor their statuses
BU
— Metrics visualize Prometheus data about the load and status of Kaspersky Unified Monitoring
and Analysis Platform services
RI
Installation results
All-in-one installation result
ST
DI
RE
OR
ED
PI
CO
As a result of an all-in-one installation, the following services are created:

— Core (the kuma-core service, which is not displayed in the interface) uses the following ports:
— 7220/tcp to receive connections to the web console
— 7210/tcp to receive connections from other KUMA services
— 7223/tcp to receive API requests
BE
— 7222/tcp to organize reverse proxy to Kaspersky CyberTrace when its nested interface is
displayed in the KUMA console
— [OOTB] CEF collector uses the following ports:
— 7232/tcp to receive connections from the core service
TO
— 5140/tcp to receive data from external sources

— [OOTB] KSC collector uses the following ports:
— 5141/tcp to receive data from external sources
T
— [OOTB] Syslog collector uses the following ports:

NO
— 5140/udp to receive data from external sources
31
D
— [OOTB] Syslog-CEF collector uses the following ports:
TE
— 5144/udp to receive data from external sources
— [OOTB] Correlator uses the following ports:
BU
— 7230/tcp to receive connections from the core service and events from the collector
— [OOTB] Storage uses the following ports:
— 7231/tcp to receive connections from other services, including the core
RI
— 2181/tcp, 2182/tcp for interactions between ClickHouse and ClickHouse Keeper and internal
interactions between the ClickHouse Keeper nodes
— 9000/tcp, 9009/tcp for inter-node communications in ClickHouse (replications, distributed
queries)
ST
The ports used for internal communications are displayed on the Services page of the web
interface, in the API port column. The ports used for receiving and sending events are not
displayed in this table. You can find them in the connector properties within the service settings.
DI
The installation wizard creates rules for ports in the server's firewall.
If services encounter issues in a distributed installation of Kaspersky Unified Monitoring and
Analysis Platform, first of all, check the firewall and open all ports that KUMA services use.
RE
Full and up-to-date information on ports is always available in the online help at
Distributed installation results

OR
ED
PI
CO
BE
TO
In a distributed installation of Kaspersky Unified Monitoring and Analysis Platform, the list of active
services is empty after the installation. However, there are service templates that simplify manual
installation; click the Add service button and then install the necessary service (daemon) on the
T
respective KUMA server.

NO
32
D
For example, start with Storage services, then proceed to the Correlator and then to Collector; if
TE
necessary, add services of Windows and Linux Agents.
In our labs, we demonstrate a distributed installation so that the students can better and quicker
understand the architecture of Kaspersky Unified Monitoring and Analysis Platform and see for
BU
themselves that creating services manually is no big deal.
Tenants and system components
RI
ST
DI
RE
OR
ED
PI
We will not describe multitenancy in detail in this course; we’ll just outline the concept.
Multitenancy is a configuration aspect that you should keep in mind during the initial setup of the services.
CO
Tenant is a way to divide data access within an installation into several logical segments.
In essence, an installation is the core around which all other services, collectors, correlators and agents
are organized.
BE
With a single core, it is possible to separate data access thanks to tenants; in this case, a single KUMA
installation serves several organizations or organizational units (tenants) and the data of each
organization (tenant) is not available to someone from another organization (tenant).
Each resource, service and event pertains to a tenant. It looks like a folder structure in the interface; each
TO
tenant’s root folder is named after the respective tenant. We will arrange all resources and service
configurations into these folders as they are created, and grant access to data of a specific tenant to each
user individually.
For example, a user who has administrator rights in tenant-1 can create resources, edit settings, etc.
T
within it, but does not have any rights in tenant-2 and cannot even see it. A user who has operator rights
can only search for events and create reports, but can neither create services or resources nor modify
settings.
NO
33
D
At the same time, there are two special tenants: Main and Shared.
TE
The Main tenant is the principal tenant that is always created, even if the customer does not use
multitenancy. The Main tenant owns all out-of-the-box resources; integrations with various third-party
systems, multitenancy mode and access permissions of all users are configured globally in the Main
BU
tenant.
Another special tenant is Shared; you do not need to explicitly grant access to its resources in contrast to
ordinary tenants. Everyone can access resources that belong to the Shared tenant.
RI
The idea is that some of the resources that tenants use in Kaspersky Unified Monitoring and Analysis
Platform are always the same, for example, sources of the same type, normalizers, correlation rules,
enrichment rules, etc. To avoid creating the same entities for each tenant, you can create them in the
ST
Shared tenant; then they will be available to everyone. As a result, you have a single configuration
repository; only the users who have permissions for the Main tenant can create and reconfigure these
resources, but everyone can use them.
If a lot of tenants (different organizations) use the same Kaspersky Unified Monitoring and Analysis
DI
Platform installation, they can use a single ClickHouse cluster as a centralized event storage. Data from
all tenants will be sent to this storage, but each user account will have access only to the events of its
tenant.
RE
Once again, when we talk about any piece of data in KUMA (events, alerts, services), a tenant is its
property, for example, every event has the TenantId field. That is, during any interaction with the KUMA
interface or API, the system checks which tenants the user account has access to.
OR
Role-based access control model
Users and roles

ED
PI
CO
BE
TO
T
NO
34
D
Only one user who can access the web interface is created during an installation. This account is named
TE
admin and has the General administrator role. The General administrator role has the highest access to
all the settings of Kaspersky Unified Monitoring and Analysis Platform.
When administrators grant an account access to a tenant, they select a user role for it:
BU
— Administrator
— Analyst
— Operator
RI
Each role has specific permissions (what is allowed and what is prohibited), which cannot be changed.
You can create a user account in Settings | Users. An account has the following settings:
ST
— Name
— Login name
— Email address for notifications
DI
— Role in a tenant: administrator, analyst, operator. For example, a user can have the administrator
role in the Moscow tenant and the operator role in the Saint-Petersburg tenant
— Password
RE
— API access rights — you can explicitly specify what actions the user can perform via API
Each user can change his or her own name, login name, email address or password. Users cannot
change their own roles.
OR
Only the General administrator can create users. An administrator can also change any account
parameters, including the user's role. You cannot delete users in the web interface, but you can disable
them.
The General administrator can work with global settings that are not bound to individual tenants in
Kaspersky Unified Monitoring and Analysis Platform. We are talking about performance metrics, users,
ED
integrations with Threat Intelligence, IRP, etc. Only the General administrator can create tenants and
hierarchies.
To grant a user the General administrator role, configure the respective option in the account properties.
PI
CO
BE
TO
T
NO
35
D
User privileges
TE
BU
RI
ST
DI
RE
OR
Generally, the roles differ as follows:

— Global administrator — the almighty
— Administrators can do anything within their tenant, for example, change or delete entities
ED
created by other users, such as report templates

— Analysts can create resources and reconfigure services, but cannot create or restart services
— Operators cannot create any resources and do not have access to services, but can search for
PI
events and work with alerts and the dashboard
Roles are described in more detailed in the online help at

CO
BE
TO
T
NO
36
D
Domain authorization
TE
BU
RI
ST
DI
RE
OR
In Kaspersky Unified Monitoring and Analysis Platform, you can configure integration with AD to enable
users to authenticate under their domain accounts.
You can specify an AD group in the role properties in Kaspersky Unified Monitoring and Analysis
ED
Platform. If an account belongs to several groups that have different roles in a tenant, it receives the role
with the least permissions.
PI
CO
BE
TO
T
NO
37
KL 034.2: Kaspersky Unified Monitoring and Analysis Platform 2.0.1 3. Event collecting and processing
D
3. Event collecting and processing
TE
BU
3.1 Collecting events
In this section, we will study how events are collected, which connectors are available in Kaspersky
RI
Unified Monitoring and Analysis Platform, and what is the difference between connectors and collectors.
You will also learn when KUMA agents for Windows and Linux come in handy.
ST
KUMA services: ports and connections
DI
RE
OR
ED
PI
CO
Let's take a closer look at the services’ interaction.
Each service has a so-called API port for technical communications within Kaspersky Unified Monitoring
and Analysis Platform.
BE
Collector, correlator and storage services receive their settings in response to requests that they send to
the API port of the core service (kuma-core). This happens every time when a service starts.
The core service (kuma-core) can also send a command to the API port of a particular service to reload
TO
its settings or restart the service. It is the administrator who initiates commands via the web interface.
First of all, SIEM obtains events from external sources and normalizes them, thus simplifying correlations,
storage and manual analysis.
Collectors are responsible for this in Kaspersky Unified Monitoring and Analysis Platform. A collector can
T
either wait for events from an active source or request events from a passive source. In the former case,
a collector listens on a port; in the latter case, it establishes a connection or sends requests to the
NO
38
D
source’s port. The administrator configures what port to listen on or what address and port to query using
TE
the connector resources specified in the collector settings.
When a collector starts, it connects to the API port of the core service (kuma-core, port 7210/tcp by
default) to retrieve its settings and find out which port to listen on or where to send requests. An
BU
administrator or analyst can use the web interface to manually reload settings or restart the service. In
this case, the core service sends the respective command to the API port of the collector service.
If several collector services are installed on a single server, each will have its own API port, which is set
up dynamically during the service installation.
RI
The collector usually sends processed (normalized) events to the correlator and to the storage
concurrently. By default, the correlator listens for events on port 7231/tcp, and the storage listens on port
ST
7230/tcp.
Collector settings
DI
RE
OR
ED
PI
CO
Events undergo several processing stages in the collector (see the diagram):
BE
— Individual events are first extracted from the incoming data

— Then the events are converted to CEF (Common Event Format); this process is named
normalization
— Next, uninteresting (from the organization’s point of view) events are filtered out
TO
— Then a group of similar events can be aggregated into a single event with collective
characteristics
— And finally, events are enriched using the core database (dictionaries, GeoIP, KSC, LDAP) and
requests to external systems (DNS, Threat Intelligence)
T
Steps of the collector setup wizard correspond to event processing stages:

NO
— Transport — specify the connector responsible for extracting individual events
39
D
— Event parsing — specify the normalizer that will convert events to CEF format
TE
— Event filtering — specify the filtering rules with conditions that will select ‘interesting’ events
— Event aggregation — specify the aggregation rules
— Event enrichment — specify the enrichment rules
BU
Processed events are usually forwarded to the correlator and storage in two independent streams. The
Routing area of the collector settings defines this behavior.
Let us now study collector settings in the order of applying.
RI
Connector
ST
DI
RE
OR
ED
PI
A connector is a resource that describes how to retrieve messages from a particular source.
The connector can be passive, i.e. listen to some port to which active sources send data, or active, and
then the connector itself connects to passive sources (database, reading from a file, etc.) to retrieve data.
CO
You can create and configure a connector as an independent resource and then select it in the Connector
drop-down list. In this case, the connector settings will not be editable from the collector setup wizard.
You will be able to modify its settings in Resources only. This is the micro-configuration principle.
Everything that is saved as resources can be used as building blocks in various service configurations.
BE
When a resource is modified, the new settings will be used in all services that work with this resource.
A connector can be configured inside the collector (inline), but then it will belong to the internal
configuration of the collector service and you will not be able to use this connector when configuring other
services.
TO
T
NO
40
D
Connection settings
TE
BU
RI
ST
DI
RE
OR
Connector settings depend on its kind. Kaspersky Unified Monitoring and Analysis Platform permits
creating the following connectors:
—
ED
tcp, udp, http, netflow, sflow describe how to receive data from active external sources
— sql, ftp, nfs, smtp, smtp-trap, kafka, nats describe how to connect to external sources to
retrieve events
— file describe how to read data from a file
PI
— diode describe how to collect events from an isolated network segment. In this scheme, KUMA
components accumulate data in a specific directory inside an isolated network segment, and
then this data is sent to another directory in an external segment
CO
— wec, wmi — describe how to collect Windows logs (locally or remotely)
Most kinds of connections have the URL parameter that specifies the address and port for establishing
connections. tcp, udp and http connections describe waiting for connections, and you do not need to
specify an address in the URL field; you can specify only a port as ":5140", i.e. a colon and the port
BE
number. This is an abbreviation of 0.0.0.0:5141, which means that the service will accept connections on
all addresses of its server on the specified port. If necessary, you can specify an address to make a
service accept connections only on this particular address.
In connections designed for requests to external systems (sql, ftp, nfs, smtp, kafka, nats), the URL field
TO
is essential: without it, the service will not know where to connect.
A file connection allows you to specify a folder and mask of files from which data will be retrieved.
T
NO
41
D
TE
BU
RI
ST
DI
RE
OR
A few examples of unique parameters in various connector types:
— sql connector: in the query field, specify the query to be run in the database; identity column is
the column to search for event identifiers, and identity seed is the identifier of the event starting
from which you need to read data (if you want to start from scratch, leave this field empty)
— kafka connector: in the topic field, specify the topic which you want to subscribe the connector
ED
to, and in the groupID field, specify an identifier (any) for this connector that it will use to
‘present’ itself to Kafka
— nats connector: in the subject field, specify the subject to subscribe to
PI
— wec connector: in the windows logs field, specify names of the logs from which events will be
collected
— wmi connector: in the remote hosts field, specify addresses of remote hosts from which events
CO
will be collected; you will also need to specify accounts and log names
A detailed description of all parameters in different types of connectors is available in the online help at
In addition to the main parameters, there are additional parameters that are the same for most
BE
connectors. For example, the buffer size (how much data to accumulate in each portion), text encoding,
encryption (you can configure mutual authentication between the source and collector), data compression
using the Snappy utility to reduce network transmission overhead, and writing debugging information to
journalctl.
TO
T
NO
42
D
Receiving Windows events
TE
BU
RI
ST
DI
RE
OR
Let's study how to receive Windows events. In this scenario, the collector receives events from another
component of Kaspersky Unified Monitoring and Analysis Platform, the KUMA agent for Windows, rather
than directly from the source.
ED
The KUMA agent reads events from the specified Windows event logs and forwards them to the specified
collector.
The KUMA agent is similar to all other KUMA services: it receives its settings from the core service by
connecting to the core API port. It also accepts commands from the core service; this way, the
PI
administrator can remotely reload the agent’s settings or restart its service.
The KUMA agent can collect events from the local Windows Event Log; in this case, a WEC connector is
CO
used. Alternatively, the KUMA agent can collect events from remote Windows Event Logs; a WMI
connector serves this purpose.
Each agent must be registered as a service in the KUMA web interface. However, it is impractical to have
hundreds or thousands of agent services in the interface; and for this reason, we do not recommend that
you install a KUMA agent on every computer on the network (although this is technically feasible).
BE
What to do if there are thousands of computers on the network? The following options are possible:
— Assign one or more computers, for example, a domain controller, as event collectors. For this
purpose, configure Windows Event Collector, subscribe to receiving events from remote
TO
computers (event sources) and store them on the local computer (event collector). Events
gathered from remote computers will get into the Forwarded Events log in this case.
Therefore, it is enough to install a KUMA agent with a WEC connector only on event collectors
and configure it to fetch events from the Forwarded Events log
— Install the KUMA agent with a WMI connector on a dedicated computer and in the KUMA agent
T
settings, specify the list of remote computers to which it will connect to pick up events from the
logs
NO
43
D
Each method has its nuances, and it’s up to the customer to decide which event receiving method is
TE
preferable.
After the KUMA agent for Windows has received events, it forwards them to the collector for processing.
BU
Windows agent
WEC connector
RI
ST
DI
RE
OR
ED
PI
Before installing the KUMA agent, configure it as a service in the web interface. To do this, first prepare
the agent configuration on the Resources | Services | Agents page.
CO
If you create a KUMA agent with a WEC connector, its main setting is the Windows logs field; list the
Windows logs whose events need to be forwarded to the collector here. You can choose preset logs:
Application, System, Security, HardwareEvents and ForwardedEvents. To receive events from other local
logs (for example, Sysmon), type in its name. Full name of the Sysmon log is Microsoft-Windows-
Sysmon/Operational.
BE
TO
T
NO
44
D
WMI connector
TE
BU
RI
ST
DI
RE
OR
If you create a KUMA agent with a WMI connector, the main settings are Default credentials and
Remote hosts.
ED
In the Default credentials field, specify an account that has Event Log Readers permissions with which
the agent will connect to the remote Windows Event Log.
In the Remote hosts field, list addresses of the target remote computers, then add an individual list of
PI
logs for each host and specify an account. You can use the account from the Default credentials field or
another one.
The account is specified as a Secret resource of Credentials kind, meaning, a login and password that
CO
are stored in the MongoDB database on the core in an encrypted form.

BE
TO
T
NO
45
D
TE
BU
RI
ST
DI
RE
OR
We’ve studied the Connector section, i.e. how the KUMA agent will get events: via WEC or WMI.
Now let's look at the Destination section that describes where to send the collected data. Specify the
address, port and protocol of the collector that will receive data from the agent.
There can be several destinations; i.e. a single KUMA agent can copy the stream into several collectors,
ED
for example, to process different types of events in different collectors.
In addition to the basic connection parameters, there are several technical settings such as encryption
(you can configure a secure connection between an agent and a collector), a delimiter between events,
PI
buffer size, the number of worker processes, compression, debugging, and others.
The KUMA agent for Windows is quite fastidious to delimiter and encryption settings. It is important that
CO
the same delimiter is specified in the Destination section of the agent and in the collector settings; for
Windows events, the delimiter must be ‘\0’. It is equally important that the same values are specified in
the TLS mode field both in the KUMA agent and in the collector.
A template of KUMA agent for Windows is available among the preset resources.
BE
TO
T
NO
46
D
Windows agent service
TE
BU
RI
ST
DI
RE
OR
When the KUMA agent configuration is ready, publish the agent service. In the Active services section,
click the Add service button; then select the necessary agent configuration and click Create service.
The KUMA core will generate a unique identifier for the service, which will be used for starting the service
ED
on a remote computer. The red status means that the KUMA agent service is not running on any remote
computer.
PI
CO
BE
TO
T
NO
47
D
A published service receives a unique identifier that the KUMA agent uses to retrieve its settings. Copy
TE
this identifier (click the Copy ID button) and use it as an installation parameter when deploying KUMA
Windows agent.
Services of other types (collectors, correlators, repositories) are created in a similar manner. When
BU
creating a service, the administrator performs the following steps:
— Creates a configuration for the service
— Publishes the configuration on the list of services and gets a unique identifier for the new service
RI
— Installs the service on a Linux system and binds it to the published configuration using its unique
identifier
To install the KUMA Windows Agent, use the kuma.exe file included with the Kaspersky Unified
ST
Monitoring and Analysis Platform distribution; by default, it is located in the folder
/kuma-ansible-installer/roles/kuma/files/
This is not an ordinary Windows installer, it is rather a utility for installing and managing the services of
DI
KUMA agent for Windows.
To register the KUMA agent as a service, run kuma.exe with the following parameters:
RE
kuma.exe agent --core <URL of the API port of the core service> --id <copied agent id> --user
<account with the Log on as a service permissions> --install
The command kuma.exe --help outputs the complete list of the utility capabilities. In particular, this
utility can display the list of installed agents (if there are more than one of them for some reason) or
OR
uninstall an agent service (using its identifier).
Note that the KUMA agent has an empty space in the API port column. The communication between the
agent and the core is one-way; the KUMA agent informs the core about its state every 15 seconds, and
the core can send the restart or configuration reload command in response.
ED
PI
CO
BE
TO
T
NO
48
D
As a result of the installation, an ordinary Windows service will be deployed. The executable file of this
TE
service is the same kuma.exe file that is copied to the folder C:\Program Files\Kaspersky Lab\KUMA\.
The following folder is also created: C:\ProgramData\Kaspersky Lab\KUMA\agent\<service ID>\. The

KUMA agent will store its logs, certificates, and event queue in it.
BU
It is worth adding that the KUMA agent does not store the settings locally. The connection parameters are
specified in the service start line. When the agent starts, it connects to the KUMA core to receive its
settings. If the agent cannot connect to the core when its service starts, it will not be able to retrieve the
settings and will not know which logs to collect or where to send them.
RI
Troubleshooting Windows agent
ST
DI
RE
OR
ED
PI
CO
If errors occur during the service installation, their description is usually clear enough to understand what
to do.
For example, the error No mapping between account names and security IDs was done means that
the specified account cannot be found in the domain.
BE
The process cannot access the file because it is being used by another process means that an
agent service is already running on this host and another one cannot be installed. To install another agent
service, you need to stop the current ones. That is, there may be several KUMA agent services in the
system and they can be running concurrently.
TO
The service did not start due to a login failure means that the account does not have the permission to
Log on as a service.
If the description is not clear and you don’t understand what the problem is, try to run the same command
without the --install parameter. This command also starts the agent, but does not register the service
T
in the system. In this case, the KUMA agent will output a detailed work log to the command line and it
most likely will contain additional descriptions that will help you solve the problem.
NO
49
D
In our example, the error The service did not respond to the start or control request in a timely
TE
fashion is quite vague; but when you run the agent without the --install parameter, another error
explains that there are problems with the secret in the agent configuration.
BU
RI
ST
DI
RE
OR
If the KUMA agent service has been successfully installed in the system, but events still do not arrive to
ED
the collector service input, select the debug checkbox in the agent settings to record extended
information.
You can find errors in the KUMA agent log file C:\ProgramData\Kaspersky Lab\KUMA\agent\<service
ID>\agent.log
PI
And the easiest way out is as follows:

CO
1. Uninstall the service (use --uninstall instead of the --install parameter)

2. Run the KUMA agent in real time without the --install parameter
3. Read the debugging information in the current session output on the command line and monitor
the collector at the same time
BE
4. When events start arriving to the collector, stop the KUMA agent
5. Start the agent installation again with the --install parameter
In this case, after the KUMA agent service is reinstalled in the system, events cannot fail to get to the
collector.
TO
A few tips on what is important to pay attention to in step 3 so that events begin to flow into the collector.
First, you already know that a KUMA agent transmits its status to the core every 15 seconds and then the
core may make it reload its settings or restart its service.
T
Second, search for the lines that begin with the prefixes [connector ‘...’] and [destination ‘...’]
NO
50
D
If there are errors in the [connector ...] lines, it means that the KUMA agent fails to retrieve Windows
TE
events. This may happen due to various reasons, for example, the account does not have rights to read
the Windows Event Log, or the remote host from which it needs to pick up events is inaccessible, or
something else.
BU
If there are errors in the [destination ...] lines, it means that the KUMA agent has retrieved Windows
events, but cannot send them anywhere because the destination is unavailable. The reasons may vary
again, perhaps the collector service is not running, or an incorrect address:port is specified in the
Destination section of the agent settings. It is also important (we have already mentioned this) that the
same delimiter is specified in the Destination section of the agent settings and in the collector
RI
configuration (for Windows events, the \0 delimiter must be used) and the same values are specified in
the TLS mode field for the KUMA agent and collector.
ST
Linux Agent
Linux agent service
DI
RE
OR
ED
PI
CO
In addition to KUMA agent for Windows, there is also the KUMA agent for Linux. In terms of installation,
BE
everything is very similar to installing the KUMA agent for Windows. First, create an agent configuration
and publish the service in the web interface, then pass the URL of the core service, the service ID and the
path to the folder where service files will be stored to the agent as parameters.
The kuma utility for running the Linux agent is also included with the Kaspersky Unified Monitoring and
TO
Analysis Platform distribution; by default, it is located in the folder /kuma-ansible-

installer/roles/kuma/files/
When you start the Linux agent, the process runs until it is interrupted. To make Linux agent start
automatically as a service, specify the required agent startup configuration in Systemd.
T
Unlike KUMA agent for Windows, the KUMA agent for Linux can read data from files, for example,
audit.log or syslog. Out-of-the-box normalizers are also available for these files.
NO
51
D
TE
BU
RI
ST
DI
RE
OR
In fact, Windows and Linux KUMA agents equally act as an intermediary between the source and
collector. Agents are almost collectors, they can receive events on a specific port or connect to the source
and pick up events. The difference is that agents cannot normalize events, they collect events and
transmit them to the collector in the same raw form, i.e. they act as redirectors and can copy the flow to
several collectors.
ED
When you create an agent configuration, almost the same types of connectors are available as for
collectors:
— tcp, udp, http describe how to receive data from active external sources
PI
— ftp, nfs, smtp, smtp-trap, kafka, nats describe how to connect to external sources to retrieve
events
— file connectors describe how to read data from a file (works on Linux agents only)
CO
— wec, wmi describe how to collect Windows events (works on Windows agents only)
We have already talked about the Destination section, it describes where to send the collected data.
Specify the address, port and protocol of the collector that will receive data from the agent.
BE
Another example of using a KUMA agent is encryption. For example, there is some source that does not
support encryption, but you want to receive its data in an encrypted form. In this case, you can install
KUMA agent on the source host and configure it to listen on some localhost port, and then send data over
a secure connection to the collector.
TO
T
NO
52
D
Troubleshooting Linux agent
TE
BU
RI
ST
DI
RE
OR
Troubleshooting Linux agent is almost the same as with Windows agent.
If Linux agent startup configuration is specified in Systemd, you can monitor its status through the
ED
standard service manager using the command systemctl status kuma-agent-<service

identifier>.
For diagnostics, you can consult the service log using journalctl or just stop the service and run sudo -u
PI
kuma <start command>; in this case, the log will be output to the terminal.
CO
BE
TO
T
NO
53
D
TE
BU
RI
ST
DI
RE
OR
If no events arrive when the agent is started, select the debug checkbox in the agent settings to record
extended information and then consult the agent log. Pay special attention to the lines that begin with the
prefixes [connector ‘...’] and [destination ‘...’]
If there are errors in the [connector ...] lines, then the KUMA agent cannot receive events, for example, if
a file connector is used, then the files not found message means that either the file is really missing or
ED
the account does not have permission to read this file.
If there are errors in the [destination ...] lines, then the KUMA agent cannot connect to the destination, it
may be inaccessible or a wrong address:port is specified in the Destination section of the agent
PI
settings.
If there are no errors but events do not arrive to the collector, check whether the necessary ports are
CO
open in the firewall on the Linux agent side, maybe events do not reach even the agent.
BE
TO
T
NO
54
D
SQL connector
TE
BU
RI
ST
DI
RE
OR
Let's take a closer look at another connector type, sql.

ED
It can connect to various SQL databases:

— MSSQL
— MySQL
— PostgreSQL
—
PI
SQLite3
— Oracle DB
— Firebird SQL
— CockroachDB
CO
This connector has several required settings:

— URL is set as a Secret resource of the urls kind. The database address, instance name and
account are specified here
— Identity column is the column to search for event identifiers
BE
— Identity seed is the identifier of the event starting from which the connector will need to read
data. If you want to start from scratch, leave this field empty. After each connection, the
connector will save the value of the last read seed to ‘know’ which events it has already retrieved
and which are new
TO
The Query field contains the SELECT statement to retrieve events from the database according to the
specified criteria.
T
NO
55
D
Connecting to the KSC database via the SQL connector
TE
BU
RI
ST
DI
RE
OR
Let's find out how Kaspersky Unified Monitoring and Analysis Platform can retrieve Kaspersky Security
Center events from its Microsoft SQL database.
ED
Sure, Kaspersky Security Center can send events to the SIEM system in different formats (syslog, CEF,
LEEF) itself. But Kaspersky Security Center cannot send events in CEF or LEEF format with the Select
license (a higher license is required), and as far as the syslog format is concerned, you must select the
types of events that need to be sent to SIEM first.
PI
Besides, Kaspersky Security Center can send only events, while its SQL database also stores other data
useful for analysis in Kaspersky Unified Monitoring and Analysis Platform that you can obtain when
accessing the database directly.
CO
The connector for Kaspersky Security Center is available out of the box. It uses two queries to the SQL
database: one of them retrieves events, and the other retrieves the list of devices connected to Kaspersky
Security Center.
BE
The preset query uses the default database name KAV; if the database has a custom name in your
installation, specify it in the Query field.
In the URL field, specify the database connection parameters. Different syntax is used for different types
of databases. For Microsoft SQL, the syntax is as follows:
TO
sqlserver://<domain>%5C<login>:<password>@<SQL server FQDN>/<SQL instance

name>?database=<database name>
Even though you specify the password explicitly, it will not be compromised. When you save the secret,
the password is encrypted and then stored in the MongoDB database on the core. If you want to modify
T
the secret, when you open it, the URL field will be empty, i.e. the password will no longer be displayed
explicitly.
NO
56
D
Therefore, to avoid re-typing the connection string when you need to change the password or just correct
TE
a typo, we recommend that you copy the connection string from the Description field when you create the
secret for the first time (naturally, without specifying the password explicitly).
The syntax of the URL field for different types of databases is described in the online help at
BU
Troubleshooting an SQL connector
RI
ST
DI
RE
OR
ED
PI
If you’ve configured a collector with a connector to the SQL database but events do not arrive to
Kaspersky Unified Monitoring and Analysis Platform, check the service log via journalctl using the
command journalctl -f -u kuma-collector-ID
CO
Pay special attention to the lines that begin with the prefixes [connector ‘...’] and [destination ‘...’]
Errors in the [connector ...] lines will show whether it is possible to connect to the SQL database. The
most common errors are an incorrect database server address, or an incorrect database name in the
Query field, or problems with the account during authentication.
BE
Errors in the [destination ...] lines may mean that there are issues with the correlator or storage service,
i.e. the event collector retrieves events from the SQL database, but they cannot reach the storage and
accumulate in the collector buffer.
TO
T
NO
57
D
3.2 Normalization of events
TE
In this section, we will talk about the Kaspersky Unified Monitoring and Analysis Platform data model,
which incoming data formats KUMA supports and what capabilities are available when converting data to
BU
KUMA format.
RI
ST
DI
RE
OR
ED
Events arrive to the collector in the raw form. Different sources provide data in different formats (syslog,
CEF, xml and others). To compare them, you need to bring them to a common form, i.e., map fields of the
PI
original format to the KUMA format and save the field values accordingly. Moreover, the same information
(email, url, hash) may be found in different fields of source events, or there may even be just some data
structure separated by special characters instead of fields.
CO
The process of bringing all this together is named normalization or parsing. This is the most important
process in the collector, because all other processes (filtration, aggregation, enrichment, correlation)
heavily depend on normalization.
BE
TO
T
NO
58
D
TE
BU
RI
ST
DI
RE
OR
When events get into the collector, the next stage of their processing is normalization, parsing an event
into fields and writing the values of the source fields into the fields of the KUMA data model (the diagram
shows 5 green rectangles: these are 5 stages of event processing in the collector). Note that KUMA uses
the CEF (Common Event Format) format.
The so-called normalizer is responsible for event parsing. This is another type of resource that describes
ED
the algorithm of how and which data of the source event to write to the KUMA format. You can create and
modify normalizers on the respective page of the web interface (Resources | Normalizers).
In a collector configuration, simply select a normalizer from the list.

PI
This stage is a must, a collector cannot exist without a normalizer. The black circle indicates that a preset
normalizer is available; click it to open its settings.
CO
BE
TO
T
NO
59
D
KUMA data model
TE
BU
RI
ST
DI
RE
OR
The KUMA data model is based on CEF (Common Event Format) with some additions. The CEF provides
fields for most data that can be found in events such as computer names, addresses, ports, file names
and checksums, identifiers of processes, users and devices. If standard CEF fields are insufficient, there
ED
are also special fields (for example, DeviceCustomString*) that an analyst can fill with custom data. There
are about 130 fields in total.
KUMA adds its own fields that store the unique identifier of the event in KUMA (ID field), identifier of the
PI
collector or correlator service that created the event (ServiceID field), the entire original event (Raw field),
unparsed fields: the part of the event from the Raw field that failed to be converted (Extra field), cyber
intelligence data that can be obtained by CyberTrace enrichment (TI field), fields with geodata, and
CO
others. There are about 40 fields in total.
For a complete list of fields in Kaspersky Unified Monitoring and Analysis Platform data model, see the
online help at https://support.kaspersky.com/help/KUMA/2.0/en-US/217941.htm
BE
TO
T
NO
60
D
Types of normalizers
TE
BU
RI
ST
DI
RE
OR
The primary task of the normalizer is to transform the values of the initial event fields into the KUMA
normalized event fields (CEF). For this purpose, map the initial fields to the KUMA fields in the Normalizer
settings.
Normalizers have a type that depends on the parsing method, i.e. what input data we expect. A collector
ED
can have only one main normalizer, meaning, you need to create a separate collector with the respective
normalizer for each event format. Otherwise, events will pass through the collector and will be written to
the storage in the raw form.
PI
Events typically have one of the widespread formats. Kaspersky Unified Monitoring and Analysis can
process the following data formats out of the box:
— csv (comma-separated values) — you need to specify the delimiter between the values in the
CO
normalizer
— kv (key-value pairs) — specify the delimiter between pairs and the delimiter within a pair in the
normalizer settings
— xml
BE
— json
— sql (an SQL query result table)
— cef, syslog, netflow, ipfix, sflow
TO
If incoming raw events have a standard format (CEF, syslog, NetFlow, IPFIX or SFlow), you can use the
built-in mapping settings available in KUMA.
If there is no ready-made normalizer for some source in KUMA, KUMA provides a flexible mapping
mechanism to convert source events of any format into KUMA events. The regexp normalizer type is
used for this purpose, which allows you to extract data based on regular expressions.
T
Kaspersky Unified Monitoring and Analysis Platform development plans include continuous expansion of
NO
supported formats, built-in mapping and example mapping for widespread event sources.
61
D
Field mapping
TE
BU
RI
ST
DI
RE
OR
The Mapping settings consist of a list of pairs: a source field – the field of the normalized KUMA event.
If the normalizer has the cef, syslog, netflow, ipfix or sflow type, you can click the Apply default mapping
button, and data will be mapped automatically based on the CEF format structure.
ED
To configure mapping for a normalizer of another kind, you must understand what fields an initial event
may have.
PI
One of the ways to understand this is to save an initial event into a special Raw field of a normalized
event. By default, KUMA stores initial events only if errors occur during normalization. When debugging
the normalizer, you can set the Keep raw event parameter to Always.
CO
Another way to map fields is to take a raw event, paste it into the Event examples field and try to write
mapping based on this event. If event format does not match the normalizer, you will immediately see the
‘normalization error’ message and will need to change the normalizer type.
Apart from saving the entire initial event, the normalizer can also write unmapped fields to a special Extra
BE
field. The Save extra fields option regulates this behavior. For example, there is an xml event that has
six fields. Say, we have written mapping rules for four fields only in the normalizer; then if the Save extra
fields option is enabled, the two unprocessed fields will be written to Extra, and if the Save extra fields
option is disabled, they will simply be discarded.
TO
T
NO
62
D
Extra field
TE
BU
RI
ST
DI
RE
OR
In fact, the Extra field is a very powerful tool that can be used for normalization, correlation and search.
ED
You can use the Extra field as a hint to see what other useful but unextracted information the original
event contains, i.e. mapping is not written for it.
The Extra field has json format; you can search for events by this field, i.e. send a SELECT query to the
ClickHouse database. You can search for a particular value of some field, or you can use the
PI
JSONExtractString function for a granular search.
And the most important feature of the Extra field is that you can leave it unnormalized and use field
CO
values in the Extra.<name of a field inside Extra> format in correlation rules. For example, if
you want to use values of the EventData.Data.CommandLine field from Extra in a correlation rule, specify
it as Extra.EventData.Data.CommandLine.
A good example is the Sysmon utility. Some events may contain hundreds of fields; the KUMA format is
clearly not enough to normalize this amount, but there is no need to fully normalize Sysmon; instead, you
BE
can simply use values in the Extra field format.

TO
T
NO
63
D
Converting fields
TE
BU
RI
ST
DI
RE
OR
A normalizer can convert data on the fly before writing to the fields of a normalized event: change to
lowercase, shorten to the specified length or cut out an arbitrary substring using a regular expression.
The following operations are available:
ED
— lower — convert to lowercase

— upper — convert to uppercase
— append — add the specified substring to the end of the value
— prepend — add the specified substring to the beginning of the value
PI
— substring — cut out a substring (you need to specify its initial and final positions)
— trim — remove characters at the end
— replace — if the initial value contains the specified substring, replace it with the specified text
CO
— regexp — replace with the value of the specified regular expression

— replaceWithRegexp — replace a matching group with the specified string
You can configure multiple transformations for the same value, for example, trim and convert to
lowercase.
BE
In particular, the regexp transformation comes in handy if the initial event has a field with various text
information. In this case, you can use regexp to map different parts of the source field to different KUMA
fields.
TO
T
NO
64
D
Extra normalizers
TE
BU
RI
ST
DI
RE
OR
You can use several normalizers in a collector. Different normalizers may be applied depending on
the conditions that an event matches. You can use this, for example, to record different information into
additional CEF fields depending on the event type.
ED
Additional normalizers can also contain conditions and pass events to other normalizers. This hierarchy
can theoretically be infinitely deep. But in practice you will hardly ever need numerous normalization
levels.
PI
For example, there are several sources that output events in CEF format. Instead of using multiple
collectors, you can send events from multiple sources to a single collector. The DeviceProcessName field
CO
of a normalized event will contain the source name. Then you need to create additional normalizers that
will check the value of the DeviceProcessName field. If the value is Source_1, then fields will be mapped
according to one algorithm, and if the value of the DeviceProcessName field is Source_2, then another
algorithm will be applied.
It is important that a condition checks the value of an initial event’s field using the name of this field in the
BE
initial event.
TO
T
NO
65
D
TE
BU
RI
ST
DI
RE
OR
Additional normalization is configured only in the properties of the main normalizer and is written from
scratch, i.e., you cannot use an existing resource as an additional normalizer.
The settings consist of a list of conditions and the corresponding normalizers. In conditional
normalization, only simple conditions are allowed: they verify that a single field of the initial event has the
specified value. For example, whether the Event.System.EventID field has the value 4608 or the
ED
DeviceEventClassID field has the value GNRL_EV_VIRUS_FOUND_AND_BLOCKED (in KSC events).

Complex conditions available in filters and correlation rules are not supported here. You cannot compare
values of different events’ fields either.
PI
It is important that a condition checks the value of an initial event’s field using the name of this field in the
initial event.
CO
Extra normalizers applied when a condition is met have the same settings as the primary (parent)
normalizer. They also have a kind that determines the format of incoming data and a table that maps
fields of the initial and normalized event.
Note that additional normalizers are implicit resources. This means that they are not listed as entities
among other resources. They are only accessible through the properties of the primary (parent)
BE
normalizer. You cannot use an existing named normalizer set up in the Resources when configuring
conditional normalization.
TO
T
NO
66
D
TE
BU
RI
ST
DI
RE
Each normalizer has one more section of settings where you can configure enrichment without sending
OR
requests to external systems. For example, dictionary enrichment. If an event contains only a numeric
code, the normalizer can add the respective description from the dictionary to the event. We will describe
these settings and dictionary settings later in our course.
ED
PI
CO
BE
TO
T
Let’s consider an example of creating and debugging normalizers.

NO
67
D
When you create a normalizer, it is convenient to have an example of the original event at hand. You can
TE
copy it to the Event examples field and monitor on the fly how the fields of the original event will be
written to the fields of the normalized event.
We have an event from Blue Coat ProxySG in our example; you can see that it has the key:value format.
BU
The delimiter between values is “=”, and the delimiter between pairs is “|”.
However, if you select the parsing method kv (key:value), you will see the “Normalization error” message
below the Event examples field. The problem is that the event beginning “Bluecoat|” looks abnormal to
our normalizer.
RI
What can you do in this case? You can change the parsing method to regexp, use a regular expression to
cut out everything that goes after “Bluecoat|” and write to the msg field in the following format:
ST
(?P<msg>.*). This is highlighted in blue on the screenshot.
Then create an additional normalizer and pass the value of the msg field without any conditions to its
input.
DI
RE
OR
ED
PI
CO
Let's see what happens in the additional normalizer. The normalizer receives a fragment of the original
event that we saved into the msg field, without “Bluecoat|”.
BE
Now, you can safely use the kv (key:value) parsing method with the “|” (pipe) delimiter between pairs and
the “=” delimiter between values.
After that, map the source fields to the corresponding fields of KUMA. The Examples column will instantly
TO
show values from the event, i.e. you can immediately see whether the mapping is written correctly.
Since we know that this normalizer is designed for Blue Coat ProxySG events, we can enrich the
DeviceVendor and DeviceProduct fields with the BlueCoat and Proxy constants, respectively.
T
NO
68
D
3.3 Collector: event processing
TE
After an event has been normalized to CEF format, there are several more stages that it must undergo in
the collector: filtering, aggregation and enrichment
BU
Filtering
RI
ST
DI
RE
OR
ED
PI
After normalization, a collector filters events. This stage has several objectives:
— Discard events that do not contain any security-related information
CO
— Save resources in further processing steps: enrichment, correlation and storage

— Reduce the stream of events at the output of the collectors that determines the license cost
Filtering, unlike normalization, is optional. A collector does not have any filters by default.
BE
TO
T
NO
69
D
TE
BU
RI
ST
DI
RE
OR
Filters are resources. You can create them in Resources | Filters and then select ready filters in the
collector settings. You can also configure a new filter right from the collector configuration. However, such
filters will be built into the collector and will not be displayed among other resources.
Inside, a filter is a composite condition that consists of simple conditions combined by logical operators
AND, OR and NOT. You can group conditions to manage the operator precedence.
ED
Every simple condition consists of a comparison operator and values to compare (left operand and right
operand). You can choose some event field, constant or data from a dictionary for left and right operand;
some operators may need some special data. For example, the inSubnet operator implies that the left
PI
operand is an event field containing an IP address, and the right operand is a constant whose value is a
subnet with a mask.
CO
For a complete list of possible comparison operations and settings, please refer to the online help at
Some of the supported comparison operations do not make much sense in the filters intended for a
collector. It is important to understand what information the collector possesses during the filtering phase
and what information is not yet available. For example, active lists can only be used in correlators, not in
BE
collectors; therefore, conditions that check if event attributes match the active list will not work. The
inCategory, inActiveDirectoryGroup and TIDetect conditions will not work either, because these fields are
added to an event during the enrichment stage that follows filtering.
TO
T
NO
70
D
Aggregation
TE
BU
RI
ST
DI
RE
OR
Aggregation is the next event processing step after filtering in a collector. Aggregation allows you to
replace a group of related events with a single event that characterizes the entire group. Aggregation is
often applied to events from network equipment (for example, NetFlow). Instead of treating each
ED
connection as a separate event, a collector can combine all connections with the same addresses and
ports over the specified period of time into a single event.
Base events that have been aggregated do not go any further. The aggregated event is forwarded
PI
instead.
Aggregation simplifies analysis and reduces resource consumption and EPS at the collectors’ output,
CO
which reduces the license cost.

BE
TO
T
NO
71
D
TE
BU
RI
ST
DI
RE
Aggregation is configured as rules, which are another kind of resources. You can configure aggregation
OR
rules in the resources and then use them in the collector settings. Alternatively, you can configure inline
aggregation rules right in the collector settings.
An aggregation rule has several key parameters:

— Identical fields — lists fields of (normalized) events whose values must coincide. For example,
ED
for network events, this can be SourceAddress, DestinationAddress, DestinationPort. In the

resulting aggregate event, these fields will be populated with the values of the base events
— Unique fields — lists the fields whose values must be preserved in the aggregate event. For
example, if you specify the DestinationPort field in Unique fields rather than in Identical fields, the
PI
aggregate event will combine base events with connections to different ports, and the
DestinationPort field of the aggregate event will list all ports to which connections were
established
CO
— Sum fields — values of these fields from base events will be summed up and written into the
respective fields of the aggregated event (each field will be summed up separately)
— Triggered rule lifetime — time limit. When the specified period is over, accumulation of base
event stops, the collector creates the respective aggregated event and starts collecting events
for the next aggregated event
BE
— Threshold — a limit on the number of events. As soon as the specified number of events with
identical fields have been accumulated, the collector creates an aggregated event and begins
collecting events for the next aggregated event
An aggregated event is created when either the time threshold or the event number threshold is reached,
TO
whichever occurs first.
You can add a filter to an aggregation rule (similarly to an enrichment rule) to apply it only to events that
meet the specified conditions rather than to all events.
T
NO
72
D
Enrichment
TE
BU
RI
ST
DI
RE
OR
After aggregation and before the events are output, they get enriched based on rules. Although
normalizer also contains enrichment settings, enrichment in the normalizer and enrichment by the rules
have different capabilities. Enrichment rules allow you to configure requests to external systems (DNS,
ED
LDAP, CyberTrace, etc.), while the normalizer can only use information from the event, dictionaries and
constants.
Apart from requests to external systems, enrichment by the rules is the same as enrichment in the
PI
normalizer. This provides analysts with more options to get the required results.
CO
BE
TO
T
NO
73
D
TE
BU
RI
ST
DI
RE
OR
Enrichment rules are resources. Like filters, they can be named (and edited separately from the collector
in Resources | Enrichment rules) or built into the collector (such rules are not displayed among the
resources).
Enrichment rule settings contain the information source and the event field into which data from the
source is recorded. Every source has its own additional parameters. Available sources: constant,
ED
dictionary, table, event, template, dns, cybertrace, timezone, geographic data.
Later in our course, there will be examples of enrichment using DNS, GeoIP, LDAP, CyberTrace and
dictionaries. Enrichment with the Event source allows you to fill in an event field based on the value of an
PI
already filled field (transformations are possible). The Template source allows you to construct a field
value from the values of several other fields. The Go template format is used: {{.EventFieldName}}.
Template example: Attack from {{.SourceAddress}} to {{.DestinationAddress}}.
CO
You can configure enrichment in the normalizer (which is a part of a collector), directly in a collector (in
the form of rules) and in the correlator (also in the form of rules). Enrichment rules are resources.
Enrichment settings configured in the normalizer are not resources and always belong to the normalizer.
A normalizer cannot query external systems; for this reason, not all enrichment sources are available:
BE
— constant — to write a fixed value to the specified field

— dictionary — to write a value from the dictionary into the specified field. A dictionary is a set of
key:value pairs, so you need to specify a key to get the respective value. You can use the value
of an already populated event field for the key. For example, you can use a dictionary to
TO
complement numerical operation code with a description.

— table — a value from the specified table (similar to a dictionary)
— event — to populate the field with a value obtained by converting another field
— template — to populate the field with a combination of constants and values of several other
T
fields
NO
74
D
DNS enrichment
TE
BU
RI
ST
DI
RE
OR
Let us consider an example of enrichment using a DNS query.
The CEF model has special fields for IP addresses and names of devices related to an event. There are
ED
three pairs of such fields:
— DeviceAddress, DeviceHostName — attributes of the device that created the event (for example,
a proxy server)
PI
— SourceAddress, SourceHostName — attributes of the device that performed the action logged in
the event (for example, the device that established a network connection)
— DestinationAddress, DestinationHostName are attributes of the device where the action logged
CO
in the event was directed to
DNS enrichment fills the missing value in each of these pairs based on the available field. For example, if
the DestinationHostName field is populated in an event but DestinationAddress is not filled, a DNS
enrichment rule will send a request with the name and write the IP address from the response to the
BE
DestinationAddress field. If the reply returns several addresses, the first one will be written to the field.
In a similar manner, a rule can populate an address based on the name if the reverse address resolution
request returns a non-empty response. This, of course, depends on the correctness of DNS configuration.
Each address-name pair is enriched independently. If both address and name fields are filled in, DNS
TO
enrichment is not performed.

T
NO
75
D
TE
BU
RI
ST
DI
RE
OR
The fields that DNS enrichment works with are preset and have been listed above. Meaning, you cannot
reconfigure a DNS enrichment rule to change which field to read the name/address from and which field
to write the address/name to.
In a DNS enrichment rule, you can configure:

ED
— DNS servers’ addresses

— Allowed number of requests per second (RPS)
— Number of worker processes
— The maximum number of tasks per process
— Response cashing lifetime
PI
— The Cache disabled option allows you not to use cached responses
A collector can receive thousands or even tens or hundreds of thousands of events per second, and each
CO
DNS query takes time. Disabling the cache will cause delays in event processing and require buffering a
large volume of events waiting for the enrichment result. Therefore, you should only disable DNS cache
for debugging.
You can configure an enrichment rule to be applied only to those events that satisfy specific conditions.
To do so, specify a filter in the rule.
BE
TO
T
NO
76
D
Enrichment with GeoIP data
TE
BU
RI
ST
DI
RE
OR
You can download a GeoIP database, which determines the geographical location by IP address, to
Kaspersky Unified Monitoring and Analysis Platform, and use this data to enrich events.
ED
In Settings | Common, import data from a file to KUMA. The file must be in CSV format.
Kaspersky specialists developed a script that converts MaxMind and IP2Location databases into CSV
format.
PI
There is a link to this script and command descriptions in the online help at
CO
You can import only one file; if you import another one, it will overwrite data in the KUMA database. Data
is exported in the same format, except for IP address ranges. If CIDR range is used (1.0.0.0/24), the
export file will contain the start and end IP addresses (1.0.0.0 — 1.0.0.255).
BE
TO
T
NO
77
D
TE
BU
RI
ST
DI
RE
OR
After the GeoIP database is loaded to the Kaspersky Unified Monitoring and Analysis Platform, you can
configure enrichment rules. The source type is geographic data. Each IP address can have 5 attributes in
the database:
— Country
— Region
ED
— City
— Latitude
— Longitude
The rule specifies from which field of the normalized event to extract the IP address and into which KUMA
PI
fields to write geographical data. KUMA has a set of internal fields for these purposes.
CO
BE
TO
T
NO
78
D
Storage spaces and partitions
TE
BU
RI
ST
DI
RE
OR
When the collector outputs events, they are sent to the correlator and storage. The storage properties
specify the retention time for events; by default, ordinary events are stored for 14 days, and audit events
are stored for a year. Some events need to be stored for a long time, while several days are enough for
others.
ED
Kaspersky Unified Monitoring and Analysis Platform allows you to configure different retention time for
different types of events. So-called spaces serve this purpose. A space is a method of grouping events in
the storage by some attribute (filter).
PI
CO
BE
TO
T
NO
79
D
TE
BU
RI
ST
DI
RE
If you open the list of active services and select a Storage service, it will have the button Go to
OR
partitions. Partitions help KUMA ‘understand’ which events to delete when their retention period expires.
Two partitions are created every day: for audit events (KUMA Audit) and for all other types of events
(KUMA Default). If spaces are configured, then a partition will also be created for each space.
You can delete any partition except KUMA Audit manually if necessary: click the three-dot menu to the
ED
left of the partition and select Delete.

PI
CO
BE
TO
T
NO
80
D
TE
BU
RI
ST
DI
RE
OR
ED
PI
CO
BE
TO
T
NO
81
KL 034.2: Kaspersky Unified Monitoring and Analysis Platform 2.0.1 4. Integrations
D
4. Integrations
TE
Integrations allow Kaspersky Unified Monitoring and Analysis Platform to receive additional information
BU
from external systems. Integrations are configured for the core (kuma-core) service, which then shares
information with other services: collectors and correlators.
For example, integrations with Kaspersky Security Center and LDAP provide KUMA with detailed
RI
information about computers connected to Kaspersky Security Center and domain user accounts, which
can be used in filters and correlation rules.
Let's focus on the following integrations now:
ST
— Kaspersky Security Center
— LDAP
— Kaspersky Threat Lookup
— Kaspersky CyberTrace
DI
— Kaspersky Endpoint Detection and Response
The complete list of possible integrations is available in the online help at
RE
4.1 Integration with Kaspersky Security Center

OR
ED
PI
CO
BE
TO
Integration of Kaspersky Unified Monitoring and Analysis Platform with Kaspersky Security Center
pursues the following objectives:
— Fill the KUMA database of assets (computers) with information about managed devices from
Kaspersky Security Center
T
— Implicitly enrich events with links to asset identifiers, if such an asset exists in the KUMA
database
NO
82
D
— Use specially prepared Kaspersky Security Center tasks to manually and automatically respond
TE
to security incidents
For integration, the KUMA core connects to the API port of Kaspersky Security Center server (13299 by
default) and authenticates using an account that has read access to information about devices. Running
BU
tasks requires additional permissions.
RI
ST
DI
RE
OR
ED
Kaspersky Security Center permits using an Active Directory account or an internal Kaspersky Security
Center account. Internal Kaspersky Security Center accounts are considered to be more secure.
Therefore, to prepare for the integration with Kaspersky Security Center, we recommend that you create
PI
a new internal account in Kaspersky Security Center for connections from Kaspersky Unified Monitoring
and Analysis Platform.
CO
To import information about managed devices from Kaspersky Security Center to the KUMA core, the
account needs the Basic functionality permissions in Kaspersky Security Center. To run Kaspersky
Security Center tasks as response, the Basic functionality permissions for Kaspersky Endpoint Security
are required.
You can also use roles instead of permissions; in this case, the Kaspersky Endpoint Security
BE
Administrator role grants all necessary permissions (including read access to information about devices).
TO
T
NO
83
D
TE
BU
RI
ST
DI
RE
OR
On the Kaspersky Unified Monitoring and Analysis Platform side, specify the account attributes in a
Secret resource that has the credentials kind. Secrets are designed to store sensitive information such as
passwords and certificates. The data specified in secrets is stored in an encrypted form and is never sent
to the web console in the clear.
The integration is configured in Settings | Kaspersky Security Center. You can configure connection to
ED
several Kaspersky Security Center servers here. For each server, specify a connection name (any) and
the following:
— URL — the connection address of the Kaspersky Security Center server in the format <name or
IP address>:<API port>
PI
— Secret — a resource of the credentials kind with a user name and password for accessing
Kaspersky Security Center
CO
If you do not use a connection to Kaspersky Security Center anymore, you can disable (the Disabled
checkbox) or delete it.
BE
TO
T
NO
84
D
TE
BU
RI
ST
DI
RE
OR
First of all, integration with Kaspersky Security Center is required to populate the Kaspersky Unified
Monitoring and Analysis Platform asset database.
Assets are computers. They provide specialists who analyze events with additional context. KUMA can
implicitly enrich events with asset identifiers if an event contains the name or address of a computer. An
asset identifier is a link to additional information about the computer, which the specialist who analyzes
ED
events may need to consult.
By default, assets are automatically imported from Kaspersky Security Center every 12 hours; you can
change this schedule if necessary. You can also click the button Import KSC assets to import them on
PI
demand (this will not affect the scheduled import in any way).
Kaspersky Unified Monitoring and Analysis Platform imports all computers with Kaspersky Security
CO
Center Network Agent that has connected to Kaspersky Security Center, i.e. whose Connection time
field is non-empty in the Kaspersky Security Center SQL database.
Along with basic information about the computer that includes its name, address, timestamp of the last
connection to Kaspersky Security Center and other standard attributes, information about hardware and
software is imported, including the operating system version and vulnerabilities. This information is
BE
collected by Kaspersky Security Center Network Agent.

TO
T
NO
85
D
TE
BU
RI
ST
DI
RE
OR
You can manually add assets that cannot be imported. Note that you will have to manually specify all
computer attributes such as its address, FQDN, operating system name and version and hardware
specifications. You cannot specify information about vulnerabilities when adding assets manually.
ED
PI
CO
BE
TO
T
NO
86
D
You can group assets into categories. An installation contains examples of asset categories. You can
TE
delete them or add new categories that better serve your purposes. Categories form a hierarchy. Each
category has one of the following criticality levels:
— Low
— Medium
BU
— High
— Critical
You can add a computer to several categories. Initially, all assets get into the Uncategorized assets
RI
category.
You can use asset categories in conditions within filters or correlation rules. For example, you can create
alerts of higher severity for critical assets.
ST
DI
RE
OR
ED
PI
CO
You can manage the structure of assets using the category shortcut menu.
For example, you can pin an important category as a separate tab to be able to quickly access its
contents. You can also recursively display assets of child categories, create subcategories and change
BE
the properties of the current one, for example, the level of importance and the filling method.
You can delete a category only if it is empty, i.e. no asset is associated with it.
TO
T
NO
87
D
TE
BU
RI
ST
DI
RE
Categories can be filled in three ways:
— Manually
— Active — dynamically, if assets meet specific conditions. For example, have a specific version of
the operating system or are located in a specific subnet
OR
— Reactive — using correlation rules, i.e. when a correlation rule is triggered, the asset will be
moved to the specified group
ED
PI
CO
BE
TO
T
If the Active category filling method is used, you can use several conditions for grouping:
— Build number
NO
— OS
88
D
— IP address
TE
— FQDN
— CVE
The conditions are set in the following format: left operand (one of the abovementioned conditions),
BU
operator (greater than, less than, equals to, ilike, inSubnet, etc.) and the value to compare.
You can combine conditions with logical operators AND, OR and NOT.
After you have set up a condition, test it. The Test conditions button displays the list of devices that
RI
match the specified condition. This is especially useful when configuring complex conditions.
You can also set up the categorization period here, meaning, how often conditions will be checked for the
ST
entire list of assets. Periods from 1 to 24 hours are available.
DI
RE
OR
ED
PI
CO
Collectors use the database of assets to implicitly enrich events with asset identifiers. This enrichment
enables analysts to consult information about computers when analyzing events. All information about the
asset is stored separately from the event in the MongoDB database managed by the KUMA core service.
Only internal fields are added to an event:
BE
— DeviceAssetID
— SourceAccountID
— DestinationAssetID
The collector receives information about assets from the core and fills in the asset identifier field in the
events in the following cases:
TO
— If the corresponding field with the name contains the FQDN of the asset. For example, if the
SourceHostName field contains an FQDN, the collector will add the SourceAssetID field with the
asset identifier to the event. The address specified in the SourceAddress field is of no
importance
T
— If the corresponding address field contains the asset address and the name field is empty. For
example, if the DestinationAddress field contains the address of a known asset and there is no
NO
89
D
name in the DestinationHostName field, the collector will add the DestinationAssetID field with
TE
the asset identifier to the event
If the name field contains a value that does not match any FQDN in the asset database, the collector
does not check the address field and does not supplement the event with the asset identifier. This
BU
situation may arise either when the *HostName field contains an FQDN, but it does not match any asset,
or when the *HostName field contains a computer name rather than its FQDN.
RI
ST
DI
RE
OR
ED
To keep track of various actions with assets in Kaspersky Unified Monitoring and Analysis Platform,
configure asset audit events.
PI
In the side menu: Settings | Asset audit.

CO
The following types of audit events are available (destinations are configured separately for each of
them):
— Asset added to KUMA
— Asset parameters changed
— Asset deleted from KUMA
BE
— Asset added to category

— Asset removed from category
— Vulnerability info added to asset
— Asset vulnerability resolved
Storage and Correlator (for events that need to be correlated) services usually act as the destination.
TO
Asset audit events pertain to the Base type, not Audit. Remember this when querying events.
Alternatively, you can pass the following values as a search condition:
— DeviceCategory = 'Audit assets'
or
T
— DeviceAction like 'assets%'

NO
90
D
4.2 LDAP integration
TE
BU
RI
ST
DI
RE
Just as integration with Kaspersky Security Center allows you to fill the database of assets, integration
with LDAP fills the database of user accounts. Information about users adds context to event analysis,
similarly to information about assets. The user identifier field provides a link to detailed information about
the user, such as when the account was created, groups that include it and when the user last logged on
to the system.
OR
Unlike assets that you can see and edit in the web interface, accounts are not displayed in the interface
and cannot be added manually.
You can use inActiveDirectoryGroup conditions in filters and correlation rules for events that contain the
ED
account identifier field.

PI
CO
BE
TO
T
NO
91
D
LDAP integration, like other integrations, is configured in Settings | LDAP server integration.
TE
You can configure connection to several different servers. For each server, you need to specify the
following:
— Secret — a resource of credentials kind with the user name and password for authentication on
BU
the LDAP server. The user must have permissions to read information about users and groups in
LDAP. In Active Directory, any domain user has these permissions by default
— URL — server address and port, 389 for LDAP and 636 for LDAPS by default
RI
— Base DN is the root node of the LDAP tree to search
Among other parameters, you can encrypt connections; to do so, create a Secret (of certificate kind) and
specify there the certificate to be used for encryption.
ST
To be able to use LDAP queries in enrichment rules, create an LDAP connection resource. Configure it
as follows:
DI
RE
OR
ED
PI
CO
Event enrichment with the account ID can be configured in the collector only, because a LDAP
BE
enrichment rule differs from other enrichment rules. In the Event enrichment section, there is a
dedicated button Add enrichment with LDAP data.
The settings are as follows:
— LDAP accounts mapping — name of the domain whose information the collector will use. It is
TO
especially important that the domain name is written correctly here

— LDAP enrichment mapping — configure the mapping rules: which values of event fields to take,
which account attributes to compare with, and which field to populate with the link to the account
The collector checks values of the *UserName and *UserID fields and maps them to account information.
T
If a match is found, the collector adds the SourceAccountID or DestinationAccountID field with the
corresponding identifier to the event.
NO
92
D
TE
BU
RI
ST
DI
RE
OR
By default, assets are automatically imported from Kaspersky Security Center every 12 hours; you can
change this schedule if necessary. You can also click the button Import KSC assets to import them on
demand (this will not affect the scheduled import in any way).
You can see imported information via the event interface. This is only possible if the collector enriches
events with the SourceAccountID or DestinationAccountID field. When you view an event, this field
ED
provides a link that opens the account information pane.

PI
CO
BE
TO
T
NO
93
D
Let's walk through an example that will require us to use several different enrichment options and LDAP
TE
integration.
The analyst would like to see information about the users from Active Directory in Kaspersky Security
Center events. This does not work out of the box because Kaspersky Security Center specifies user
BU
names in the <Domain Name>\\<Username> format in the DestinationUserName field. Meanwhile, Active
Directory account attributes do not use this format for usernames.
The analyst needs to configure enrichment tools to add the DestinationUserID field with the objectSid
value to Kaspersky Security Center events. The collector will map this field to an imported account and
RI
implicitly enrich the event with the DestinationAccountID field.
ST
DI
RE
OR
ED
PI
To begin with, we need to split the value of the DestinationUserName field into the domain name and
CO
user name.
Let’s use regular expressions to cut out the left part and supplement “ABC” with “.LAB” so that the domain
name matches the LDAP data. Write the result to the DestinationNtDomain field.
In a similar manner, we ’ll use regular expressions to out the right part and convert the value into
BE
lowercase. The result should replace the original field, DestinationUserName.

TO
T
NO
94
D
TE
BU
RI
ST
DI
RE
OR
Next, we need to add the user's SID to the DestinationUserID field of the event. You can do this in the
following way (this solution is maybe not the most elegant, but it is quite efficient):
— Export user names and SIDs to a CSV file
— Import the username-SID pairs from the file into a dictionary
ED
— Use dictionary enrichment in the normalizer, because the normalization stage precedes requests
to external systems, and we will have a field with the user's SID before LDAP enrichment
A dictionary is a Kaspersky Unified Monitoring and Analysis Platform resource that stores key:value pairs.
Dictionaries are designed to enrich events with static information. For example, add an operation
PI
description based on its available code. Or supplement a user name with the respective SID.
A dictionary as a resource has very simple settings:

CO
— Name
— A list of key:value pairs
You can compose a dictionary manually or import from a CSV (comma-separated values) file. When
importing, Kaspersky Unified Monitoring and Analysis automatically recognizes the delimiter.
BE
TO
T
NO
95
D
TE
BU
RI
ST
DI
RE
OR
Now that the dictionary is ready, we need to configure the normalizer to use it. Dictionaries are stored in
the core service database. Collectors receive dictionaries that are listed in their properties with the
settings.
To enrich events with the user’s SID, you need to add another enrichment element with the following
settings to the normalizer:
ED
— Source kind — dictionary

— Dictionary — name of the dictionary into which we have imported user names and SIDs from
Active Directory
PI
— Key fields — the field whose value you want to use as a key to search the dictionary for. In this
example, it is the username from the DestinationUserName field (abbreviated and lowercase)
— Target field — the field where you want to write the value from the dictionary that corresponds to
CO
the specified key. In this case, it is DestinationUserID
For the collector to receive the dictionary and start using the new settings, make it reload the settings:
click the respective command on the three dot menu of its service on the service management page.
BE
TO
T
NO
96
D
TE
BU
RI
ST
DI
RE
OR
Now, if we look at the normalized Kaspersky Security Center events, we will see that:
— The DestinationUserName field contains a simple username in lowercase letters
— The DestinationNtDomain field contains the domain name in all capital letters
— The DestinationUserID field contains the user’s SID
ED
— The DestinationAccountID field contains the user identifier from the Kaspersky Unified
Monitoring and Analysis Platform database that opens a card with information about the user
imported from Active Directory
PI
The first three changes result from the enrichment that we configured in the normalizer. The last change
is the result of LDAP enrichment based on the value of the DestinationUserID field.
CO
BE
TO
T
NO
97
D
4.3 Kaspersky Threat Lookup
TE
BU
RI
ST
DI
RE
OR
Kaspersky Threat Lookup is a subscription service. The customer’s analysts can search extensive
Kaspersky Threat Lookup cyberintelligence database for information about files (by hash) and web
ED
resources (by IP or URL). A response to the request includes detailed data about the object, for example,
its geographical distribution, reliability, known attacks related to it (if any), etc.
Typically, the customers’ analysts use the Kaspersky Threat Intelligence Portal web interface for queries.
PI
Kaspersky Unified Monitoring and Analysis Platform enables them to configure integration with Kaspersky
Threat Lookup through special APIs and search for information about files and web resources without
leaving the KUMA web console, right from the event.
CO
A subscription to Kaspersky Threat Lookup is not included with Kaspersky Unified Monitoring and
Analysis Platform licenses. Customers must purchase a Kaspersky Threat Lookup subscription if they
want to integrate it into KUMA.
BE
TO
T
NO
98
D
TE
BU
RI
ST
DI
RE
OR
Integration with Kaspersky Threat Lookup (KTL) is configured in Kaspersky Unified Monitoring and
Analysis Platform web console on the Settings | Kaspersky Threat Lookup page and contains only two
options:
— The secret with credentials for authentication in Kaspersky Threat Intelligence Portal (a required
parameter)
ED
— A proxy server address — specify it if the customer uses a proxy server for connecting to the
internet (an optional parameter)
The address where to send KTL requests is not specified anywhere. It is permanent and coincides with
PI
the address of the web version of Kaspersky Threat Intelligence Portal, https://tip.kaspersky.com
Querying Kaspersky Threat Lookup requires the same credentials as authentication in Kaspersky Threat
CO
Intelligence Portal web console:

— Username
— Password
— Certificate
— Certificate password
BE
Specify all these parameters in a Secret resource of the ktl kind. A certificate for accessing Kaspersky TIP
is supplied in *.pfx format with a password, and you must also specify this password in the secret.
Kaspersky Threat Intelligence Portal users have different access permissions:

— Web only — can use only the web version of Kaspersky TIP
TO
— API only — can only send queries through the Kaspersky TIP API
— Full — can use the web portal and API equally
In the KUMA settings, you must specify a user with API or FULL access.
T
NO
99
D
TE
BU
RI
ST
DI
RE
OR
After you configure integration with Kaspersky Threat Lookup, new capabilities become available in the
event interface. KUMA automatically recognizes lines that contain file hashes, IP addresses and URLs
and turns them into links. Clicking on this link opens either information from the KTL about the
corresponding indicator or, if this indicator has not been previously queried, a pane with the KTL search
settings.
ED
In the search settings, you can select specific information categories. Data categories are different for
different indicator types (hash, IP, URL). Information about the (Trust) Zone is available for all indicators.
Green means that you can trust the object. Red corresponds to dangerous objects. There can be many
entries in a group. For example, the ‘File downloaded from URLs’ group that lists addresses from which
PI
the file with the requested hash has been downloaded may contain multiple entries. You can limit the
number of records in the response.
To query a new attribute, click the Request button. As a result, Kaspersky Unified Monitoring and
CO
Analysis Platform creates and immediately launches a Kaspersky Threat Lookup query task. When the
task completes, clicking on the indicator will open a pane with information about the object from the KTL
instead of the query setup pane.
BE
TO
T
NO
100
D
TE
BU
RI
ST
DI
RE
OR
You can monitor the tasks’ progress in the Task manager. You can only consult the result and restart the
task. If a task fails, hover the mouse over the task status bar to see a brief description of the error. You
cannot see or change any task parameters here.
Responses to KTL requests are saved to a dedicated cache, which then helps display additional
information about objects in events. When you click on a hash or address in an event, KUMA checks if
ED
the cache contains information about that object and if yes, displays it in a special side pane. There is the
date and time when the information was received at the bottom of the card, and if you believe that the
information is outdated, click the Update button to re-send the request.
PI
Information from KTL is not added to events and therefore cannot be used in filters and correlation
conditions. It is only available for context analysis.
CO
BE
TO
T
NO
101
D
4.4 Kaspersky CyberTrace
TE
BU
RI
ST
DI
RE
OR
Kaspersky CyberTrace is a platform for managing cyberintelligence data. Kaspersky CyberTrace loads
indicators of compromise from a variety of sources and helps SIEM systems find indicators in the events
being processed.
ED
Kaspersky Unified Monitoring and Analysis Platform can interact with CyberTrace in two modes:
— In continuous integration mode, similarly to another SIEM system, i.e. redirect the event stream
to Kaspersky CyberTrace and receive alerts about matches in response
PI
— Requests through enrichment rules
Requests are more useful in this case. They help Kaspersky Unified Monitoring and Analysis Platform
CO
find out that some objects in an event are indicators of compromise. In filters and correlation rules, you
can apply TIDetect conditions to events enriched with such requests. That is, you can eventually receive
alerts about events that contain indicators of compromise. Only Kaspersky CyberTrace enrichment rules
are necessary for this.
Integration with Kaspersky CyberTrace provides two capabilities:

BE
— Build Kaspersky CyberTrace interface into the KUMA interface, which allows analysts to manage
KUMA and Kaspersky CyberTrace as a single system
— Enriching events with CyberTrace data
— Register URL, IP or hash values from events as indicators of compromise in Kaspersky
TO
CyberTrace (such indicators are added to the Internal TI feed in Kaspersky CyberTrace) to be
able to detect these indicators in new events later
Port 9999 is used for enrichment rules in CyberTrace (you can change it in the CyberTrace settings). Port
443 on the CyberTrace side is used for filling Internal TI and interactions with the CyberTrace interface.
T
The KUMA core acts as a proxy when you work with the Kaspersky CyberTrace interface built into the
NO
Kaspersky Unified Monitoring and Analysis Platform interface. The nested interface is available on TCP
102
D
port 7222 (while the regular KUMA web interface port is TCP 7220). You cannot change this in the KUMA
TE
interface, because it is specified in the core service startup options on the Linux server.
BU
RI
ST
DI
RE
OR
Integration with Kaspersky CyberTrace is configured in Kaspersky Unified Monitoring and Analysis
Platform web console on the Settings | Kaspersky CyberTrace page and contains the following options:
— Host — address of the server where the primary Kaspersky CyberTrace service is running
— Port — the port of the CyberTrace web interface (and API port), 443 by default
ED
— Secret — a resource of credentials kind with the user name and password for authentication in
CyberTrace. Permissions of this user in CyberTrace will determine the appearance of the
CyberTrace subinterface in KUMA.
Integration with Kaspersky CyberTrace at the web interface and API levels requires that Multi-user mode
PI
is enabled in Kaspersky CyberTrace. This functionality is available with any commercial CyberTrace
license, but is not available with a free license.
CO
If Multi-user mode is not activated, the attempt to configure CyberTrace integration on the KUMA side will
fail. To make sure multi-user mode has been activated, consult Settings | Licensing on the Kaspersky
CyberTrace side.
BE
TO
T
NO
103
D
TE
BU
RI
ST
DI
RE
OR
If you integrate the products successfully, a new Kaspersky CyberTrace section will appear in the KUMA
interface, which will show the full Kaspersky CyberTrace interface with all its capabilities.
When you work with the nested CyberTrace interface, web browser’s requests are forwarded to a special
port 7222/tcp on the KUMA core, and the core component proxies all requests to the original address of
CyberTrace web interface (by default, port 443/tcp of the CyberTrace server).
ED
PI
CO
BE
TO
T
NO
104
D
Event enrichment from CyberTrace works as follows. The analyst sets up an enrichment rule in the
TE
collector and specifies which of the event fields to compare with indicators of compromise in CyberTrace
along with the indicators’ type: Hash, IP or URL.
The collector sends a request to CyberTrace, CyberTrace compares the transmitted attributes with
BU
indicators, and in case of a match, sends the indicator details to KUMA. When the collector receives a
non-empty response, it adds two fields to the event: TI indicator with the value of the matched indicator
and Indicator category with name of the data feed where the indicator was found. You can use these
parameters in filters and correlation rules.
RI
In the event interface, the Indicator category field expands and shows various attributes of the indicator
of compromise: where and when it was detected, what other indicators it is related to, and so on
ST
There is the TI field in the KUMA data model. This is an internal KUMA field that combines a TI indicator
and Indicator category; use the TI field when searching for events in the storage, in filter conditions and
correlation rules.
DI
RE
OR
ED
PI
CO
A Kaspersky CyberTrace enrichment rule has the following settings in KUMA:

— Source kind — cybertrace
BE
— URL — CyberTrace listen address. The default port is 9999. Optionally, you can limit the number
of connections and requests per second in the connection
— Mapping between the event fields and types of indicators to compare. Select a KUMA event field
on the left (for example, FileHash) and the respective indicator type on the right (in this case,
TO
hash; for other fields, it can be URL or IP). You can configure comparison of multiple event fields
with different types of indicators within a single rule
Optionally, you can specify a timeout and a filter if you want to save resources.
When collector processes an event, it generates a separate event to be sent to CyberTrace. For the
T
mapping shown on the screenshot, the event format will be as follows:

Id=<value of the ID field> | ip=<destinationAddress field value> |
NO
105
D
hash=<value of the DeviceCustomString4 field> | url=<value of the FilePath
TE
field> | hash=<value of the FileHash field> |
BU
RI
ST
DI
RE
OR
You can find the connection address (which is specified in the enrichment rule in the URL field, see the
previous screenshot) in the CyberTrace settings in the Settings | Service | Connection settings section.
ED
Port 9999/tcp is used by default.
Kaspersky CyberTrace supports multitenancy mode, which permits you to configure a dedicated port for
requests of each CyberTrace and KUMA client. For this purpose, create a new tenant for KUMA in
Settings | Tenants, specify the port where Kaspersky CyberTrace accepts requests and set the same
PI
port in the connection on the Kaspersky Unified Monitoring and Analysis Platform side.
CO
BE
TO
T
NO
106
D
TE
BU
RI
ST
DI
RE
OR
When you install Kaspersky CyberTrace, the initial setup wizard starts, which prompts you to select your
SIEM system type. Kaspersky CyberTrace uses different regular expressions to parse events received
from different SIEM systems.
If KUMA is selected in the wizard, CyberTrace will expect events of a strictly defined format; mismatching
events will be discarded.
ED
If another SIEM system is chosen, then most likely standard regular expressions will be used to extract
hashes, IP addresses and URLs. In this case, if you want to set up additional integration with KUMA, you
can create a separate tenant in CyberTrace, which will await events in KUMA format.
PI
If an indicator is detected, in addition to enriching the KUMA event, this indicator will be displayed in
Kaspersky CyberTrace in the Detections section. The respective source event that CyberTrace received
CO
from KUMA will also be shown there.

BE
TO
T
NO
107
D
TE
BU
RI
ST
DI
RE
OR
In addition to the nested web interface, integration with Kaspersky CyberTrace permits sending indicators
from KUMA events to the InternalTI data feed in CyberTrace.
The scenario is as follows:

— When investigating an incident, the analyst decides that some of the KUMA events are related to
ED
the incident and contain characteristic indicators of compromise: file hashes, IP or URLs of
dangerous servers
— The analyst clicks the indicator in the KUMA event and selects the command Add to InternalTI
of CyberTrace
PI
— KUMA sends the selected value to CyberTrace, where it is added to the InternalTI data feed (a
special list of indicators of compromise in CyberTrace that is filled manually)
—
CO
If CyberTrace enrichment and the corresponding correlation rules are configured, KUMA will
generate alerts for new events that contain the published indicators
KUMA automatically recognizes hashes, IP addresses and URLs in events using built-in (non-
configurable) regular expressions. After you configure integration with CyberTrace, all hashes, IP and
URLs in any fields of KUMA events (even if they constitute only a part of the field value) become links that
BE
open a menu with the command to send the indicator to CyberTrace.
On the CyberTrace side, you can find the transmitted indicators in the Indicators section. Filter the table:
select InternalTI in the Suppliers column. Attributes of such an indicator will include a link to the initial
event in Kaspersky Unified Monitoring and Analysis, from which the analyst sent the indicator to
CyberTrace.
TO
T
NO
108
D
4.5 Kaspersky Endpoint Detection and Response
TE
BU
RI
ST
DI
RE
OR
Integration of Kaspersky Unified Monitoring and Analysis Platform with Kaspersky Endpoint Detection and
Response allows you to perform response tasks on assets using Kaspersky Endpoint Agent.
ED
It is assumed that the Kaspersky Endpoint Detection and Response solution has already been deployed
on the customer's network. Detailed information about this is provided in course KL 025: Kaspersky Anti
Targeted Attack. Kaspersky Endpoint Detection and Response.
PI
During the integration, the KUMA core connects to the Central Node server and registers as an external
system for API requests. Integration is only possible with a Kaspersky Symphony XDR license.
CO
The integration is configured in Settings | Kaspersky Endpoint Detection and Response.
On the Kaspersky Unified Monitoring and Analysis Platform side, specify the Central Node connection
address and port, as well as the certificate that will be used for secure connections. You need to create a
Secret resource of kata/edr kind for this purpose. There is the Download icon in such a resource; click it
to generate an archive with a certificate and a private key. Unpack this archive and add the contents to
BE
the same secret.

TO
T
NO
109
D
TE
BU
RI
ST
DI
RE
OR
When you save the connection, Kaspersky Unified Monitoring and Analysis Platform sends an API
request to the Central Node to register as an external system. The Centra Node administrator must
authorize the KUMA core service.
KUMA sends a request to the kaspersky/kata/response_api docker container on the Central Node. If this
container is not running for some reason, an error will be displayed in the integration window when you
ED
click the Save button.

PI
CO
BE
TO
T
NO
110
D
Upon successful integration with Kaspersky Endpoint Detection and Response, a new KEDR response
TE
button appears in the properties of assets where Kaspersky Endpoint Agent is installed.
The following types of response are possible:

— Enable network isolation — Kaspersky Endpoint Agent uses the Windows packet filter to isolate
BU
the computer from the network. Network isolation blocks all incoming and outgoing packets and
connections except for those for which exclusions are specified
— Disable network isolation — revoke network isolation on the selected asset
RI
— Add prevention rule — create a rule to block the file by checksum (MD5 or SHA256), on all
computers or on the current one
— Delete prevention rule
ST
— Run program — remote execution of a command or start of a program on a computer. To
execute a command, specify:
— The executable file to run on the computer. The file must be located on the target machine.
The task does not permit selecting a file on your computer, copying it to the target computer
DI
and running it there
— Command line parameters (optional)
— Working folder where the command will be executed (optional)
RE
OR
ED
PI
CO
BE
TO
T
NO
111
KL 034.2: Kaspersky Unified Monitoring and Analysis Platform 2.0.1 5. Correlation and work with events
D
5. Correlation and work with events
TE
BU
5.1 Work with events
In this section, we will study the tools that you can use in Kaspersky Unified Monitoring and Analysis
RI
Platform to work with events that have already been saved into the storage.
ST
DI
RE
OR
ED
PI
A collector outputs normalized base or aggregated events and sends them to the correlator and storage.
Correlation events output by a correlator and audit events generated by the core service (kuma-core) are
CO
also saved into the storage. An analyst can find any events in the storage and analyze them on the
respective page of the web console.
The Events page contains the following tools:

— SQL query to search the database for events
BE
— Lollipop chart that displays distribution of the detected events over time
— Table with found events; you can customize its columns. You can select to display any set of
event fields in the table. Since the storage contains normalized events, the list of possible fields
is limited to the KUMA data model (CEF and internal KUMA fields)
TO
Above the search bar, there are additional settings:

— How often to refresh the results (re-run the search)
— Over which period to search (you can specify an arbitrary interval). The same period is visualized
on the chart
T
— Name of the storage to query

NO
You can save the parameters for future reuse.
112
D
You can export the displayed events to TSV (tab separated value) format.
TE
BU
RI
ST
DI
RE
OR
To see the full contents of an event, select it in the table. Details are displayed in the side pane. An event
may contain links to additional context:
— Descriptions of related assets
ED
— Attributes of related accounts

— Details concerning indicators of compromise obtained from Kaspersky CyberTrace or Kaspersky
Threat Lookup
PI
CO
BE
TO
T
NO
113
D
The histogram shows the distribution of the found events over time and their number within each interval.
TE
You can interactively select an interval on the timeline with the mouse and the button Show events will
appear. When you click it, the web console will automatically narrow down the interval and display the
respective events.
BU
RI
ST
DI
RE
OR
ED
Sometimes, for troubleshooting or analysis, you need to limit the search to events of a particular collector.
Each event has an internal ServiceID field that contains the identifier of the KUMA service that created
the event. Since base events are created by a collector, their ServiceID contains the collector’s identifier.
This field allows you to find all events output by a collector.
PI
The Kaspersky Unified Monitoring and Analysis Platform web interface provides a convenient way to get
a list of events of a particular service (collector or correlator) in a couple of clicks instead of manually
setting up such a query. To do so, select the service in the list of services (Resources | Active services)
CO
and click Go to events. This action opens a new browser tab with the Events section where the search
by the ServiceID of the corresponding service is already configured. The analyst only needs to run the
query or enable automatic refreshment for the results.
BE
TO
T
NO
114
D
TE
BU
RI
ST
DI
RE
An event search query is an SQL query that the core sends to the ClickHouse storage. ClickHouse
OR
supports distributed query processing on all cluster nodes concurrently (if the storage is a multi-shard
cluster) and returns search results to the core that displays them in the web interface.
To fine-tune the query, you do not have to know SQL syntax (although this knowledge would be very
useful). The KUMA web interface provides graphical tools for creating and modifying SQL queries. In
particular, you can click on any field value in the table of found events and add that value to the search
ED
query as an additional condition or exception.

PI
CO
BE
TO
T
NO
115
D
The pane with detailed description of an event provides the same capability. Instead of clicking on the
TE
value, hover the mouse over the field until the ‘plus’ and ‘minus’ buttons appear. The ‘plus’ button adds
the field value as a condition to the query. The ‘minus’ button adds the selected value as an exception.
BU
RI
ST
DI
RE
OR
Click the icon to the left of the search bar to open SQL builder, where you can edit the query in GUI.
ED
In a query, you can specify:

— SELECT — which fields to extract from the database (all by default)
— WHERE — conditions that the events must meet (in the
PI
<event field> <operator> <value> format). Available operators depend on the type of
data that the selected field contains
— ORDER BY — by which field(s) to sort the results (by default, not to sort, which in reality means
CO
sorting by time when the event was added to the database)

— LIMIT — how many events to search for (250 by default)
All these parameters are standard SQL query directives; search capabilities are limited to SQL query
syntax. In particular, the wildcard character for an arbitrary substring is % rather than *.
BE
Previously saved search parameters are available in the extended query configuration interface: click the
Saved searches button. Users with the Analyst role can see only their own saved queries. The
administrator can see saved searches of all users and can delete them.
TO
T
NO
116
D
TE
BU
RI
ST
DI
RE
OR
You can display statistics on the event search page. Statistics show the distribution of values for each
field within the found events. An analyst can use statistics to quickly filter out the most numerous events
and focus on rare events.
Statistics are displayed in a side pane. To open the statistics pane, click the three dots in the upper right
corner and select the respective command in the menu. This menu also contains commands for
ED
retrospective scanning and exporting the found events into a text file in the TSV format (tab-separated
values). As far as retrospective scanning is concerned, we will study it later.
PI
5.2 Correlation
CO
The next large topic is correlation. In this section, we’ll study how to find useful information that may
indicate cybersecurity incidents in the data that flows into the correlator. Let's look at various tools that
Kaspersky Unified Monitoring and Analysis Platform uses to detect correlations.
BE
TO
T
NO
117
D
TE
BU
RI
ST
DI
Correlation rules are another kind of Kaspersky Unified Monitoring and Analysis Platform resources. They
RE
are used in the settings of the correlator service, but you can create and modify them independently as
other resources. An all-in-one installation of Kaspersky Unified Monitoring and Analysis Platform includes
a few sample correlation rules. When you conduct pilot projects, a set of about a hundred correlation
rules and a description document are also provided. Importing rules into KUMA takes a few seconds.
There are three types of correlation rules in Kaspersky Unified Monitoring and Analysis Platform:
OR
— Simple correlation rules analyze each event individually and are applied if an event meets the
specified conditions. For example, a simple rule can be applied when an event about a detected
network attack comes from Kaspersky Security Center
— Standard correlation rules analyze combinations of events and can respond to accumulation of
ED
specific events or to events that arrive in a particular order. Also, standard rules can compare
events. Examples of standard rules:
— Kaspersky Security Center sent 10 network attack events in 1 minute
— 30 failed brute-force attempts followed by a successful logon (a successful password attack)
PI
— Kaspersky Security Center sent a threat detection event and then there were no threat
neutralization events within an hour (an unprocessed threat)
CO
— Operational correlation rules are similar to simple rules, but they fill so-called active lists with
values from events instead of creating correlation events. For example, you can make an
operational rule that will fill the active list with all dangerous links intercepted in the mail. And
then you can create a simple rule that will be applied when a computer accesses one of these
addresses. A combination of these rules will detect connection to a dangerous address that has
been sent by email, even if a long time has elapsed between the message arrival and opening
BE
the link
TO
T
NO
118
D
Simple correlation rule
TE
BU
RI
ST
DI
RE
OR
Settings of each rule are grouped into three sections:

— General settings that determine the rule type, its priority (for alerts), propagated fields and event
ED
grouping parameters (we will explain this later)

— Selectors, i.e. conditions for selecting events and applying the rule based on the selected events
— Actions: enrichment for correlation events, active list filling, where to send correlation events and
PI
whether to create alerts if the conditions are met
A simple rule always contains one selector. A simple rule is applied to each event that matches
the specified condition. For example, when groups with high privileges are modified or when you need to
CO
convert a KATA detection into an alert in KUMA.
A simple rule is designed for alerts that should be triggered when even a single event that meets specific
conditions is detected. Therefore, a simple rule contains only one selector that sets conditions for this
rule.
BE
Selector is a filter. Therefore, in the selector settings, you can select a ready preconfigured filter from
among the available resources. Alternatively, you can configure a new inline filter. In the selector settings,
you can use other filters within the nested conditions, similarly to other filters. Meaning, you can create a
complex condition: (event field value equals X) or (conditions of the filter Y are met).
TO
T
NO
119
D
TE
BU
RI
ST
DI
RE
OR
A simple rule is applied every time when an event that matches the selector’s filter arrives. The analyst
can configure a rule to trigger one or more of the following actions:
— Output — create a correlation event that will be sent to the specified destinations (typically, to the
storage) and for which an alert will be generated (or supplemented)
— Loop — forward the correlation event to the input of the same correlator for recursive processing
ED
— Update active lists — add or remove an entry to/from an active list based on the contents of the
event fields
— Enrich the correlation event using a dictionary, initial event data, constant or template, without
PI
requests to external systems (i.e., the same enrichment as in a normalizer in a collector). You
can set up enrichment in the correlator just like in a collector
— Move an asset to a category (or delete from a category). You can only select a category with
CO
Reactive filling
BE
TO
T
NO
120
D
TE
BU
RI
ST
DI
RE
OR
General rule settings include its kind (simple, standard, operational), priority and additional settings that
depend on the rule kind.
Only those rules that create correlation events have priority: simple and standard, but not operational.
Alerts are generated (or supplemented) based on correlation events. The rule priority determines the
priority of the respective alert: Low, Medium, High or Critical. An analyst or administrator can change alert
ED
priority when investigating an incident
In a simple rule, the Propagated fields parameter simply lists which fields of the base event the
correlator will copy to the correlation event when the rule is applied. This parameter is required, and you
PI
must specify at least one field.
For example, if a simple rule is triggered by events about network attacks, it is logical to list the fields with
CO
information that characterize the attack in the Propagated fields: the attacker's address, the victim's
address and the type of attack. The analyst should check which fields of the base events contain this
information and list them as ‘Propagated fields’.
In case of a simple rule, a correlation event will contain a link to the base event, and the analyst can
always find details about the incident even if field copying via ‘Propagated fields’ is not configured.
BE
But if analysts plan to create other rules to be applied not only to base events but also to correlation
events, the fields copied to the correlation event will determine the conditions that the analyst will be able
to use for it.
TO
T
NO
121
D
TE
BU
RI
ST
DI
RE
OR
When such a rule is applied, correlation events will be saved to the storage. You can find them by the
Correlated value of the Type field, or, for example, by the ServiceID of the correlator service.
A correlation event card has the Detailed view button that opens the event’s details, in particular:
— Base events that matched the rule (in case of a simple rule, there is one base event)
ED
— Assets related to the base events

— Users related to the base events
A correlation event is not the same as an alert. We will tell you about alerts after all the correlation rules.
PI
However, the detailed view of a correlation event resembles an alert very much.
CO
BE
TO
T
NO
122
D
Standard correlation rule
TE
BU
RI
ST
DI
RE
OR
Let us remind you that simple correlation rules react only to individual events, and if you want to find
relationships between several events or a sequence of events, you need to use standard correlation
rules.
ED
Let's take a simple example: the analyst believes that a single event of accessing a dangerous URL from
a network computer does not require close attention, but would like to be informed about numerous
connections during a short period of time. This example can have a few variations:
PI
— Simply a lot of connections to dangerous URLs: from different computers and to different URLs
— Many connections to various dangerous URLs from the same computer
CO
— Numerous connections to the same dangerous URL from different computers

— A lot of connections from the same computer to the same dangerous URL
All these situations can be described by standard correlation rules in Kaspersky Unified Monitoring and
Analysis Platform.
BE
TO
T
NO
123
D
TE
BU
RI
ST
DI
RE
OR
Let's talk about variations of this example. What if the analyst does not care where connections to a
dangerous address are established from: the same computer or different ones? What settings must the
rule have in order to be triggered after three connections to the same dangerous address from any
computer?
Only RequestUrl must be specified for the identical fields. In this case, events will be grouped only by the
ED
value of the dangerous address. In other words, the correlator will react after the threshold (3) is
exceeded for the events with the same RequestUrl field values, i.e., connections to the same dangerous
address. There are no other limitations in the correlator (except that these are KATA events generated by
the url_web or ids technology), which means that connections from any computers are taken into
PI
account.
CO
BE
TO
T
NO
124
D
TE
BU
RI
ST
DI
RE
OR
Let's modify the conditions: make the rule detect three connections to the same dangerous address from
the same computer.
To be notified when three or more connections to a dangerous address are established in 30 seconds
from the same computer, the analyst needs to configure a correlation rule with the following general
parameters:
ED
— Kind: Standard
— Identical fields: SourceAddress, RequestUrl
— Observation window: 30 seconds
PI
and selector parameters

— Filter: url_web events from KATA
—
CO
Threshold: 3
The rule will

— Pick out only events that match the selector filter: url_web events from the KATA product
— Group events by values of identical SourceAddress and RequestUrl fields
— Accumulate events in a bucket for 30 seconds from the moment when the bucket was created
BE
(that is, from the moment when the first event was added to the bucket)
— Be applied if a bucket accumulates 3 events
TO
T
NO
125
D
TE
BU
RI
ST
DI
RE
OR
Standard rules are more complex and can be used in very different ways, depending on the scenario. To
better understand them, let's look at our examples from the point of view of the correlator logic.
Note an important principle of standard rules. Standard rules organize all incoming events into groups
(so-called buckets) by values of Identical fields, and then process each group independently. The criteria
are checked separately within each bucket. Therefore, a rule is always applied to a bucket where all
ED
events have the same values of Identical fields.
Values of the fields listed as Identical fields will be copied to the correlation event (similar to the
Propagated fields parameter in a simple rule).
PI
CO
BE
TO
T
NO
126
D
TE
BU
RI
ST
DI
RE
Let us focus on the last situation where many connections are detected from the same computer to the
OR
same dangerous URL.
In order to single out these situations, you need to specify the fields that contain the computer’s address
and a dangerous URL in the Identical fields parameter. In case of Kaspersky Anti Targeted Attack
Platform events, these are the SourceAddress and RequestUrl fields. Accordingly, a correlation rule with
these settings will create a separate bucket for each combination of SourceAddress and RequestUrl
ED
values and apply the ‘many’ criterion (3 in our case, which is defined among other rule settings) to each
group separately.
PI
CO
BE
TO
T
NO
127
D
The ‘many’ criterion consists of two parts: how many events and during what period. The period is set by
TE
the Window parameter in the general settings of a standard rule.
In a more generalized sense, the Window parameter determines the bucket’s lifetime. It works as follows:
— Identical fields specify how to group events
BU
— Selectors determine which events will be grouped (if an event does not match any selector, it will
not fall into any bucket)
— If an event matches a selector and there is already a bucket with the same set of identical field
RI
values as in this event, it goes there
— If an event matches a selector, but its identical field values do not match any bucket, a new
bucket is created with the lifetime specified by the Window parameter
ST
— As soon as a bucket's lifetime ends, it is deleted
— If a new event with a set of identical field values matching a bucket that no longer exists arrives
later, a new bucket is created and the lifetime countdown starts again
DI
Meaning, a bucket accumulates events during its lifetime (or observation window), then gets deleted and
event can accumulate anew. This occurs concurrently and independently for each combination of
identical field values.
RE
OR
ED
PI
CO
BE
Let’s assume that in our example about many connections to the same dangerous address from the
same computer, ‘many’ means 3 or more connections in 30 seconds. The Window parameter in the
general settings of the rule specifies ‘30 seconds’. ‘3 or more’ is defined by the Selector threshold in the
TO
selector settings.
Also, selector has a filter to select events. In this case, we do not want to count all events that have the
SourceAddress and RequestUrl fields. We are interested in events about connecting to a dangerous
address. Such events are generated, for example, by Kaspersky Anti Targeted Attack Platform.
Therefore, let us configure the selector to pick out Kaspersky Anti Targeted Attack Platform events about
T
dangerous connections (in this case, url_web events).

NO
128
D
The rule will be applied if a bucket accumulates the number of events specified in the Selector threshold
TE
parameter during its lifetime. Later, we will look at examples where there may be more than one selector
and there are other conditions in addition to the thresholds.
BU
RI
ST
DI
RE
OR
What if a bucket accumulates much more events than the selector threshold prescribes during its
ED
lifetime? In the Actions section, there are several subsections where the analyst has a choice of identical
output options (send to storage, send back to the correlator, etc.):
— On first threshold — create a correlation event only after the threshold is exceeded for the first
time and ignore further accumulations during the bucket’s lifetime. For example, if a bucket
PI
accumulates 10 events in 30 seconds while its threshold is 3, there will be only one correlation
event after the third accumulated event
— On every threshold — create a correlation event each time when the threshold is exceeded
CO
during the bucket’s lifetime. That is, if a bucket accumulates 10 events and the threshold is 3, 3
correlation events will be created: after the 3rd, 6th and 9th event gets in the bucket
— On subsequent threshold — create a correlation event at all thresholds exceeds except the first
one, i.e. after the 6th, 9th, etc. events if the threshold is 3.
BE
What is the purpose of this option if we have On every threshold and skipping the first threshold
makes no practical sense? To differently react to the first and subsequent thresholds. For
example, you can configure to send only the first correlation event to the correlator input, but add
all correlation events to the storage. Or add only data from the first event to an active list and
skip other thresholds, since there are no new artifacts for the list in subsequent events
TO
— On timeout — standard rules also allow you to configure what to do when the bucket lifetime is
over. This action is only used together with the Recovery option in the selector settings; we will
tell you about it later.
T
NO
129
D
TE
BU
RI
ST
DI
RE
OR
Let us further complicate the example and proceed with studying correlation rule settings. There is the
Unique fields parameter in the General settings of a standard rule. It is optional and makes a bucket
count only events with unique values of the selected fields.
When events are added to a bucket, the rule will compare the value of the unique fields of the new event
with the values of the unique fields of the existing events within the bucket. If one of the events in the
ED
bucket already has the same combination of the unique fields as a new event, the new event is discarded
and not added to the bucket.
Unique fields allow you to implement the following scenario: suppose you do not consider 3 connections
PI
from the same computer (or even two different computers) to a dangerous address in 30 seconds to be a
big problem. However, you would like to receive alerts if 3 different computers connect to the same
dangerous address within 30 seconds.
CO
To achieve this, specify SourceAddress for the Unique fields parameter. Buckets will still count events of
connecting to a dangerous address, but events will only be added to the bucket if they contain a new
computer address in SourceAddress. And the rule will only be applied if a bucket accumulates 3 events
with different SourceAddress values.
BE
TO
T
NO
130
D
TE
BU
RI
ST
DI
RE
OR
You can configure several selectors within a standard rule. This permits accumulating different types of
events (in the broad sense) in a bucket, and allows the rule to be applied not only when a certain number
of similar events are detected, but also when a certain combination of related but different events is
accumulated.
For example, you can create a rule that will be applied if 50 failed password bruteforce attempts are
ED
followed by a successful logon. This rule requires two selectors:
— An event selector with the "failed login attempt: invalid password" condition (the specific
condition will depend on which system the events came from and which fields contain the
PI
necessary information) and the threshold of 50

— An event selector with the "successful login attempt" condition and threshold 1
—
CO
Identical fields: SourceAddress, DestinationHostName, DestinationUserName, so as not to

confuse the password bruteforce attempts for different user accounts on different computers
This combination of conditions can detect a successful bruteforce attempt.
In general, a rule with multiple selectors is applied when thresholds are exceeded for all selectors.
BE
TO
T
NO
131
D
TE
BU
RI
ST
DI
RE
OR
In the previous example with a password bruteforce, the rule will be applied regardless of the order of
events. Even if there was a successful logon first and then 50 failed attempts. This is also suspicious, but
does not mean that there was a successful bruteforce attack. A successful password bruteforce assumes
that a successful logon followed numerous failed attempts.
To add such a condition to a rule, you need to configure the Order by parameter that allows you to
ED
compare timestamps of different events. In particular, you can compare the timestamp of a successful
logon event with the timestamps of unsuccessful attempts.
In general, if the Order by parameter is enabled, the rule first accumulates events in different selectors
PI
until all of them reach their thresholds in the bucket. When all thresholds are reached, the Order by
parameter checks timestamps in the selectors. Order by uses timestamps as a condition, meaning, Order
by is the name of the field from which the timestamp is taken. If Selector 1 reaches the threshold before
Selector 2, the rule is triggered. To change the order, swap selectors (drug-n-drop), because the Order by
CO
parameter is based on the order of selectors.
Since a bucket may contain multiple events from each selector, the question arises: from which events
will the Order by parameter take field values for comparing? The answer is: from the first event of each
selector.
BE
TO
T
NO
132
D
TE
BU
RI
ST
DI
RE
Now, let's return to the scenario when a rule is triggered at the end of the group's lifetime — the On
OR
timeout action. On timeout actions are only used if the rule has a selector with the Recovery option
enabled.
Let’s look at an example. Protection solutions successfully neutralize most of the malicious objects
detected on the network, which is of little interest. But analysts would like to receive alerts about those
rare cases when a dangerous object was detected but the protection solution has failed to delete it. How
ED
can you configure this in KUMA?
If an object has been processed successfully, a detection event will be followed by a disinfection or
deletion event. If an object has failed to be neutralized, there will be no disinfection or deletion event after
PI
the detection event. You can use this difference to configure the rule.
The settings are as follows:

CO
— Identical fields — threat identifier (or file name if the protection application does not assign
unique identifiers to detections)
— Window — 1 hour
— First selector — ‘dangerous object detected’ event with threshold 1
BE
— Second selector — ‘dangerous object disinfected’ or ‘dangerous object removed’ event with
threshold 1 and the Recovery checkbox selected.
‘Recovery’ means that if the respective selector has reached its threshold by the moment of rule
conditions check, the rule will not be applied
— Action — On timeout, so that the conditions for applying the rule are checked only after the
TO
bucket's lifetime expires
Such a rule is applied if there is no disinfection event (no recovery selector events) within an hour
(observation window) after a dangerous object is detected (first selector). The rule is applied when the
lifetime (observation window) of the bucket created when an object is detected expires.
T
You can use recovery selectors not only with the On timeout action. But On timeout actions only work if
NO
the rule has a selector with the recovery flag.
133
D
Variables
TE
BU
RI
ST
DI
RE
OR
Values of event fields, active lists or dictionaries may be not enough to implement some cybersecurity
scenarios.
Variables may come in handy here. They contain a specific function whose result you can use in
correlators in Kaspersky Unified Monitoring and Analysis Platform.
ED
There are several types of functions that you can call in variables:
— Operations with strings
— Operations with timestamps
PI
— Mathematical operations
— Operations with active lists and dictionaries
CO
You can use the result:

— To enrich correlation events
— When working with active lists and tables
— In selectors of correlation rules when creating filters for events
BE
— In correlation rules, when looking for Identical and Unique fields
There are two types of variables:

— Global variables are declared at the correlator level and are available in any correlation rule. The
TO
same variable can take different values in different selectors of the same rule, depending on the
filter conditions
— Local variables are declared at the level of selectors in the correlation rules
T
NO
134
D
TE
BU
RI
ST
DI
RE
For example, you want to pay special attention to cases when the KATA IDS technology detects
OR
something on a weekend.
You can use the extract_from_timestamp function, which allows you to represent time information in the
format of years, months, days, hours, minutes, seconds, or days of the week. Step-by-step instructions
are as follows:
ED
1. Declare the weekday variable with this function and pass the value of the DeviceReceiptTime
field and time format as a parameter. Possible options are: y, M, d, h, m, s, wd.
extract_from_timestamp(DeviceReceiptTime, ‘wd’)
2. In the selector filter, specify the conditions for the KATA product and IDS technology, and
PI
another condition if the variable value is Saturday or Sunday.

When referencing the variable, type $ before its name.
CO
3. To display the value of a variable in a correlation event:

— Add the variable to propagated fields
— Add the variable to an enrichment rule that will write its value to a field of the correlation
event
BE
You can use variables in standard correlation rules to compare values of different fields in different
selectors. This is demonstrated in Lab 17.
Here is the list of functions that you can call in variables in Kaspersky Unified Monitoring and Analysis
Platform.
TO
The syntax for declaring various variables is described in detail in the online help at
— Operations with strings:

— len — returns the number of characters in the string
T
— to_lower — converts data to lowercase

NO
135
D
— to_upper — converts data to uppercase
TE
— append — adds characters to the end of the string
— prepend — adds characters to the beginning of the string
— substring — allows you to cut out a substring from a string
BU
— tr — truncates the string
— replace — replaces all occurrences of sequence of characters A with sequence of
characters B in a string
RI
— regexp_capture — allows you to get data that matches a regular expression from the source
string
— regexp_replace — replaces sequences of characters that match a regular expression with
ST
another sequence of characters
— Operations with timestamps:
— now — returns the current time in epoch format
DI
— extract_from_timestamp — allows you to get information about time in the form of year,
month, day, hour, minute, second, or day of the week from a timestamp
— parse_timestamp — allows you to convert a timestamp into epoch format
RE
— format_timestamp — allows you to convert a timestamp into RFC3339 format
— truncate_timestamp — allows you to round down time and then convert it into epoch format.
Time rounding options are 1s, 1m, 1h, 24h
— time_diff — allows you to calculate the time interval between two timestamps in epoch
OR
format
— Mathematical operations allow you to add, subtract, multiply, divide:
— Round — rounding
— Ceil — rounding up
ED
— Floor — rounding down

— Abs — getting the absolute value of a number
— Pow — exponentiation
PI
— Operations with active lists and dictionaries:

— active_list — getting information about a value in the specified column from AcliveList
CO
active_list('ActiveList,'Score',RequestUrl)
— dict — getting information about the value that corresponds to the specified parameter
dict('exampleDictionary',SourceAddress)
— table_dict — getting information about a value in the specified column
BE
table_dict('TableDict','SID',SourceUserName)
TO
T
NO
136
D
Active lists
TE
BU
RI
ST
DI
RE
OR
An active list is a list in the memory of a correlator that accumulates data from events to be used in
comparison conditions of correlation rules. Lists help identify patterns over long periods of time.
ED
For example, an analyst would like to receive alerts if a connection to a dangerous URL that has
previously been encountered in email is detected in the organization's web traffic. This combination may
indicate a successful attack, whereas just messages with dangerous links on the one hand and
connections to dangerous addresses on the other hand happen quite often and do not imply a serious
PI
incident.
To sort these situations, you need two selectors and the Order by parameter:
CO
— The first selector will pick out ‘dangerous URL detection in email’ events with threshold 1
— The second selector will pick out ‘dangerous URL detection in web traffic’ events with threshold 1
— URL will be the grouping field
— The Order by parameter will compare timestamps of events and check if the web request was
logged after the email was received
BE
This rule will work, but what Window value to specify in it? You can specify an hour, but then you won't be
aware of incidents when a user clicks a link in a yesterday's email or clicks a link from a Friday's email on
Monday. You can specify 7 days, but this will dramatically increase requirements for the correlator's
memory because all buckets are stored there. With a week's lifetime, the correlator will have to store a
huge number of buckets in its memory.
TO
Instead, you can adopt a different approach: configure a rule to fill in a list with addresses found in the
mail, and another rule to check if a dangerous address found in web traffic matches a value in the list
filled from email. This way, the correlator will store only the list of addresses in the memory instead of
numerous events with a lot of fields.
T
Active lists are stored in the correlator memory, but are regularly cached to disk; this way, a list will not be
lost if the service restarts or malfunctions. If several correlator services use the same active list resource,
NO
each of these lists will have its own status.
137
D
TE
BU
RI
ST
DI
RE
To use an active list in the correlator, create it as a resource first. This resource has only a few settings:
OR
— List name
— The lifetime of entries in the list (an optional parameter). If you do not specify it, entries will live
indefinitely long in the list. Whether this is justified depends on what data is stored in the list.
ED
PI
CO
BE
TO
T
NO
138
D
Correlation rules fill active lists. The Actions section contains the Update active lists subsection in
TE
addition to the Output and Loop actions, where you can specify which lists to fill with what values from the
correlation event when applying the rule.
A single rule can fill multiple lists or perform multiple operations on a single list. The following operations
BU
are available:
— set — to add or update an entry
— del — to remove an entry from the list
— get — to enrich the correlation event with data from the list (we will provide an example later)
RI
Let's start by filling a list. In the properties of the set command, specify:
— Key fields — values of these fields will be the keys of the list’s entries. All entries in a list have a
ST
table structure (the Key column and its attributes); in the conditions of correlation rules, you can
only match events against keys from a list. A key is the combination of the values of all the listed
fields. You will be able to compare only with the whole key rather than with a part of it
— Mapping defines the key attributes. Every attribute has a name (arbitrary) and a value. You can
DI
either take an attribute’s value from an event field or set it as a constant. You can use attributes
to enrich events and for correlation conditions. There must be at least one attribute
If a key exists already, a set operation will overwrite its attributes with the values from the fields of the
RE
new event.
The del operation has only the Key fields parameter; it deletes the record with the corresponding key.
OR
ED
PI
CO
BE
TO
Any rule can fill a list. However, simple and standard rules always create correlation events and alerts. To
silently fill a list without creating correlation events and alerts, use operational rules.
Operational rules are designed for filling active lists. An operational rule has the following settings:
— A selector without a threshold. It defines conditions for events whose fields will be added to the
T
list
— The action (update the specified active list) with the trigger On every event; names of the key
NO
fields for the list and the fields from which the context will be taken are also specified here
139
D
A selector without a threshold means that operating rules react to individual events, i.e. behave like
TE
simple rules.
Only set, delete and sum operations are available in an operational rule. The get operation does not
make sense here because it enriches correlation events, and an operational rule does not create such
BU
events.
RI
ST
DI
RE
OR
ED
To make correlator use a list, it is enough to create rules that fill an active list, and the correlator will
automatically create it in the memory.
PI
Since active lists reside in the correlator’s memory, to consult their contents, you need to open the list of
services, select the correlator service and click the button Go to active lists.
CO
BE
TO
T
NO
140
D
TE
BU
RI
ST
DI
RE
The Go to active lists command displays all active lists of the correlator, the number of entries in them,
OR
the list size and the path to its file on the disk (where the list is cached). An analyst can export, import or
clear a list.
The contents are exported in JSON format. You can import CSV, TSV and JSON.
An analyst can also display the contents of a list to consult its entries, find out when they were created or
ED
updated and when their lifetime expires if it is configured. An analyst can manually delete and add (but
not edit) entries.
You can open each entry to consult its additional attributes.

PI
CO
BE
TO
T
NO
141
D
To access the contents of an active list, you can use the following methods in a correlation rule selector:
TE
— The inActiveList operator. This condition has two parameters:
— Active list name
BU
— Key fields of the event to check against the list
Values of the event’s key fields are compared only with the keys of the list’s entries. Attributes of
these entries do not play any role in this case.
— The active list operand. This condition has several parameters:
RI
— Name of the active list
— Key fields of the event that you use to check if the list contains such a record
ST
— Context of the record, i.e. you can check not only if an URL is present in the active list, but
also, for example, whether its context includes the User field with the value alex@abc.lab
You can compare contents of two active lists in a similar manner; i.e. there can be an active list
in the left and right operands at the same time.
DI
— A variable with the active_list function
RE
OR
ED
PI
CO
BE
You can use attributes of an active list’s entries to enrich correlation events. For instance, in our example
with connecting to an emailed dangerous address, you can add the name of the message recipient to the
correlation event. For this purpose, you need to configure the operational rule to save it as an attribute in
the active list. Then in a simple correlation rule in the Actions section, select to perform the get operation
TO
on the active list and write the contents of the respective entry attribute from the active list into some field
of the correlation event.
T
NO
142
D
Retrospective scanning
TE
BU
RI
ST
DI
RE
OR
Typically, a correlator only works with real-time events that it receives from collectors.
But sometimes, you need to apply correlation rules to historical events. Retrospective scanning serves
ED
this purpose. The Retroscan command is available on the three-dot menu in the upper right corner of the
event search page.
The Retroscan command creates a retroscan task, where the analyst configures:
PI
— Name of the correlator service that will apply rules to historical events
— Names of the correlation rules to be applied
CO
— Whether to generate alerts when historical events match the rules

— Whether to perform incident responses configured for the correlator (responses will be described
later in our course)
The analyst does not explicitly configure which events to retroscan. Instead, the task uses the current
BE
search settings:
— Query (without taking into account the limit)

— Timespan
—
TO
The storage to search for events
The task is performed by the KUMA core (kuma-core):
— The core queries the storage

—
T
The storage returns the list of events

— The core forwards the events to the correlator configured in the task and specifies which rules to
NO
apply
143
D
The created task appears on the Task manager page, where the analyst can monitor its progress. When
TE
the task completes, you can find its correlation events by the Go to Events command from its three-dot
menu. Correlation events created by retrospective scanning have an additional ReplayID field that stores
the unique identifier of retroscanning.
BU
You can re-run a retroscan task using its three-dot menu. The new correlation events will have a different
ReplayID.
Retroscan is also useful when debugging correlation rules. To test a rule, you can run it in Retroscan
mode on the corresponding historical events instead of reproducing incidents in real time.
RI
ST
DI
RE
OR
ED
PI
CO
BE
TO
T
NO
144
KL 034.2: Kaspersky Unified Monitoring and Analysis Platform 2.0.1 6. Response, alerts, reports and monitoring
D
6. Response, alerts, reports and monitoring
TE
BU
6.1 Alerts
Correlator outputs correlation events. They are not alerts by themselves, but when a correlation event
RI
appears, the core always either creates a new alert or supplements an existing alert (retroscanning does
not necessarily create alerts).
ST
DI
RE
OR
ED
PI
CO
The general principle of generating alerts is as follows. When a new correlation event appears, the core
checks the rule that created the event:
— If there are no open alerts for this rule, a new alert is created with a link to the correlation event
— If there is a new, assigned or escalated but not closed alert for the same rule, a link to the new
correlation event is added to it
BE
An alert accumulates correlation events up to a threshold (the alert size is limited to 16MB), after which
the alert is considered full and new events will no longer be added to it. However, new alerts will not be
created either, so it is important to keep an eye on full alerts.
TO
Analysts can:
— Change the priority of an alert (its initial priority is calculated as the average of the correlation
rule criticality and the criticality of the category that the asset belongs to)
— Assign an alert to themselves or other employees
T
NO
145
D
— Escalate, i.e. convert an alert into an incident
TE
In Kaspersky terms, an incident is a confirmed alert. An incident can be bound to several alerts;
for example, if an analyst discovers initial compromise and lateral movement during an
investigation and links these alerts to a single incident
BU
— Close an alert for one of the following reasons: processed, incorrect data or an incorrect
correlation rule
Closed alerts are not displayed by default. This is controlled by the filter configured for the Status column.
An analyst can filter the alert table by any column.
RI
ST
DI
RE
OR
ED
PI
Click an alert to open its details. The analyst can perform all processing activities here: change priority,
assign, escalate and close.
CO
Alert details include:

— Correlation events related to the alert (every time a rule is applied, a correlation event is
generated; these events are added to an existing alert while it remains open)
— Base events that matched the rule
BE
— Endpoints related to these events (including assets)

— User accounts related to these events
TO
T
NO
146
D
TE
BU
RI
ST
DI
RE
OR
You can open a card with the details of an associated asset or user from an alert.
Each alert also contains a history of changes where an analyst can leave comments for other analysts,
for example.
ED
PI
CO
BE
TO
T
You can also consult all events related to the alert: correlation and base.
NO
147
D
It is worth noting that an alert is a kind of virtual container into which all related artifacts, events, assets
TE
and accounts are copied. Alerts are stored in the MongoDB database on the KUMA core.
BU
RI
ST
DI
RE
OR
You can configure notifications about alerts in Kaspersky Unified Monitoring and Analysis Platform. To do
this, you need to specify the SMTP server parameters in Settings | Common:
ED
— Host — smtp server address

— Port — smtp server port
— Secret — authentication parameters; you can leave them empty if the server supports
PI
anonymous connections
— From — the address that will be specified in the From field of the messages
CO
The Monitoring notifications option pertains to event source monitoring policies; this is described in the
corresponding section of our course.
SMTP settings are also used for emailing reports and notifications to KUMA users.
BE
TO
T
NO
148
D
TE
BU
RI
ST
DI
RE
OR
After you’ve configured SMTP server settings, set up a notification template. It is also a resource. One
template is available in the list of resources by default.
You can change the notification subject and text as follows:
— Subject — a string where you can use values of the correlation event fields in the {{.EventField}}
ED
format. Field names are case sensitive

— Template — message where you can also use field values in the {{.EventField}} format.
PI
CO
BE
TO
T
NO
149
D
TE
BU
RI
ST
DI
RE
OR
The last step is to set up a notification rule.☺
Notification rules reside in Settings | Alerts | Notification rules. You need to specify the following in a
rule:
— Name
ED
— Recipient addresses — you can add any addresses, not only KUMA users
— Correlation rules that will trigger sending the notification. An email is sent only when a rule is
matched for the first time, i.e. if there are no other open alerts created by this rule
PI
— Notification template
CO
BE
TO
T
NO
150
D
TE
BU
RI
ST
DI
RE
OR
In Kaspersky Unified Monitoring and Analysis Platform, when a correlation rule is triggered, an alert of the
same name is created, which accumulates correlation events until it is closed.
But you can configure so-called segmentation rules that will create separate alerts if a correlation event
satisfies specific conditions. These conditions are set in the segmentation rules. For example, if the
DestinationUserName of a correlation event belongs to some Active Directory group, then a separate
ED
alert will be created for such a correlation event. The alert name will have the following format:
<Name of the correlation rule> (<Name of the segmentation rule>)
A selector works with correlation events in a segmentation rule; therefore, it is important that the
PI
correlation event must be enriched with the necessary fields from the base event.
This is configured in Settings | Alerts | Segmentation rules.

CO
6.2 Response
BE
In this section, we will study response tools (including automated response) available in Kaspersky
Unified Monitoring and Analysis Platform and how you can use them.
TO
T
NO
151
D
TE
BU
RI
ST
DI
RE
OR
Incidents need to be responded to. Kaspersky Unified Monitoring and Analysis Platform saves time by
automatic response to correlation events:
— Running a Kaspersky Security Center task (for example, to update databases and scan critical
areas of the computer)
— Running a script — the script will be executed on the server where the correlator service is
ED
running and can take values of event fields as parameters

— Launching a Kaspersky Endpoint Detection and Response task — for example, to isolate an
infected device or run an executable file
PI
— Launching a Kaspersky Industrial CyberSecurity for Networks task — to change the status of the
device in the industrial network
CO
BE
TO
T
NO
152
D
TE
BU
RI
ST
DI
RE
OR
To be able to automatically run Kaspersky Security Center tasks in response to correlation rules, first of
all, integrate Kaspersky Unified Monitoring and Analysis Platform with Kaspersky Security Center (which
is described in the Integrations section of this course).
Also, the tasks on the Kaspersky Security Center side must be created in advance. They must be
configured as follows:
ED
— The task name must start with KUMA

— The task must pertain to Kaspersky Endpoint Security for Windows or Kaspersky Endpoint
Security for Linux
PI
— The task must be created for a set of computers (rather than a group)
KUMA ignores tasks that do not meet these requirements.

CO
To be able to run tasks, grant the permission to modify and run Kaspersky Endpoint Security tasks to the
account specified in the Kaspersky Security Center integration settings in KUMA. The easiest way to
achieve this is to grant the Kaspersky Endpoint Security Administrator role to this account on the
Kaspersky Security Center side. KUMA needs the modification permission to be able to assign a task to
computers related to the alert.
BE
TO
T
NO
153
D
TE
BU
RI
ST
DI
RE
OR
An analyst can run tasks manually from the card of an asset imported from Kaspersky Security Center.
The KSC response button displays the list of available tasks (see the task requirements above). Select
one of them and click Start. The task will be assigned to the selected computer with the schedule
Immediately. If the Kaspersky Security Center server successfully synchronizes with the computer, the
task will start immediately. If forced synchronization fails for some reason, the computer will run the task
after a scheduled synchronization with Kaspersky Security Center. By default, planned synchronization
ED
takes place every 15 minutes.

PI
CO
BE
TO
T
NO
154
D
To run Kaspersky Security Center tasks automatically, create a response resource with the following
TE
settings:
— Kind — ksctasks
— Kaspersky Security Center Task — one of the tasks that meets the requirements
BU
— Event field — the field that contains the identifier of the asset where the task needs to be run.
You can select one of the following: SourceAssetID, DestinationAssetID, DeviceAssetID. Which
field to choose depends on what events the correlation rule applies to and what fields are filled in
those events. In Kaspersky Security Center events, the identifier of the compromised computer
RI
is usually specified in the DestinationAssetID field
— Filter — an additional filter to run the task when some additional conditions are met rather than
every time when the correlation rule is applied
ST
You need to add the created response resource to the correlator configuration. Since response is a
setting of a correlator rather than that of a specific correlation rule, it is applied when any rule is matched.
In order to use different actions for different correlation rules, there is a filter in the response settings
where you can specify conditions, for example, name of the matched correlation rule.
DI
RE
OR
ED
PI
CO
BE
Kaspersky Security Center tasks provide limited capabilities and are applicable only to assets imported
from Kaspersky Security Center.
The analyst can create a script to run in response to a matched correlation rule (bash, perl or any other
script that can be executed on a Linux server). To make the script affect specific computers or accounts,
TO
you can pass event field values to it as parameters.
Copy the prepared script to the following folder of the correlator service:
/opt/kaspersky/kuma/correlator/<service identifier>/scripts
Then you need to configure a response resource with the following settings:
T
— Kind — script
NO
— Timeout — how long to wait for the script to complete
155
D
— Filter — additional conditions for a response (to run the script not after every application of each
TE
correlation rule)
— Script file name — the file must be located in the abovementioned folder
— Script arguments — you can pass values of the correlation event fields in the Go template format
BU
{{.EventField}}. Field names are case sensitive
Add the configured resource to the correlator service configuration and restart the service.
RI
6.3 Dashboard and reports
ST
Kaspersky Unified Monitoring and Analysis Platform provides the dashboard and reports to show the
overall security situation. They consist of widgets that visualize various statistics.
DI
RE
OR
ED
PI
CO
A dashboard layout defines which widgets to show, what to show on them and how to position widgets on
BE
the page. Each user can create a custom set of layouts and switch between them to get different slices of
network status.
The created layouts are sorted alphabetically, and unless the preferred layout is selected, the first layout
on the list is displayed by default. You can select a preferred layout to see it when you open the
dashboard. To do so, click the star to the left of the layout name in the list of layouts.
TO
To adjust a layout, expand the list of layouts, hover over the name of the necessary layout, wait for the
pencil image to appear to the right of the name and click it.
T
NO
156
D
TE
BU
RI
ST
DI
RE
OR
Every layout has general settings and a set of widgets, each with its own additional settings.
General layout settings include:

— Refresh rate (for all layout’s widgets)
— The reporting period (widgets can use the layout’s period or have their own)
ED
— Layout name
To add a new widget to a layout, use the Add widget drop-down list. To remove or modify a widget, click
the gear button in the upper right corner of the widget.
PI
CO
BE
TO
T
NO
157
D
TE
BU
RI
ST
DI
RE
OR
A variety of widgets are available in Kaspersky Unified Monitoring and Analysis Platform layouts; each
has a more or less fixed view of the information displayed. In standard widgets, you can change only the
reporting period and a few auxiliary display options.
Several dozen preset widgets are grouped into categories:

ED
— Alerts
— Assets
— Incidents
— Event sources
— Users
PI
— Active lists
— Events
CO
The complete list of widgets is available in the online help at

BE
TO
T
NO
158
D
TE
BU
RI
ST
DI
RE
OR
The Events widget is of most interest because it allows you to run an SQL query in the event storage and
visualize the response. It enables the analyst to customize dashboards almost unlimitedly. If some
information type is stored in the database, you can retrieve and display it.
The Events widget has three sections of settings. The first section contains SQL query settings (similar to
those on the event search page), visualization method, reporting period (the same as the layout reporting
ED
period by default) and the option that allows you to add data of the previous period. Meaning, you can see
data over the current and previous period on a single chart to assess the dynamics.
The SQL query parameters depend on the visualization method:

PI
— To present data in a chart, you need to specify by which field to combine events (in the Select
parameter, the field with the value attribute), and which field to use to calculate the metric for the
group (the field with the metric attribute and metric type: count, min, max, avg, sum)
CO
— For a table, you need to specify which event fields to display in the table columns and
(optionally) by which fields to group records and by which field to count the metric for the group
— For a counter, specify the query conditions, the metric count field and the metric (count, min,
max, avg, sum)
BE
— For a histogram, the metric is fixed (count by id, i.e. the histogram simply visualizes distribution
of events over time) and you only need to specify the query conditions
TO
T
NO
159
D
TE
BU
RI
ST
DI
RE
In the second section of the settings, you define axes for graphs.
OR
The third section sets other visualization parameters: graph orientation, colors, legend, summing up,
widget name and description.
ED
PI
CO
BE
TO
T
Reports are built from the same elements as the dashboard, but they can be generated on a schedule,
saved to a file and emailed.
NO
160
D
Reports are generated to templates (similarly to dashboard views that are based on layouts).
TE
BU
RI
ST
DI
RE
OR
Report templates have almost the same settings as dashboard layouts. A template has a reporting period
and a set of widgets. Unlike a dashboard, a report template does not have a refresh rate, but has a
lifetime for storing reports in the KUMA database and a logo to be displayed in the reports. You can use
any image for the logo.
ED
Available widgets and their settings are exactly the same as in dashboard layouts.
PI
CO
BE
TO
T
NO
161
D
You can set up a schedule for generating a report (via the three-dot menu of its template). You can
TE
choose the time when to create a report and the frequency in days, weeks, months or years.
You can also specify email addresses below the schedule to have the report emailed. The SMTP server
parameters specified in Settings | Common are used for sending reports.
BU
You cannot specify arbitrary recipient addresses here; you can only select from addresses specified in
Settings | Users.
RI
6.4 Metrics
ST
In this section, we will talk about monitoring event sources and about the performance characteristics of
KUMA services that are displayed as metrics.
DI
RE
OR
ED
PI
CO
There is the Sources status section in the side menu of the KUMA interface. It displays the list of
BE
sources that send data to collectors. A source is a virtual entity that has the following parameters:
— DeviceProduct
— DeviceHostName
— DeviceAddress
— DeviceProcessName
TO
— Tenant
We can find values of these parameters in the fields of events that arrive to the collectors. Each unique
set of values is registered as a separate source whose event flow is displayed over the last week.
The list of sources is refreshed and events are counted every minute.
T
NO
162
D
TE
BU
RI
ST
DI
RE
OR
Data on the frequency and number of incoming events is an important indicator of the system state. For
example, you can see when the flow of events grows or decreases abnormally, or even stops.
Monitoring policies keep track of such situations. Specify the lower threshold in the policy (the upper
threshold is optional) and how events will be counted (policy type):
ED
— By EPS — the number of events per second over the specified period of time. The average
value for the entire period is calculated, but you can additionally track peaks during the specified
intervals
— By count — the number of events over the specified period of time
PI
The policy must be applied to an event source. After that, the source status can be either green
(everything is fine) or red (the stream is abnormal) — in this case, a Monitoring event is generated. You
CO
can also configure emailing notifications to any address.

BE
TO
T
NO
163
D
TE
BU
RI
ST
DI
RE
OR
Another important source of information about Kaspersky Unified Monitoring and Analysis Platform is the
Prometheus metrics available on the Metrics page. It shows statistics of events at the input and output of
various services, statistics of delays in event processing by various services, error metrics and buffer
usage.
For example, if a service buffer starts to grow dramatically, it may mean that the service cannot send
ED
events to the destination (there is a network error or hardware is malfunctioning) or fails to handle the flow
of events (incorrect configuration or resource estimation error).
Metrics also show the load on the operating system in general and the load that KUMA services create.
PI
The Grafana solution visualizes metrics in the console.

CO
BE
TO
T
NO
164
D
TE
BU
RI
ST
DI
RE
OR
There are several preconfigured panels in the Metrics section. By default, metrics of collector services are
displayed. Click on the KUMA Collectors header to switch to the correlator, core, storage or tenant
metrics. Every section shows its own metrics.
You can additionally filter the displayed metrics by service names: show the load for the selected services
or all together.
ED
Experts familiar with Prometheus and the PromQL query language can also create and customize their
own information panels.
PI
CO
BE
TO
T
NO
165
D
TE
BU
RI
ST
DI
RE
The following metrics can be useful for Collector services:
OR
— IO | Processing EPS — input collector flow — the number of events processed per second
— IO | Output EPS — output collector flow — the number of events sent to the destination per
second
— IO | Output Disk Buffer Size — the current size of the disk buffer; zero means that no batch of
ED
events is buffered, everything is fine. If the buffer grows, it may mean that the destinations
(correlator, storage) are unavailable
— IO | Output Event Loss — the number of events lost per second. A loss may occur if they can
neither be sent out nor written to the buffer if it is full (the buffer size is set in a connector
PI
resource)
— Normalization | Raw & Normalized event size — shows which collectors retain raw events and
the average sizes of raw and normalized events
CO
— Normalization | Errors — the number of normalization errors per second. It grows if the format of
incoming events does not match the normalizer type
— Filtration | EPS — the number of events discarded by the collector per second. Shows how filters
optimize the flow of events at the output of the collector, which also affects the license count
BE
— Aggregation | EPS — the number of input and output events per second in an aggregation rule.
Allows you to evaluate the efficiency of aggregation rules
— Enrichment | Queue — the size of the enrichment request queue. Shows you if a particular
enrichment rule is a bottleneck.
— Enrichment | Errors — the number of enrichment source access errors per second
TO
— Process | all metrics — general metrics of each collector service, show the impact on the
operating system
— OS | all metrics — general metrics of the operating system, show utilization of CPU, RAM, Disk
and the average load on the system
T
NO
166
D
TE
BU
RI
ST
DI
RE
The following metrics can be useful for Correlator services:
OR
— IO | Processing EPS — input correlator flow — the number of events processed per second
— IO | Output EPS — output correlator flow — the number of events sent to the destination per
second
— Correlation | EPS — the number of correlation events generated by a correlation rule per second
ED
— Correlation | Buckets — the current number of correlation groups (buckets) inside a correlation
rule (only for Standard rules). Correlation groups live in the correlator's memory during the time
specified in the Window parameter of the correlation rule. This metric helps keep track of rules
with large observation windows that can potentially affect utilization of system resources.
PI
— Correlation | Rate Limiter Hits — shows how often the correlation rule is triggered per second.
The default limit is 100. If more than 100 events to which the rule is applicable arrive in a second
and the metric has hit the ceiling, you need to increase the Rate limit in the correlation rule
CO
— Correlation | Active Lists On-Disk Size — shows the current size of each active list on the disk
— Response | RPS — number of response rule activations per second. If the number is abnormal,
it may make sense to set up a filter in the response rule
— Process | all metrics — general metrics of each collector service, show the impact on the
BE
operating system
TO
T
NO
167
D
TE
BU
RI
ST
DI
The following metrics can be useful for Storage services:
RE
OR
— ClickHouse | General | Active Queries — the total number of currently executed queries
— ClickHouse | Insert | EPS — the number of events written to the storage per second.
— ClickHouse | Insert | Rejected Insert QPS — the number of write requests (per second) that the
ClickHouse node rejected
ED
— ClickHouse | Insert | Failed Inserts QPS — the number of unsuccessful write requests (per
second)
— ClickHouse | Insert | SELECT QPS — the number of unsuccessful read requests (per second)
PI
— ClickHouse | Replication | Active Connections — the number of active connections to the

ClickHouse cluster nodes. Normally, this number should be equal to the number of nodes in the
ClickHouse cluster
CO
— ClickHouse | Replication | Read-only Replicas — the number of ClickHouse replicas that are in
read-only mode. Normally, there should be none
— ClickHouse | Replication | Active Replication Fetches — the number of active data replication
processes at the moment
BE
— Agent | all metrics — general metrics of each storage service that show the impact on the
operating system
TO
For the full list of metrics, consult the online help at

T
NO
168
D
TE
BU
RI
ST
DI
RE
OR
ED
PI
CO
BE
TO
T
NO
169

KL 034.2 Kuma Student Guide en v0.8

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

KL 034.2 Kuma Student Guide en v0.8

Uploaded by

Copyright:

Available Formats

KL 034.2: Kaspersky Unified Monitoring and Analysis Platform 2.0.

3. Event collecting and processing ........................................................................................37

Collector settings ............................................................................................................................39

SQL connector ................................................................................................................................55

KUMA data model ..........................................................................................................................60

3.3 Collector: event processing ............................................................................................................69

Storage spaces and partitions ........................................................................................................79

4.3 Kaspersky Threat Lookup...............................................................................................................98

4.5 Kaspersky Endpoint Detection and Response .............................................................................109

Cybersecurity Information Security

DBMS DataBase Management System

KATA Kaspersky Anti Targeted Attack

KES Kaspersky Endpoint Security

KSC Network Agent

SIEM Security Information and Event Management

WEC Windows Event Collector

WMI Windows Management Instrumentation

XDR eXtended Detection and Response

The official documentation is available at

and network hardware”.

attributes of different events.

Visualize data for analysis and incident investigation

can easily detect

situation requires special attention

included in the allow list, then an incident is recorded

SIEM key features

storage) per second. That’s the first factor.

The more such resources, the better for the customer.

1.2 About KUMA

be searchable similarly to base events.

correlator creates a so-called correlation event

or, conversely, the stream has increased abnormally

search the database for events of a particular type

settings of the storage service).

tolerance, create several replicas per shard.

KUMA configuration principles

Industrial CyberSecurity for Networks. Responses are used in correlators

settings and connection resources

measured in events per second (EPS).

server and allocate another server for the storage.

The figures show several load examples.

20K EPS and 12-month retention

50K EPS and 6-month retention

— Oracle Linux 8.6 or later

For an all-in-one installation:

installer/roles/kuma/files/ and rename it license.key. A key file usually has an

3. Prepare an Ansible inventory file for a distributed installation

On our diagram, we have a two-node ClickHouse cluster (kuma-storage1.abc.lab and kuma-

In a production environment, we recommend that you deploy ClickHouse Keeper services to

Sharding and replication in ClickHouse

Let's look at the possible configurations of a four-node ClickHouse cluster.

The first configuration example: 1 four-replica shard

Advantages: the most reliable way to store data (4 copies)

Second configuration: 4 one-replica shards

Third configuration: 2 two-replica shards

data (if a cluster node malfunctions, data will not be lost).

As a result of an all-in-one installation, the following services are created:

— 5140/tcp to receive data from external sources

— [OOTB] Syslog collector uses the following ports:

— 5140/udp to receive data from external sources

Distributed installation results

respective KUMA server.

Tenants and system components