KL 034.3.

Kaspersky Unified
Monitoring and Analysis
Platform

Student guide
 D
TE
Table of contents
1. General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

BU
1.1. About SIEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. About KUMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1. All-in-one installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

RI
2.2. Distributed installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3. Web console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.4. Installation results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

ST
2.5. Tenants and system components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.6. Role-based access control and authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3. Event collecting and processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

DI
3.1. Collecting events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.2. Normalization of events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.3. Collector: event processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

RE
4. Integrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.1. Integration with Kaspersky Security Center. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.2. LDAP integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
4.3. Kaspersky Threat Lookup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
OR
4.4. Kaspersky CyberTrace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
4.5. Kaspersky Endpoint Detection and Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
4.6. Kaspersky Automated Security Awareness Platform. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
5. Correlation and work with events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
5.1. Working with events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
ED

5.2. Correlation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

6. Response, alerts, reports and monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
6.1. Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
6.2. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
PI

6.3. Monitoring and reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

6.4. MITRE ATT&CK matrix coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
CO

6.5. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

BE
TO
T
NO
 Preface KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
Glossary

Administration Server Kaspersky Security Center Administration Server

BU
Central Node Kaspersky Anti Targeted Attack Central Node

DBMS Database management system

RI
EPS Events per second

ST
IS Information security

IT Information technology

DI
KATA Kaspersky Anti Targeted Attack

RE
KEA Kaspersky Endpoint Agent

KEDR Kaspersky Endpoint Detection and Response

OR
KES Kaspersky Endpoint Security

KICS Kaspersky Industrial CyberSecurity

KSC Kaspersky Security Center

ED

KSWS Kaspersky Security for Windows Server

PI

KUMA Kaspersky Unified Monitoring and Analysis

Network Agent Kaspersky Security Center Network Agent

CO

SIEM Security information and event management

WEC Windows Event Collector

BE

WMI Windows Management Instrumentation

XDR Extended detection and response

TO
T
NO

1
 Chapter 1. General KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
Chapter 1. General
1.1. About SIEM

BU
This guide covers the Kaspersky Unified Monitoring and Analysis Platform product (or KUMA for
short), version 3.2.

RI
The official documentation is available at https://support.kaspersky.com/help/KUMA/3.2/en-US/
217694.htm.

ST
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. Kaspersky Unified Monitoring and

DI
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

RE
needed, what problems they can solve and how they do it.

So, what is SIEM (Security Information and Event Management)? To avoid reinventing the wheel, let’s
quote Wikipedia:
OR
ED
PI
CO
BE

To put it in a less formal language, SIEM is a system that collects events from the whole corporate
TO

network and helps information security specialists filter this data stream and automatically or semi-
automatically find indicators of cybersecurity incidents.

Typical SIEM tasks

T
NO

2
 Chapter 1. General KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
Events that theoretically can help detect and investigate a cybersecurity incident may be logged by
different systems, have different structure, format, encoding. This can be a Windows event log, Linux
OR
audit event log, SQL database, etc.

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 form. Thus,
ED

the next task of SIEM is to convert them into some normalized form to be able to compare attributes
of different events.

To detect correlations indicative of security incidents in normalized events, a SIEM system groups
PI

events by various attributes and uses a set of correlation rules, conditions and more complex
detection mechanisms.
CO

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

Another example is when the proxy server provides information that a file was downloaded; this event
can be related to a file operation on a computer if file hashsums coincide.
TO

Other functions of a typical SIEM are quite common, and you can find them in various analysis and
management systems:

• Visualize data for analysis and incident investigation

T

• Notify responsible employees when ‘interesting’ events are detected

NO

3
 Chapter 1. General KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
• Build reports about the system status and operation results

Use cases

BU
RI
ST
DI
RE
OR

SIEM systems typically permit configuring flexible conditions to search a database of events for a
wide variety of patterns and correlations. Here are a few simple incident examples that SIEM can find:
ED

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

events in a short period of time, this is a clear sign of a brute-force attack that a SIEM system
can easily detect
CO

• 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-existent, and grant it administrator permissions. And then use the TGT to obtain a
BE

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 issued TGT ticket is presented. A domain user receives a TGT every 10 hours, so a
TO

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

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

4
 Chapter 1. General KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
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

BU
(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
situation requires special attention

RI
• 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,

ST
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

DI
• 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
included in the allow list, then an incident is recorded

RE
All these examples demonstrate that in order to detect an incident, the system must take into account
multiple events, which are sometimes significantly separated in time and created by different systems.
OR
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 system resources.
ED

SIEM key features

PI
CO
BE
TO
T

Since a SIEM system potentially works with a huge number of events, it is crucial that it operates
NO

5
 Chapter 1. General KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
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 storage) per second. That’s the first factor.

BU
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

RI
into equipment, they expect good performance with reasonable resources.

Apart from that, the system must be widely scalable, i.e. have no limit on the amount of processed

ST
information.

Another important thing is out-of-the-box functionality. Setting up SIEM from scratch is quite difficult:

DI
you need to study formats of all kinds of logs that you want to collect. Windows events are XML,
events from network equipment are something else (Netflow or syslog), events from security

RE
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
OR
for popular systems as possible and provide them out of the box.

The same is true for enrichment rules. There are typical situations where enrichment is appropriate,
for example, adding computer names by IP addresses or querying an external treat intelligence
ED

system to find out whether hashes, URLs and IP addresses from incoming events are known
indicators of 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
PI

automatically, such as a brute-force attack, network scanning, various techniques from the MITRE
ATT&CK matrix, and so on. It is also reasonable to have out-of-the-box rules for these situations
CO

rather than make the customer create them manually.

The more such resources, the better for the customer.

BE

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

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

Kaspersky Unified Monitoring and Analysis Platform has all the characteristics of a good SIEM:
NO

6
 Chapter 1. General KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
• The microservice architecture provides seamless scalability without bottlenecks: you can
deploy a full-featured demo system on an office workstation; on the other hand, if necessary,
the solution can be deployed in a high-availability and distributed architecture with a throughput

BU
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

RI
protocols, incoming data formats and ready-to-use out-of-the-box resources are constantly
supplemented

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

DI
resources in many different ways to solve a variety of practical tasks

Kaspersky Unified Monitoring and Analysis Platform provides a wide range of capabilities to enrich

RE
events from external sources and close (but optional) integration with Kaspersky ecosystem of
products and services:

• Kaspersky Security Center provides extended information about assets (including their
OR
vulnerabilities) for analysis, and automated incident response

• Kaspersky Threat Lookup allows you to query the Kaspersky cloud cyberthreat intelligence
database to gain context and detect indicators of compromise
ED

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

1.2. About KUMA

CO

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

KUMA operation principles

TO
T
NO

7
 Chapter 1. General KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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
OR
implemented as Linux services and each service is responsible for a specific function:

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

local MongoDB database, and all services connect to the core to get their settings

• Collector receives events from external sources and pre-processes them: normalizes
(transforms into a single format), filters, aggregates and enriches with data from external
PI

sources

• Correlator processes already normalized events from collectors and applies correlation rules to
CO

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
BE

explicitly through the web interface, or implicitly through a dashboard widget, report or
retroscanning task. At the technical level, the storage is a ClickHouse cluster that uses the
ClickHouse Keeper component to coordinate interaction between the nodes.
TO

In addition to other services, there are also KUMA agents for Windows and Linux.

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

correlator and storage A KUMA agent for Windows can collect events in one of the following
modes:
NO

8
 Chapter 1. General KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
• WEC mode, when the agent collects events from the log of the device where it is installed

• WMI mode, when a single agent collects Windows events over the network from multiple
devices

BU
• ETW mode, when the agent receives events from the ETW session locally

• File mode, when the agent receives events from a file

RI
We will describe the process of collecting events from Windows Event Log in detail in one of the
following sections.

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

DI
Additionally, KUMA agents for Linux and Windows can relay events or split data flows within the

RE
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.
OR
KUMA architecture (simplified)
ED
PI
CO
BE
TO

Let’s consider data flows in Kaspersky Unified Monitoring and Analysis Platform.

Kaspersky Unified Monitoring and Analysis Platform primarily receives events from external sources.
It supports multiple sources and event formats: NetFlow from network hardware, Windows events,
T

events from security tools such as Kaspersky Security Center or Kaspersky Anti Targeted Attack
NO

Platform and others.

9
 Chapter 1. General KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
Kaspersky Unified Monitoring and Analysis Platform can listen for events in different formats on the
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

BU
the online help at https://support.kaspersky.com/help/KUMA/3.2/en-US/217776.htm

Collectors receive events from external sources (alternatively, an active collector can retrieve events

RI
from 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 even for data of the same type (for example, CEF or syslog) that come from different

ST
sources. This will simplify configuration and troubleshooting.

Collectors are installed on a Linux operating system. You can install multiple collectors on a single

DI
server, or allocate a separate server to each collector. When a collector receives data, it converts it
into the CEF format, which is the internal data format in Kaspersky Unified Monitoring and Analysis

RE
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.
OR
The collector can also filter data and discard what the administrator or analyst consider to be
uninteresting and undeserving of processing and storage.

The collector can aggregate events, meaning, replace a group of similar events with a single event
ED

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

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:
CO

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

• 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 this account from Active Directory
TO

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

• Kaspersky CyberTrace — a collector can query the local cyberthreat intelligence platform in a
similar manner and supplement events with data from matching indicators of compromise
NO

10
 Chapter 1. General KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
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 and use them to convert or supplement events. For example, you can use a dictionary to

BU
replace or supplement numerical event codes with text descriptions.

Normalized and enriched events output by the collector are named base events. The collector mirrors

RI
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

ST
along with the normalized event.

The correlator’s task is to find relationships between events that are important from the security point

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

RE
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 the configured response rules are triggered. For example, you can configure the
OR
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.
ED

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
PI

will be searchable similarly to base events.

All services exchange data with the core, from which they receive their settings. All changes that we
CO

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

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
TO

online help at https://support.kaspersky.com/help/KUMA/3.2/en-US/217973.htm

T
NO

11
 Chapter 1. General KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
Speaking of architecture, we should mention the Event Router service. Collectors usually send events
to the correlator and storage in two streams. In specific cases, a collector may have even more than
OR
two destinations. This can become a bottleneck if the collector is located behind a thin channel in
relation to the destination points. Each destination also requires a separate port to be opened on
firewalls. The Event Router service permits keeping collected data within a single stream as long as
possible and forking it later. Events are sent in internal format to the API port of event router.
ED

Data in KUMA
PI
CO
BE
TO
T
NO

At different stages of event processing, it makes sense to talk about different types of events in

12
 Chapter 1. General KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
Kaspersky Unified Monitoring and Analysis Platform:

• At the beginning, collectors receive initial (raw) events

BU
• The collector processes them and outputs normalized events

• Normalized events made from raw events are named base events

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

ST
• A correlator processes events by applying correlation rules to them. When a rule is matched,
the correlator creates a so-called correlation event

• Additionally, Kaspersky Unified Monitoring and Analysis services can generate audit events

DI
about their status changes

• There are also monitoring events that show that an event source has stopped generating

RE
events or, conversely, the stream has increased abnormally

• Base, aggregated, correlation, audit and monitoring events are all normalized and you can
search the database for events of a particular type
OR
Services process events in streaming mode in real time and save them to the storage for further
analysis, search or retrospective correlation.

In addition to events, Kaspersky Unified Monitoring and Analysis Platform deals with the following
ED

types of objects:

• Assets represent the organization’s computers. An analyst can organize assets into categories
PI

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
CO

them manually if necessary

• Accounts — the core imports information about accounts from the specified LDAP server; you
can use this data for filtering and correlation
BE

• Dictionaries contain information in the key-value format or in a table; you can use it to configure
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
TO

• GeoIP — you can upload a database of IP addresses with the respective geographical data
(country, region, city, longitude, latitude) into KUMA

• Settings are organized as so-called resources (connectors, normalizers, filters,

correlation/aggregation/enrichment rules, and others) and are used to configure services
T
NO

Assets, accounts, all settings and resources are stored on the core server in a local MongoDB

13
 Chapter 1. General KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
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.

BU
Report templates and dashboard layouts are also stored in MongoDB.

Another database, a VictoriaMetrics time series database, stores Prometheus metrics on the core.

RI
Prometheus is a monitoring system that collects metrics from the specified endpoints. The Grafana

ST
solution visualizes metrics in the KUMA interface.

The last element in this diagram is the storage where our SIEM system sends events. Technically,

DI
events are stored in a ClickHouse database in KUMA. ClickHouse is an open source column-oriented
DBMS developed by Yandex.

RE
Storing data in ClickHouse
OR
ED
PI
CO
BE

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
TO

now), to which the KUMA system writes incoming events for storage.

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
T

ClickHouse, meaning, it acts as a connector between KUMA and ClickHouse.

NO

14
 Chapter 1. General KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
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

BU
outdated events from the ClickHouse database when their retention period expires (this period is also
one of the settings of the storage service).

RI
Storing data in ClickHouse: sharding and replication

ST
DI
RE
OR
ED

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,
PI

accordingly, only one Storage service.

CO

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

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

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).
T

When new data are written to the database, they are distributed among all shards according to a
NO

15
 Chapter 1. General KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
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

BU
shards to balance the load and optimize performance.

There can be any number of shards, starting from one; it depends on the database operation

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

ST
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

DI
breakdown of a server with a single replica may mean that all data stored on the shard will be lost. To
ensure high availability, create several replicas per shard.

RE
In our diagram, each replica rectangle (replica-1, replica-2) represents a separate physical or virtual
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.
OR
Meaning, a shard is a logical entity, while replicas are servers with ClickHouse installed that are
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
ED

database.

ClickHouse Keeper is a ClickHouse database coordination service for data replication and distributed
querying; it can also be deployed as a cluster.
PI

There must be an odd number of keepers to avoid the split-brain problem: 1, 3 or 5 (typically, 3
CO

keepers are used). ClickHouse Keeper services can be installed either on separate or on the same
servers as the 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
BE

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.

For more information about ClickHouse, refer to its official documentation.

TO

KUMA configuration principles

T
NO

16
 Chapter 1. General KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
Kaspersky Unified Monitoring and Analysis Platform consists of several interacting services: core,
collector, correlator and storage, and also services of the agent that collects Windows events.
OR
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
ED

converting data, and so on.

Resources are simply sets of parameters that are stored as JSON structures in the core database.
When a service starts, it sends a request to the core service and receives its settings in response.
PI

The core reads its own settings from the database directly.
CO

The advantage of such an organization is that each resource has its clear and specific purpose and a
very small set of parameters.

For example, a connector resource consists of an address, port and protocol; it also describes the
BE

low-level format of data that comes from a source (encoding and delimiter between the events).

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
TO

(aggregation rules) and which events to enrich (enrichment rules). The storage and correlator
addresses (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
T

different correlation rules or even rules of other types (enrichment, aggregation).

NO

17
 Chapter 1. General KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
Kaspersky Unified Monitoring and Analysis Platform has the following resources:

• Connectors set network parameters for receiving data from external sources or connecting to

BU
external sources; they also describe high-level parameters for parsing events, such as
encoding, delimiter and others. Collectors use connectors to extract raw events

• Normalizers are complex configurations for converting raw events to normalized events. The

RI
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

ST
correlation rules or to selectively apply enrichment, aggregation or response

• Aggregation rules describe how to replace multiple similar events with a single joint event.

DI
They are used in collectors

• Enrichment rules specify how to add new information fields to events: either by converting

RE
available fields or by requesting data from external systems. Enrichment is used in collectors
and correlators

• Correlation rules enable correlators to detect correlations. Correlation rules use filters to pick
out events
OR
• 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
ED

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

correlators

• Dictionaries are static key/value sets that can be used in filtering conditions and enrichment
CO

rules

• Secrets include user names, passwords and sometimes certificates for authentication in
external systems. They are used in global settings and connection resources
BE

• 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
Industrial CyberSecurity for Networks. Responses are used in correlators
TO

• 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
settings and connection resources
T
NO

18
 Chapter 1. General KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
Formally, services do not pertain to resources, but in reality, services are also a kind of resources that
use other resources.

BU
Hardware requirements

RI
ST
DI
RE
OR

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
ED

is usually measured in events per second (EPS).

During the load tests, Kaspersky Unified Monitoring and Analysis Platform successfully processed a
PI

stream of 500K EPS; and the bottleneck was the speed of the collector’s network interface card rather
than the computing platform.
CO

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:

• Types of processed events. Events of different formats may require different amount of
BE

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
TO

rules before using them in the production environment. Quite often, the same aim can be
achieved in several different ways and testing helps find the most efficient one

A pilot rollout enables you evaluate resources more accurately. However, resource consumption may
T

change over time as a result of a reconfiguration or adding correlation rules.

NO

19
 Chapter 1. General KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
To process a 10K EPS stream, it is usually enough to install the core, collector and correlator on a
single server and allocate another server for the storage.

BU
The product team has a sizing guide with approximate server specifications for typical EPS streams in
an 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

RI
needed.

The figures show several load examples.

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

DI
Storage presumes replication in this case.

In total, you need to allocate 5 servers with adequate hardware if you deploy keepers on the storages

RE
and on the core.
OR
ED
PI
CO
BE

To process a data stream of 50K EPS, we recommend that you add another collector and thus
allocate 8 adequate servers in total, taking into account storage replication; keepers can coexist with
other roles.
TO
T
NO

20
 Chapter 1. General KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
Data volume depends on the intensity of the event flow, the amount of data in each event, the
retention period, and the number of replicas in the storage cluster.
OR
To estimate the resources required for a particular workload, partners should contact their manager at
Kaspersky, and Kaspersky employees can contact the product team.

How and where EPS is counted

ED
PI
CO
BE
TO
T

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
NO

21
 Chapter 1. General KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
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.

BU
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

RI
limit by more than 30%, the administrator will be notified by email, and the same notification will
appear in the interface.

ST
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
resources and services. Running services will keep going, but if you need to restart something, you

DI
will not be able to start the service without a new license.

RE
OR
ED
PI
CO
BE
TO
T
NO

22
 Chapter 2. Deployment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
Chapter 2. Deployment
In this chapter, we will talk about Kaspersky Unified Monitoring and Analysis Platform installation

BU
options 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

Kaspersky Unified Monitoring and Analysis Platform supports two installation modes:
PI

• 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

CO

combinations

It is better to evaluate system requirements for a distributed installation based on the results of a pilot
rollout and recommendations of the product team, depending on the intensity of the incoming event
BE

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 3.2 supports:
T

• Ubuntu 22.04 LTS

NO

23
 Chapter 2. Deployment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
• Oracle Linux 8.6, 8.7, 9.2, 9.4

• Astra Linux Special Edition 1.7 or later

BU
An all-in-one installation is intended for demonstration purposes and fits small organizations; the
following configuration is recommended for it:

RI
• Processor with 4 (or more) processing cores (if HyperThreading is used, each thread is
considered as a core)

ST
• at least 8GB of RAM

• at least 100GB of hard drive space

DI
• 100Mbps (or higher) network interface

The web interface supports the following browsers:

RE
• Google Chrome 110 or later

• Mozilla Firefox 110 or later

OR
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.
ED

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, run the
PI

hostnamectl status command. By default, all connections between the services are encrypted with
certificates that the Kaspersky Unified Monitoring and Analysis Platform Core issues for the FQDN
CO

addresses of the servers where services (collectors, correlators, storages) run.

More information about system and hardware requirements is available in the online help at
https://support.kaspersky.com/help/KUMA/3.2/en-US/217889.htm
BE

The online help also describes prerequisites. For example, Python 3.6 or higher must be installed in
the system, and SELinux must be disabled. https://support.kaspersky.com/help/KUMA/3.2/en-US/
231034.htm
TO

2.1. All-in-one installation

T
NO

24
 Chapter 2. Deployment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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.
OR
Then you will need to perform a few simple steps that depend on KUMA installation mode.

For an all-in-one installation:

ED

• Prepare an Ansible inventory file

Edit the single.inventory.yml.template file included with the distribution. 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 4 collector services with default normalization
rules for popular event sources, a correlator service and a storage service. The default value of
BE

the deploy_example_services variable in the single.inventory.yml.template is true.

• Copy your Kaspersky Unified Monitoring and Analysis key file to the folder /kuma-ansible-
installer/roles/kuma/files/ and rename it license.key. A key file usually has an alphanumeric
TO

name that must be changed to license.key. Otherwise, the installation will return an error
informing that the license.key file was not found in the installer folder

• Run the install.sh script with the name of the prepared Ansible yml file as a parameter, for
T

example:
NO

25
 Chapter 2. Deployment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
./install.sh single.inventory.yml

Then accept the license agreement, after which the script will install all product components

BU
according to the parameters specified in the yml file.

2.2. Distributed installation

RI
ST
DI
RE
OR
ED

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

by-step instructions are as follows:

• Generate an ssh key to authenticate the installer on all target hosts. Command example:
CO

ssh-keygen –N “”

• Copy the public ssh key to all servers where Kaspersky Unified Monitoring and Analysis
BE

Platform components will be installed (core, collector, correlator, storage nodes). Command
example:
TO

ssh-copy-id –i /root/.ssh/id_rsa root@<hostname>

• Prepare an Ansible inventory file for a distributed installation: edit the

distributed.inventory.yml template file included with the distribution. In the file, specify the
T

FQDN and IP address of the target server for each component (core, storage, collectors and
NO

26
 Chapter 2. Deployment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
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. In our diagram, we have a two-node ClickHouse cluster

BU
(kuma-storage1.abc.lab and kuma-storage2.abc.lab), these are two replicas of a single shard,
meaning, a high-availability configuration. The storage is controlled by ClickHouse Keeper
services; there should be an odd number of them, 3 or 5, in such a configuration.

RI
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

ST
server.

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

DI
dedicated servers, because the system response time is important for them.

RE
• Copy your Kaspersky Unified Monitoring and Analysis key file to the /kuma-ansible-
installer/roles/kuma/files/ folder and rename it license.key

• Run the install.sh script with the name of the prepared Ansible yml file as a parameter, for
example:
OR

./install.sh distributed.inventory.yml

Then accept the license agreement, after which the script will connect to other servers, copy
ED

files there, and install components in accordance with the parameters specified in the yml file.

Sharding and replication in ClickHouse

PI
CO
BE
TO
T
NO

27
 Chapter 2. Deployment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
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.

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

RI
The first configuration example: 1 four-replica shard

Advantages:

ST
• The most reliable way to store data (4 copies)

DI
Shortcomings:

• This amount of stored data copies is rather excessive in most cases

RE
• Since there is only one shard in this configuration, a SELECT query cannot run in parallel on
different nodes

• Additional resources are required for multiple replications of data between all nodes
OR

Second configuration: 4 one-replica shards

Advantages:
ED

• In this configuration, a SELECT query can run in parallel on all 4 shards.

Shortcomings:
PI

• The least reliable way to store data (if a node malfunctions, part of data will be lost).
CO

Third configuration: 2 two-replica shards

• Takes the best from both previously described configurations.

• In this configuration, a SELECT query can run in parallel on 2 cluster shards.

BE

• A fairly reliable way to store data (if a cluster node malfunctions, data will not be lost).
TO
T
NO

28
 Chapter 2. Deployment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
Starting with version 2.1, KUMA has High Availability mode. High availability is achieved by installing
Core on a Kubernetes cluster. A special distribution is used for installation: kuma-ansible-installer-ha-
OR
2.1.0.XXX.tar.gz. The cluster is configured in the Ansible inventory file.

It is important to understand that only the Core service along with mongodb, victoria-metrics, grafana
and vmalert are installed on Kubernetes. Therefore, it makes no sense to install the other KUMA
ED

services (storage, collector, correlator) on the same host.

These services can be successfully installed on the host, but outside the Kubernetes cluster; and if
the host malfunctions, Core will fail over automatically, while other services will not.
PI

Deployment of all components on the same host is recommended for demonstration

CO

purposes only.
BE
TO
T
NO

29
 Chapter 2. Deployment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
A high-availability KUMA configuration in a production environment will most likely look like the
diagram in the slide above.
OR
There are 2 node roles in Kubernetes:

• Control Plane fulfills most of the cluster management and administration tasks, stores
metadata and distributes the workload
ED

• Worker nodes run workloads, that is, host KUMA processes

A pod is an abstraction in Kubernetes that manages a group of application containers and shared
PI

resources. Containers run as a single unit in a pod.

CO

Each pod is scheduled to a worker node where it remains until termination or deletion. In case of a
worker node failure, identical pods are scheduled on other available nodes in the cluster.

The following KUMA services run in a dedicated pod, each service in a dedicated container:
BE

• core

• mongodb

• victoria-metrics
TO

• grafana

• vmalert
T

All other services run outside the Kubernetes cluster. The Storage cluster is organized using
NO

30
 Chapter 2. Deployment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
ClickHouse tools. A load balancer is located between the Kubernetes cluster and the other KUMA
services. During installation, KUMA can automatically configure nginx as a balancer. The balancer
handles KUMA core traffic (ports 72XX) and the service traffic of the cluster (ports 6443, 9443, 8132).

BU
KUMA traffic goes from external services (storage, collectors, correlators) to worker nodes and in the
reverse direction.

RI
You can find more details in the Kubernetes documentation

• https://docs.k0sproject.io/v1.24.6+k0s.0/high-availability/

ST
• https://docs.k0sproject.io/v1.24.6+k0s.0/networking/?h=net

DI
RE
OR
ED
PI

There is a native k0s application for managing a Kubernetes cluster, but the best option is to use the
CO

k9s application that provides a graphical interface.

You can download the current version from github https://github.com/derailed/k9s/releases

BE

In general, you can install a binary file on a Linux system as follows:

cd /tmp/
curl -L
https://github.com/derailed/k9s/releases/download/v0.27.3/k9s_Linu
TO

x_amd64.tar.gz | tar zx
sudo mv k9s /usr/bin

You must run k9s together with a configuration file with the Kubernetes cluster connection settings.
T

The k0s-kubeconfig.yml file is created in several places:

NO

31
 Chapter 2. Deployment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
• On the host where the kuma-ansible-installer/artifacts/k0s-kubeconfig.yml installer was run

• On the main Control Plane node in the home directory of the user specified in the inventory file
as ansible_user, /root/k0s-kubeconfig.yml by default

BU
It is best to use the following command to export the path of k0s-kubeconfig.yml to a variable:

RI
export KUBECONFIG=/root/k0s-kubeconfig.yml

ST
Then you will be able to run k9s without parameters.

You can view and manage services from the interface. In KUMA Pod, you can see which containers
are running; you can also view the logs of each specific service here.

DI
2.3. Web console

RE
OR
ED
PI
CO

The installation takes a few minutes. When it completes, you can manage Kaspersky Unified
BE

Monitoring and Analysis Platform through its web interface at https://<FQDN of the server running the
core service>:7220

After the installation, Kaspersky Unified Monitoring and Analysis Platform has only one administrator
TO

account:

• Username: admin
T

• Password: mustB3Ch@ng3d!
NO

32
 Chapter 2. Deployment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
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.

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
ED

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
PI

• Alerts — this is where you deal with correlation alerts

• Incidents — a section for working with incidents. In Kaspersky terms, an incident is a

CO

confirmed alert. You can create an incident from an alert automatically or manually and link
several alerts to it if necessary

• Events — the page for manually searching and analyzing events in the database and for re-
analysis of historical events by retrospectively applying correlation rules
BE

• Assets — the page for managing your organization’s computers (assets) where you can import
computers from Kaspersky Security Center, add them manually and organize into categories

• Reports — you can configure the reports’ appearance and generation schedule here. Report
TO

templates consist of the same layouts and widgets as the Dashboard

• Resources — this section consists of two parts:

◦ Services — this is the page for configuring and managing Kaspersky Unified Monitoring
T

and Analysis Platform services: collectors, correlators, storage and Windows agents.
NO

33
 Chapter 2. Deployment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
You can create new service configurations and reload settings or restart services

◦ Resources — you can configure resources necessary for service configurations here

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

RI
Center, LDAP account importing requests, Kaspersky Threat Lookup requests, export of events
from the ClickHouse database, retroscanning and some other activities. Tasks are created

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

• Settings — the global settings of Kaspersky Unified Monitoring and Analysis Platform, in

DI
particular, license management, user and role settings, tenant settings, integration with
Kaspersky and third-party solutions and systems, etc.

RE
• Sources status — this section displays the list of sources that send data to collectors; you can
apply policies to sources and monitor their statuses

• Metrics visualize Prometheus data about the load and status of Kaspersky Unified Monitoring
OR
and Analysis Platform services
ED
PI
CO
BE
TO

Let’s talk a bit about resources in KUMA. Most of the KUMA settings are configured as resources. For
example, to create and install a collector or correlator service, you must create the appropriate
configuration as a resource.
T
NO

34
 Chapter 2. Deployment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
In addition to services, KUMA has many other elements that are stored as different types of
resources, such as secrets, normalizers, correlation rules, active lists, and others. All these are also
OR
resources that can be saved, reused, imported and exported. In a sense, resources define the KUMA
operation logic.

2.4. Installation results

ED
PI
CO
BE
TO

As a result of installation with the deploy_example_services = true parameter, the following services
T

are created in the Ansible inventory file:

NO

35
 Chapter 2. Deployment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
• Core (the kuma-core service), which uses the following ports:

◦ 7220/tcp to receive connections to the web console

BU
◦ 7210/tcp to receive connections from other KUMA services

◦ 7223/tcp to receive API requests

◦ 7222/tcp to organize a reverse proxy for Kaspersky CyberTrace (this functionality

RI
becomes available when you configure integration with Kaspersky CyberTrace)

• [OOTB] CEF collector uses the following ports:

ST
◦ 7232/tcp to receive connections from the core service

◦ 5140/tcp to receive data from external sources

DI
• [OOTB] KSC collector uses the following ports

RE
◦ 7233/tcp to receive connections from the core service

◦ 5141/tcp to receive data from external sources

• [OOTB] Syslog collector uses the following ports

OR
◦ 7234/tcp to receive connections from the core service

◦ 5140/udp to receive data from external sources

• [OOTB] Syslog-CEF collector uses the following ports:

ED

◦ 7235/tcp to receive connections from the core service

◦ 5144/udp to receive data from external sources

PI

• [OOTB] Correlator uses the following ports:

◦ 7230/tcp to receive connections from the core service and events from the collector
CO

• [OOTB] Storage uses the following ports:

◦ 7231/tcp to receive connections from other services, including the core

◦ 2181/tcp, 2182/tcp for interactions between ClickHouse and ClickHouse Keeper and
BE

internal interactions between the ClickHouse Keeper nodes

◦ 9000/tcp, 9009/tcp for inter-node communications in ClickHouse (replications,

distributed queries)
TO

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

The installation wizard creates rules for ports in the server’s firewall.
NO

36
 Chapter 2. Deployment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
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.

BU
Full and up-to-date information on ports is always available in the online help at
https://support.kaspersky.com/help/KUMA/3.2/en-US/217770.htm

RI
ST
DI
RE
OR

If deploy_example_services = false, the list of active services is empty after the installation.
ED

However, there are service templates that simplify manual installation; click the Add service button
and then install the necessary service (daemon) on the respective KUMA server.
PI

For example, start with Storage services, then proceed to the Correlator and then to Collector; if
necessary, add services of Windows and Linux Agents.
CO

In our labs, we demonstrate a distributed installation so that the participants can better and quicker
understand the architecture of Kaspersky Unified Monitoring and Analysis Platform and see for
themselves that creating services manually is not difficult.
BE
TO
T
NO

37
 Chapter 2. Deployment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
Starting with KUMA version 2.1, the Reload button was renamed to Update configuration; we click it
to update service configuration after modifying it. The Log button downloads the log of the
OR
corresponding service. The logs are located in the following directories:

• /opt/kaspersky/kuma/storage/<ID>/log/storage

• /opt/kaspersky/kuma/collector/<ID>/log/collector
ED

• /opt/kaspersky/kuma/correlator/<ID>/log/correlator

The Status column shows the service status. In addition to the On and Off statuses, other statuses
PI

may be displayed there, indicating that, for example, a configuration update or restart is required, or
that there is an error in the service log. You will see this in the labs. Understanding the state of each
CO

service is very important to ensure the correct operation of the entire KUMA system.
BE
TO
T
NO

38
 Chapter 2. Deployment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
KUMA updates out-of-the-box resources automatically, which means that new correlation rules,
normalizers, connectors and other resources become available to users soon after they are published
OR
on the update servers.

This is configured in Settings | Repository update; the default update schedule is every 24 hours.
After the task completes, the number of packages and the number of resources in the packages are
ED

displayed, and the administrator can import them into KUMA, for example, into the folder of the
Shared tenant, to make them available to all tenants.

Each resource has an ID in the MongoDB database; when you import an existing resource, KUMA will
PI

prompt you whether it is necessary to overwrite the existing one.

CO
BE
TO
T
NO

39
 Chapter 2. Deployment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
You cannot modify out-of-the-box resources in KUMA (regardless of their origin: built in or imported
from the updatable repository).
OR
The corresponding message is displayed on a blue background in the resource properties. This
prevents overwriting custom changes when new resources are imported. Resources would have the
same ID in this case, and it is impossible to track the revision history of each individual resource or
ED

compare versions.

To make any changes, copy the necessary resource and work with the copy.
PI

For example, you almost always have to modify connectors and normalizers, e.g. enable saving of
raw events or add some kind of transformation to the normalization scheme.
CO

2.5. Tenants and system components

BE
TO
T
NO

40
 Chapter 2. Deployment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
We will not describe multitenancy in detail in this course; we’ll just outline the concept.
OR
Multitenancy is a configuration aspect that you should keep in mind during the initial setup of the
services.

Tenant is a way to divide data access within an installation into several logical segments.
ED

In essence, an installation is the core around which all other services, collectors, correlators and
agents are organized.
PI

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).
CO

Each resource, service and event pertains to a tenant. It looks like a folder structure in the interface;
each 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
BE

tenant to each user individually.

For example, a user who has administrator rights in tenant-1 can create resources, edit settings, etc.
within it, but does not have any rights in tenant-2 and cannot even see it. A user who has operator
TO

rights can only search for events and create reports, but can neither create services or resources nor
modify settings.

At the same time, there are two special tenants: Main and Shared.
T
NO

The Main tenant is the principal tenant that is always created, even if the customer does not use

41
 Chapter 2. Deployment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
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
tenant.

BU
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,

ST
enrichment rules, etc. To avoid creating the same entities for each tenant, you can create them in the
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

DI
resources, but everyone can use them.

RE
If a lot of tenants (different organizations) use the same Kaspersky Unified Monitoring and Analysis
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.
OR
So, 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.
ED

2.6. Role-based access control and authentication

Users and roles

PI
CO
BE
TO
T
NO

42
 Chapter 2. Deployment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
Only one user who can access the web interface is created during an installation. This is the
Administrator user with the General admin role. This role has the highest access to all the settings of
OR
Kaspersky Unified Monitoring and Analysis Platform. When administrators grant access to a tenant to
an account, they select a user role for it. Each role has specific permissions (what is allowed and what
is prohibited), which cannot be changed. A role can be described as a set of actions that a user can
perform in the system.
ED

You can create a user account in Settings | Users. An account has the following settings:

• Name
PI

• Login
CO

• Email address for notifications

• Role in a tenant: administrator, analyst, operator. For example, a user can have the
administrator role in the London tenant and the operator role in the Bristol tenant
BE

• Password

• API access rights — you can explicitly specify what actions the user can perform via API

Users can change their own names, login names, email addresses and passwords. Users cannot
TO

change their own roles. Only the General admin 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.
T

The General admin can work with global settings that are not bound to individual tenants in Kaspersky
NO

Unified Monitoring and Analysis Platform. We are talking about performance metrics, users,

43
 Chapter 2. Deployment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
integrations with Threat Intelligence, IRP, etc. Only the General admin can create tenants.

To grant a user the General admin role, configure the respective option in the account properties.

BU
User privileges

Generally, the roles differ as follows:

RI
• General admin has the highest possible privileges in KUMA

ST
• Tenant administrators can do anything within their tenant, for example, change or delete
entities (such as report templates) created by other users

• The Tier 2 Analyst role is intended for users responsible for configuring the KUMA system to

DI
receive and process events from a specific tenant. They also create and configure correlation
rules.

RE
• The Tier 1 Analyst role is intended for users responsible for configuring the KUMA system to
receive and process events from a specific tenant. They also create and configure correlation
rules. Users with this role have fewer rights than a tier 2 analyst.
OR
• The Junior Analyst role is intended for users who work with security threats of a specific
tenant. A user with this role can use resources of the shared tenant via REST API.

• The Access to shared resources role is intended for working with the shared tenant. Users
ED

with this role have read permission on shared resources. Only a user who has the General
admin role can edit resources in the shared tenant.

All permissions are listed in the documentation at https://support.kaspersky.com/kuma/3.2/218031

PI

Domain authorization and authentication

CO
BE
TO
T
NO

44
 Chapter 2. Deployment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
In Kaspersky Unified Monitoring and Analysis Platform, you can configure integration with AD to
enable users to authenticate under their domain accounts.
OR
ED
PI
CO
BE

You can specify an AD group in the role properties in Kaspersky Unified Monitoring and Analysis
TO

Platform. If an account belongs to several groups that have different roles in a tenant, it receives the
role with the least permissions.
T
NO

45
 Chapter 2. Deployment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
KUMA supports integration with ADFS and FreeIPA. ADFS extends domain authentication. If the
ADFS service is configured in the domain, you can enable Single Sign-On on the KUMA side and log
OR
on to the KUMA web console as a domain user.

To do so, create a connection group and configure rules in the ADFS Management Console, then
copy the group ID, Web API ID, ADFS server address and KUMA web console address. If everything
ED

is configured correctly, the ‘Sign in via ADFS’ option will appear on the KUMA logon page.

FreeIPA is an integrated identity and authentication solution for Linux networked environments, a
counterpart of Microsoft Active Directory.
PI

KUMA has only one connection for domain authentication, which means that you can use either AD or
CO

FreeIPA.
BE
TO
T
NO

46
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
Chapter 3. Event collecting and processing
3.1. Collecting events

BU
In this section, we will study how events are collected, which connectors are available in Kaspersky
Unified Monitoring and Analysis Platform, and what is the difference between connectors and

RI
collectors. You will also learn when KUMA agents for Windows and Linux come in handy.

KUMA services: ports and connections

ST
DI
RE
OR
ED
PI

Let’s take a closer look at the services’ interaction.

CO

Each service has a so-called API port for technical communications within Kaspersky Unified
Monitoring and Analysis Platform.

Collector, correlator and storage services receive their settings in response to requests that they send
BE

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 its settings or restart the service. It is the administrator who initiates commands via the web
TO

interface.

First of all, SIEM obtains events from external sources and normalizes them, thus simplifying
correlations, storage and manual analysis.
T

Collectors are responsible for this in Kaspersky Unified Monitoring and Analysis Platform. A collector
NO

47
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
can 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 source’s port. The administrator configures what port to listen on or what address and

BU
port to query using 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

RI
default) to retrieve its settings and find out which port to listen on or where to send requests. An
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.

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

DI
The collector usually sends processed (normalized) events to the correlator and to the storage

RE
concurrently. By default, the correlator listens for events on port 7231/tcp, and the storage listens on
port 7230/tcp.

Collector settings
OR
ED
PI
CO
BE

Events undergo several processing stages in the collector (see the diagram):
TO

• Individual events are first extracted from the incoming data

• Then the events are converted to CEF (Common Event Format); this process is named
normalization
T
NO

48
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
• Next, uninteresting (from the organization’s point of view) events are filtered out

• Then a group of similar events can be aggregated into a single event with collective
characteristics

BU
• And finally, events are enriched using the core database (dictionaries, GeoIP, KSC, LDAP) and
requests to external systems (DNS, Threat Intelligence)

RI
Steps of the collector setup wizard correspond to event processing stages:

ST
• Transport — specify the connector responsible for extracting individual events

• Event parsing — specify the normalizer that will convert events to CEF format

DI
• Event filtering — specify the filtering rules with conditions that will select ‘interesting’ events

• Event aggregation — specify the aggregation rules

RE
• Event enrichment — specify the enrichment rules

Processed events are usually forwarded to the correlator and storage in two independent streams.
The Routing area of the collector settings defines this behavior.
OR
Let’s now study collector settings in the order of applying.

Connector
ED
PI
CO
BE
TO

A connector is a resource that describes how to retrieve messages from a particular source.
T

The connector can be passive, i.e. listen to some port to which active sources send data, or active,
NO

49
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
and then the connector itself connects to passive sources (database, reading from a file, etc.) to
retrieve data.

BU
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

RI
principle. Everything that is saved as resources can be used as building blocks in various service
configurations. When a resource is modified, the new settings will be used in all services that work
with this resource.

ST
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

DI
other services.

RE
Connection settings
OR
ED
PI
CO
BE

Connector settings depend on its kind. Kaspersky Unified Monitoring and Analysis Platform permits
creating the following connectors:

• tcp, udp, http, netflow, sflow describe how to receive data from active external sources
TO

• 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

T

• diode describe how to collect events from an isolated network segment. In this scheme, KUMA
NO

50
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
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

• wec, wmi — describe how to collect Windows logs (locally or remotely)

BU
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

RI
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 number. This is an abbreviation of 0.0.0.0:5141, which means that the service will accept

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

DI
In connections designed for requests to external systems (sql, ftp, nfs, smtp, kafka, nats), the URL
field is essential: without it, the service will not know where to connect.

RE
A file connection allows you to specify a folder and mask of files from which data will be retrieved.
OR
ED
PI
CO
BE

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
TO

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
T

to, and in the groupID field, specify an identifier (any) for this connector that it will use to
‘present’ itself to Kafka
NO

51
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
• nats connector: in the subject field, specify the subject to subscribe to

• wec connector: in the windows logs field, specify names of the logs from which events will be
collected

BU
• wmi connector: in the remote hosts field, specify addresses of remote hosts from which events
will be collected; you will also need to specify accounts and log names

RI
A detailed description of all parameters in different types of connectors is available in the online help
at

ST
https://support.kaspersky.com/help/KUMA/3.2/en-US/233592.htm

DI
In addition to the main parameters, there are additional parameters that are the same for most
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),

RE
data compression using the Snappy utility to reduce network transmission overhead, and writing
debugging information to journalctl.

Receiving Windows events

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
respective collector.
PI

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
CO

administrator can remotely reload the agent’s settings or restart its service.
BE
TO
T
NO

52
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
The KUMA agent can collect events from the local Windows Event Log; in this case, a WEC
(Windows Event Collector) connector is used.
OR
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
ED

technically feasible).

What to do if there are thousands of computers on the network? The following options are possible:
PI

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

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
BE

and configure it to fetch events from the Forwarded Events log

• Install the KUMA agent with a WMI (Windows Management Instrumentation) connector on a
dedicated computer.
TO
T
NO

53
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
An agent with a WMI connector can remotely connect to other computers and pick up events from
their logs.
OR
ED
PI
CO
BE

When installed on a Windows OS, KUMA Agent can read text files and transfer data to a KUMA
TO

collector. A single agent installed on a Windows server can report data from Windows Event logs and
text log files. For example, you will no longer need to use network folders to get Exchange Server
transport logs, IIS logs, etc. To configure reading events from a file, select the file connector. One line
of a file is treated as one event. Line delimiters: \n.
T
NO

A Windows agent also has another connector type: ETW (Event Tracing for Windows). This connector

54
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
has a specific task: it receives events from the Microsoft-Windows-DNSServer {EB79061A-A566-
4698-9119-3ED2807060E7} provider. KUMA Windows agent uses the ETW transport to retrieve an
extended DNS log, diagnostic events, and analytical data about the operation of the DNS server. This

BU
provides much more information than the DNS debug log, with less impact on DNS server
performance.

RI
After the KUMA agent for Windows has received events, it forwards them to the collector for
processing.

ST
Windows agent

WEC connector

DI
RE
OR
ED
PI
CO

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.

If you create a KUMA agent with a WEC connector, its main setting is the Windows logs field; list the
BE

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

Windows-Sysmon/Operational.

WMI connector
T
NO

55
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
If you create a KUMA agent with a WMI connector, the main settings are Default credentials and
Remote hosts.
OR
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 area, list addresses of the target remote computers, then add an individual list
ED

of logs for each host and specify an account. You can use the account from the Default credentials
field or another one. This information can only be specified manually.
PI

The account is added as a Secret resource of Credentials kind, meaning, a login and password that
are stored in the MongoDB database on the core in an encrypted form.
CO

ETW connector
BE
TO
T
NO

56
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
You need to set up a session on the DNS server in advance. An ETW connector can only work locally,
i.e. the agent must be installed on the server where the DNS service is running. This connector can
OR
receive events from one provider only: {EB79061A-A566-4698-9119-3ED2807060E7} -
Microsoft‑Windows‑DNSServer.
ED
PI
CO
BE
TO

We’ve studied the Connector section, i.e. how the KUMA agent will get events.

Now let’s look at the Destination section that describes where to send the collected data. Specify the
T

address, port and protocol of the collector that will receive data from the agent.
NO

57
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
There can be several destinations; i.e. a single KUMA agent can copy the stream into several
collectors, for example, to process different types of events in different collectors.

BU
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, buffer size, the number of worker processes, compression, debugging, and others.

RI
KUMA agent for Windows is quite demanding in terms of delimiter and encryption settings. It is
important that the same delimiter is specified in the Destination section of the agent and in the

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

DI
A template of KUMA agent for Windows is available among the preset resources.

Windows agent service

RE
OR
ED
PI
CO

When the KUMA agent configuration is ready, publish the agent service. In the Active services
BE

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
TO

service on a remote computer. The red status means that the KUMA agent service is not running on
any remote computer.
T
NO

58
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
A published service receives a unique identifier that the KUMA agent uses to retrieve its settings.
Copy this identifier (click the Copy ID button) and use it as an installation parameter when deploying
OR
KUMA Windows agent.

Services of other types (collectors, correlators, repositories) are created in a similar manner. When
creating a service, the administrator performs the following steps:
ED

• Creates a configuration for the service

• Publishes the configuration on the list of services and gets a unique identifier for the new
PI

service

• Installs the service on a Linux system and binds it to the published configuration using its
CO

unique identifier

To install the KUMA Windows Agent, use the kuma.exe file included with the Kaspersky Unified
Monitoring and Analysis Platform distribution; by default, it is located in the folder /kuma-ansible-
BE

installer/roles/kuma/files/

This is not an ordinary Windows installer, it is rather a utility for installing and managing the services of
KUMA agent for Windows.
TO

To register the KUMA agent as a service, run kuma.exe with the following parameters:

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
T

service permissions> --install

NO

59
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
The following command outputs the complete list of the utility capabilities:

kuma.exe --help

BU
In particular, this utility can display the list of installed agents (if there are more than one of them for
some reason) or uninstall an agent service (using its identifier).

RI
Notice 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

ST
seconds, and the core can send the restart or configuration reload command in response.

DI
RE
OR
ED
PI

As a result of the installation, an ordinary Windows service will be deployed. The executable file of this
CO

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

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
TO

the settings and will not know which logs to collect or where to send them.

Troubleshooting Windows agent

T
NO

60
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
If errors occur during the service installation, their description is usually clear enough to understand
what to do.
OR
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.

The process cannot access the file because it is being used by another process means that an agent
ED

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

The service did not start due to a login failure means that the account does not have the permission to
CO

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
BE

the service 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.
TO

In our example, the error The service did not respond to the start or control request in a timely 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.
T
NO

61
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
If the KUMA agent service has been successfully installed in the system, but events still do not arrive
to the collector service input, select the debug checkbox in the agent settings to record extended
OR
information. You can find errors in the KUMA agent log file C:\ProgramData\Kaspersky
Lab\KUMA\agent\<service ID>\agent.log

And the easiest way out is as follows:

ED

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

2. Run the KUMA agent in real time without the --install parameter
PI

3. Read the debugging information in the current session output on the command line and
monitor the collector at the same time
CO

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
BE

collector.

A few tips on what is important to pay attention to in step 3 so that events begin to flow into the
collector.
TO

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

62
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
If there are errors in the [connector …] lines, it means that the KUMA agent fails to retrieve Windows
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,

BU
or something else.

If there are errors in the [destination …] lines, it means that the KUMA agent has retrieved Windows

RI
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

ST
the same delimiter is specified in the Destination section of the agent settings and in the collector
configuration (for Windows events, the \0 delimiter must be used) and the same values are specified

DI
in the TLS mode field for the KUMA agent and collector.

Linux agent

Linux agent service

RE
OR
ED
PI
CO
BE

In addition to KUMA agent for Windows, there is also the KUMA agent for Linux. In terms of
installation, 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
TO

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 Analysis Platform distribution; by default, it is located in the /kuma-ansible-
T

installer/roles/kuma/files/ folder.
NO

63
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
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.

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

RI
ST
DI
RE
OR

Windows and Linux KUMA agents equally act as an intermediary between the source and collector.
ED

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
PI

to several collectors.
CO

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
BE

• 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 (on Windows and Linux)
TO

• wec, wmi, etw describe how to collect Windows events (work on Windows agents only)

In the connector settings, Auditd is a switch for a mechanism that groups auditd log event entries
received from the connector into a single event.
T

We have already talked about the Destination section, it describes where to send the collected data.
NO

64
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
Specify the address, port and protocol of the collector that will receive data from the agent.

Another example of using a KUMA agent is encryption. For example, there is some source that does

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

RI
Troubleshooting Linux agent

ST
DI
RE
OR
ED

Troubleshooting Linux agent is almost the same as with Windows agent.

PI

If Linux agent startup configuration is specified in Systemd, you can use the following command to
CO

monitor its status through the standard service manager:

systemctl status kuma-agent-<service identifier>.

BE

For diagnostics, you can consult the service log using journalctl or just stop the service and then
start:

sudo -u kuma <start command>

TO

In this case, the log will be output to the terminal.

T
NO

65
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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
OR
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
ED

really missing or 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.
CO

If there are no errors but events do not arrive to the collector, check whether the necessary ports are
open in the firewall on the Linux agent side, maybe events do not reach even the agent.

SQL connector
BE
TO
T
NO

66
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
Let’s take a closer look at another connector type, sql. It can connect to various SQL databases:
OR
• MSSQL

• MySQL

• PostgreSQL
ED

• SQLite3

• Oracle DB

• Firebird SQL
PI

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

• Identity column is the column to search for event identifiers

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

connector will save the value of the last read seed to ‘know’ which events it has already
retrieved and which are new

The Query field contains the SELECT statement to retrieve events from the database according to
T

the specified criteria.

NO

67
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
Connecting to the KSC database via the SQL connector

BU
RI
ST
DI
RE
Let’s find out how Kaspersky Unified Monitoring and Analysis Platform can retrieve Kaspersky
OR
Security Center events from its Microsoft SQL database.

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
ED

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
CO

when accessing the database directly.

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

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:
T

sqlserver://<domain>%5C<login>:<password>@<SQL server FQDN>/<SQL

instance name>?database=<database name>
NO

68
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
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 the secret, when you open it, the URL field will be empty, i.e. the password will no longer be

BU
displayed explicitly.

Therefore, to avoid re-typing the connection string when you need to change the password or just

RI
correct 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).

ST
The Secret separately switch lets you save credentials separately from the URL.

The syntax of the URL field for different types of databases is described in the online help at

DI
https://support.kaspersky.com/help/KUMA/3.2/en-US/220746.htm

RE
Troubleshooting an SQL connector
OR
ED
PI
CO
BE

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
following command:
TO

journalctl -f -u kuma-collector-ID

Pay special attention to the lines that begin with the prefixes [connector ‘…’] and [destination ‘…’]
T

Errors in the [connector …] lines will show whether it is possible to connect to the SQL database. The
NO

69
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
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.

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

RI
3.2. Normalization of events

ST
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 KUMA format.

DI
RE
OR
ED
PI
CO

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 original format to the KUMA format and save the field values accordingly. Moreover, the
BE

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.

The process of bringing all this together is named normalization or parsing. This is the most important
TO

process in the collector, because all other processes (filtration, aggregation, enrichment, correlation)
heavily depend on normalization.
T
NO

70
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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
OR
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
ED

describes 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).
PI

In a collector configuration, simply select a normalizer from the list.

CO

This stage is a must, a collector cannot exist without a normalizer. The round icon indicates that a
preset normalizer is available; click it to open its settings.

KUMA data model

BE
TO
T
NO

71
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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,
OR
file names and checksums, identifiers of processes, users and devices. If standard CEF fields are
insufficient, there are also special fields (for example, DeviceCustomString*) that an analyst can fill
with custom data. There are about 130 fields in total.
ED

KUMA adds its own fields that store the unique identifier of the event in KUMA (ID field), identifier of
the 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
PI

field), cyber intelligence data that can be obtained by CyberTrace enrichment (TI field), fields with
geodata, and others. There are about 40 fields in total.
CO

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/3.2/en-US/217941.htm

Types of normalizers
BE
TO
T
NO

72
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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
OR
Normalizer settings.

Normalizers have a type that depends on the parsing method, i.e. what input data we expect. A
collector can have only one main normalizer, meaning, you need to create a separate collector with
ED

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.

Events typically have one of the widespread formats. Kaspersky Unified Monitoring and Analysis can
PI

process the following data formats out of the box:

CO

• csv (comma-separated values) — you need to specify the delimiter between the values in the
normalizer

• kv (key-value pairs) — specify the delimiter between pairs and the delimiter within a pair in the
normalizer settings
BE

• xml

• json
TO

• sql (an SQL query result table)

• cef, syslog, netflow, ipfix, sflow

If incoming raw events have a standard format (CEF, syslog, NetFlow, IPFIX or SFlow), you can use
T

the built-in mapping settings available in KUMA.

NO

73
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
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.

BU
Kaspersky Unified Monitoring and Analysis Platform development plans include continuous expansion
of supported formats, built-in mapping and example mapping for widespread event sources.

RI
Extended KUMA data model

ST
DI
RE
OR
ED

You can create new fields in the KUMA data model. When creating a new field, add a prefix that
PI

indicates the data type to its name. The following data types are supported:
CO

• S. — string

• N. — number

• F. — floating-point number
BE

• SA. — array of strings

• NA. — array of numbers

• FA. — array of floating-point numbers

TO

Arrays can be used only in kv and json normalizers. A prefixmust be uppercase. In one of the course
labs, you will have the opportunity to extend the KUMA data model by creating a custom field.
T
NO

74
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
Field mapping

BU
RI
ST
DI
RE
The Mapping settings consist of a list of pairs: a source field – the field of the normalized KUMA
OR
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
CO

debugging the normalizer, you can set the Keep raw event parameter to Always.

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
BE

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 field. The Save extra fields option regulates this behavior. For example, there is an xml event
TO

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.
T
NO

75
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
Extra field

BU
RI
ST
DI
RE
The Extra field is a very powerful tool that can be used for normalization, correlation and search.
OR

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

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
JSONExtractString function for a granular search.
PI

And the most important feature of the Extra field is that you can leave it unnormalized and use field
values in the Extra.<name of a field inside Extra> format in correlation rules. For example, if you want
CO

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
BE

is no need to fully normalize Sysmon; instead, you can simply use values in the Extra field format.

Converting fields
TO
T
NO

76
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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.
OR
The following operations are available:

• lower — convert to lowercase

• upper — convert to uppercase

ED

• regexp — replace with the value of the specified regular expression

• substring — cut out a substring (you need to specify its initial and final positions)
PI

• replace — if the initial value contains the specified substring, replace it with the specified text

• trim — remove characters at the end

CO

• append — add the specified substring to the end of the value

• prepend — add the specified substring to the beginning of the value

• replaceWithRegexp — replace a matching group with the specified string

BE

• decodeHexString — convert a HEX string to text

• decodeBase64String — convert a Base64 string to text

TO

• decodeBase64URLString — convert a Base64url string to text

• entropy — transform the original field using an entropy calculation function

You can configure multiple transformations for the same value, for example, trim and convert to
T

lowercase.
NO

77
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
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.

BU
RI
ST
DI
RE
OR

The example shows that the original event contains an encoded command; if you apply the correct
conversion, this command will be displayed instead of the HEX string.
ED

Normalization depending on the source address

PI
CO
BE
TO
T

Typically, it is more convenient to create a separate collector service for each type of event source,
NO

78
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
but sometimes you may need one collector service to receive and normalize events from different
types of sources, for example, if you have too many collectors or you have a limited number of ports
that you can open on firewalls. This collector logic can be configured on the Parsing settings tab.

BU
You can specify source addresses and their corresponding normalizers there. This is convenient in
some situations, but it lowers performance.

RI
ST
DI
RE
OR
ED

This method is available for collectors with UDP, TCP, and HTTP connectors. If a UDP, TCP, or HTTP
connector is specified in the collector at the Transport step, then at the Event parsing step on the
Parsing settings tab you can specify several IP addresses and specify which normalizer should be
PI

used for events coming from specified addresses. The following normalizers are available: json, cef,
regexp, syslog, csv, kv, xml. All sources that send data to a collector must use the same transport as
the collector (UDP, TCP or HTTP).
CO

You can organize Syslog and regexp normalizers into a chain: set additional normalization conditions
depending on the value of the DeviceProcessName field. The difference with additional normalization
(which will be discussed later) is that you can specify shared normalizers. Using this additional level of
BE

normalization increases the consumption of computing resources, but not by much.

Extra normalizers
TO
T
NO

79
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
You can use several normalizers in a collector sequentially. We are no longer talking about
normalization that depends on the source IP address. Here we are talking about a situation where an
OR
event passes through several different normalizers that can be applied depending on the event
contents. For example, events from a Windows Event Log may have different structures and,
depending on the value of the Event ID field, they should be parsed differently.
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
CO

field 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.
BE

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.
TO
T
NO

80
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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.
OR
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.
BE

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)
normalizer. You cannot use an existing named normalizer set up in the Resources when configuring
TO

conditional normalization.
T
NO

81
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
Each normalizer has one more section of settings where you can configure enrichment without
sending requests to external systems. For example, dictionary enrichment. If an event contains only a
OR
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

Let’s consider an example of creating and debugging normalizers.

When you create a normalizer, it is convenient to have an example of the original event at hand. You
T

can copy it to the Event examples field and monitor on the fly how the fields of the original event will
NO

be written to the fields of the normalized event.

82
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
We have an event from Blue Coat ProxySG in our example; you can see that it has the key:value
format. The delimiter between values is “=”, and the delimiter between pairs is “|”.

BU
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

ST
format: (?P<msg>.*).

Then create an additional normalizer and pass the value of the msg field without any conditions to its

DI
input.

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

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. You can
configure this on the Enrichment tab.
T
NO

83
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
Thus, we were able to process the event using two normalizers: in the first, we removed the part that
couldn’t be processed by an out-of-the-box normalizer, and in the second, we used the preset kv
OR
normalizer.
ED
PI
CO
BE
TO

3.3. Collector: event processing

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
T
NO

84
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
Filtering

BU
RI
ST
DI
RE
After normalization, a collector filters events. This stage has several objectives:
OR

• Discard events that do not contain any security-related information

• Save resources in further processing steps: enrichment, correlation and storage

ED

• 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.
PI
CO
BE
TO
T
NO

85
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
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.

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

RI
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

ST
operand; some operators may need some special data. For example, the inSubnet operator implies
that the left operand is an event field containing an IP address, and the right operand is a constant
whose value is a subnet with a mask.

DI
For a complete list of possible comparison operations and settings, please refer to the online help at

RE
https://support.kaspersky.com/help/KUMA/3.2/en-US/217880.htm

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
OR
phase and what information is not yet available. For example, active lists can only be used in
correlators, not in 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.
ED
PI
CO
BE
TO

Filter conditions can also be set and viewed in source code mode. You can switch between modes
T

when creating filtering criteria. To switch to source code mode, click the Code button. When you
NO

switch between modes, the configured condition filters are preserved. If the filter code is not displayed

86
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
on the Code tab after you bind the created filter to a resource, switch to the Builder tab and return to
the Code tab. The filter code will be displayed.

BU
Aggregation

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
ED

is often applied to events from network equipment (for example, NetFlow). Instead of treating each
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.
PI

Base events that have been aggregated do not go any further. The aggregated event is forwarded
CO

instead.

Aggregation simplifies analysis and reduces resource consumption and EPS at the collectors’ output,
which reduces the license cost.
BE
TO
T
NO

87
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
Aggregation is configured as rules, which are another kind of resources. You can configure
aggregation rules in the resources and then use them in the collector settings. Alternatively, you can
OR
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
PI

• 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 aggregate event will combine base events with connections to different ports, and
CO

the DestinationPort field of the aggregate event will list all ports to which connections were
established

• Sum fields — values of these fields from base events will be summed up and written into the
BE

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
TO

for the next aggregated event

• 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
T
NO

An aggregated event is created when either the time threshold or the event number threshold is

88
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
reached, whichever occurs first.

You can add a filter to an aggregation rule (similarly to an enrichment rule) to apply it only to events

BU
that meet the specified conditions rather than to all events.

Enrichment

RI
ST
DI
RE
OR
ED

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
PI

(DNS, LDAP, CyberTrace, etc.), while the normalizer can only use information from the event,
dictionaries and constants.
CO

Apart from requests to external systems, enrichment by the rules is the same as enrichment in the
normalizer. This provides analysts with more options to get the required results.
BE
TO
T
NO

89
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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
OR
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
PI

an 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:
CO

{{.EventFieldName}}. Template example: Attack from {{.SourceAddress}} to {{.DestinationAddress}}.

Two types of CyberTrace enrichment are available: cybertrace and cybertrace-http. When using the
former type, it is easy to reach the limit on simultaneous connections to CyberTrace. In this mode,
BE

requests are processed one at a time, and a queue of enrichment requests accumulates in KUMA.
The cybertrace-http enrichment type was designed to solve this problem; when used, requests to
CyberTrace are processed in batches, rather than one at a time. The cybertrace-http method is
recommended for use in systems with a large event flow. Cybertrace-http performs significantly better
TO

than cybertrace, which remains available to ensure backwards compatibility.

T
NO

90
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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.
OR
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:
ED

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

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
complement numerical operation code with a description.
CO

• table — a value from the specified table (similar to a dictionary)

• event — to populate the field with a value obtained by converting another field
BE

• template — to populate the field with a combination of constants and values of several other
fields

DNS enrichment
TO
T
NO

91
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
Let’s 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 three pairs of such fields:
OR
• DeviceAddress, DeviceHostName — attributes of the device that created the event (for
example, a proxy server)

• SourceAddress, SourceHostName — attributes of the device that performed the action logged
ED

in the event (for example, the device that established a network connection)

• DestinationAddress, DestinationHostName are attributes of the device where the action logged
in the event was directed to
PI

DNS enrichment fills the missing value in each of these pairs based on the available field. For
CO

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 DestinationAddress field. If the reply returns several addresses, the first one will be
written to the field.
BE

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

Each address-name pair is enriched independently. If both address and name fields are filled in, DNS
enrichment is not performed.
T
NO

92
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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
OR
which field to write the address/name to.

In a DNS enrichment rule, you can configure:

• DNS server addresses

ED

• Allowed number of requests per second (RPS)

• Number of worker processes

PI

• The maximum number of tasks per process

• Response cashing lifetime

CO

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

each 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.
TO

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.

Enrichment with GeoIP data

T
NO

93
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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.
OR
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.
ED

There is a link to this script and command descriptions in the online help at
https://support.kaspersky.com/help/KUMA/3.2/en-US/233257.htm
PI

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),
CO

the export file will contain the start and end IP addresses (1.0.0.0 — 1.0.0.255).
BE
TO
T
NO

94
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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
OR
attributes in the database:

• Country

• Region
ED

• City

• Latitude
PI

• Longitude

The rule specifies from which field of the normalized event to extract the IP address and into which
CO

KUMA fields to write geographical data. KUMA has a set of internal fields for these purposes.

Storage spaces and partitions

BE
TO
T
NO

95
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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
OR
events are stored for a year. Some events need to be stored for a long time, while several days are
enough for others.

Kaspersky Unified Monitoring and Analysis Platform allows you to configure different retention time for
ED

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

If you open the list of active services and select a Storage service, it will have the Go to partitions

96
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
button. 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

BU
(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
left of the partition and select Delete.

RI
ST
DI
RE
OR
ED

In KUMA, you can move old events that need long-term preservation from a fast and expensive
ClickHouse storage to a slow and cheap storage (so-called cold storage). The system provides a
PI

unified search with all SQL capabilities for all data regardless of the storage location.

An HDFS (Hadoop Distributed File System) cluster or local drives mounted in the operating system
CO

can be used as a cold storage subsystem. When you add a disk for cold storage, retention period
settings appear in the properties of the Storage resource.

The hot and cold days add up to make the total retention period. In our example, events will be moved
BE

to cold storage on the second day and then stored for 60 days, i.e. the total retention period is 61
days. Cold storage is configured separately for ordinary and audit events.
TO
T
NO

97
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
In KUMA, the ClickHouse cluster configuration is specified in the properties of the Storage resource.
In a distributed installation, the Storage resource will most likely have to be created from scratch and it
OR
is important to correctly specify the FQDN of the cluster nodes and configuration of shards, replicas
and keepers; otherwise, the service will not start.

When you connect an HDFS cold storage to a ClickHouse cluster, the path must include subfolders
ED

denoting the shard number and replica number. These folders must be created on HDFS in advance.

If your ClickHouse cluster consists of one node, i.e. 1 shard, 1 replica, you do NOT need to

specify /1/1/ at the end of the path (see the previous slide). KUMA will do this automatically.
PI
CO
BE
TO
T
NO

98
 Chapter 3. Event collecting and processing KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
The list of partitions shows when a partition moves from hot storage to cold and when it will be
deleted. If cold storage is not enabled, these two dates will be the same.
OR
In our example, we’ve configured transfer to cold storage on the second day; older events must be
moved to cold storage. KUMA checks the partition lifetime every hour and when the kuma-core
service restarts.
ED
PI
CO
BE
TO

You can see that after the nearest partition lifetime check, events older than 24 hours have been
T

moved to cold storage. You can also see the date when the partition will be permanently deleted from
NO

the system.

99
 Chapter 4. Integrations KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
Chapter 4. Integrations
Integrations allow Kaspersky Unified Monitoring and Analysis Platform to receive additional

BU
information 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.

ST
Let’s focus on the following integrations now:

DI
• Kaspersky Security Center

• LDAP

RE
• Kaspersky Threat Lookup

• Kaspersky CyberTrace

• Kaspersky Endpoint Detection and Response

OR
The complete list of possible integrations is available in the online help at

https://support.kaspersky.com/help/KUMA/3.2/en-US/217927.htm
ED

4.1. Integration with Kaspersky Security Center

PI
CO
BE
TO
T
NO

Integration of Kaspersky Unified Monitoring and Analysis Platform with Kaspersky Security Center

100
 Chapter 4. Integrations KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
pursues the following objectives:

• Fill the KUMA database of assets (computers) with information about managed devices from

BU
Kaspersky Security Center

• Implicitly enrich events with links to asset identifiers, if such an asset exists in the KUMA
database

RI
• Use specially prepared Kaspersky Security Center tasks to manually and automatically
respond to security incidents

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

DI
Running tasks requires additional permissions.

RE
OR
ED
PI
CO

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
BE

secure. Therefore, to prepare for the integration with Kaspersky Security Center, we recommend that
you create a new internal account in Kaspersky Security Center for connections from Kaspersky
Unified Monitoring and Analysis Platform.
TO

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

You can also use roles instead of permissions; in this case, the Kaspersky Endpoint Security
NO

101
 Chapter 4. Integrations KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
Administrator role grants all necessary permissions (including read access to information about
devices).

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
ED

is never sent to the web console in the clear.

The integration is configured in Settings | Kaspersky Security Center. You can configure connection
to several Kaspersky Security Center servers here. For each server, specify a connection name (any)
PI

and the following:

CO

• URL — the connection address of the Kaspersky Security Center server in the format <name
or IP address>:<API port>

• Secret — a resource of the credentials kind with a user name and password for accessing
Kaspersky Security Center
BE

If you do not use a connection to Kaspersky Security Center anymore, you can disable (the Disabled
checkbox) or delete it.
TO
T
NO

102
 Chapter 4. Integrations KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
First of all, integration with Kaspersky Security Center is required to populate the Kaspersky Unified
Monitoring and Analysis Platform asset database.
OR
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
ED

who analyzes 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 Import KSC assets button to import
PI

them on demand (this will not affect the scheduled import in any way).
CO

Kaspersky Unified Monitoring and Analysis Platform imports all computers with Kaspersky Security
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.
BE

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 collected by Kaspersky Security Center Network Agent.
TO
T
NO

103
 Chapter 4. Integrations KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
Quite a lot of fields appeared in asset properties starting with KUMA 2.1. These are mainly fields that
KUMA receives from KSC via Open API.
OR
Useful fields:

• KSC extended status ID — host status in KSC (green, yellow, red)

ED

• KSC extended status — a text description of a status, why it is yellow or red (if the status is
green, this field is normally empty)

• Real-time protection status

PI

• Anti-virus databases last updated — database release timestamp

• Endpoint Sensor status — KEA status

CO

• System last started—operating system start timestamp

Other new fields:

BE

• Encryption status

• Anti-virus protection status of mail servers

• Spam protection status

TO

• Data Leakage Prevention status

• Protection last updated — when the last database update task was run
T

• Information last updated — when information about the device was last updated in KSC
NO

104
 Chapter 4. Integrations KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
You can create custom fields if necessary.

BU
RI
ST
DI
RE
OR
Custom fields are set up in Settings | Assets. Only a user who has the General admin role can use
this functionality.

You can use regular expressions to restrict field values. For example, if a field must contain only
numeric values, you can use a regular expression to prohibit any characters other than digits.
ED

Or, for example, if a field must contain the email address of the device owner, prohibit any values that
do not match the [email protected] format.
PI

After the General admin creates custom fields, they become available for editing in an asset card in
the Custom fields area.
CO

The regular expression a field value must match is displayed below the field.

If a custom field is empty, it is not displayed in the asset card, but becomes available when you switch
BE

to edit mode.
TO
T
NO

105
 Chapter 4. Integrations KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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
OR
specifications. You cannot specify information about vulnerabilities when adding assets manually.
ED
PI
CO
BE
TO

You can group assets into categories. An installation contains examples of asset categories. You can
delete them or add new categories that better serve your purposes. Categories form a hierarchy. Each
category has one of the following criticality levels:
T

• Low
NO

106
 Chapter 4. Integrations KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
• Medium

• High

BU
• Critical

You can add a computer to several categories. Initially, all assets get into the Uncategorized assets
category.

RI
You can use asset categories in conditions within filters or correlation rules. For example, you can

ST
create alerts of higher severity for critical assets.

DI
RE
OR
ED
PI

You can manage the structure of assets using the category shortcut menu.
CO

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 the properties of the current one, for example, the level of importance and the filling method.
BE

You can delete a category only if it is empty, i.e. no asset is associated with it.
TO
T
NO

107
 Chapter 4. Integrations KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
When working with numerous assets, you can use search and configure it as a set of conditions
similar to filters: left and right operands, and a comparison operator. Any field from the asset
OR
properties, including new ones, can be used for the left operand.

You can export search result to a file in CSV format.

Almost all of these fields can be used to dynamically categorize assets.

ED
PI
CO
BE
TO
T

Categories can be filled in three ways:

NO

108
 Chapter 4. Integrations KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
• 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

BU
• Reactive — using correlation rules, i.e. when a correlation rule is triggered, the asset will be
moved to the specified group

RI
ST
DI
RE
OR
ED

If the Active category filling method is used, you can use several conditions for grouping:

• Build number
PI

• OS

• IP address
CO

• FQDN

• CVE
BE

The conditions are set in the following format: left operand (one of the abovementioned conditions),
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.
TO

After you have set up a condition, test it. The Test conditions button displays the list of devices that
match the specified condition. This is especially useful when configuring complex conditions.
T

You can also set up the categorization period here, meaning, how often conditions will be checked for
the entire list of assets. Periods from 1 to 24 hours are available.
NO

109
 Chapter 4. Integrations KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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
OR
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:

• DeviceAssetID
ED

• SourceAccountID

• DestinationAssetID
PI

The collector receives information about assets from the core and fills in the asset identifier field in the
events in the following cases:
CO

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

importance

• 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
name in the DestinationHostName field, the collector will add the DestinationAssetID field with
TO

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
T

situation may arise either when the *HostName field contains an FQDN, but it does not match any
NO

110
 Chapter 4. Integrations KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
asset, or when the *HostName field contains a computer name rather than its FQDN.

BU
RI
ST
DI
RE
OR
To keep track of various actions with assets in Kaspersky Unified Monitoring and Analysis Platform,
configure asset audit events.

In the side menu: Settings | Asset audit.

ED

The following types of audit events are available (destinations are configured separately for each of
them):
PI

• Asset added to KUMA

• Asset parameters changed

CO

• Asset deleted from KUMA

• Asset added to category

• Asset removed from category

BE

• Vulnerability info added to asset

• Asset vulnerability resolved

TO

Storage and Correlator (for events that need to be correlated) services usually act as the destination.

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:
T
NO

111
 Chapter 4. Integrations KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
DeviceCategory = 'Audit assets'

or

BU
DeviceAction like 'assets%'

RI
ST
DI
RE
OR
ED

KUMA can delete assets for which information is out of date. If no information about an asset is
updated during a synchronization, such an asset is marked as archived. Depending on the settings,
an archived asset can either be deleted after its storage period expires or can be stored indefinitely.
PI

You can also delete assets manually.

CO

4.2. LDAP integration

BE
TO
T
NO

112
 Chapter 4. Integrations KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
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,
OR
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.
ED

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
PI

the account identifier field.

CO
BE
TO
T
NO

113
 Chapter 4. Integrations KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
LDAP integration, like other integrations, is configured in Settings | LDAP server.
OR
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
the LDAP server. The user must have permissions to read information about users and groups
ED

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
PI

• 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)
CO

and specify there the certificate to be used for encryption.

BE
TO
T
NO

114
 Chapter 4. Integrations KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
Event enrichment with the account ID can be configured in the collector only, because a LDAP
enrichment rule differs from other enrichment rules. In the Event enrichment section, there is a
OR
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
ED

especially important that the domain name is written correctly here

• LDAP enrichment mapping — configure the mapping rules: which values of event fields to take,
PI

which account attributes to compare with, and which field to populate with the link to the
account
CO

The collector checks values of the UserName and UserID fields and maps them to account
information. If a match is found, the collector adds the SourceAccountID or DestinationAccountID field
with the corresponding identifier to the event.
BE
TO
T
NO

115
 Chapter 4. Integrations KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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
OR
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

Let’s walk through an example that will require us to use several different enrichment options and
NO

LDAP integration.

116
 Chapter 4. Integrations KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
Suppose a source sends events that contain usernames, but KUMA cannot associate them with
accounts from Active Directory due to differences in the record format. The analyst would like to see
information about users from Active Directory in events, but this doesn’t work ‘out of the box’, because

BU
the source sends user names in the <Domain Name>\\<Username> format in the
DestinationUserName field. Meanwhile, Active Directory does not use this format for usernames.

RI
The analyst needs to configure enrichment tools to add the DestinationUserID field with the objectSid
value to events. The collector will map this field to an imported account and 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
user name.
CO

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

In a similar manner, we’ll use regular expressions to out the right part and convert the value into
lowercase. The result should replace the original field, DestinationUserName.
TO
T
NO

117
 Chapter 4. Integrations KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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):
OR
• Export user names and SIDs to a CSV file

• Import the username-SID pairs from the file into a dictionary

• Use dictionary enrichment in the normalizer, because the normalization stage precedes
ED

requests to external systems, and we will have a field with the user’s SID before LDAP
enrichment
PI

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
CO

operation description based on its available code. Or supplement a user name with the respective
SID.

A dictionary as a resource has very simple settings:

BE

• Name

• A list of key:value pairs

TO

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.
T
NO

118
 Chapter 4. Integrations KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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
OR
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
PI

Active Directory

• Key fields — the field whose value you want to use as a key to search the dictionary for. In this
CO

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 the specified key. In this case, it is DestinationUserID
BE

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.
TO
T
NO

119
 Chapter 4. Integrations KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
Now, if we look at the normalized events, we will see that:
OR
• 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

120
 Chapter 4. Integrations KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
If LDAP enrichment is configured, response via Active Directory is available in alerts and incidents in
the Related users section, and even in events. The SourceAccountID and DestinationAccountID
OR
fields contain links to account properties.

As part of response, KUMA can:

• Block an account
ED

• Reset the user’s password

• Add an account to a group

PI

• Remove an account from a group

CO

KUMA uses ldap-utils to run commands.

BE
TO
T
NO

121
 Chapter 4. Integrations KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
KUMA can only have one LDAP connection to one domain. The account used for LDAP queries must
have the appropriate permissions, otherwise an error is displayed.
OR
The slide shows common response-related mistakes, for example, lack of the necessary rights or an
attempt to move an account to a non-existent group.

If the ‘Password never expires’ option is set up for an account, an attempt to reset its password will
ED

return an error. The same will happen if the ‘User cannot change password’ option is enabled.

The Response rules resource has the ‘Response via Active Directory’ rule type. Such a rule works
PI

with the SourceAccountID and DestinationAccountID event fields.

CO

4.3. Kaspersky Threat Lookup

BE
TO
T
NO

122
 Chapter 4. Integrations KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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
OR
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
ED

queries.

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
PI

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

123
 Chapter 4. Integrations KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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
OR
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)
PI

The address where to send KTL requests is not specified anywhere. It is permanent and coincides
with the address of the web version of Kaspersky Threat Intelligence Portal: https://tip.kaspersky.com
CO

Querying Kaspersky Threat Lookup requires the same credentials as authentication in Kaspersky
Threat Intelligence Portal web console:

• Username
BE

• Password

• Certificate

• Certificate password
TO

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

Kaspersky Threat Intelligence Portal users have different access permissions:

NO

124
 Chapter 4. Integrations KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
• Web only — can use only the web version of Kaspersky TIP

• API only — can only send queries through the Kaspersky TIP API

BU
• Full — can use the web portal and API equally

In the KUMA settings, you must specify a user with API or FULL access.

RI
ST
DI
RE
OR
ED

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
PI

corresponding indicator or, if this indicator has not been previously queried, a pane with the KTL
search settings.
CO

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
BE

can be many entries in a group. For example, the ‘File downloaded from URLs’ group that lists
addresses from which the file with the requested hash has been downloaded may contain multiple
entries. You can limit the number of records in the response.
TO

To query a new attribute, click the Request button. As a result, Kaspersky Unified Monitoring and
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.
T
NO

125
 Chapter 4. Integrations KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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.
OR
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
ED

if 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

4.4. Kaspersky CyberTrace

BE
TO
T
NO

126
 Chapter 4. Integrations KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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
OR
the events being processed.

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
ED

to Kaspersky CyberTrace and receive alerts about matches in response

• Requests through enrichment rules

PI

Requests are more useful in this case. They help Kaspersky Unified Monitoring and Analysis Platform
find out that some objects in an event are indicators of compromise. In filters and correlation rules,
CO

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

Integration with Kaspersky CyberTrace provides two capabilities:

• Build Kaspersky CyberTrace interface into the KUMA interface, which allows analysts to
manage KUMA and Kaspersky CyberTrace as a single system
TO

• Enriching events with CyberTrace data

• Register URL, IP or hash values from events as indicators of compromise in Kaspersky

CyberTrace (such indicators are added to the Internal TI feed in Kaspersky CyberTrace) to be
T

able to detect these indicators in new events later

NO

127
 Chapter 4. Integrations KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
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.

BU
The KUMA core acts as a proxy when you work with the Kaspersky CyberTrace interface built into the
Kaspersky Unified Monitoring and Analysis Platform interface. The nested interface is available on

RI
TCP port 7222 (while the regular KUMA web interface port is TCP 7220). You cannot change this in
the KUMA interface, because it is specified in the core service startup options on the Linux server.

ST
DI
RE
OR
ED

Integration with Kaspersky CyberTrace is configured in Kaspersky Unified Monitoring and Analysis
PI

Platform web console on the Settings | Kaspersky CyberTrace page and contains the following
options:
CO

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

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

Integration with Kaspersky CyberTrace at the web interface and API levels requires that Multi-user
mode is enabled in Kaspersky CyberTrace. This functionality is available with any commercial
CyberTrace license, but is not available with a free license.
T

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
NO

128
 Chapter 4. Integrations KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
Kaspersky CyberTrace side.

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
ED

address of CyberTrace web interface (by default, port 443/tcp of the CyberTrace server).
PI
CO
BE
TO
T

Event enrichment from CyberTrace works as follows. The analyst sets up an enrichment rule in the
NO

129
 Chapter 4. Integrations KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

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

BU
The collector sends a request to CyberTrace, CyberTrace compares the transmitted attributes with
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

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

ST
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

DI
There is the TI field in the KUMA data model. This is an internal KUMA field that combines a TI

RE
indicator and Indicator category; use the TI field when searching for events in the storage, in filter
conditions and correlation rules.
OR
ED
PI
CO
BE

A Kaspersky CyberTrace enrichment rule has the following settings in KUMA:

• Source kind — cybertrace

TO

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

field on the left (for example, FileHash) and the respective indicator type on the right (in this
case, hash; for other fields, it can be URL or IP). You can configure comparison of multiple
NO

130
 Chapter 4. Integrations KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
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.

BU
When collector processes an event, it generates a separate event to be sent to CyberTrace. For the
mapping shown on the screenshot, the event format will be as follows:

RI
Id=<value of the ID field> | ip=<destinationAddress field value> |
hash=<value of the DeviceCustomString4 field> | url=<value of the
FilePath field> | hash=<value of the FileHash field> |

ST
DI
RE
OR
ED
PI

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
CO

section. 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
BE

Settings | Tenants, specify the port where CyberTrace accepts requests and set the same port in the
connection on the Kaspersky Unified Monitoring and Analysis Platform side.
TO
T
NO

131
 Chapter 4. Integrations KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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
OR
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
CO

Kaspersky CyberTrace in the Detections section. The respective source event that CyberTrace
received from KUMA will also be shown there.
BE
TO
T
NO

132
 Chapter 4. Integrations KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

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

• When investigating an incident, the analyst decides that some of the KUMA events are related
to the incident and contain characteristic indicators of compromise: file hashes, IP or URLs of
ED

dangerous servers

• The analyst clicks the indicator in the KUMA event and selects the command Add to Internal
PI

TI of CyberTrace

• KUMA sends the selected value to CyberTrace, where it is added to the InternalTI data feed (a
CO

special list of indicators of compromise in CyberTrace that is filled manually)

• If CyberTrace enrichment and the corresponding correlation rules are configured, KUMA will
generate alerts for new events that contain the published indicators
BE

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 open a menu with the command to send the indicator to CyberTrace.
TO

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
T

CyberTrace.
NO

133
 Chapter 4. Integrations KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
4.5. Kaspersky Endpoint Detection and Response

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.

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:
ED

Kaspersky Anti Targeted Attack. Kaspersky Endpoint Detection and Response.

During the integration, the KUMA core connects to the Central Node server and registers as an
PI

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
BE

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 the same secret.
TO
T
NO

134
 Chapter 4. Integrations KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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
OR
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
ED

when you click the Save button.

PI
CO
BE
TO
T

Upon successful integration with Kaspersky Endpoint Detection and Response, a new KEDR
NO

response button appears in the properties of assets where Kaspersky Endpoint Agent is installed.

135
 Chapter 4. Integrations KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
The following types of response are possible:

• Enable network isolation — Kaspersky Endpoint Agent uses the Windows packet filter to

BU
isolate 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

ST
• Delete prevention rule

• Run program — remote execution of a command or start of a program on a computer. To

DI
execute a command, specify:

◦ The executable file to run on the computer. The file must be located on the target

RE
machine. The task does not permit selecting a file on your computer, copying it to the
target computer and running it there

◦ Command line parameters (optional)

OR
◦ Working folder where the command will be executed (optional)

4.6. Kaspersky Automated Security Awareness Platform

ED
PI
CO
BE
TO

Kaspersky Automated Security Awareness Platform is an online training platform that helps users
learn about information security rules and cybersecurity threats they may encounter in real life, and
T

put theory into practice.

NO

136
 Chapter 4. Integrations KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
The documentation is available at https://support.kaspersky.com/ASAP/1.0/en-US/204775.htm

You can work with this platform via API. First, generate a token with the necessary permissions.

BU
The following permissions are sufficient for integration with KUMA:

• Get a list of training groups

RI
• Get reports

• Edit user information

ST
However, you can only generate one token; and if you intend to use API in several different systems,
creating a single token with maximal permissions might make sense.

DI
To configure integration in KUMA, you will need to copy the token and Open API URL.

RE
OR
ED
PI
CO

On the KUMA side, integration with Kaspersky ASAP is configured in the Settings | Kaspersky
BE

Automated Security Awareness Platform. Create a Secret resource, select the Token type and
copy the token from Kaspersky ASAP. In addition to the token, you must specify the address where
KUMA will send API requests to.
TO

Also, specify an email address where reports will be sent when users complete training modules.

Response via Kaspersky ASAP is available in the properties of user accounts that are displayed in
alerts and incidents in the Related users section.
T

First, KUMA checks whether the user’s email address is registered with Kaspersky ASAP, and if so,
NO

137
 Chapter 4. Integrations KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
displays information from Kaspersky ASAP: what group this user belongs to, which courses has
assigned, which of them are completed and which are in progress.

BU
Training modules are assigned to groups in Kaspersky ASAP. An administrator creates a group,
assigns the necessary training modules to it (topics and levels of complexity may vary), adds user
accounts to the group, and starts the training process.

RI
As part of threat response, KUMA can move a user to a group with a different training program.

ST
If a group is not available, it means that training has already started and a new user cannot be added.
You can either move the user to an available group or create a new group with the desired learning
path.

DI
In any case, training can only be started in the Kaspersky ASAP platform, while KUMA helps track the
progress.

RE
OR
ED
PI
CO
BE
TO
T
NO

138
 Chapter 5. Correlation and work with events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
Chapter 5. Correlation and work with events
5.1. Working with events

BU
In this section, we will study the tools that you can use in Kaspersky Unified Monitoring and Analysis
Platform to work with events that have already been saved into the storage.

RI
ST
DI
RE
OR
ED

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 also saved into the storage. An analyst can find any events in the storage and
PI

analyze them on the respective page of the web console.

CO

The Events page contains the following tools:

• SQL query to search the database for events

• Lollipop chart that displays distribution of the detected events over time
BE

• 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) Above the search bar, there
TO

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
T

visualized on the chart

NO

139
 Chapter 5. Correlation and work with events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
• Name of the storage to query. You can search through several storages simultaneously. Note
that grouping queries, retroscan, and export to TSV are not supported when you search across
multiple clusters.

BU
You can save the parameters for future reuse.

You can export the displayed events to TSV (tab separated value) format.

RI
ST
DI
RE
OR
ED

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:
PI

• Descriptions of related assets

CO

• Attributes of related accounts

• Details concerning indicators of compromise obtained from Kaspersky CyberTrace or

Kaspersky Threat Lookup
BE
TO
T
NO

140
 Chapter 5. Correlation and work with events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
The histogram shows the distribution of the found events over time and their number within each
interval.
OR
You can interactively select an interval on the timeline with the mouse and the Show events button
will appear. When you click it, the web console will automatically narrow down the interval and display
the respective events.
ED
PI
CO
BE
TO

Sometimes, for troubleshooting or analysis, you need to limit the search to events of a particular
T

collector. Each event has an internal ServiceID field that contains the identifier of the KUMA service
NO

that created the event. Since base events are created by a collector, their ServiceID contains the

141
 Chapter 5. Correlation and work with events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
collector’s identifier. This field allows you to find all events output by a collector.

The Kaspersky Unified Monitoring and Analysis Platform web interface provides a convenient way to

BU
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) and click Go to events. This action opens a new browser tab with the Events

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

ST
DI
RE
OR
ED

An event search query is an SQL query that the core sends to the ClickHouse storage. ClickHouse
PI

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

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
BE

search query as an additional condition or exception.

TO
T
NO

142
 Chapter 5. Correlation and work with events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
The pane with detailed description of an event provides the same capability. Instead of clicking on the
value, hover the mouse over the field until the ‘plus’ and ‘minus’ buttons appear. The ‘plus’ button
OR
adds the field value as a condition to the query. The ‘minus’ button adds the selected value as an
exception.
ED
PI
CO
BE
TO

After you receive a list of events, you often need to group them in order to isolate a cybersecurity
incident. KUMA can group events by one or more fields for the resulting list of events.
T

To group events, you no longer need to manually adjust the query text — you can click on the field in
NO

the Events section and select + Add Group BY in the context menu. You can sequentially select

143
 Chapter 5. Correlation and work with events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
multiple fields for grouping; the fields will be automatically added to the query string. After you’
selected the necessary fields, click Run query. As a result, events will be grouped by the specified
fields. Found groups will be displayed in the Groups area. Display is available in table and card form.

BU
You can switch between display modes. You can also export groups and events in TSV format.

You can exclude a group from the filter. The query will change automatically.

RI
ST
DI
RE
OR
ED

If you want to return to the original query, click Return to initial query. You can switch between the
groups and view their contents. You can remove a group from the grouping, thereby going back a
step. Statistics, retroscan by group and export to TSV are also available.
PI

If you want the result of grouping to be time-independent (because events are constantly arriving),
CO

you can fix the relative interval and apply it as an absolute interval so that events of interest do not
disappear from the query.
BE
TO
T
NO

144
 Chapter 5. Correlation and work with events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
Click the icon to the left of the search bar to open SQL builder, where you can edit the query in GUI.
OR
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 <event field> <operator> <value>
ED

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 sorting by time when the event was added to the database)
PI

• LIMIT — how many events to return (250 by default)

CO

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 %, not *.

Previously saved search parameters are available in the extended query configuration interface: click
BE

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

145
 Chapter 5. Correlation and work with events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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
OR
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 a command for
ED

retrospective scanning. We will study retroscanning after correlation in this course.

PI
CO
BE
TO
T

When working with events in KUMA, you can save your custom sets of event fields.
NO

146
 Chapter 5. Correlation and work with events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
This is convenient because different sources usually have specific fields that contain useful
information.

BU
RI
ST
DI
RE
OR
For example, let’s consider EDR telemetry events that KATA receives from KEA installed on the hosts.
Telemetry is stored in the Kafka database, there is a special connector for it, and a normalizer has
been added.
ED

You can configure a custom view with the fields that deserve attention in these events. In the picture,
we’ve selected 8 fields and arranged them in the necessary order:
PI

• Timestamp

• DeviceHostName
CO

• SourceUserName

• Name

• DeviceAction
BE

• DestinationAddress

• Technique
TO

• Tactic

If you click the gear icon and then ‘Save current preset’, you will be able to instantly apply this view
when working with events of this collector.
T

It probably makes sense to create a set of fields for each source: for Windows events, for KSC, for
NO

147
 Chapter 5. Correlation and work with events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
netflow, etc.

5.2. Correlation

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

RI
ST
DI
RE
OR
ED

Correlation rules are another kind of Kaspersky Unified Monitoring and Analysis Platform resources.
They are used in the settings of the correlator service, but you can create and modify them
PI

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
CO

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:
BE

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

• Standard correlation rules analyze combinations of events and can respond to accumulation of
specific events or to events that arrive in a particular order. Also, standard rules can compare
events. Examples of standard rules:
T

◦ Kaspersky Security Center sent 10 network attack events in 1 minute

NO

148
 Chapter 5. Correlation and work with events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
◦ 30 failed brute-force attempts followed by a successful logon (a successful password
attack)

◦ Kaspersky Security Center sent a threat detection event and then there were no threat

BU
neutralization events within an hour (an unprocessed threat)

• Operational correlation rules are similar to simple rules, but they fill so-called active lists with

RI
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

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

DI
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 the link

RE
Simple correlation rule
OR
ED
PI
CO
BE

Settings of each rule are grouped into three sections:

• General settings that determine the rule type, its priority (for alerts), propagated fields and
TO

event grouping parameters (we will explain this later)

• Selectors, i.e. conditions for selecting events and applying the rule based on the selected
events
T

• Actions: enrichment for correlation events, active list filling, where to send correlation events
and whether to create alerts if the conditions are met
NO

149
 Chapter 5. Correlation and work with events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
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 convert a KATA detection into an alert in KUMA.

BU
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

RI
for this rule.

Selector is a filter. Therefore, in the selector settings, you can select a ready preconfigured filter from

ST
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).

DI
RE
OR
ED
PI
CO

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:
BE

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

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

requests to external systems (i.e., the same enrichment as in a normalizer in a collector). You
NO

150
 Chapter 5. Correlation and work with events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
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
Reactive filling

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

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
PI

priority of the respective alert: Low, Medium, High or Critical. An analyst or administrator can change
alert priority when investigating an incident
CO

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 must specify at least one field.
BE

For example, if a simple rule is triggered by events about network attacks, it is logical to list the fields
with 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’.
TO

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

But if analysts plan to create other rules to be applied not only to base events but also to correlation
NO

events, the fields copied to the correlation event will determine the conditions that the analyst will be

151
 Chapter 5. Correlation and work with events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
able to use for it.

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:
ED

• Base events that matched the rule (in case of a simple rule, there is one base event)

• Assets related to the base events

PI

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

rules. However, the detailed view of a correlation event resembles an alert very much.

Standard correlation rule

BE
TO
T
NO

152
 Chapter 5. Correlation and work with events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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
OR
rules.

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
ED

numerous connections during a short period of time. This example can have a few variations:

• Simply a lot of connections to dangerous URLs: from different computers and to different URLs
PI

• Many connections to various dangerous URLs from the same computer

• Numerous connections to the same dangerous URL from different computers

CO

• 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

153
 Chapter 5. Correlation and work with events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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
OR
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
ED

the 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
PI

events generated by the url_web or ids technology), which means that connections from any
computers are taken into account.
CO
BE
TO
T
NO

154
 Chapter 5. Correlation and work with events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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
OR
established in 30 seconds from the same computer, the analyst needs to configure a correlation rule
with the following general parameters:

• Kind: Standard
ED

• Identical fields: SourceAddress, RequestUrl

• Observation window: 30 seconds

PI

and selector parameters

• Filter: url_web events from KATA

CO

• Threshold: 3

The rule will

BE

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

(that is, from the moment when the first event was added to the bucket)

• Be applied if a bucket accumulates 3 events

T
NO

155
 Chapter 5. Correlation and work with events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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.
OR
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
ED

where all 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

156
 Chapter 5. Correlation and work with events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
Now, let’s focus on the last situation where many connections are detected from the same computer
to the same dangerous URL.
OR
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
ED

rule with these settings will create a separate bucket for each combination of SourceAddress and
RequestUrl 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

157
 Chapter 5. Correlation and work with events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
The ‘many’ criterion consists of two parts: how many events and during what period. The period is set
by the Window parameter in the general settings of a standard rule.

BU
In a more generalized sense, the Window parameter determines the bucket’s lifetime. It works as
follows:

• Identical fields specify how to group events

RI
• Selectors determine which events will be grouped (if an event does not match any selector, it
will not fall into any bucket)

ST
• If an event matches a selector and there is already a bucket with the same set of identical field
values as in this event, it goes there

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

RE
• 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
OR
Meaning, a bucket accumulates events during its lifetime (or observation window), then gets deleted
and events can accumulate anew. This occurs concurrently and independently for each combination
of identical field values.
ED
PI
CO
BE
TO

Let’s assume that in our example about many connections to the same dangerous address from the
T

same computer, ‘many’ means 3 or more connections in 30 seconds. The Window parameter in the
NO

general settings of the rule specifies ‘30 seconds’. ‘3 or more’ is defined by the Selector threshold in

158
 Chapter 5. Correlation and work with events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
the selector settings.

Also, selector has a filter to select events. In this case, we do not intend to simply count all events that

BU
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’s configure the selector to pick out Kaspersky Anti Targeted Attack Platform

RI
events about dangerous connections (in this case, url_web events).

The rule will be applied if a bucket accumulates the number of events specified in the Selector

ST
threshold 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.

DI
RE
OR
ED
PI
CO

What if a bucket accumulates much more events than the selector threshold prescribes during its
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.):
BE

• 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
accumulates 10 events in 30 seconds while its threshold is 3, there will be only one correlation
event after the third accumulated event
TO

• On every threshold — create a correlation event each time when the threshold is exceeded
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
T

• On subsequent threshold — create a correlation event at all thresholds exceeds except the first
NO

one, i.e. after the 6th, 9th, etc. events if the threshold is 3.

159
 Chapter 5. Correlation and work with events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
What is the purpose of this option if we have On every threshold and skipping the first
threshold doesn’t seem to make any practical sense? To differently react to the first and
subsequent thresholds. For example, you can configure to send only the first correlation event

BU
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

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

ST
tell you about it later.

DI
RE
OR
ED
PI

Let’s further complicate the example and proceed with studying correlation rule settings. There is the
CO

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
BE

event with the values of the unique fields of the existing events within the bucket. If one of the events
in the 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.
TO

Unique fields allow you to implement the following scenario: suppose you do not consider 3
connections 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.
T
NO

To achieve this, specify SourceAddress for the Unique fields parameter. Buckets will still count

160
 Chapter 5. Correlation and work with events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
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.

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
ED

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
PI

followed by a successful logon. This rule requires two selectors:

CO

• 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
necessary information) and the threshold of 50

• An event selector with the "successful login attempt" condition and threshold 1
BE

• Identical fields: SourceAddress, DestinationHostName, DestinationUserName, so as not to

confuse the password bruteforce attempts for different user accounts on different computers
TO

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.
T
NO

161
 Chapter 5. Correlation and work with events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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,
OR
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
PI

selectors 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,
CO

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 parameter is based on the order of selectors.
BE

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.
TO
T
NO

162
 Chapter 5. Correlation and work with events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

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
timeout action. On timeout actions are only used if the rule has a selector with the Recovery option
OR
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
ED

rare cases when a dangerous object was detected but the protection solution has failed to delete it.
How can you configure this in KUMA?

If an object has been processed successfully, a detection event will be followed by a disinfection or
PI

deletion event. If an object has failed to be neutralized, there will be no disinfection or deletion event
after the detection event. You can use this difference to configure the rule.
CO

The settings are as follows:

• Identical fields — threat identifier (or file name if the protection application does not assign
BE

unique identifiers to detections)

• Window — 1 hour

• First selector — ‘dangerous object detected’ event with threshold 1

TO

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

rule conditions check, the rule will not be applied

NO

163
 Chapter 5. Correlation and work with events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
• Action — On timeout, so that the conditions for applying the rule are checked only after the
bucket’s lifetime expires

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

RI
You can use recovery selectors not only with the On timeout action. But On timeout actions only
work if the rule has a selector with the Recovery flag.

ST
Variables

DI
RE
OR
ED
PI
CO

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

There are several types of functions that you can call in variables:

• Operations with strings

TO

• Operations with timestamps

• Mathematical operations
T

• Operations with active lists and dictionaries

NO

164
 Chapter 5. Correlation and work with events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
You can use the result:

• To enrich correlation events

BU
• When working with active lists and tables

• In selectors of correlation rules when creating filters for events

RI
• In correlation rules, when looking for Identical and Unique fields

There are two types of variables:

ST
• Global variables are declared at the correlator level and are available in any correlation rule.
The same variable can take different values in different selectors of the same rule, depending

DI
on the filter conditions

• Local variables are declared at the level of selectors in the correlation rules

RE
OR
ED
PI
CO

For example, you want to pay special attention to cases when the KATA IDS technology detects
BE

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
TO

instructions are as follows:

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

extract_from_timestamp(DeviceReceiptTime, ‘wd’)
NO

165
 Chapter 5. Correlation and work with events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
• In the selector filter, specify the conditions for the KATA product and IDS technology, and
another condition if the variable value is Saturday or Sunday. When referencing the variable,
type $ before its name.

BU
• To display the value of a variable in a correlation event:

◦ Add the variable to propagated fields

RI
◦ Add the variable to an enrichment rule that will write its value to a field of the correlation
event

ST
You can use variables in standard correlation rules to compare values of different fields in different
selectors. This is demonstrated in one of our labs.

DI
RE
OR
ED
PI
CO

Here is the list of functions that you can call in variables in Kaspersky Unified Monitoring and Analysis
Platform.

The syntax for declaring various variables is described in detail in the online help at
BE

https://support.kaspersky.com/help/KUMA/3.2/en-US/234740.htm

Operations with strings:

TO

• len — returns the number of characters in the string

• to_lower — converts data to lowercase

• to_upper — converts data to uppercase

T
NO

166
 Chapter 5. Correlation and work with events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
• append — adds characters to the end of the string

• prepend — adds characters to the beginning of the string

BU
• substring — allows you to cut out a substring from a string

• index_of — returns the first position of a character or substring in a string; the index is zero-
based

RI
• last_index_of — returns the last position of a character or substring in a string; the index is
zero-based

ST
• tr — truncates the string

• replace — replaces all occurrences of sequence of characters A with sequence of characters B

DI
in a string

• regexp_capture — allows you to get data that matches a regular expression from the source

RE
string

• regexp_replace — replaces sequences of characters that match a regular expression with

another sequence of characters
OR
The index_of and last_index_of functions together with the substring function lets you get a substring
without using regular expressions in correlation rules. This way, you can reduce the load on the
correlator. This method requires approximately 2 times fewer computing resources compared to
regular expressions.
ED

Operations with timestamps:

PI

• now — returns the current time in epoch format

• extract_from_timestamp — allows you to get information about time in the form of year, month,
CO

day, hour, minute, second, or day of the week from a timestamp

• parse_timestamp — allows you to convert a timestamp into epoch format

• format_timestamp — allows you to convert a timestamp into RFC3339 format

BE

• 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 format
TO

Mathematical operations allow you to add, subtract, multiply, divide and:

• Round
T

• Ceil — round up
NO

167
 Chapter 5. Correlation and work with events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
• Floor — round down

• Abs — get the absolute value of a number

BU
• Pow — exponentiate

Operations with active lists, context tables and dictionaries:

RI
• active_list — gets information about a value in the specified column from AcliveList

ST
active_list('ActiveList,'Score',RequestUrl)

• context_table — returns the value of the specified field

DI
context_table('tbl1', 'list_field1', 'key1', 'key1_val')

RE
• dict — gets information about the value that corresponds to the specified key

dict('exampleDictionary',SourceAddress)
OR
• table_dict — gets information about a value in the specified column

table_dict('TableDict','SID',SourceUserName)
ED

Active lists and context tables

PI
CO
BE
TO
T
NO

168
 Chapter 5. Correlation and work with events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
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.

BU
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

RI
connections to dangerous addresses on the other hand happen quite often and do not imply a serious
incident.

ST
To sort these situations, you need two selectors and the Order by parameter:

• The first selector will pick out ‘dangerous URL detection in email’ events with threshold 1

DI
• The second selector will pick out ‘dangerous URL detection in web traffic’ events with
threshold 1

RE
• 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
OR
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
ED

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.

Instead, you can adopt a different approach: configure a rule to fill in a list with addresses found in the
PI

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
CO

numerous events with a lot of fields.

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
BE

resource, each of these lists will have its own status.

TO
T
NO

169
 Chapter 5. Correlation and work with events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

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

Correlation rules fill active lists. The Actions tab contains the Active lists update area in addition to
T

the Output and Loop actions, where you can specify which lists to fill with what values from the
NO

170
 Chapter 5. Correlation and work with events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
correlation event when applying the rule.

A single rule can fill multiple lists or perform multiple operations on a single list. The following

BU
operations are available:

• set — add or update an entry

RI
• del — remove an entry from the list

• get — enrich the correlation event with data from the list (we will provide an example later)

ST
• sum — add a constant, the value of a correlation event field, or the value of a local variable to
the value of a field from the active list

DI
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

RE
a 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
OR
• Mapping defines the key attributes. Every attribute has a name (arbitrary) and a value. You can
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
ED

If a key exists already, a set operation will overwrite its attributes with the values from the fields of the
new event.

The del operation has only the Key fields parameter; it deletes the record with the corresponding key.
PI
CO
BE
TO
T
NO

171
 Chapter 5. Correlation and work with events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
Any rule can fill a list. However, simple and standard rules always create correlation events. Alert
creation can be disabled. To silently fill a list without creating correlation events, use operational rules.
OR
Operational rules are designed for filling active lists and context tables (we will talk about them later).
An operational rule has the following settings:

• A selector without a threshold. It defines conditions for events whose fields will be added to the
ED

list

• The action (update the specified active list) with the trigger On every event; names of the key
PI

fields for the list and the fields from which the context will be taken are also specified here

A selector without a threshold means that operating rules react to individual events, i.e. behave like
CO

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
BE

events.
TO
T
NO

172
 Chapter 5. Correlation and work with events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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.
OR
Since active lists reside in the correlator’s memory, to view their contents, you need to open the list of
Active services, select the Correlator service and click the button Go to active lists.
ED
PI
CO
BE
TO

The Go to active lists command displays all active lists of the correlator, the number of entries in them,
the list size and the path to its file on the disk (where the list is cached). An analyst can export, import
T

or clear a list.
NO

173
 Chapter 5. Correlation and work with events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
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

BU
or 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.

RI
ST
DI
RE
OR
ED

To access the contents of an active list, you can use the following methods in a correlation rule
selector:
PI

• inActiveList operator. This condition has two parameters:

CO

• Name of the active list

• Key fields of the event that you use to check if the list contains such a record

Values of the event’s key fields are compared only with the keys of the list’s entries. Attributes
BE

of these entries do not play any role in this case.

• active list operand. This condition has several parameters:

• Name of the active list

TO

• Key fields of the event that you use to check if the list contains such a record

• 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 [email protected] value
T
NO

174
 Chapter 5. Correlation and work with events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
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.

BU
• A variable with the active_list function

RI
ST
DI
RE
OR

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
ED

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 on the Actions tab, select to
perform the get operation on the active list and write the contents of the respective entry attribute from
PI

the active list into some field of the correlation event.

CO
BE
TO
T
NO

175
 Chapter 5. Correlation and work with events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
Context tables are an evolution of the concept of active lists. They perform similar tasks and have
similar functionality. In general, the approach to working with them is the same. Context tables, unlike
OR
active lists, have a more strict and ordered structure. In this sense, they are much more like database
tables. Fields in context tables are typed.

A context table (as well as an active list) can be used in different correlators. In this case, a separate
ED

context table entity is created for each correlator. Thus, the contents of the context tables used by
different correlators are different, even if the ID and name of the context tables are the same. Context
tables let you work with data arrays, for example, a context list field can contain an array of IP
PI

addresses, numbers, strings, etc.

You can add, edit, delete, import and export records in a correlator context table.
CO

When a record is deleted from a context table after its lifetime expires, a service event is created in
the correlator. These events only exist in the correlators. They are not forwarded to other destinations.
Service events are sent for processing by the correlation rules of the correlator where the context
BE

table operates. You can configure correlation rules to monitor these events; this can help you process
security events and identify threats.

Context tables can be used in correlation rules. Here, too, everything is very similar to active lists,
TO

except that one more additional operation can be performed with a context table: merge. This
operation lets you add the value of a field from a correlation event, a local variable or a constant to the
existing value of a field in the context table.
T
NO

176
 Chapter 5. Correlation and work with events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
Retrospective scanning

BU
RI
ST
DI
RE
Typically, a correlator only works with real-time events that it receives from collectors.
OR

But sometimes, you need to apply correlation rules to historical events. Retrospective scanning
serves this purpose. The Retroscan command is available on the three-dot menu in the upper right
corner of the event search page.
ED

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)
BE

The analyst does not explicitly configure which events to retroscan. Instead, the task uses the current
search settings:

• Query (without taking into account the limit)

TO

• Timespan

• The storage to search for events

T

The task is performed by the KUMA core (kuma-core):

NO

177
 Chapter 5. Correlation and work with events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
• The core queries the storage

• The storage returns the list of events

BU
• The core forwards the events to the correlator configured in the task and specifies which rules
to apply

The created task appears on the Task manager page, where the analyst can monitor its progress.

RI
When 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

ST
field that stores the unique identifier of retroscanning.

You can re-run a retroscan task using its three-dot menu. The new correlation events will have a

DI
different ReplayID.

Retroscan is also useful when debugging correlation rules. To test a rule, you can run it in Retroscan

RE
mode on the corresponding historical events instead of reproducing incidents in real time.
OR
ED
PI
CO
BE
TO
T
NO

178
 Chapter 6. Response, alerts, reports and monitoring KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
Chapter 6. Response, alerts, reports and monitoring
6.1. Alerts

BU
Correlator outputs correlation events. They are not alerts by themselves, but when a correlation event
appears, the core always either creates a new alert or supplements an existing alert (retroscanning

RI
does not necessarily create alerts).

ST
DI
RE
OR
ED

The general principle of generating alerts is as follows. When a new correlation event appears, the
core checks the rule that created the event:
PI

• If there are no open alerts for this rule, a new alert is created with a link to the correlation event
CO

• 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

An alert accumulates correlation events up to a threshold (16MB), after which the alert is considered
BE

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.

Analysts can:
TO

• 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)
T

• Assign an alert to themselves or other employees

NO

179
 Chapter 6. Response, alerts, reports and monitoring KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
• Escalate, i.e. convert an alert into an incident

In Kaspersky terms, an incident is a confirmed alert. An incident can be bound to several alerts;

BU
for example, if an analyst discovers initial compromise and lateral movement during an
investigation and links these alerts to a single incident

• Close an alert for one of the following reasons: processed, incorrect data or an incorrect

RI
correlation rule

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

DI
RE
OR
ED
PI

Click an alert to open its details. The analyst can perform all processing activities here: change
CO

priority, assign, escalate and close.

Alert details include:

BE

• 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

TO

• Endpoints related to these events (including assets)

• User accounts related to these events

T
NO

180
 Chapter 6. Response, alerts, reports and monitoring KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
You can open a card with the details of an associated asset or user from an alert.
OR
Each alert also contains a history of changes where an analyst can leave comments for other
analysts, for example.
ED
PI
CO
BE
TO

You can also consult all events related to the alert: correlation and base.

It is worth noting that an alert is a kind of virtual container into which all related artifacts, events,
T

assets and accounts are copied. Alerts are stored in the MongoDB database on the KUMA core.
NO

181
 Chapter 6. Response, alerts, reports and monitoring KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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:
OR
• Host — smtp server address

• Port — smtp server port

• Secret — authentication parameters; you can leave them empty if the server supports
ED

anonymous connections

• From — the address that will be specified in the From field of the messages
PI

The Monitoring notifications option pertains to event source monitoring policies; this is described in
the corresponding section of our course.
CO

SMTP settings are also used for emailing reports and notifications to KUMA users.
BE
TO
T
NO

182
 Chapter 6. Response, alerts, reports and monitoring KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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.
OR
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 following
format:
ED

{{.EventField}}
PI

• Template — message where you can also use field values in the same format.
CO

Field names are case sensitive


BE
TO
T
NO

183
 Chapter 6. Response, alerts, reports and monitoring KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
The last step is to set up a notification rule.
RE
OR
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

184
 Chapter 6. Response, alerts, reports and monitoring KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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.
OR
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
ED

group, then a separate alert will be created for such a correlation event. The alert name will have the
following format:
PI

<Name of the correlation rule> (<Name of the segmentation rule>)

CO

A selector works with correlation events in a segmentation rule; therefore, it is important that the
correlation event must be enriched with the necessary fields from the base event.

This is configured in Settings | Alerts | Segmentation rules.

BE

Let us remind you that alerts are generated as a result of correlation rule triggering, i.e. each alert is
related to a correlation rule.
TO

Users complained about the following when working with alerts in KUMA 2.0:

• An alert accumulates correlation events until its status changes to Closed, i.e. regardless of
whether this alert is assigned to someone or escalated to an incident, events continue to
T

accumulate, and a new alert is not created

NO

185
 Chapter 6. Response, alerts, reports and monitoring KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
• Alert size is limited to 16MB; when this threshold is reached, it is considered to be full and
correlation events are no longer added to it. But new alerts are not created either, so it is
important to monitor overflowing alerts

BU
• Segmentation rules work only for specific field values and these values have to be specified
manually. For example, there is a correlation rule that detects brute force attempts. The
correlation event contains the value of the DestinationUserName field: the account whose

RI
password is being brute-forced. Since a correlation rule tracks behavior, all events end up in
the same alert no matter what account is brute-forced.

ST
To have different alerts generated for different values of the DestinationUserName field, the
analyst can configure segmentation rules. The problem is that you CANNOT simply request

DI
"Create a separate alert for each unique DestinationUserName". You must explicitly specify the
account for which a separate alert must be created. For example, if [email protected] and

RE
[email protected] accounts are specified in a rule, a separate alert will be created for each of them
in case of a brute-force attempt; but if there is an attempt to brute-force [email protected], the
correlation event will be sent to a common alert.
OR
All these inconveniences were fixed in KUMA starting with version 2.1:

• An alert accumulates correlation events while it has the New status. As soon as its status
changes, the next triggering of the correlation rule generates a new alert
ED

• You can limit the number of correlation events in a rule. When the threshold is reached, a new
alert will be created

• In the segmentation rules, you can specify the field based on which segmentation will be
PI

performed. In the described example, it is enough to specify the DestinationUserName field in

the segmentation rule, and a separate alert will be created for each unique value of this field.
CO

You can add several fields; in this case, a separate alert will be created for each unique set of
values
BE
TO
T
NO

186
 Chapter 6. Response, alerts, reports and monitoring KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
Alert segmentation is configured in two stages in KUMA:
RE
OR
• Create a segmentation rule as a resource

• Link the segmentation rule to a correlation rule in Settings | Alerts

ED
PI
CO
BE
TO

The following kinds of segmentation rules are available:

• ‘By filter’ is the behavior used in KUMA 2.0

T
NO

187
 Chapter 6. Response, alerts, reports and monitoring KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
• By event limit—specify the threshold value for the number of correlation events

• By identical fields—specify one or more fields; a separate alert will be generated for each
unique value or set of values

BU
Also, for each type of segmentation rule, you can configure alert naming rules.

RI
An alert name will contain name of the correlation rule in any case, but you can also use Go
templates to add a suffix: plain text or values of the necessary event fields.

ST
DI
RE
OR
ED

This is an example of a list of alerts generated as a result of triggered segmentation rules.

PI

Red frame: After an alert status changes from New to any other, a new alert is created next time
CO

when the correlation rule is triggered.

Green frame: If there is no segmentation rule of the ‘By event limit’ type, a new alert accumulates
events and may overflow. As a result, nothing is added to an overflowed alert. If there is a
BE

segmentation rule of the ‘By event limit’ type, a new alert will be created every time when the
threshold is reached. In our example, the threshold was reached 2 times.

Yellow frame: Segmentation rule of type ‘By identical field’ with two fields: SourceUserName and
TO

SourceHostName. Each unique set of values generates a separate alert and adds values of these
fields to its name.

By default, the value of the {{.Timestamp}} field is also added to the name of an alert generated using
T

segmentation. It is not very useful, and the analyst should think the naming over.
NO

188
 Chapter 6. Response, alerts, reports and monitoring KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
Multiple segmentation rules may be created for one correlation rule. In this case, segmentation rules
are applied sequentially, and all their naming rules add the respective suffixes separated with "|" (the
topmost line in the screenshot). The analyst should keep this in mind to avoid duplication of suffixes in

BU
different segmentation rules.

6.2. Response

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

ST
DI
RE
OR
ED
PI

Incidents need to be responded to. Kaspersky Unified Monitoring and Analysis Platform saves time by
automatic response to correlation events:
CO

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

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
TO

• Launching a Kaspersky Industrial CyberSecurity for Networks task — to change the status of
the device in the industrial network

• Via Active Directory — for example, to block a user account, reset its password, add or remove
T

a user from a group.

NO

189
 Chapter 6. Response, alerts, reports and monitoring KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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
OR
(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
PI

Security for Linux

• The task must be created for a set of computers (rather than a group)
CO

KUMA ignores tasks that do not meet these requirements.

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
BE

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.
TO
T
NO

190
 Chapter 6. Response, alerts, reports and monitoring KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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
OR
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,
ED

planned synchronization takes place every 15 minutes.

PI
CO
BE
TO
T

To run Kaspersky Security Center tasks automatically, create a response resource with the following
NO

191
 Chapter 6. Response, alerts, reports and monitoring KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
settings:

• Kind — ksctasks

BU
• Kaspersky Security Center Task — one of the tasks that meets the requirements

• 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

RI
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

ST
computer is usually specified in the DestinationAssetID field

• Filter — an additional filter to run the task when some additional conditions are met rather than

DI
every time when the correlation rule is applied

You need to add the created response resource to the correlator configuration. Since response is a

RE
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.
OR
ED
PI
CO
BE

Kaspersky Security Center tasks provide limited capabilities and are applicable only to assets
imported from Kaspersky Security Center.
TO

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, you can pass event field values to it as parameters.
T
NO

Copy the prepared script to the following folder of the correlator service

192
 Chapter 6. Response, alerts, reports and monitoring KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
/opt/kaspersky/kuma/correlator/<service identifier>/scripts

Then you need to configure a response resource with the following settings:

BU
• Kind — script

• Timeout — how long to wait for the script to complete

RI
• Filter — additional conditions for a response (to run the script not after every application of
each correlation rule)

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

DI
format:

{{.EventField}}

Field names are case-sensitive.

RE

OR
Add the configured resource to the correlator service configuration and restart the service.

6.3. Monitoring and reports

Kaspersky Unified Monitoring and Analysis Platform provides the dashboard and reports to show the
ED

overall security situation. They consist of widgets that visualize various statistics.
PI
CO
BE
TO
T

A dashboard layout defines which widgets to show, what to show on them and how to position widgets
NO

193
 Chapter 6. Response, alerts, reports and monitoring KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
on the page. Each user can create a custom set of layouts and switch between them to get different
slices of network status.

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

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

ST
DI
RE
OR
ED
PI

Every layout has general settings and a set of widgets, each with its own additional settings.

General layout settings include:

CO

• Refresh rate (for all layout’s widgets)

• The reporting period (widgets can use the layout’s period or have their own)
BE

• 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.
TO
T
NO

194
 Chapter 6. Response, alerts, reports and monitoring KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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
OR
the reporting period and a few auxiliary display options.

Several dozen preset widgets are grouped into categories:

• Alerts
ED

• Assets

• Incidents
PI

• Event sources

• Users
CO

• Active lists

• Events
BE

The complete list of widgets is available in the online help at

https://support.kaspersky.com/help/KUMA/3.2/en-US/218042.htm
TO
T
NO

195
 Chapter 6. Response, alerts, reports and monitoring KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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
OR
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
ED

layout reporting 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.
PI

The SQL query parameters depend on the visualization method:

CO

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

• For a table, you need to specify which event fields to display in the table columns and
BE

(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)
TO

• 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
T
NO

196
 Chapter 6. Response, alerts, reports and monitoring KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

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

Reports are built from the same elements as the dashboard, but they can be generated on a
schedule, saved to a file and emailed.
T

Reports are generated to templates (similarly to dashboard views that are based on layouts).
NO

197
 Chapter 6. Response, alerts, reports and monitoring KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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
OR
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.

Available widgets and their settings are exactly the same as in dashboard layouts.
ED
PI
CO
BE
TO

You can set up a schedule for generating a report (via the three-dot menu of its template). You can
T

choose the time when to create a report and the frequency in days, weeks, months or years.
NO

198
 Chapter 6. Response, alerts, reports and monitoring KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
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
ST
DI
RE
OR

The following report formats are available in KUMA in addition to HTML: PDF, CSV, Split CSV, Excel.
ED

Split CSV is an archive with CSV files, where each widget is saved as a separate file. To ensure
correct generation of PDF reports, you need to install additional packages on the Core host.
PI

The following packages are required for Oracle Linux:

CO

• nss

• gtk2

• atk
BE

• libxkbcommon

• libdrm

• at-spi2-atk
TO

• mesa-libgbm

• alsa-lib
T

An example of a command that you can use to install additional packages:

NO

199
 Chapter 6. Response, alerts, reports and monitoring KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
sudo yum install nss gtk2 atk libxkbcommon libdrm at-spi2-atk
mesa-libgbm alsa-lib

BU
The packages required for Astra Linux are listed in the documentation https://support.kaspersky.com/
help/KUMA/3.2/en-US/231034.htm

6.4. MITRE ATT&CK matrix coverage

RI
Mitre Att&ck (Adversarial Tactics, Techniques & Common Knowledge) is a globally-accessible

ST
knowledge base of adversary tactics and techniques based on real-world observations created by the
Mitre Corporation.

DI
Information is presented in the form of matrices in the MITRE ATT&CK knowledge base. Each matrix
is a table where column headers correspond to cybercriminals' tactics, i.e. the main stages of a cyber

RE
attack or preparation for it, and cells correspond to techniques, i.e. the methods of implementing these
tactics. For example, according to MITRE ATT&CK, data collection is an attack tactic, and collection
methods, such as automated collection or collecting data from removable media, are techniques.
OR
ED
PI
CO
BE

KUMA lets you evaluate how your correlation rules “cover” the elements of the MITRE matrix. To do
this, you need to download a list of elements in the form of a json file, load it into KUMA, map your
TO

correlation rules to MITRE techniques, export this information from KUMA and load it into MITRE
ATT&CK Navigator.
T
NO

200
 Chapter 6. Response, alerts, reports and monitoring KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
The MITRE list is available at https://github.com/mitre/cti/releases; you need to select the necessary
release. KUMA 3.2 supports version 14.1.
OR
ED
PI
CO
BE

In KUMA, upload the list to Settings | Common | MITRE Techneques List Settings. You can also
TO

see what information has already been uploaded.

T
NO

201
 Chapter 6. Response, alerts, reports and monitoring KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
After uploading the list, you can map your correlation rules to the loaded techniques. You can do this
in the correlation rule settings.
OR
ED
PI
CO
BE

After mapping the correlation rules, you can export a file for MITRE ATT&CK Navigator from KUMA.
TO

To do this, click the three dots icon under Resources | Correlation rules.
T
NO

202
 Chapter 6. Response, alerts, reports and monitoring KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
Then open https://mitre-attack.github.io/attack-navigator/, and in the Open Existing Layer area click
Upload form local to upload the file exported from KUMA.
OR
ED
PI
CO
BE

6.5. Metrics
TO

In this section, we will talk about monitoring event sources and about the performance characteristics
of KUMA services that are displayed as metrics.
T
NO

203
 Chapter 6. Response, alerts, reports and monitoring KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
There is the Sources status section in the side menu of the KUMA interface. It displays the list of
sources that send data to collectors. A source is a virtual entity that has the following parameters:
OR
• DeviceProduct

• DeviceHostName

• DeviceAddress
ED

• DeviceProcessName

• Tenant
PI

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
CO

week.

The list of sources is refreshed and events are counted every minute.
BE

You can open events of a particular source from this page: select the required source and click the
events link. This will get you to the Events section. Conditions of the search query will be set up
automatically.
TO
T
NO

204
 Chapter 6. Response, alerts, reports and monitoring KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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.
OR
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):

• By EPS — the number of events per second over the specified period of time. The average
ED

value for the entire period is calculated, but you can additionally track peaks during the
specified intervals
PI

• By count — the number of events over the specified period of time

The policy must be applied to an event source. After that, the source status can be either green
CO

(everything is fine) or red (is abnormal) — in this case, a Monitoring event is generated. You can also
configure emailing notifications to any address.
BE
TO
T
NO

205
 Chapter 6. Response, alerts, reports and monitoring KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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
OR
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
PI

create. The Grafana solution visualizes metrics in the console.

CO
BE
TO
T
NO

206
 Chapter 6. Response, alerts, reports and monitoring KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
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
OR
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

207
 Chapter 6. Response, alerts, reports and monitoring KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
The following metrics can be useful for Collector services:

• IO | Processing EPS — input collector flow — the number of events processed per second

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

RI
events is buffered, everything is fine. If the buffer grows, it may mean that the destinations
(correlator, storage) are unavailable

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

DI
resource)

• Normalization | Raw & Normalized event size — shows which collectors retain raw events and

RE
the average sizes of raw and normalized events

• Normalization | Errors — the number of normalization errors per second. It grows if the format
of incoming events does not match the normalizer type
OR
• 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

• Aggregation | EPS — the number of input and output events per second in an aggregation rule.
ED

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

• Enrichment | Errors — the number of enrichment source access errors per second
CO

• 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
BE
TO
T
NO

208
 Chapter 6. Response, alerts, reports and monitoring KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

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
ED

second

• Correlation | Buckets — the current number of correlation groups (buckets) inside a correlation
PI

rule (only for Standard rules). Correlation buckets 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.
CO

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

rule

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

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
operating system
T

• OS | all metrics — general metrics of the operating system, show utilization of CPU, RAM, Disk
NO

and the average load on the system

209
 Chapter 6. Response, alerts, reports and monitoring KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
BU
RI
ST
DI
RE
The following metrics can be useful for Storage services:
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)
PI

• ClickHouse | Insert | SELECT QPS — the number of unsuccessful read requests (per second)

• ClickHouse | Replication | Active Connections — the number of active connections to the

CO

ClickHouse cluster nodes. Normally, this number should be equal to the number of nodes in the
ClickHouse cluster

• ClickHouse | Replication | Read-only Replicas — the number of ClickHouse replicas that are in
BE

read-only mode. Normally, there should be none

• ClickHouse | Replication | Active Replication Fetches — the number of active data replication
processes at the moment
TO

• Agent | all metrics — general metrics of each storage service that 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

KUMA also monitors metrics of the agent, core and other components. For the full list of metrics,

210
 Chapter 6. Response, alerts, reports and monitoring KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

D
TE
consult the online help at https://support.kaspersky.com/KUMA/3.2/en-US/218035.htm

BU
RI
ST
DI
RE
OR
ED
PI
CO
BE
TO
T
NO

211
 KL 034.3.2

Kaspersky Unified
Monitoring and Analysis
Platform

Lab guide
Table of contents
1. Install Kaspersky Unified Monitoring and Analysis Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Task A: Install KUMA services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Task B: Change the web console administrator password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Task C: Get acquainted with demo resources and create storage services. . . . . . . . . . . . . . . . . . 14
Task D: Create a correlator service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Task E: Create a collector service and send a test event to KUMA . . . . . . . . . . . . . . . . . . . . . . . . 36
Task F: Add a Kaspersky Endpoint Security license key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2. Configure receiving events from Windows Event Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Task A: Create a service account for the agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Task B: Create a secret resource for the kuma account. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Task C: Configure the KUMA agent resource to collect Windows events via WMI . . . . . . . . . . . . 65
Task D: Configure a collector to receive Windows events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Task E: Install the KUMA agent service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Task F: Make sure events arrive. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3. Configure receiving events from a Windows DNS analytic log (optional) . . . . . . . . . . . . . . . . . . . . 85
Task A: Create a collector. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Task B: Create an ETW session. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Task C: Configure and install a KUMA agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Task D: Make sure events arrive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
4. Configure receiving Linux events (optional). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Task A: Create a resource with a collector configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Task B: Install the collector service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Task C: Create a resource with a Linux agent configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Task D: Install the Linux agent and check for events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Task E: Configure the Linux agent to start automatically (optional) . . . . . . . . . . . . . . . . . . . . . . . 122
Task F: Create and test a correlation rule (optional). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
5. Configure receiving Kaspersky Security Center events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Task A: Create a login for the collector account on the SQL server . . . . . . . . . . . . . . . . . . . . . . . 131
Task B: Configure and install the collector service for KSC events . . . . . . . . . . . . . . . . . . . . . . . 137
Task C: Make sure events arrive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
6. Configure receiving Kaspersky Anti Targeted Attack Platform events . . . . . . . . . . . . . . . . . . . . . . 148
Task A: Configure and install the collector service for KATA events. . . . . . . . . . . . . . . . . . . . . . . 148
Task B: Configure sending KATA events to the collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
7. Configure receiving EDR telemetry from KATA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Task A: Configure and install the collector service for EDR telemetry . . . . . . . . . . . . . . . . . . . . . 159
Task B: Make sure events arrive at the collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
8. Configure DNS data enrichment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Task A: Configure a DNS connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Task B: Add an enrichment rule to a collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Task C: Make sure enrichment works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
9. Configure GeoIP data enrichment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Task A: Convert a MaxMind GeoIP database to a format that KUMA supports . . . . . . . . . . . . . . 178
Task B: Upload geodata to KUMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Task C: Create an enrichment rule and add it to the collector . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
 Task D: Make sure enrichment works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
10. Import information about computers from Kaspersky Security Center . . . . . . . . . . . . . . . . . . . . 190
Task A: Configure an account for connections from KUMA in Kaspersky Security Center . . . . . 190
Task B: Configure a connection to Kaspersky Security Center . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Task C: Import assets and categorize them . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Task D: Manually add a computer to the list of assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
11. Configure event enrichment using Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Task A: Create an Active Directory connection in the KUMA settings . . . . . . . . . . . . . . . . . . . . . 209
Task B: Set up event enrichment in a KATA collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Task C: Make sure KATA events contain detailed information about the user . . . . . . . . . . . . . . . 214
12. Configure enrichment with CyberTrace data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Task A: Configure integration with the CyberTrace web user interface . . . . . . . . . . . . . . . . . . . . 218
Task B: Configure KUMA’s connection to CyberTrace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Task C: Add an event enrichment rule to the collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Task D: Make sure enrichment works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
13. Configure cold storage for events in KUMA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Task A:Mount disks for cold data storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Task B: Configure cold data storage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Task C: Make sure events arrive at the cold storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
14. Create a simple correlation rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Task A: View a KATA IDS event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Task B: Create a simple correlation rule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Task C: Add the rule to the correlator settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Task D: Test the rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
15. Create a standard correlation rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Task A: Study a KATA URL Reputation event. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Task B: Configure a standard correlation rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Task C: Add the rule to the correlator settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Task D: Test the rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
16. Configure an alert for events logged in a specific order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Task A: Prepare filters to select url_web and url_mail events from KATA . . . . . . . . . . . . . . . . . . 271
Task B: Create a standard correlation rule with an order by filter. . . . . . . . . . . . . . . . . . . . . . . . . 274
Task C: Add the rule to the correlator settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Task D: Test the rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
17. Create a correlation rule using a local variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Task A: Configure a simple correlation rule using a local variable . . . . . . . . . . . . . . . . . . . . . . . . 281
Task B: Add the rule to the correlator settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Task C: Test the rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
18. Create an operational correlation rule to fill an active list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Task A: Prepare an active list for malicious addresses found in email . . . . . . . . . . . . . . . . . . . . . 290
Task B: Create an operational correlation rule to fill the active list . . . . . . . . . . . . . . . . . . . . . . . . 291
Task C: Add the rule to the correlator settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Task D: Test the rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
19. Create a correlation rule using an active list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Task A: Create a correlation rule that uses an active list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Task B: Add the rule to the correlator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Task C: Test the rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
20. Run retrospective scanning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
Task A: Simulate an incident. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
Task B: Create a standard correlation rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
Task C: Add the rule to the correlator settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Task D: Perform retrospective scanning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
21. Configure a response by running a Kaspersky Security Center task . . . . . . . . . . . . . . . . . . . . . 315
Task A: Prepare a critical areas scan task in Kaspersky Security Center . . . . . . . . . . . . . . . . . . 315
Task B: Run the task via the computer properties in the KUMA web console . . . . . . . . . . . . . . . 320
Task C: Configure an automated response to an alert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Task D: Add supplementary fields to the correlation rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Task E: Update the correlator settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
Task F: Make sure the automated response works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
22. Configure a response by running a Kaspersky Endpoint Detection and Response task. . . . . . . 330
Task A: Create a secret resource for integration with KATA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Task B: Configure integration between KUMA and KATA EDR . . . . . . . . . . . . . . . . . . . . . . . . . . 332
Task C: Run a task via the computer properties in the KUMA web console. . . . . . . . . . . . . . . . . 334
23. Study reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Task A: Study and modify the preconfigured dashboard layouts . . . . . . . . . . . . . . . . . . . . . . . . . 348
Task B: Create a new layout with a widget about audit events . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Task C: Create a report based on an existing template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
24. Send a request to KUMA via the REST API (optional). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Task A: Create a token for sending requests to KUMA via the REST API . . . . . . . . . . . . . . . . . . 363
Task B: Task B: Find and close KUMA alerts via the REST API. . . . . . . . . . . . . . . . . . . . . . . . . . 367
25. Configure the Event router service (optional). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
Task A: Create a configuration for the Event router service . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
Task B: Install the Event router service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Task C: Configure event streams to pass through the Event router service. . . . . . . . . . . . . . . . 377
Task D: Make sure events arrive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
26. Create a rule based on an entropy calculation (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
Task A: Configure a normalizer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
Task B: Create a correlation rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Task С: Test the correlation rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Lab 1. Install Kaspersky Unified Monitoring and

Analysis Platform
Scenario

You are preparing to demonstrate the capabilities of Kaspersky Unified Monitoring and Analysis
Platform. To show a distributed installation, you are going to deploy KUMA services on three servers.

Contents

Task A: Install KUMA services

Task B: Change the web console administrator password

Task C: Get acquainted with demo resources and create storage services

Task D: Create a correlator service

Task E: Create a collector service and send a test event to KUMA

Task F: Add a Kaspersky Endpoint Security license key

Task A: Install KUMA services

Download the KUMA distribution from https://kas.pr/kuma32 to the kuma-core.abc.lab server. Prepare
a file that describes the distributed installation mode for Ansible, generate SSH keys for remote
installation and copy them to all target servers; then install the product.

The task is performed on admin-laptop.

All management will be performed remotely from the administrator’s workstation. The
administrator will use the ssh client to install and configure Kaspersky Unified Monitoring

and Analysis Platform and then the web interface of the product.

1
Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

1. Log in as
ABC\Administrator,
password: Ka5per$Ky

2. Start PuTTY (you can find

shortcuts for it on the
desktop, in the Start menu
and on the taskbar)

3. To connect to the server from

which KUMA will be installed
on the target servers, for the
Host Name (or IP address),
type kuma-core

4. Click Open

5. If the PuTTY Security Alert

window appears, click
Accept

6. Log in to the admin account

with the password
Ka5per$Ky

2
Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

7. Download the KUMA Platform distribution from https://kas.pr/kuma32:

curl -L https://kas.pr/kuma32 -o kuma.tar.gz

8. Download the KUMA license key (ask the instructor where to get it):

curl -L <link to the license key file> -o license.key

It is very important not to make a mistake here, because if there is a typo in the address,
the contents of the web page with the error will be downloaded and placed in the

license.key file. With such a "license", KUMA installation will fail.

9. Make sure the correct license file has been downloaded by running the command:

cat license.key | head -2

10. After executing the command, you should see the serial number.

If you see HTML tags instead of the serial number, then there was probably a mistake in

the URL when downloading the license. Correct the URL and download again.

3
Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

11. To make sure the kuma.tar.gz

and license.key files have
been created in the current
directory, run the following
command:

ls

12. Unzip the KUMA installation

files:

tar -xvzf
kuma.tar.gz

13. To make sure the kuma-ansible-installer directory was created as a result of unpacking the
kuma.tar.gz archive, run the following command again:

ls

14. Go to the folder with the KUMA distribution using the command

cd kuma-ansible-installer

15. Make sure the folder is not empty. In particular, make sure it contains the installation script
install.sh and file templates describing various installation types in *.yml format:

ls

16. Get acquainted with the structure and default installation parameters in the template file. To do so,
run:

mcedit distributed.inventory.yml.template

4
Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

To save time, we will not fill out the file manually.


17. Press F10 to exit the editor. Do not save changes

18. Run the following command to download a ready file:

curl -L https://kas.pr/kumayml -o distributed.inventory.yml

5
Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

19. Run the following command to open and view the downloaded file

mcedit distributed.inventory.yml

6
Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

7
Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

20. Press F10 to exit the editor. Do not save changes

21. To switch the console to superuser mode, run:

su

Enter the password Ka5per$Ky to elevate privileges


22. Generate a key to authenticate the KUMA installer on the SSH servers of the target machines:

ssh-keygen –N ""

23. When prompted for a file name (Enter file in which to save the key (/root/.ssh/id_rsa):), press
ENTER without typing any data

24. Copy the SSH key to all nodes where KUMA components will be installed, including kuma-
core.abc.lab. Let’s start with the kuma-core.abc.lab server:

ssh-copy-id –i /root/.ssh/id_rsa [email protected]

25. Confirm that you want to connect to the specified server:

yes

Enter the password Ka5per$Ky for the root user on the server you are copying the

key to

8
Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

26. Now, copy the key to kuma-storage-1.abc.lab:

ssh-copy-id –i /root/.ssh/id_rsa [email protected]

To save time, press the up key in the console to display the previous command.
Change the hostname in the command from kuma-core.abc.lab to kuma-storage-

1.abc.lab

27. Confirm that you want to connect to the specified server:

yes

Enter the password Ka5per$Ky for the root user on the server you are copying the

key to

28. Now, copy the key to kuma-storage-2.abc.lab:

ssh-copy-id –i /root/.ssh/id_rsa [email protected]

To save time, press the up key in the console to display the previous command.
Change the hostname in the command from kuma-storage-1.abc.lab to kuma-storage-

2.abc.lab

9
Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

29. Confirm that you want to connect to the specified server:

yes

Enter the password Ka5per$Ky for the root user on the server you are copying the

key to

30. Copy the license.key file to the folder with KUMA files:

cp /home/admin/license.key roles/kuma/files/

If you plan to activate the product using a key file, it must be located in this particular

folder and be named license.key.

31. Start installation of KUMA:

./install.sh distributed.inventory.yml

32. To accept the license agreement, enter:

Yes

10
Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

33. Wait for the installation to complete. You should see a message stating that the process ended
successfully:

34. Scroll up the text in the terminal and make sure there are no messages about unavailability of
target hosts and no errors in the PLAY RECAP section:

unreachable=0
failed=0

35. Enter the following commands to exit superuser mode and the installer directory:

exit
cd ..

Task B: Change the web console administrator password

Open the KUMA web console in a web browser at https://kuma-core.abc.lab:7220. Log in as admin
using the password mustB3Ch@ng3d!. In the user management menu, set a new password for the
administrator.

The task is performed on admin-laptop.

11
Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

36. Start Google Chrome and go to https://kuma-core.abc.lab:7220

If the page does not open, in the PuTTY terminal connected to kuma-core, run the

reboot command to restart the server

If a browser warning about an insecure connection appears, select Advanced and then

Proceed to kuma-core.abc.lab (unsafe)

37. Log in as admin using the

password
mustB3Ch@ng3d!

38. Open the account settings:

click the Administrator
username in the lower left
corner and select Profile

12
Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

39. Click Change password

40. Enter the old password

mustB3Ch@ng3d! in the
Current password field

41. In the New password and

Confirm password fields,
type the new password:
Ka5per$Ky

42. Click OK

43. Set Email to [email protected]

44. Click Save

13
Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Task C: Get acquainted with demo resources and create

storage services
The web console already has some preset resource templates. Review the list of preconfigured
resources and create storage services based on the [OOTB] Storage resource.

The task is performed on admin-laptop.

45. In the KUMA web console, open the Settings section

46. Switch to the License subsection and make sure KUMA is activated with the license key

14
Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

47. Open Resources

48. Click the Active services tile

15
Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

49. Notice that the list includes only the core service so far. Click Add service

16
Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

50. Review the list of demo

resources (collector,
correlator, agent and storage)
available by default

51. Scroll down the list and

select the only available
storage resource: [OOTB]
Storage

52. Click Create service

53. Pay attention to the status of

the created storage service

The service status is shown in the respective column. The color red means that the
service is not running yet or is running with errors. To complete the process of creating a

service, you need to install it on the corresponding KUMA server. We will need the
identifier of the created service for the installation.

54. Open the properties of the [OOTB] Storage resource

To open the resource settings, click the resource name in the Name column.

55. Scroll down the list of
settings to ClickHouse
cluster nodes

56. In the FQDN field, change

the value to kuma-storage-
1.abc.lab; in the Shard ID,
Replica ID and Keeper ID
fields, leave the value 1

17
Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

57. Click the Add node button to

add configurations for kuma-
storage-2.abc.lab and kuma-
core.abc.lab nodes

58. For kuma-storage-2.abc.lab,

enter the following values in
the appropriate fields: FQDN:
kuma-storage-2.abc.lab

Shard ID 1

Replica ID 2

Keeper ID 2

59. Create a configuration for the

kuma-core.abc.lab node in a
similar manner and specify
the following values:

Shard ID 0

Replica ID 0

Keeper ID 3

60. Click Save

61. Select the created [OOTB] Storage service in the web console and click Copy ID to copy its
identifier to the clipboard

18
Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

62. Start PuTTY (you can find

shortcuts for it on the
desktop, in the Start menu
and on the taskbar)

63. To connect to the server

where we will install the
Kaspersky Unified Monitoring
and Analysis storage service,
in the Host Name (or IP
address) field, enter kuma-
storage-1

64. Click Open

65. If the PuTTY Security Alert

window appears, click
Accept

66. Log in to the admin account

with the password
Ka5per$Ky

67. To install the storage service, run the following command with these parameters (type everything
on a single line):

◦ core — address of the primary KUMA service, https://kuma-core.abc.lab:7210 in this case

◦ id — the copied service ID

sudo /opt/kaspersky/kuma/kuma storage --core https://kuma-

core.abc.lab:7210 --id <paste ID from the clipboard> --install

19
Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

After you enter the installation command, the terminal "freezes". You do not need to wait
until the command is executed, because it is waiting for the second storage service to

connect.

68. Return to the KUMA web console and click the Refresh icon next to the search box to check the
status of the storage service

The service is still red, but now the console displays the FQDN of the endpoint where we
have installed the service and the API port through which other KUMA services can

interact with it.

69. Click + Add service again to add a storage service to the second node of the ClickHouse cluster

70. Scroll down the list of demo resources and select [OOTB] Storage

71. Click Create service

20
Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

72. Make sure another storage service appears in the list

Both services are red, but they will both turn green when we install the service on the

kuma-storage-2.abc.lab server and add an allow rule for its API port.

73. Select the record of the created [OOTB] Storage service in the web console and click Copy ID to
copy its identifier to the clipboard

21
Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

74. Start PuTTY (you can find

shortcuts for it on the
desktop, in the Start menu
and on the taskbar)

75. To connect to the second

server where we will install
the other Kaspersky Unified
Monitoring and Analysis
storage service, in the Host
Name (or IP address) field,
enter kuma-storage-2

76. Click Open

77. If the PuTTY Security Alert

window appears, click
Accept

78. Log in to the admin account

with the password
Ka5per$Ky

79. To install the storage service, run the following command with these parameters (type everything
on a single line):

◦ core — address of the primary KUMA service, https://kuma-core.abc.lab:7210 in this case

◦ id — the copied service ID

sudo /opt/kaspersky/kuma/kuma storage --core https://kuma-

core.abc.lab:7210 --id <paste ID from the clipboard> --install

22
Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

80. Return to the KUMA web console and click the Refresh button to check the status of the storage
service

81. Make sure both [OOTB] Storage services have the green status now, which means that they are
running

Typically, after services are installed, it takes 2-3 minutes to start them and update their
status in the web console. If several minutes have passed and the services have not

changed their status to green, ask your instructor for help.

82. Click Add service again to add a storage service to the third node of the ClickHouse cluster

83. Scroll down the list of demo resources and select [OOTB] Storage

84. Click Create service

23
Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

85. Make sure one more Storage service appears in the list

86. Select the record of the created [OOTB] Storage service in the web console and click Copy ID to
copy its identifier to the clipboard

87. Return to the open PuTTY window with a connection to kuma-core

If you closed this window, run PuTTY (you can find shortcuts for it on the desktop, in the
Start menu and on the taskbar); in the Host Name (or IP address) field, type kuma-core;

then click Open. To log in, use the username admin and password Ka5per$Ky

24
Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

88. To install the storage service, run the following command with these parameters (type everything
on a single line):

◦ core — address of the primary KUMA service, https://kuma-core.abc.lab:7210 in this case

◦ id — the copied service ID

sudo /opt/kaspersky/kuma/kuma storage --core https://kuma-

core.abc.lab:7210 --id <paste ID from the clipboard> --install

89. Return to the KUMA web console and click the Refresh button to check the status of the third
storage service

90. Open Resources

91. Click Destinations

25
Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

92. Expand the tree on the left and select the OOTB node

93. Open the properties of the [OOTB] Storage resource

To open the resource settings, click the resource name in the Name column.

26
Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

94. Pay attention to the default

value of the resource’s URL
setting. The storage service
address is incorrect. Delete it

95. In the drop-down list, select

the first [OOTB] Storage
entry. As a result, the URL
setting of the resource will
receive the value kuma-
storage-1.abc.lab:7221

96. Click + Add

27
 Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

97. In the drop-down list, select

the second [OOTB] Storage
entry. As a result, the second
URL setting of the resource
will receive the value kuma-
storage-2.abc.lab:7221

98. Click Save

99. In the side menu, select Events

100. Click the Run query button below the query field to search the KUMA storage for events

101. Notice that the storage has already received an internal KUMA audit event. Open this event. Click
on an empty space within the row that contains the event (be careful not to click a value in any of
the columns).

28
 Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform


If the event is not found, try to increase the search time interval. Change it from 5 minutes
(the default value) to 15 minutes or 1 hour and repeat the search.

102. Review the information

available in the KUMA audit
event

Task D: Create a correlator service

Create a correlator service using the [OOTB] Correlator resource.

The task is performed on admin-laptop.

29
 Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

103. In the KUMA web console,

open the Resources section

104. Click Active services

105. Click Add service

106. Select the [OOTB] Correlator resource

107. Click Create service

108. Pay attention to the status of the created Correlator service

As with a storage service, to finish creating a correlator service, you need to install it on

the corresponding KUMA server.

109. Open the properties of the [OOTB] Correlator service

To open the service properties, click its name in the Service column

30
 Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

110. Switch to the Correlation section

111. Notice that the correlator contains a set of pre-configured correlation rules

31
 Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

112. Switch to the Routing section

113. Notice that the correlator sends events to the storage

The correct storage addresses are used since we have edited the [OOTB] Storage

destination resource

32
 Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

114. Switch to the Setup validation section

115. Note the recommended command syntax for installing the service with the specified settings on
the KUMA server

116. Copy the command to the clipboard by clicking the icon in the lower right corner of the code
block.

117. Open the window with the SSH session to the kuma-core.abc.lab server

If you closed PuTTY, start it and reconnect to kuma-core.abc.lab. Authenticate as admin


with the password Ka5per$Ky

33
 Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

118. Paste the command from the clipboard

119. Type sudo before the copied command to run it with superuser privileges; it should look as
follows:

sudo /opt/Kaspersky/kuma/kuma correlator --core https://kuma-

core.abc.lab:7210 --id <id from the copied command> --api.port
<port from the copied command> --install

120. Press ENTER to run the command; use the password Ka5per$Ky to elevate privileges

121. Return to the KUMA web console

122. Click Save in the correlator settings window

123. Go to Resources | Active services and click Refresh

124. Make sure the [OOTB] Correlator service has the green status now, which means that it is
running

125. Open Resources

126. Click Destinations

34
 Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

127. Open the properties of the [OOTB] Correlator resource

To open the resource settings, click the resource name in the Name column.

128. Pay attention to the default
value of the resource’s URL
setting. The correlator
service address is incorrect.
Delete it

129. In the drop-down list, select

the [OOTB] Correlator entry.
As a result, the URL setting
of the resource will receive
the value kuma-
core.abc.lab:7231

35
 Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

130. Click Save

Task E: Create a collector service and send a test event to

KUMA
Create a tcp collector service based on a demo resource. Download the selection designed for
sending test events from https://kas.pr/kuma_events to the kuma-core.abc.lab server and run a
command to replay a recorded event. In the KUMA web console, make sure the event arrives and is
saved to the storage.

The task is performed on admin-laptop.

131. In the KUMA web console, go to Resources | Active services

132. Click Add service

36
 Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

133. Select the [OOTB] CEF collector resource

134. Click Create service

135. Pay attention to the status of the created Collector service

As with other services, to finish creating a collector service, you need to install it on the

corresponding KUMA server.

136. Open the properties of the [OOTB] CEF service

To open the service properties, click its name in the Service column.

37
 Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

137. Switch to the Transport section

138. Pay attention to the port where the connector will receive events from sources

38
 Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

139. Switch to the Event parsing section

140. Click the round icon to open event parsing settings

141. Notice that the collector uses the [OOTB] CEF normalizer

We will not elaborate on these settings now; they will be covered later.

142. Click the X button to close the pane with event parsing settings

39
 Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

143. Open Routing

144. Notice that the collector sends events to the correlator and to the storage

40
 Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

145. Switch to the Setup validation section

146. Note the recommended command syntax for installing the service with the specified settings on
the KUMA server

147. Copy the command to the clipboard by clicking the icon in the lower right corner of the code
block.

148. Open the window with the SSH session to the kuma-core.abc.lab server

If you closed PuTTY, start it and reconnect to kuma-core.abc.lab. Authenticate as admin


with the password Ka5per$Ky

149. Paste the command from the clipboard

150. Type sudo before the copied command to run it with superuser privileges; it should look as
follows:

sudo /opt/kaspersky/kuma/kuma collector --core https://kuma-

core.abc.lab:7210 --id <ID from the copied command> --api.port
<port from the copied command> --install

151. Press ENTER to run the command

Enter the password Ka5per$Ky to elevate privileges


41
 Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

152. Return to the KUMA web console

153. Click the Save button in the collector settings

154. Go to Resources | Active services and click Refresh

155. If the service has the Update required status, select its checkbox and click the Update
configuration button

156. Click OK to confirm the

configuration update

157. Make sure the [OOTB] CEF service has the green status now, which means that it is running

42
 Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

158. Return to the window where an ssh session to the kuma-core.abc.lab server is opened

If you closed the previous session, start PuTTY, connect to the kuma-core.abc.lab server

and log in as admin with the password Ka5per$Ky

159. In the terminal, make sure you are logged on as the admin@kuma-core user and run the
following command to make sure you are in the /home/admin directory:

pwd

If the user or directory is incorrect, the easiest solution is to close the PuTTY session and

reconnect to kuma-core.abc.lab.

160. Create an events folder and download the events.zip archive into it

mkdir ~/events
cd ~/events
curl -L https://kas.pr/kuma32events -o events.zip

161. Unpack the copied archive

unzip events.zip

43
 Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

The contents of the archive you’ve downloaded may differ from what is shown in the

screenshot.

162. Send the recorded events to the collector:

sudo /opt/kaspersky/kuma/kuma tools load --raw --events event01

--cfg cef.cfg --replay 1

To confirm elevation of privilege, enter the password Ka5per$Ky


163. Open the KUMA web console and switch to the Events section

164. Click the Run query button to search the KUMA storage for events

165. Make sure a new event with the Network attack detected description in the Name column arrives
at the server

This is a network attack detection event from Kaspersky Security Center


Sometimes the command sends more identical events than you specify. This will not

interfere with the lab tasks.

44
 Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

166. Open this event

167. Review its contents

Task F: Add a Kaspersky Endpoint Security license key

In one of the subsequent labs, you will study KUMA’s response functions, including response via
Kaspersky Security Center. This functionality does not work without a license key.

The dc, ksc, kuma-core, kuma-storage-1, kuma-storage-2 and admin-laptop machines must be
powered on.

45
 Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

The task is performed on admin-laptop.

168. Get an activation code from

the instructor

169. In a new web browser

window, open the Kaspersky
Security Center web console
at https://ksc.abc.lab:8080

170. Log in to the system as

Administrator with the
password Ka5per$Ky

If a browser warning about an insecure connection appears, select Advanced and then

Proceed to ksc.abc.lab (unsafe)

46
 Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

171. In the KSC console, click the

gear icon to open the
administration server settings

172. Switch to the License keys section

173. Click the Select button

174. Click + Add new license key

47
 Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

175. Specify your activation code

176. Click Send

177. Select the Automatically

distribute license key to
managed devices checkbox

178. Click Save

179. Select the added license

180. Click OK in the lower-right corner of the page

48
 Lab 1. Install Kaspersky Unified Monitoring and Analysis Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

181. Make sure the new license is displayed as active

182. Click Save

Conclusion

In this lab, you have learned how to quickly set up a distributed installation of KUMA with all services
and settings required to receive and process CEF events. You have learned how to:

• Copy the KUMA installation files to the server from which the installation will be performed

• Start the installation

• Connect to the web interface and change the administrator password

• Create collector, correlator, and storage services in the web console

49
Lab 2. Configure receiving events from Windows Event Log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Lab 2. Configure receiving events from Windows

Event Log
Scenario

Scenario. You want to send events from Windows logs to KUMA. For this purpose, KUMA uses
collector services and a Windows Agent that collects events directly or through WMI queries. In our
labs, we perform this task by sending WMI queries to target devices.

A special KUMA agent service sends WMI queries. It can send queries locally and to remote devices.
The agent forwards the received raw events to the KUMA collector service, which normalizes and
processes them.

To successfully start the KUMA agent service, you need an account that has the Log on as a service
permissions; and to successfully receive events, this account must be able to read logs of all target
devices.

Contents

Task A: Create a service account for the agent

Task B: Create a secret resource for the kuma account

Task C: Configure the KUMA agent resource to collect Windows events via WMI

Task D: Configure a collector resource for Windows events

Task E: Install the services of the collector and KUMA agent

Task F: Make sure events arrive

Task A: Create a service account for the agent

A KUMA agent service of the wmi type needs a special account under which the agent service will be
started on an endpoint. You can use the same account to send WMI queries; in this case, it must also
be a member of the Event Log Readers group on the remote devices from which the agent will collect
raw events.

The dc, ksc, kuma-core, kuma-storage-1, kuma-storage-2 and admin-laptop machines must be
powered on.

50
Lab 2. Configure receiving events from Windows Event Log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

The task is performed on admin-laptop.

1. Run the Active Directory Users and Computers app as an administrator

For example, right-click the Start button, begin typing users in the search bar and under

the Active Directory Users and Computers app, select Run as administrator

2. Select the abc.lab | Users node

3. Click the Create a new user in the current container button to create a new account

51
Lab 2. Configure receiving events from Windows Event Log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

4. Set up the user

Full name kuma

User logon kuma

name

5. Click Next

52
Lab 2. Configure receiving events from Windows Event Log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

6. Specify the password for the

user: Ka5per$Ky

7. Clear the User must change

password at next logon
checkbox

8. Select the User cannot

change password and
Password never expires
checkboxes

9. Click Next to create the

account

10. Click Finish

11. Select the abc.lab | Builtin node

12. Double-click the Event Log Readers group to edit it

53
Lab 2. Configure receiving events from Windows Event Log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

13. In the Event Log Readers

Properties window, open the
Members tab

14. Click Add

15. In the Enter the object

names to select field, type
kuma

16. Click Check Names and

make sure the
[email protected] account has
been added to the field

17. Click OK to confirm the

selection

54
Lab 2. Configure receiving events from Windows Event Log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

18. Make sure the kuma account

has appeared in the
Members list

19. Click OK

20. Run the Local Security Policy app as an administrator

For example, right-click the Start button, begin typing local in the search bar, and under

the Local Security Policy app, select Run as administrator

55
Lab 2. Configure receiving events from Windows Event Log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

21. In the Local Security Policy window, open the Local Policies | User Rights Assignment node

22. Scroll down the list of settings and double-click Log on as a service to reconfigure it

56
Lab 2. Configure receiving events from Windows Event Log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

23. In the Log on as a service

Properties window, click
Add User or Group

24. In the Enter the object

names to select field, type
kuma

25. Click Check Names and

make sure the
[email protected] account has
been added to the field

26. Click OK to confirm the

selection

57
Lab 2. Configure receiving events from Windows Event Log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

27. Make sure the ABC\kuma

account has appeared in the
list

28. Click OK

29. Run the Computer Management app as an administrator

For example, right-click the Start button, begin typing computer in the search bar and

under the Computer Management app, select Run as administrator

58
Lab 2. Configure receiving events from Windows Event Log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

30. In the Computer Management window, open System tools | Local Users and Groups | Groups

31. Double-click the Event Log Readers group to edit it

59
Lab 2. Configure receiving events from Windows Event Log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

32. Notice that the list of

accounts is empty in the
Event Log Readers group

33. Click Add

34. In the Enter the object

names to select field, type
kuma

35. Click Check Names and

make sure the
[email protected] account has
been added to the field

36. Click OK to confirm the

selection

60
Lab 2. Configure receiving events from Windows Event Log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

37. Make sure the account

ABC\kuma ([email protected])
has been added to the group

38. Click OK

39. In the Computer Management window, right-click the Computer Management (local) node. In
the shortcut menu, select Connect to another computer

40. In the Another computer

field, type ksc

41. Click OK

61
Lab 2. Configure receiving events from Windows Event Log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

42. In the Computer Management (KSC) snap-in, open System Tools | Local Users and Groups |
Groups

43. Double-click the Event Log Readers group to edit it

44. Notice that the list of Event

Log Readers accounts is
empty on the ksc.abc.lab
device

45. Click Add

62
Lab 2. Configure receiving events from Windows Event Log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

46. In the Enter the object

names to select field, type
kuma

47. Click Check names and

make sure the
[email protected] account has
been added to the field

48. Click OK to confirm the

selection

49. Make sure the account

ABC\kuma ([email protected])
has been added to the group

50. Click OK

Task B: Create a secret resource for the kuma account

Create a new Secret resource with the credentials of the [email protected] account that you created in
the previous task.

The task is performed on admin-laptop.

63
Lab 2. Configure receiving events from Windows Event Log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

51. In the KUMA web console,

go to Resources | Secrets

52. In the left pane, select the

Main folder

53. Click Add folder

54. Name the folder Lab

55. Click Save

56. Select the Lab folder

57. Click + Add

64
Lab 2. Configure receiving events from Windows Event Log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

58. Specify the following:

a. Name: [Lab]
[email protected]

b. Tenant: Main

c. Kind: credentials

d. User: [email protected]

e. Password: Ka5per$Ky

59. Click Create new to create

the resource

60. Make sure a new entry has appeared in the list of secret resources: [Lab] [email protected]

Task C: Configure the KUMA agent resource to collect Windows

events via WMI
To install services in KUMA, you must first create a configuration for each service on the core side. In
a scenario that involves collecting Windows events via WMI, we need to prepare two services: the
KUMA agent service that will retrieve events via WMI, and the collector service that will receive events
from the agent, normalize them and pass them further along the KUMA event-processing pipeline.

In this task, you will create a KUMA agent configuration to collect Windows events.

The task is performed on admin-laptop.

65
Lab 2. Configure receiving events from Windows Event Log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

61. In the KUMA web console,

go to Resources | Agents

62. Click + Add to create a new

agent configuration

63. For Agent name, type [Lab]

Agent Windows WMI

64. Go to the Configuration

resource #1 tab

65. In the Connector area,

configure how the Windows
agent will query devices:

Name [Lab] Agent

Windows

Kind wmi

Defaul [Lab]
t [email protected]
crede
ntials

In the drop-down list, select the [Lab] [email protected] secret resource created in the
previous task. This resource will be used to send WMI queries to the target devices that

you will specify now. The [email protected] service account is perfect for this, because it has
the right to read logs of Windows devices, which you granted in the first task.

66
Lab 2. Configure receiving events from Windows Event Log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

66. In the Remote hosts section, start filling in the list of devices from which the agent will collect
events. Click on the empty area under the name of the Host column to start entering data

67. Add information about the first device:

Server admin-laptop

Domain abc.lab

68. Log type: select the Security and System checkboxes in the drop-down list

69. Secret: leave as default

70. Continue filling in the Remote hosts list. Click + Add to add a new entry to the list

Add ksc.abc.lab and dc.abc.lab to the list of devices from which events will be collected.
Set the values of the Domain, Log type and Secret fields similarly to the ones that we

previously configured for admin-laptop.

67
Lab 2. Configure receiving events from Windows Event Log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

71. For the ksc.abc.lab device, specify the following:

Server ksc

Domain abc.lab

Log type Security, System

Secret as default

72. Repeat the previous step for the dc.abc.lab device:

Server dc

Domain abc.lab

Log type Security, System

Secret as default

73. Scroll down to the Destinations section

74. In the Destinations section, specify the connection settings for the collector service where the
agent will forward the collected events:

Name [Lab] Windows WMI

Kind tcp

URL kuma-core.abc.lab:5140

68
Lab 2. Configure receiving events from Windows Event Log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Pay attention to the port number — it belongs to the [OOTB] CEF collector. In this lab, you
will not create a separate collector service to receive events from Windows logs. Instead,
we will reconfigure the CEF collector to handle events from two different sources. There is

no technical need for such a solution. We do this in the lab to demonstrate the
functionality.

69
Lab 2. Configure receiving events from Windows Event Log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

75. Switch to the Advanced

settings tab

76. Scroll down the list of

settings

77. In the Delimiter drop-down

list, select \0

78. Leave the default values for

all other settings and click
Create new

79. Make sure a configuration

has been created for the
[Lab] Agent Windows WMI
agent

Task D: Configure a collector to receive Windows events

Reconfigure the [OOTB] CEF WMI collector to receive events from the KUMA agent that you created
in the previous task.

The task is performed on admin-laptop.

80. Go to Resources | Active services and open the [OOTB] CEF collector

70
Lab 2. Configure receiving events from Windows Event Log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

81. Change the collector name to [OOTB] CEF WMI

82. Switch to the Transport section

83. In the Delimiter value field, select \0

Note that the same delimiters must be used in the agent settings and in the
configuration of the collector service that will receive data from the agent. In the agent

settings, we selected \0 for the delimiter, so we must choose the same value in the
collector settings.

71
Lab 2. Configure receiving events from Windows Event Log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

84. Switch to the Event parsing section

85. Switch to the Parsing settings tab

86. Specify the IP address 10.28.0.61 in the block with the [OOTB] CEF normalizer

87. Click the + Event source button

88. In the area that appears, specify the IP address 10.28.0.150

89. Select [OOTB] Microsoft Products for KUMA 3 as the normalizer for this block

90. Click Save

72
Lab 2. Configure receiving events from Windows Event Log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

91. In Resources | Active services, select the [OOTB] CEF WMI collector

92. Click the Restart button to restart the service and apply the new collector settings

93. Click OK to confirm the

configuration update

94. Verify that the status of the [OOTB] CEF WMI collector service is green. This means that it is up
and running without errors

73
Lab 2. Configure receiving events from Windows Event Log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Task E: Install the KUMA agent service

Install the agent service using the abc\kuma service account.

The task is performed on admin-laptop.

95. Run the WinSCP application:

open the Start menu and
begin typing winscp

74
 Lab 2. Configure receiving events from Windows Event Log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

96. Connect to the kuma-core

server:

a. For the Host name, type

kuma-core.abc.lab

b. In the User name field,

type root

c. For the Password, type

Ka5per$Ky

d. Click Login

97. Click Accept to confirm the

connection

98. In the left pane of WinSCP, open \Desktop\KUMA\

99. In the right pane of WinSCP, open the /home/admin/kuma-ansible-installer/roles/kuma/files

directory

100. Select the kuma.exe file

101. Click Download

75
 Lab 2. Configure receiving events from Windows Event Log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

102. Click OK to confirm copying

103. Make sure the kuma.exe file appears in the C:\Users\Administrator\Desktop\KUMA folder

104. Close WinSCP

105. In the KUMA web console,

go to Resources | Active
services

106. Click Add service to add the

KUMA Agent service for
Windows events

76
 Lab 2. Configure receiving events from Windows Event Log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

107. Select the agent

configuration that you
created during this lab: [Lab]
Agent Windows WMI

108. Click Create service

109. Select the created [Lab] Agent Windows WMI service in the web console and click Copy ID to
copy its identifier to the clipboard

110. Run Windows PowerShell as an administrator

For example, right-click the Start button and select Windows PowerShell (Admin)

77
 Lab 2. Configure receiving events from Windows Event Log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

111. Go to the .\Desktop\KUMA folder, where you downloaded the agent installer

cd .\Desktop\KUMA\

112. Enter the agent installation command in the following format:

.\kuma.exe agent --core https://kuma-core.abc.lab:7210 --id

<agent service ID> --user abc\kuma --install

Instead of <agent service ID>, paste the value that you copied to the clipboard in one of

the previous steps.

113. Press ENTER

114. Type y and press ENTER again to accept the user agreement

115. Enter the password Ka5per$Ky to use the abc\kuma service account

116. Press ENTER once again

117. Verify that the agent service is running by entering the command

Get-Service *kuma*

78
 Lab 2. Configure receiving events from Windows Event Log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

118. The status of the service should be Running

119. Return to the web console and open Resources | Active services

120. Click the Refresh icon next to the search box to update the status of services

121. Make sure the status of the [Lab] Agent Windows WMI service is green

Task F: Make sure events arrive

In the KUMA console, display the list of events that have arrived at the [OOTB] CEF WMI collector
from the agent over the last 5 minutes. Make sure the list is not empty. Make sure events are arriving
from all specified devices.

The task is performed on admin-laptop.

122. In the KUMA web console, open Resources | Active services and select the checkbox in the
row with the [OOTB] CEF WMI collector

123. Click the Go to events button to display a list of events from the collector

A new tab with the Events page of the KUMA web console will open

79
 Lab 2. Configure receiving events from Windows Event Log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

124. Notice that the query string contains the collector service ID

125. Make sure new events have arrived at the KUMA storage (DeviceProduct = Windows)

126. Click on the third icon to the left of the Run query button to open the query builder

Let’s find events from each of the devices specified in the agent parameters to make sure

events are arriving from all devices

127. Click the Add condition button to add another criterion to the WHERE operator

128. Specify the following search parameters: DeviceHostName = admin-laptop.abc.lab

Start typing the name of the field to search for. Then use the suggestion in the drop-down

list and select the appropriate DeviceHostName value.

129. Click Apply query

80
 Lab 2. Configure receiving events from Windows Event Log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

130. Notice that a new query has appeared in the query field

131. Click Run query

132. Make sure admin-laptop.abc.lab is specified in the DeviceHostName field of all found events

If nothing is found, try to increase the search interval from 5 minutes to 15 minutes or the

last hour.

If necessary, add a column with the host name to the table. To do this, click on the gear

icon under the Run query button and select the DeviceHostName field

81
 Lab 2. Configure receiving events from Windows Event Log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

133. Repeat the search for the dc.abc.lab and ksc.abc.lab devices

134. Make sure the KUMA storage receives events from all the specified devices

135. Make sure the collector continues to receive and normalize CEF events. To do this, return to the
PuTTY window where the connection to kuma-core was established. Resend events with the
command:

sudo /opt/kaspersky/kuma/kuma tools load --raw --events event01

--cfg cef.cfg --replay 1

If you closed PuTTY, run it from the Start menu and reconnect to the kuma-core host
using the admin account with the password Ka5per$Ky. Do not forget to change to the

events directory using the cd events/ command

To confirm elevation of privilege, enter the password Ka5per$Ky


136. In the Events section of the KUMA web console, open the query builder again

137. Click Default query

138. Click Add condition

139. Specify Name like

Network%

82
 Lab 2. Configure receiving events from Windows Event Log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Type the Name field name in the left operand field. Scroll through the filtered fields to find
the Name field. The filtered list contains fields whose name contains Name. The list is

sorted alphabetically.

140. Click Apply query

141. Click Run query

142. Make sure a new event with the description Network attack detected in the Name column arrives
at the server

Conclusion

The lab demonstrates how to send Windows events to KUMA using a collector and an agent via WMI.
To accomplish this, the following is required:

83
Lab 2. Configure receiving events from Windows Event Log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

• Collector with a normalizer for Windows events

• Configuration for Windows Agent on the KUMA server

• Windows Agent service installed on a Windows computer and connected to the KUMA collector
and core

This lab also demonstrates the collector’s ability to receive events in different formats from different
sources.

84
Lab 3. Configure receiving events from a Windows DNS analytic log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
(optional)

Lab 3. Configure receiving events from a Windows

DNS analytic log (optional)
Scenario

Your network uses a DNS running on Microsoft Windows, and you want to receive events from the
DNS server log using Event Tracing for Windows (ETW). To do this, you need to create a collector,
configure an ETW session, and configure and install the KUMA agent on the DNS server.

Contents

Task A: Create a collector

Task B: Create an ETW session

Task C: Configure and install a KUMA agent

Task D: Make sure events arrive

Task A: Create a collector

Create a resource and a service for the collector, and install the collector service on the server.

The dc, ksc, kuma-core, kuma-storage-1, kuma-storage-2 and admin-laptop machines must be
powered on.

The task is performed on admin-laptop.

1. In the web console, go to Resources | Collectors

2. Click + Add

85
Lab 3. Configure receiving events from a Windows DNS analytic log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
(optional)

3. In the Collector name field,

specify [Lab] Windows ETW

4. Switch to the Transport

section

5. Specify http in the Kind field

6. In the URL field, type :5141

86
Lab 3. Configure receiving events from a Windows DNS analytic log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
(optional)

7. Switch to the Event parsing

section

8. Click + Add event parsing

9. In the Normalizer field, enter

etw to filter the list of
normalizers

10. Select the [OOTB] Microsoft

DNS ETW logs json
normalizer

11. Click OK

87
Lab 3. Configure receiving events from a Windows DNS analytic log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
(optional)

12. Open Routing

13. Click + Add

14. On the Create destination

page, expand the
Destination drop-down list

15. Select the [OOTB]

Correlator destination

16. Click Save

17. Add the [OOTB] Storage destination in the same way

88
Lab 3. Configure receiving events from a Windows DNS analytic log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
(optional)

18. Switch to the Setup

validation section

19. Click Create and save

service

20. Copy the recommended

command for installing the
service by clicking on the
icon in the lower right corner
of the area with the code

21. Click Save

22. Run PuTTY

23. Connect to kuma-core using the admin account with the password Ka5per$Ky

24. Paste the command from the clipboard and add sudo to the beginning

sudo /opt/kaspersky/kuma/kuma collector --core https://kuma-

core.abc.lab:7210 --id <ID from the copied command> --api.port
<port from the copied command> --install

25. Return to the KUMA web console and click Save

26. Go to Resources | Active services

27. Make sure the created service has appeared in the list and its status is green

89
Lab 3. Configure receiving events from a Windows DNS analytic log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
(optional)

Task B: Create an ETW session

Create an Event Tracing for Windows session to which DNS events will be logged. In our lab
environment, the DNS and domain controller run on the dc.abc.lab server, which does not have a
graphical interface installed. Accordingly, some operations are more convenient to perform from
admin-laptop.

The dc, ksc, kuma-core, kuma-storage-1, kuma-storage-2 and admin-laptop machines must be
powered on.

The task is performed on admin-laptop.

28. Right-click the Start menu

and start the Computer
Management snap-in

90
Lab 3. Configure receiving events from a Windows DNS analytic log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
(optional)

29. Right-click the Computer

Management (Local) root
node

30. In the shortcut menu, select

Connect to another
computer

31. Switch the radio button to

Another computer and
specify dc.abc.lab

32. Click OK

33. Go to System Tools |

Performance | Data
Collector Sets | Event
Trace Sessions

34. Click the Create a new Data

Collector Set button

Keep in mind that such a session will not be restored after a reboot. However, we are not
yet going to restart machines in our lab environment, so it’s OK. To have the session

restored after a server restart, create it in Startup Event Trace Sessions.

91
Lab 3. Configure receiving events from a Windows DNS analytic log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
(optional)

35. For the name, type DNSLog

36. Click Next

37. Click Add

38. In the list of providers, find

and select Microsoft-
Windows-DNSServer

39. Click OK

92
Lab 3. Configure receiving events from a Windows DNS analytic log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
(optional)

40. Click Finish

41. Double-click the newly

created DNSLog session

93
Lab 3. Configure receiving events from a Windows DNS analytic log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
(optional)

42. Go to the Trace Session tab

43. Expand the Stream mode

list and select Real Time

44. Click OK

45. Right-click the DNSLog

session and select Start in
the menu

94
Lab 3. Configure receiving events from a Windows DNS analytic log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
(optional)

46. The session status should

change to Running

Task C: Configure and install a KUMA agent

Create a resource with an agent configuration, and a service. Install the agent on dc.abc.lab.

The task is performed on admin-laptop and dc.

47. Run Active Directory Users

and Computers

For example, click the Start menu, start typing "active", and run Active Directory Users

and Computers

48. In the snap-in, go to the abc.lab | Builtin

95
Lab 3. Configure receiving events from a Windows DNS analytic log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
(optional)

49. Double-click the

Performance Log Users
group to open it

96
Lab 3. Configure receiving events from a Windows DNS analytic log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
(optional)

50. Switch to the Members tab

51. Click Add…

52. In the white field, type kuma

53. Click Check Names

54. Click OK

55. Click OK again

56. Close the Active Directory Users and Computers snap-in

57. Open the Group Policy

Management snap-in

For example, click the Start menu, start typing active, and run Active Directory Users

and Computers

97
Lab 3. Configure receiving events from a Windows DNS analytic log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
(optional)

58. Go to Forest: abc.lab |

Domains | abc.lab | Group
Policy Object

59. Right-click the Default

Domain Controllers Policy

60. In the shortcut menu, select

Edit

61. In the snap-in that opens, go

to Computer configuration |
Policies | Windows
Settings | Security Settings
| Local Policies | User
Rights Assignment

62. Find and double-click the

Log on as a service policy

98
Lab 3. Configure receiving events from a Windows DNS analytic log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
(optional)

63. Select the Define these

policy settings checkbox to
activate the policy

64. Click Add User or Group…

65. In the window that opens,

click Browse

66. In the white field, type kuma

67. Click Check Names

68. Click OK

69. Click OK again

99
Lab 3. Configure receiving events from a Windows DNS analytic log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
(optional)

70. Click OK a third time

71. Close the Group Policy Management Editor snap-in

72. Close the Group Policy Management snap-in

We granted the ABC\Kuma account the permissions to read the necessary data and the
"Log on as a service" permissions on the domain controller. This configuration may not be
consistent with best practices in production environments. In our lab, we do this to save

time and keep the scenario simple. For example, in a production environment, you may
not want to edit the Default Domain Controllers Policy.

73. In the KUMA web console, go to Resources | Agents

100
Lab 3. Configure receiving events from a Windows DNS analytic log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
(optional)

74. Click Add agent to create a

new agent configuration

75. In the Name field, specify

[Lab] Agent Windows ETW

76. Switch to the Configuration

resource #1 tab

77. In the Connector area, in the

Name field, specify Agent
Windows ETW

78. In the Kind drop-down list,

select etw

79. In the Session name box,

enter DNSLog

101
Lab 3. Configure receiving events from a Windows DNS analytic log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
(optional)

80. Scroll down the window. In

the Destinations area,
specify the name ETW
Collector

81. In the Kind field, select http

82. In the URL field, type kuma-

core.abc.lab:5141

83. Click Create new

84. In the KUMA web console, go to Resources | Active services

85. Click + Add service .

102
Lab 3. Configure receiving events from a Windows DNS analytic log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
(optional)

86. Select the [Lab] Agent

Windows ETW checkbox

87. Click Create service

88. Select the checkbox in the row for the new service

89. Click Copy ID

103
Lab 3. Configure receiving events from a Windows DNS analytic log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
(optional)

90. Right-click the Start menu

and select Run

91. Type the path

\\dc.abc.lab\c$\kuma

92. Click OK

93. Copy the kuma.exe file from the KUMA folder on the desktop to this folder

94. Right-click the install-agent.ps1 file

95. In the shortcut menu, select Edit

104
 Lab 3. Configure receiving events from a Windows DNS analytic log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
(optional)

96. The file that opens contains the agent installation string

The DC virtual machine, where we are going to install the agent, does not have a GUI. We

will edit the installation command remotely to conveniently copy the agent’s service ID.

97. Replace the characters ID with the value from the clipboard

98. Save the changes and close Powershell ISE

99. Copy the \Desktop\KUMA\kuma.exe file to the \\dc.abc.lab\c$\kuma folder

100. Switch to the DC virtual machine

101. Log in to DC using the Administrator account with the password Ka5per$Ky

105
 Lab 3. Configure receiving events from a Windows DNS analytic log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
(optional)

102. Run the following command to enforce group policies:

gpupdate /force

103. Run the agent installation script by sequentially executing the following three commands,
pressing ENTER for each of them:

PowerShell
cd C:\kuma\
.\agent-install.ps1

104. The installer will show the user agreement. Type Y and press ENTER to accept it

When prompted for the password, type Ka5per$Ky


105. Run the following command to make sure the agent service is installed and running

Get-Service *kuma* | fl

106
 Lab 3. Configure receiving events from a Windows DNS analytic log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
(optional)

The value of the Status field should be Running


106. Return to the web console and open Resources | Active services

107. Make sure the agent service is green

If the service is displayed as disabled, click the Refresh icon next to the search box to

update statuses.

Task D: Make sure events arrive

Verify that the installed agent sends events.

The task is performed on admin-laptop.

108. In the KUMA web console, go to Resources | Active services

109. Select the checkbox for the [Lab] Windows ETW collector

110. Click Go to events

107
 Lab 3. Configure receiving events from a Windows DNS analytic log KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
(optional)

111. Make sure events are arriving

112. Examine the fields in events

113. We will not need data from

the DNS logs in subsequent
labs. At this stage, you can
stop collecting this data. To
do so, go back to the
Computer Management
snap-in (connected to
DC.ABC.LAB) and stop the
session: right-click it and then
select Stop

You can run the Computer Management snap-in from the Start menu. To connect to
DC.ABC.LAB, right-click the root node in the snap-in and select Connect to another

computer

Conclusion

In this lab, you configured a mechanism to receive events from DNS logs. To use incoming data
efficiently in a production environment, you will need to fine-tune the ETW session. This is required in
order to receive only relevant events, since even in this small lab environment, a session generates
approximately 1 EPS.

108
Lab 4. Configure receiving Linux events (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Lab 4. Configure receiving Linux events (optional)

Scenario

You want to receive events from computers running Linux (Ubuntu), in particular, when the the root
account is used for remote access to servers via SSH. To do this, you need to install the Linux agent,
configure the collection of data from the /var/log/auth.log log, install a collector, and create a
correlation rule.

If the agent is installed on an Oracle server in your lab, the log name will be

/var/log/secure.

Contents

Task A: Create a resource with a collector configuration

Task B: Install the collector service

Task C: Create a resource with a Linux agent configuration

Task D: Install the Linux agent and check for events

Task E: Configure the Linux agent to start automatically

Task F: Create and test a correlation rule

Task A: Create a resource with a collector configuration

Create a resource with a collector configuration to receive Linux audit events. Create a collector
service.

The task is performed on admin-laptop.

109
Lab 4. Configure receiving Linux events (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

1. In the KUMA web console,

go to Resources |
Collectors

2. Open the Lab folder and click

+ Add

3. Specify the collector name

[Lab] Linux audit

4. Switch to the Transport

section

5. In the Kind field, select tcp

6. In the URL field, type :5142

110
Lab 4. Configure receiving Linux events (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

7. Switch to the Event parsing

section

8. Click + Add event parsing

9. In the Normalizer drop-down

list, select [OOTB] Linux
auditd syslog for KUMA 3.2

10. Click OK

11. Switch to the Routing section

12. Click + Add

111
Lab 4. Configure receiving Linux events (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

13. In the window that opens, in

the Destination field, select
[OOTB] Storage

14. Click Save

15. In the Routing section, click the + Add button again

16. Add the [OOTB] Correlator destination in the same way

17. Click Save

18. Make sure you have two destinations added

112
Lab 4. Configure receiving Linux events (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

19. Switch to the Setup validation section

20. Click Create and save service

21. A command for installing the collector will be generated in the window. Copy it to the clipboard
using the icon in the lower right corner of the area with the code

22. Click Save

113
Lab 4. Configure receiving Linux events (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Task B: Install the collector service

Install the collector service to receive Linux audit events.

The task is performed on admin-laptop.

114
Lab 4. Configure receiving Linux events (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

23. Start PuTTY (you can find

shortcuts for it on the
desktop, in the Start menu
and on the taskbar)

24. In the Host Name (or IP

address) field, type kuma-
core

25. Click Open

26. Log in to the admin account

with the password
Ka5per$Ky

27. Paste the command for installing the collector from the clipboard, and add sudo before the
copied command in order to execute it with superuser permissions. You should end up with the
following:

sudo /opt/kaspersky/kuma/kuma collector --core https://kuma-

core.abc.lab:7210 --id <ID from the copied command> --api.port
<port from the copied command> --install

28. Press ENTER to run the command

Enter the password Ka5per$Ky to elevate privileges


29. Return to the KUMA web console and open Resources | Active services

30. Make sure the [Lab] Linux audit service has the green status now, which means that it is running

115
Lab 4. Configure receiving Linux events (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Task C: Create a resource with a Linux agent configuration

Create a configuration resource with a file connector for the Linux agent.

The dc, ksc, kuma-core, kuma-storage-1, kuma-storage-2 and admin-laptop machines must be
powered on.

The task is performed on admin-laptop.

31. In the KUMA web console, go to Resources | Agents

32. Open the Lab folder and click + Add

116
Lab 4. Configure receiving Linux events (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

33. Specify the name [Lab] Agent

Linux

34. Switch to the Configuration

resource #1 tab

35. In the Connector area, fill in

the fields:

a. Name: [Lab] Agent

Linux

b. Kind: file

c. File path:
/var/log/auth.log

If the agent is installed on an Oracle server in your lab, the log name will be

/var/log/secure.

117
Lab 4. Configure receiving Linux events (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

36. Scroll down the page a little

and fill in the fields in the
Destinations area:

a. Name: [Lab] Linux

collector

b. kind: tcp

c. URL: kuma-
core.abc.lab:5142

37. Click Create new

38. Make sure a resource with a Linux agent configuration appears

Task D: Install the Linux agent and check for events

Install the agent on kuma-storage-2.abc.lab.

The task is performed on admin-laptop.

118
Lab 4. Configure receiving Linux events (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

39. In the web console, go to

Resources | Active
services

40. Click + Add service

41. Select [Lab] Agent Linux

42. Click Create service

43. Select the created [Lab] Agent Linux service

44. Click Copy ID

119
Lab 4. Configure receiving Linux events (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

45. Start PuTTY (you can find

shortcuts for it on the
desktop, in the Start menu
and on the taskbar)

46. In the Host Name (or IP

address) field, type kuma-
storage-2

47. Click Open

48. Log in to the admin account

with the password
Ka5per$Ky

49. Use the following commands to create a working directory for the agent (press ENTER after each
command):

sudo mkdir -p /opt/kaspersky/kuma/agent

sudo mkdir -p /opt/kaspersky/kuma/agent/<ID from the clipboard>

Enter the password Ka5per$Ky to elevate privileges


50. Let’s start the service. Type the following command:

sudo /opt/kaspersky/kuma/kuma agent --core https://kuma-

core.abc.lab:7210 --id <ID from the clipboard> --wd
/opt/kaspersky/kuma/agent/<ID from the clipboard>/

51. Press ENTER

120
Lab 4. Configure receiving Linux events (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

The terminal will "freeze". This means that we have started the agent. Do not interrupt its
operation. Let’s check for events and configure automatic start of the agent service on the

server.

52. Return to the KUMA web console and open Resources | Active services

53. Click the Refresh icon next to the search box to update the status of services

54. Make sure the [Lab] Linux audit service has the green status now, which means that it is running

55. Select the [Lab] Linux audit correlator service

56. Click Go to events

57. Make sure events are arriving.

121
Lab 4. Configure receiving Linux events (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Task E: Configure the Linux agent to start automatically

(optional)
Configure the Linux agent to start automatically.

The task is performed on admin-laptop.

58. Open a browser and

download the configuration
file from https://kas.pr/
kumaagentservice

59. This link should download a

kuma-agent-ID.service file

60. In the web console, go to Resources | Active services

61. Select the checkbox for the [Lab] Agent Linux service

62. Click Copy ID

63. Rename the downloaded

configuration file: replace the
ID letters with the copied ID
of the agent’s service

64. Open the file with Notepad or Notepad++

65. Find the line starting with ExecStart=

122
Lab 4. Configure receiving Linux events (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

66. In this line, replace the <ID> characters with the agent’s service ID from the clipboard in two
places

67. Save the changes and close the file

68. Start the WinSCP application

69. Connect to the kuma-

storage-2 server:

a. For the Host name, type

kuma-storage-2.abc.lab

b. In the User name field,

type root

c. For the Password, type

Ka5per$Ky

d. Click the Login button

If a warning window appears, click Accept


123
Lab 4. Configure receiving Linux events (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

70. In the right pane of WinSCP, open the /usr/lib/systemd/system/ directory

71. In the left pane of WinSCP, find and select the configuration file

72. Click Upload

73. Click OK to confirm copying

74. Close WinSCP. Click Yes to

confirm closing

75. Return to the open PuTTY window with a connection to kuma-storage-2

76. Stop the Linux agent by pressing Ctl+C

77. Run the following commands:

sudo systemctl daemon-reload

sudo systemctl start kuma-agent-<paste the ID of the Linux
agent service from the clipboard>.service
sudo systemctl enable kuma-agent-<paste the ID of the Linux
agent service from the clipboard>.service
sudo systemctl status kuma-agent-<paste the ID of the Linux
agent service from the clipboard>.service

124
Lab 4. Configure receiving Linux events (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

78. The last command displays the status of the service. Make sure the service is active and is
configured to start automatically

79. Press Q to finish viewing the status

80. Close the PuTTY window with the connection to kuma-storage-2

81. Open a new PuTTY window

82. Attempt to connect to kuma-

storage-2 using incorrect
credentials, for example, user
name labtest1234 with an
arbitrary password

83. In the web console, go to

Resources | Active
services

84. Select the [Lab] Linux audit

collector service

85. Click Go to events

86. Find events that were generated as a result of the failed login attempt

87. Examine details of the events

125
Lab 4. Configure receiving Linux events (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Task F: Create and test a correlation rule (optional)

Create a rule that generates an alert when someone remotely logs on to the Linux server as root. We
will talk about correlation rules in more detail a little later, and there will be important labs on this topic
later in the course.

The task is performed on admin-laptop.

88. In the KUMA web console,

go to Resources |
Correlation rules

89. Click + Add to create a

correlation rule

126
Lab 4. Configure receiving Linux events (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

90. In the Name field, specify

[Lab] Successful SSH root
login attempt

91. In the Kind field, select

Simple

92. In the Propagated fields

field, specify
DeviceHostName

93. In the Severity drop-down

list, choose High

94. Switch to the Selectors tab

95. Click </> Code to switch to code entry mode

96. Enter the following conditions for the selector:

DeviceProcessName='sshd'
AND DestinationUserName='root'

127
 Lab 4. Configure receiving Linux events (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

97. Switch to the Actions tab

98. Select the Output checkbox

99. Click Create new

100. Make sure the rule has

appeared on the list

101. Reopen the rule you just

created

102. Notice that after you save the

rule, the Correlators tab
appears

103. Switch to the Correlators tab

128
 Lab 4. Configure receiving Linux events (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

104. Click + Add

105. Expand the tree and select

[OOTB] Correlator

106. Click OK

107. Click Save

108. In the KUMA web console,

go to Resources | Active
services

109. Select the checkbox for the

[OOTB] Correlator

110. Click Update configuration

129
 Lab 4. Configure receiving Linux events (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

111. Click OK to confirm the

correlator configuration
update

112. In PuTTY, connect to kuma-

storage-2 using the root
account with the password
Ka5per$Ky

113. Close PuTTY

114. In the KUMA web console,

go to Resources | Alerts

115. Make sure there is a new

alert named [Lab]
Successful SSH root login
attempt.

Conclusion

In this lab, you configured, installed, and tested a Linux agent.

130
Lab 5. Configure receiving Kaspersky Security Center events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Lab 5. Configure receiving Kaspersky Security

Center events
Scenario

You want KUMA to receive Kaspersky Security Center events, including security events from
computers managed via Kaspersky Security Center. The simplest method is to query the SQL
database that stores all Kaspersky Security Center events along with events that endpoint security
applications send to KSC.

Appropriate collector and normalizer templates are available by default. The administrator only needs
to adjust the KSC database connection parameters for the collector and install the service.

Contents

Task A: Create a login for the collector account on the SQL server

Task B: Configure and install the collector service for KSC events

Task C: Make sure events arrive

Task A: Create a login for the collector account on the SQL

server
Create an SQL login for connecting to the Kaspersky Security Center database and querying the
database according to the principle of minimal sufficiency. The KUMA collector will use this login to
interact with the Kaspersky Security Center database.

The dc, ksc, kuma-core, kuma-storage-1, kuma-storage-2 and admin-laptop machines must be
powered on.

The task is performed on admin-laptop.

131
Lab 5. Configure receiving Kaspersky Security Center events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

1. Run Microsoft SQL Server

Management Studio

For example, right-click the Start button, begin typing SQL in the search bar, and below

Microsoft SQL Server Management Studio 18, select Run as administrator

2. Make sure the Server name

field contains the
KSC\SQLEXPRESS instance

3. Click Connect

132
Lab 5. Configure receiving Kaspersky Security Center events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

4. In the console, open

KSC\SQLEXPRESS (…) |
Security | Logins

5. Right-click Logins

6. Select New Login

133
Lab 5. Configure receiving Kaspersky Security Center events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

7. Click Search

8. Click Locations

9. Select Entire Directory

10. Click OK

11. In the Enter the object

names to select field, type
kuma

12. Click Check Names

13. Click OK to confirm the

selection

134
Lab 5. Configure receiving Kaspersky Security Center events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

14. Make sure the Login name:

field contains ABC\kuma

15. Open User Mapping

16. Select the checkbox in the

intersection of the Map
column and the KAV row

17. Click the “…” button (three-

dot menu) on the right

135
Lab 5. Configure receiving Kaspersky Security Center events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

18. Click Browse

19. Scroll down the list and

select the [dbo] option

20. Click OK

21. Make sure the [dbo] object

has appeared in the Enter
the object names to select
field

22. Click OK

23. In the Database role

membership for KAV area
at the bottom, select the
db_datareader parameter

24. Click OK

136
Lab 5. Configure receiving Kaspersky Security Center events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

25. Make sure the ABC\kuma

login has appeared in the list

26. Close the Microsoft SQL

Server Management Studio
window

Task B: Configure and install the collector service for KSC

events
During installation of KUMA, a demo resource of an active collector is automatically created for KSC
events received by querying the SQL database. Examine its default settings, make the necessary
changes, then install the collector service.

The task is performed on admin-laptop.

137
Lab 5. Configure receiving Kaspersky Security Center events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

27. Return to the KUMA web

console and open
Resources | Active
services

28. Click Add service to add an

active collector service for
KSC events

29. Select the [OOTB] KSC SQL

collector resource

30. Click Create service

31. Pay attention to the status of the created [OOTB] KSC SQL service

As with other services, to finish creating a collector service, you need to install it on the

corresponding KUMA server.

32. Open Resources | Connectors

138
Lab 5. Configure receiving Kaspersky Security Center events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

33. Select [OOTB] KSC MSSQL and click the Duplicate button

139
Lab 5. Configure receiving Kaspersky Security Center events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

34. Expand the drop-down list in

the URL field

35. In the URL field, click the

pencil button to the right of
the [OOTB] KSC MSSQL
value to edit the default
secret resource for
connecting to the SQL
database

36. In the URL field, specify the Kaspersky Security Center database connection settings in a single
line:

sqlserver://abc%5Ckuma:[email protected]/SQLEXPRESS?databas
e=KAV

37. Click Save

38. Click Create new to save

your changes to the [OOTB]
KSC MSSQL - copy
connector resource

140
Lab 5. Configure receiving Kaspersky Security Center events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Format of the secret in the URL field:

sqlserver://<domain>%5C<login>:<password>@<SQL server FQDN>/<SQL

instance>?database=<database name>.

39. In Resources | Active

services, open the
properties of the [OOTB]
KSC SQL service

To open the service properties, click its name in the Service column.

40. Switch to the Transport section

41. Click the button. In the drop-down list, select the [OOTB] KSC MSSQL – copy connector
resource

141
Lab 5. Configure receiving Kaspersky Security Center events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

42. Switch to the Event parsing section

43. Notice that the service already uses the default event normalizer

We still will not dwell upon the parsing, filtering, aggregation and event enrichment
settings; other labs will be devoted to them. For now, let’s take it for granted that the

minimum necessary parsing settings for the corresponding type of incoming events are
preconfigured in the collector resources.

142
Lab 5. Configure receiving Kaspersky Security Center events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

44. Switch to the Routing section

45. Notice that the collector sends events to the correlator and to the storage

46. Switch to the Setup validation section

47. Note the recommended command syntax for installing the service with the specified settings on
the KUMA server

48. Click the icon in the lower right corner of the code block to copy the command to the clipboard

49. Click Save

143
Lab 5. Configure receiving Kaspersky Security Center events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

50. Open the window with the SSH session to the kuma-core.abc.lab server

If you closed PuTTY, start it and reconnect to kuma-core.abc.lab. Authenticate as admin


with the password Ka5per$Ky.

51. Paste the command from the clipboard

52. Type sudo before the copied command to run it with superuser privileges; it should look as
follows:

sudo /opt/Kaspersky/kuma/kuma correlator --core

https://kuma-сore.abc.lab:7210 --id <id from the copied
command> --api.port <port from the copied command> --install

53. Press ENTER to run the command

Enter the password Ka5per$Ky to elevate privileges.


144
Lab 5. Configure receiving Kaspersky Security Center events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

54. Return to the KUMA web console

55. Go to Resources | Active services and click Refresh

56. Make sure the [OOTB] KSC SQL service has the green status now, which means that it is
running

If the service has the Restart required status, select it and click the Restart button.

Task C: Make sure events arrive
In the KUMA console, display the list of events that have arrived at the [OOTB] KSC SQL collector
from the KSC database over the last 5 minutes. Make sure the list is not empty. Review the arriving
events.

The task is performed on admin-laptop.

57. Select the [OOTB] KSC SQL collector in the web console and click Go to events to open the list
of events from this collector

145
Lab 5. Configure receiving Kaspersky Security Center events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

A new tab with the Events page of the KUMA web console will open.

58. Notice that the query string contains the collector service ID

59. Make sure the list of events is being filled with new events received via the configured collector

146
Lab 5. Configure receiving Kaspersky Security Center events KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

60. Click on one of the events to

review its contents

Conclusion

The lab demonstrates how to configure receiving events from the Kaspersky Security Center
database in KUMA using an active collector and an sql connector.

This integration method (via querying the database) is recommended and has a number of
advantages over integration with a passive KUMA collector, which receives events sent by the
Kaspersky Security Center server.

147
Lab 6. Configure receiving Kaspersky Anti Targeted Attack Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
events

Lab 6. Configure receiving Kaspersky Anti Targeted

Attack Platform events
Scenario

You want to analyze Kaspersky Anti Targeted Attack Platform events in KUMA. The default normalizer
resource for Kaspersky Anti Targeted Attack events is created automatically when KUMA is installed.
But there is no dedicated collector resource for these events. Create a new collector for Kaspersky
Anti Targeted Attack and configure Kaspersky Anti Targeted Attack to send events there.

Contents

Task A: Configure and install the collector service for KATA events

Task B: Configure sending KATA events to the collector

Task A: Configure and install the collector service for KATA

events
No collector is created for KATA events during installation of KUMA. Create a new collector resource
to receive KATA events. When creating the collector, use the default KATA event normalizer resource.
Install the KATA event collector service using the created resource on the kuma-core.abc.lab server;
then allow the collector ports in the server’s firewall and make sure the collector receives events.

The dc, kata-cn, ksc, kuma-core, kuma-storage-1, kuma-storage-2 and admin-laptop machines
must be powered on.

The task is performed on admin-laptop.

148
Lab 6. Configure receiving Kaspersky Anti Targeted Attack Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
events

1. In the KUMA web console,

open the Resources section

2. Click Collectors

3. If there is no Lab folder,

create it by clicking + Add
folder

4. In the Name field, type Lab

5. Click Save

6. Select the Lab folder in the

tree on the left

7. Click + Add

149
Lab 6. Configure receiving Kaspersky Anti Targeted Attack Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
events

8. In the Name field, specify the

collector name [Lab] KATA

9. Switch to the Transport

section

10. In the Kind field, select tcp

11. In the URL field, type :5143

12. Do not change the other

settings in this section

Kaspersky Anti Targeted Attack can send events using TCP and UDP. UDP does not

guarantee delivery, so it is better to use the TCP transport for important events.

Port 5143 is not yet occupied by other collectors in our infrastructure.


13. Switch to the Event parsing
section

14. Click + Add event parsing

150
Lab 6. Configure receiving Kaspersky Anti Targeted Attack Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
events

15. In the Normalizer drop-down

list, type KATA and select
[OOTB] KATA

16. Click OK

17. Switch to the Routing

section

18. Click + Add

19. In the Destination drop-

down list, select [OOTB]
Storage

20. Click Save

21. Add [OOTB] Correlator as a

second destination in the
same way

22. Make sure the collector

sends events to both the
correlator and the storage

151
Lab 6. Configure receiving Kaspersky Anti Targeted Attack Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
events

23. Switch to the Setup

validation section

24. Click Create and save

service

25. Pay attention to the

recommended command for
installing a service with the
specified settings

26. Click the icon in the lower

right corner of the code block
to copy the installation
command to the clipboard

27. Click Save

28. Open the window with the SSH session to the kuma-core.abc.lab server

If you closed PuTTY, start it and reconnect to kuma-core.abc.lab. Authenticate as admin


with the password Ka5per$Ky.

29. Paste the command from the clipboard

30. Type sudo before the copied command to run it with superuser privileges; it should look as
follows:

sudo /opt/kaspersky/kuma/kuma collector --core https://kuma-

core.abc.lab:7210 --id <ID from the copied command> --api.port
<port from the copied command> --install

31. Press ENTER to run the command

Enter the password Ka5per$Ky to elevate privileges.


152
Lab 6. Configure receiving Kaspersky Anti Targeted Attack Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
events

32. Return to the KUMA web console

33. Go to Resources | Active services and click Refresh

34. Make sure the [Lab] KATA service has the green status now, which means that it is running

Task B: Configure sending KATA events to the collector

Complete this task if you have a KATA installation in the lab environment. The collector is ready to
receive events. Configure sending events to the collector in the settings of Kaspersky Anti Targeted
Attack Platform Central Node. The Kaspersky Anti Targeted Attack Central Node web console is
located at https://kata-cn.abc.lab:8443. The administrator username is Administrator, and the
password is Ka5per$Ky.

The task is performed on admin-laptop.

35. In a new web browser window, open the Kaspersky Anti Targeted Attack Central Node web
console at https://kata-cn.abc.lab:8443

If a browser warning about an insecure connection appears, select Advanced and then

Proceed to kata-cn.abc.lab (unsafe).

153
Lab 6. Configure receiving Kaspersky Anti Targeted Attack Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
events

36. On the login page, select the

Local administrator
checkbox

37. Log in as Administrator,

password: Ka5per$Ky

38. Get a link to the KATA license

file from your instructor and
download the license file to
disk

39. Switch to the Settings |

License section

40. Click the Import button in the

KATA area and select the
downloaded license file

41. Scroll down the text of the

KSN Statement and select I
agree to participate in KSN

42. Click Apply

154
Lab 6. Configure receiving Kaspersky Anti Targeted Attack Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
events

43. Get a link to the KEDR

license file from your
instructor and download the
license file to disk

44. In the KATA web console,

click the Import button in the
KEDR area and select the
downloaded license file

45. Scroll down the text of the

KSN Statement and select I
agree to participate in KSN

46. Click Apply

47. Make sure you have 2 valid

licenses

155
Lab 6. Configure receiving Kaspersky Anti Targeted Attack Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
events

48. Switch to the Settings |

SIEM system section

49. In the Data to send area,

select the Activity log and
Alerts checkboxes

50. Configure sending events to

KUMA:

a. Host/IP: kuma-
core.abc.lab

b. Protocol: TCP

c. Port: 5143

d. Host ID: kata-cn

e. Heartbeat: 10 minutes

51. When the protocol is

changed, the port number is
reset! Be sure to specify the
correct port and protocol
before proceeding to the next
step.

52. Click Apply to save

the changes

53. Log out from the system: click the Administrator username in the lower left corner and select
Log out

You need to log out in order to generate an event in KATA and receive it at the collector.

54. Return to the browser window with the KUMA web console

55. Go to Resources | Active services

56. Select the [Lab] KATA collector and click Go to events to open the list of its events

156
Lab 6. Configure receiving Kaspersky Anti Targeted Attack Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
events

A new tab with the Events page of the KUMA web console will open.

57. Notice that the query string contains the collector service ID

58. Make sure events arrive at the collector

157
Lab 6. Configure receiving Kaspersky Anti Targeted Attack Platform KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
events

59. Click on the event named

Managing user accounts. A
panel with event details will
open on the right

60. Examine the event fields

Conclusion

The lab demonstrates how to create and configure a new Kaspersky Anti Targeted Attack Platform
event collector service and how to configure Kaspersky Anti Targeted Attack Platform to send events
to KUMA.

158
Lab 7. Configure receiving EDR telemetry from KATA KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Lab 7. Configure receiving EDR telemetry from KATA

Scenario

If you do not have a KEDR installation in the lab environment, skip this lab and proceed to the next.
You want to promptly receive up-to-date versions of normalizers and correlation rules published by
Kaspersky experts. To do so, configure updates from Kaspersky servers in KUMA, download updates,
then import available resources to the Shared tenant. Use the received data to normalize the EDR
telemetry from the lab environment.

Contents

Task A: Configure and install the collector service for EDR telemetry

Task B: Make sure events arrive at the collector

Task A: Configure and install the collector service for EDR

telemetry
Create a new collector resource to receive EDR telemetry events. When creating a resource, use the
[Lab] KEDR telemetry normalizer created in one of the previous tasks. Use the created resource to
install the collector service on the kuma-core.abc.lab server.

The task is performed on admin-laptop.

1. In the KUMA web console,

go to Resources |
Connectors

2. Click + Add folder. For the

name, type Lab

3. Open the Lab folder

159
Lab 7. Configure receiving EDR telemetry from KATA KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

4. Click + Add

5. Fill in the connector fields:

a. Name: [Lab] KEDR

telemetry

b. Kind: kata/edr

c. URL: 10.28.0.51:443

6. Expand the drop-down list in

the Secret field

7. Click Create new

8. In the Name field, specify

[Lab] KEDR

9. Click Generate and

download a certificate and
private encryption key

160
Lab 7. Configure receiving EDR telemetry from KATA KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

10. The certificate.zip archive

should be downloaded to the
Downloads folder. Unpack it.
There should be two files
inside

11. In the Create secret window,

click the + Upload certificate
button and select the
cert.pem file from the
unpacked archive

12. Click the + Upload private

key button and select the
key.pem file from the
unpacked archive

13. Click the Create new button

to create a secret resource

14. Click the Create new button

again to create a connector
resource

161
Lab 7. Configure receiving EDR telemetry from KATA KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

15. Open Resources | Collectors

16. Select the Lab folder in the tree on the left

We created it in one of the previous labs. If this folder is absent, create it.

17. Click + Add

18. In the Collector name field,

specify [Lab] KEDR telemetry

19. Switch to the Transport

section

20. In the Connector drop-down

list, select [Lab] KEDR
telemetry

162
Lab 7. Configure receiving EDR telemetry from KATA KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

21. Switch to the Event parsing

section

22. Click Add event parsing

23. In the Normalizer field, type

KEDR and select the found
[Lab] [OOTB pack] KEDR
telemetry normalizer
resource

24. Click OK

25. Switch to the Routing

section

26. Click + Add

27. In the Destination drop-

down list, select [OOTB]
Storage

28. Click Save

163
Lab 7. Configure receiving EDR telemetry from KATA KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

29. Add [OOTB] Correlator as a

second destination in the
same way

30. Make sure the collector

sends events to both the
correlator and the storage

31. Switch to the Setup

validation section

32. Click Create and save

service

33. Pay attention to the

recommended command for
installing a service with the
specified settings

34. Copy the installation

command to the clipboard

35. Click Save

164
Lab 7. Configure receiving EDR telemetry from KATA KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

36. Open the window with the SSH session to the kuma-core.abc.lab server. If you closed PuTTY,
start it and reconnect to kuma-core.abc.lab. Authenticate as admin with the password
Ka5per$Ky

37. Paste the command from the clipboard

38. Type sudo before the copied command to run it with superuser privileges; it should look as
follows:

sudo /opt/kaspersky/kuma/kuma collector --core https://kuma-

core.abc.lab:7210 --id <ID from the copied command> --api.port
<port from the copied command> --install

39. Press ENTER to run the command

Enter the password Ka5per$Ky to elevate privileges.


40. Make sure the command has been executed without errors

41. Open a new tab in your

browser and go to
https://kata-cn.abc.lab:8443

42. Select the Local

administrator checkbox

43. Type the username

Administrator

44. Enter the password

Ka5per$Ky

45. Click Log in

46. Open the External systems section

47. Click Accept

165
Lab 7. Configure receiving EDR telemetry from KATA KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

48. Make sure the connection status has changed to Authorized

Task B: Make sure events arrive at the collector

Find the events that have arrived at the [Lab] KEDR telemetry collector.

The task is performed on admin-laptop.

49. Return to the KUMA web console

50. Go to Resources | Active services

51. Select the [Lab] KEDR telemetry service and click the Restart button

166
Lab 7. Configure receiving EDR telemetry from KATA KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

52. Wait a while and refresh the page

53. Make sure the [Lab] KEDR telemetry service has the green status now, which means that it is
running

54. Select the [Lab] KEDR telemetry collector and click Go to events to open the list of its events

A new tab with the Events page of the KUMA web console will open.

55. Make sure events have arrived

167
Lab 7. Configure receiving EDR telemetry from KATA KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform


If there are no events, wait 5 minutes and click the Run query button.

56. Click any event on the list

The Event details pane will open on the right. Notice that KUMA has parsed the EDR

telemetry event already and displays its attributes.

Conclusion

This lab demonstrates how to use the automatic resource update subsystem to get up-to-date
versions of normalizers and correlation rules published by Kaspersky experts and then to use the
downloaded KEDR telemetry event normalization settings to create a collector service in KUMA.

168
Lab 8. Configure DNS data enrichment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Lab 8. Configure DNS data enrichment

Scenario

Scenario. You want to add missing data about computer names and IP addresses to events. For
example, if a raw event contains only an IP address but no name, or vice versa, you want the collector
to query DNS and add the data from the DNS response to the event. To do this, set up a DNS
enrichment rule in Kaspersky Unified Monitoring and Analysis and add this rule to the [OOTB] CEF
normalizer.

Contents

Task A: Configure a DNS connection

Task B: Add an enrichment rule to a collector

Task C: Make sure enrichment works

Task A: Configure a DNS connection

Create a new DNS enrichment rule and specify the DNS server connection parameters in it.

The dc, ksc, kuma-core, kuma-storage-1, kuma-storage-2 and admin-laptop machines must be
powered on.

The task is performed on admin-laptop.

1. In the KUMA web console,

open the Resources section

2. Click Enrichment rules

3. In the left pane, select the

Main folder

4. Click + Add folder and

create a folder named Lab

169
Lab 8. Configure DNS data enrichment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

5. Select the Lab folder

6. Click + Add

7. Configure the enrichment

settings:

a. In the Name field, specify

[Lab] DNS enrichment

b. In the Source kind field,

select dns

c. In the URL field, type

10.28.0.10

8. Do not fill in the other fields.

9. Click Create new in the

lower-left corner to create the
resource

Task B: Add an enrichment rule to a collector

Configure the [OOTB] CEF normalizer to store the raw event to be able to compare the normalized
event with its non-normalized version. Add a DNS enrichment rule to the [OOTB] CEF WMI collector
and reload its settings.

The task is performed on admin-laptop.

170
Lab 8. Configure DNS data enrichment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

10. In the KUMA web console,

open the Resources |
Normalizers section

11. Select the checkbox for the

[OOTB] CEF normalizer and
click Duplicate

12. Open the event parsing

settings

Click the round icon.


13. In the Keep raw event drop-
down list, select Always

14. Click OK

By default, the [OOTB] CEF normalizer saves raw events only when it encounters an error
during normalization, for example, because of an incorrect format. If an event is
processed without errors, extra information will be discarded. To be able to compare a

normalized event with its raw version, we need to see what other data the initial event
contained.

171
Lab 8. Configure DNS data enrichment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

15. Click the Create new button at the bottom

16. In the KUMA web console, open the Resources | Active services section

17. Click the name of the [OOTB] CEF WMI service to open its settings

18. Switch to the Event parsing

section

19. Switch to the Parsing

settings tab

20. Under IP address 10.28.0.61,

in the Normalizer drop-down
list, select [OOTB] CEF -
copy

172
Lab 8. Configure DNS data enrichment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

21. Switch to the Event

enrichment section

22. Click + Add enrichment

23. In the Enrichment rule drop-

down list, select the [Lab]
DNS enrichment resource

24. Make sure the Event

enrichment section now
displays settings from the
[Lab] DNS Enrichment
resource

173
Lab 8. Configure DNS data enrichment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

25. Switch to the Setup

validation section

26. Click Save and update

service configurations to
save the settings and apply
them to the collector service

27. Click the Save button to exit

the collector settings

Task C: Make sure enrichment works

Send a test event to the collector and make sure the stored events are enriched with DNS data.

The task is performed on admin-laptop.

28. Open the window with the SSH session to the kuma-core.abc.lab server

If you closed PuTTY, run it and connect to kuma-core.abc.lab as admin with the password

Ka5per$Ky.

29. Make sure you are in the events folder. If necessary, navigate to it using the command:

cd ~/events

30. Replay recorded events from the event03 file:

sudo /opt/kaspersky/kuma/kuma tools load --raw --events event03

--cfg cef.cfg --replay 1

Enter the password Ka5per$Ky to elevate privileges.


174
Lab 8. Configure DNS data enrichment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

31. Return to the KUMA web

console

32. Open Resources | Active

services and select the
checkbox in the row for the
[OOTB] CEF WMI collector
service

33. Click Go to events

34. Find a new event named Network attack detected and click on an empty space in its row to
open it

175
Lab 8. Configure DNS data enrichment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

35. Notice that the

SourceAddress,
SourceHostName,
DestinationAddress and
DestinationHostName fields
are filled in the normalized
event

36. Also notice that the original

raw event contains only the
destination name
(dhost=dc.abc.lab) and the
source address
(src=10.28.0.150)

The missing information (source name and destination address) was obtained through
DNS enrichment. The raw data contains neither the FQDN admin-laptop.abc.lab nor the

IP address 10.28.0.10.

Conclusion

176
Lab 8. Configure DNS data enrichment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

This lab demonstrates how to enrich events using DNS queries.

177
Lab 9. Configure GeoIP data enrichment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Lab 9. Configure GeoIP data enrichment

Scenario

You want to supplement events with geolocation data based on IP addresses specified in various
fields of the initial event. You can use geodata from third-party sources such as MaxMind or
IP2Location, but they need to be converted to a format that KUMA 2.0 supports. Convert a MaxMind
GeoIP database to a format that KUMA supports. Upload the converted data to KUMA, configure a
geodata enrichment rule, and add this rule to the [OOTB] CEF normalizer.

Contents

Task A: A. Convert a MaxMind GeoIP database to a format that KUMA supports

Task B: B. Upload geodata to KUMA

Task C: C. Create an enrichment rule and add it to the collector

Task D: D. Make sure enrichment works

Task A: Convert a MaxMind GeoIP database to a format that

KUMA supports
Convert a third-party MaxMind GeoIP database to a format that KUMA supports using a special script.

The task is performed on admin-laptop.

1. Go to https://help.kaspersky.com

2. Scroll down the list of products and open the documentation for KUMA 3.2

178
Lab 9. Configure GeoIP data enrichment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

3. Switch to your language if available

4. In the search box, enter MaxMind and open the article Converting geographic data from MaxMind
and IP2Location

5. Read the article and study the geodata format used in KUMA

6. Download the script that converts data from MaxMind and IP2Location to the KUMA geodata
format (use the corresponding link in the article)

179
Lab 9. Configure GeoIP data enrichment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

7. Extract the script from the archive

8. Run Windows PowerShell as an administrator

For example, right-click the Start button and select Windows PowerShell (Admin).

180
Lab 9. Configure GeoIP data enrichment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

9. Go to the folder C:\users\Administrator\Downloads\converter where converter.py has been

unzipped

10. Run the following command to convert MaxMind data from the C:\Max\MaxMind.zip archive to the
KUMA geodata format:

python .\converter.py --type maxmind --input C:\Max\MaxMind.zip

--out C:\Max\geoip_maxmind.csv

11. Wait for the script to complete (this may take several minutes). When ready, the message
Successfully done will appear in the console.

Task B: Upload geodata to KUMA

Upload the csv file that you prepared in the previous task to the core so that KUMA services can use
this geodata for enrichment.

The task is performed on admin-laptop.

12. Return to the KUMA web console

13. Open Settings | Common

14. In GeoIP settings, click Import from file

181
Lab 9. Configure GeoIP data enrichment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

15. Select the

geoip_maxmind.csv file
prepared in the previous task

16. Click Open

17. Wait for the data to be uploaded successfully (which may take several minutes).

182
Lab 9. Configure GeoIP data enrichment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

When ready, the console will display the message After uploading geodata you must

restart services with ‘geographic data’ enrichment rules.

Task C: Create an enrichment rule and add it to the collector

Create a new geographic data enrichment rule. Add the geodata enrichment rule to the [OOTB] CEF
WMI collector and reload its settings.

The task is performed on admin-laptop.

18. In the KUMA web console,

open the Resources |
Enrichment rules section

19. In the left pane, select the

Lab folder

If this folder is absent,


create it.

183
Lab 9. Configure GeoIP data enrichment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

20. Click + Add

21. Configure the enrichment

settings:

a. Name: [Lab] GeoIP

b. Tenant: Main

c. Source kind: geographic

data

22. In the Mapping geographic

data to event fields area, in
the drop-down list, select
SourceAddress

23. Click the Apply default

mapping button to add pre-
configured pairs of geodata
attributes and KUMA event
fields for SourceAddress

During geodata enrichment, an IP address will be extracted from the SourceAddress field

of a KUMA event, and the corresponding geodata will be obtained from the database.

24. Verify that your Mapping 1

settings match the settings in
the screenshot

25. Click + Add mapping

184
Lab 9. Configure GeoIP data enrichment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

26. In the Event field with IP

address drop-down list,
select DestinationAddress

27. Click the Apply default

mapping button to add pre-
configured pairs of geodata
attributes and KUMA event
fields for DestinationAddress

28. Leave other settings

unchanged

29. Click Create new in the

lower-left corner to create
and save the resource

30. In the KUMA web console,

open the Resources | Active
services section

31. Click the name of the [OOTB]

CEF WMI service to open the
collector settings

185
Lab 9. Configure GeoIP data enrichment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

32. Switch to the Event

enrichment section

33. Scroll down the list and click

+ Add enrichment

34. In the Enrichment rule drop-

down list, select the [Lab]
GeoIP resource

186
Lab 9. Configure GeoIP data enrichment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

35. Make sure the Event

enrichment section now
displays settings from the
[Lab] GeoIP resource

36. Switch to the Setup

validation section

37. Click Save and update

service configurations to
save the settings and apply
them to the collector service

38. Click Save to close the

collector settings

Task D: Make sure enrichment works

Send a test event to the collector and make sure the stored events are enriched with geodata.

The task is performed on admin-laptop.

187
Lab 9. Configure GeoIP data enrichment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

39. Open the window with the SSH session to the kuma-core.abc.lab server

If you closed PuTTY, run it and connect to kuma-core.abc.lab as admin with the password

Ka5per$Ky.

40. Go to the ~/events directory

cd ~/events

41. Replay recorded events from the event04 file:

sudo /opt/kaspersky/kuma/kuma tools load --raw --events event04

--cfg cef.cfg --replay 1 --limit 1

In this task, it is important to send just a single event. If the utility sends several events,
the collector will "glue" them together and the normalizer will not be able to process them

correctly. To send exactly one event, add the --limit 1 parameter to the usual send
command. This sets a limit on the number of events per second.

Enter the password Ka5per$Ky to elevate privileges.


42. Return to the KUMA web console

43. Find the event that arrived at the [OOTB] CEF WMI collector. To do so, open Resources | Active
services and select the checkbox in the row with the collector service [OOTB] CEF WMI. Click
Go to events

44. Find the event where DeviceProduct = netflow

188
Lab 9. Configure GeoIP data enrichment KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

45. To open the test event, click

on an empty space in its row

46. Notice that the

SourceCountry,
SourceRegion, SourceCity,
SourceLatitude and
SourceLongitude fields are
filled in the normalized event

47. Also notice that the original

raw event contains only
information about the IP
address of the connection
source (src=89.215.32.5) but
has no geodata

Geodata has been

added thanks to the

configured event
enrichment.

Conclusion

The lab demonstrates how to prepare and upload geodata to KUMA and then enrich the received
events with this information.

189
Lab 10. Import information about computers from Kaspersky Security KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Center

Lab 10. Import information about computers from

Kaspersky Security Center
Scenario

You want to populate the list of assets (computers) to take into account the asset’s category and
status when handling events. The easiest way to achieve this is to import computer information from
Kaspersky Security Center.

Contents

Task A: Configure an account for connections from KUMA in Kaspersky Security Center

Task B: Configure a connection to Kaspersky Security Center

Task C: Import assets and categorize them

Task D: Manually add a computer to the list of assets

Task E: Add a Kaspersky Endpoint Security license

Task A: Configure an account for connections from KUMA in

Kaspersky Security Center
To import computers, the kuma-core service connects to the Kaspersky Security Center server on the
port allocated to the Kaspersky Security Center web console (13299/tcp by default) under an account
that has access to Kaspersky Security Center.

Following the principle of minimum sufficiency, open Kaspersky Security Center and grant the
kuma.abc.lab user account the minimum permissions necessary for obtaining data about devices and
running Kaspersky Endpoint Security for Windows tasks on these devices.

The dc, ksc, kuma-core, kuma-storage-1, kuma-storage-2 and admin-laptop machines must be
powered on.

The task is performed on admin-laptop.

190
Lab 10. Import information about computers from Kaspersky Security KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Center

1. In a new web browser

window, open the Kaspersky
Security Center web console
at https://ksc.abc.lab:8080

2. Log in to the system as

Administrator with the
password Ka5per$Ky

If a browser warning about an insecure connection appears, select Advanced and then

Proceed to ksc.abc.lab (unsafe).

3. Go to Users & roles | Users

4. To quickly find the kuma user account in the table, type its name in the search field and press
ENTER

5. Select the kuma user that has the User type in the table and click the Assign role button

191
Lab 10. Import information about computers from Kaspersky Security KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Center

6. Select the Kaspersky

Endpoint Security
Administrator role and click
Next

This role is sufficient for automating responses by launching Kaspersky Endpoint Security

tasks as well as for obtaining data about computers where the Network Agent is installed.

192
Lab 10. Import information about computers from Kaspersky Security KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Center

7. Select the KSC scope and

click Assign role

8. Close the web console of Kaspersky Security Center

Task B: Configure a connection to Kaspersky Security Center

The connection to Kaspersky Security Center is configured in the Settings section. A connector
resource is not required in this case. Add a connection to the ksc.abc.lab:13299 server using the
secret resource created in one of the previous labs.

The task is performed on admin-laptop.

9. Return to the KUMA web console

10. Go to Settings | Kaspersky Security Center

11. Click Add settings for a new tenant

193
Lab 10. Import information about computers from Kaspersky Security KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Center

12. In the Tenant drop-down list,

select Main

13. Click Add connection

14. Specify the following:

a. Name: ksc.abc.lab

b. URL: ksc.abc.lab:13299

c. Secret: [Lab]
[email protected]

15. Leave the other settings

unchanged

16. Click Save to save

the connection

If the Secret drop-down list does not show any records and the console hangs, refresh

the page or open Connection parameters in a new browser window.

194
Lab 10. Import information about computers from Kaspersky Security KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Center

17. Click Save

18. Make sure the Settings

saved pop-up window
appears

Task C: Import assets and categorize them

Import computers from Kaspersky Security Center into the list of assets in KUMA. Create new asset
subcategories High business impact and Critical business impact within the Categorized assets |
Business impact category.

Manually place the Admin-Laptop computer in the High business impact category. Create a filter to
automatically add assets to the Critical business impact category with the following parameters: the
OS version contains ‘Windows Server’.

The task is performed on admin-laptop.

19. In the KUMA web console, open the Assets section

20. Select the Main | Uncategorized assets category in the left pane

21. Click the Import KSC assets button (at the top right)

195
Lab 10. Import information about computers from Kaspersky Security KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Center

If you see devices that have already been included in Uncategorized assets, then the
import task has already been created automatically without you clicking the Import KSC

assets button. Proceed with the instructions anyway.

22. In the Tenant drop-down list,

select the Main tenant

23. Click OK

196
Lab 10. Import information about computers from Kaspersky Security KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Center

24. Note the pop-up window that

informs you that the task for
importing KSC assets has
been created: Import task
created

25. In the KUMA web console,

open the Task manager
section

26. Make sure the KSC assets

import task manually created
by the Administrator has
appeared in the list

27. To view the results of the

task, click on an empty space
in its row

28. Return to the Assets section in the console

29. Make sure the Main | Uncategorized assets category now contains the ADMIN-LAPTOP and
KSC devices

30. Click the name of the ADMIN-LAPTOP computer

197
Lab 10. Import information about computers from Kaspersky Security KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Center

31. Read available information

about the computer in the
right pane

198
Lab 10. Import information about computers from Kaspersky Security KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Center

32. Expand the Software info

section to make sure you can
see information about the
programs installed on the
computer

33. Click Cancel in the lower-

right corner to close the asset
properties

34. In the category tree on the left, expand the Main | Categorized assets node, then expand
Business impact

35. Click the Add category button below the tree of categories

199
Lab 10. Import information about computers from Kaspersky Security KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Center

36. Set the category parameters:

a. Name: High business

impact

b. Parent: Main /
Categorized assets /
Business impact

c. Categorization kind:
Manually

d. Severity: High

37. Save the category

200
Lab 10. Import information about computers from Kaspersky Security KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Center

38. In the category tree on the

left, expand the Business
impact node and select the
created High business
impact node

39. Notice that the list of

computers is empty (on the
right)

40. Select the Main root category

41. Select the Admin-Laptop computer in the list of assets

42. Click the Link to category button in the lower right corner

201
Lab 10. Import information about computers from Kaspersky Security KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Center

43. Select the Main |

Categorized assets |
Business impact | High
business impact category
and click Submit

44. Select the Main | Categorized assets | Business impact | High business impact category in
the tree on the left

45. Make sure the ADMIN-LAPTOP computer is displayed there

202
Lab 10. Import information about computers from Kaspersky Security KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Center

46. Return to the Main |

Categorized assets |
Business impact category

47. Click the Add category

button below the tree of
categories

48. Set the category parameters:

a. Name: Critical business

impact

b. Parent: Main /
Categorized assets /
Business impact

c. Categorization kind:
Active

d. Severity: Critical

49. Scroll down the list of category settings

50. Set the categorization

parameter: Repeat
categorization every: 1h

51. In the Conditions area, click

+ Add condition

52. Create the following query

condition: if OS ilike
Windows Server

53. Click Test conditions

54. Make sure the KSC server is

displayed in the selection

55. Click OK and Save to save

the category

56. Open the Main | Categorized assets | Business impact | Critical business impact category in
the tree on the left

57. Make sure the KSC device has been automatically moved to the asset category

203
Lab 10. Import information about computers from Kaspersky Security KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Center

Task D: Manually add a computer to the list of assets

If necessary, you can manually supplement the assets that Kaspersky Security Center has supplied to
KUMA with other objects.

The task is performed on admin-laptop.

58. Open the Main |

Uncategorized assets
category in the tree on the
left

59. Click the Add asset button in

the upper-right corner

204
Lab 10. Import information about computers from Kaspersky Security KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Center

60. Fill in the fields as follows:

a. Asset name: DC

b. Tenant: Main

c. IP address: 10.28.0.10

d. FQDN: dc.abc.lab

61. Expand the Software area

62. Fill in the fields as follows:

a. Operating system name:

Microsoft Windows
Server 2019

b. Operating system build:

17763

63. Click the Add button in the

lower-right corner to add the
asset

64. Make sure a new DC device has appeared in the Uncategorized assets category

The manually created DC asset satisfies the criterion of the dynamic Critical business

Impact category. Make sure the device moves to this category automatically.

65. Open the Main | Categorized assets | Business impact | Critical business impact category in
the tree on the left. The DC device has most likely not yet been moved to this category.

This dynamic group of assets is updated once an hour; let’s start the categorization

manually to avoid waiting so long.

66. Hover the mouse cursor over the Critical business impact category, click … to the right of the
asset name and select Start categorization

205
Lab 10. Import information about computers from Kaspersky Security KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Center

67. Select any other category,

then return to Critical
business impact

68. Make sure the DC device has

been moved to this asset
category

69. Open the window with the SSH session to the kuma-core.abc.lab server

If you closed PuTTY, run it and connect to kuma-core.abc.lab as admin with the password

Ka5per$Ky.

206
Lab 10. Import information about computers from Kaspersky Security KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Center

70. Go to the ~/events directory, if necessary:

cd ~/events

71. To replay recorded events from the event05 file, run the following command (type it on a single
line):

sudo /opt/kaspersky/kuma/kuma tools load --raw --events event05

--cfg cef.cfg --replay 1

Enter the password Ka5per$Ky to elevate privileges.


72. Return to the KUMA web console

73. Find the events that have arrived at the [OOTB] CEF WMI collector

Open Resources | Active services, select the checkbox in the row for the [OOTB] KSC

collector service. Click Go to events, and then click on the magnifying glass icon.

207
Lab 10. Import information about computers from Kaspersky Security KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Center

74. Find a new event named

Network attack detected
and click on an empty space
in its row to open it

75. Notice that the

SourceAssetID and
DestinationAssetID fields
have appeared in the
normalized event

76. Click the identifier in the

SourceAssetID field

77. Study the information about

the source of the network
attack

The missing information about the source name and destination IP of the network attack
was obtained thanks to DNS enrichment; this data allowed the system to link the event

with the admin-laptop.abc.lab and dc.abc.lab assets.

Conclusion

This lab demonstrates how to import assets from Kaspersky Security Center, how to create them
manually and how to categorize them. A subsequent lab will show how you can use asset categories
in the conditions of correlation rules.

208
Lab 11. Configure event enrichment using Active Directory KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Lab 11. Configure event enrichment using Active

Directory
Scenario

You want to import information about domain users to KUMA to be able to enrich events with this
data. This will allow you to see extended information about accounts in events and configure
correlation rules based on account membership in Active Directory groups. For this purpose,
configure an LDAP connection to the domain controller in the KUMA settings.

Contents

Task A: Create an Active Directory connection in the KUMA settings

Task B: Set up event enrichment in a KATA collector

Task C: Make sure KATA events contain detailed information about the user

Task A: Create an Active Directory connection in the KUMA

settings
Configure connection to the Active Directory of the abc.lab domain; specify dc.abc.lab:3268 as the
address for LDAP requests.

The dc, kata-cn, ksc, kuma-core, kuma-storage-1, kuma-storage-2 and admin-laptop machines
must be powered on.

The task is performed on admin-laptop.

Start the kata-cn virtual machine, which is required for this lab.

1. In the KUMA web console, open the Settings section

2. Go to the LDAP server settings

3. Click Add settings for a new tenant

209
Lab 11. Configure event enrichment using Active Directory KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

4. In the Tenant drop-down list,

select Main

5. After you select a tenant, the

Add connection button will
appear. Click it

210
Lab 11. Configure event enrichment using Active Directory KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

6. Specify the following

connection settings:

a. Name: abc.lab

b. Secret: [Lab]
[email protected]

c. URL: dc.abc.lab:389

d. Type: insecure

e. Base DN:
DC=abc,DC=lab

7. Leave the default values for

the other settings

8. Click Save to save the

connection settings

[Lab] [email protected] is a secret with access credentials that we created in one of the
previous labs for the kuma.abc.lab service account. We will use this secret because the

permissions of this account are quite sufficient for sending LDAP requests.

9. Click Save in the LDAP

server integration window to
save the settings

10. Click Import accounts to

force importing accounts
from Active Directory

211
Lab 11. Configure event enrichment using Active Directory KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

11. In the KUMA web console, open the Task manager section

12. Make sure the Accounts import task manually created by the Administrator has appeared in the
list

13. Click on the task status to

check that it has imported
new accounts

Task B: Set up event enrichment in a KATA collector

In the settings of the [Lab] KATA event collector, configure enrichment with Active Directory data via
LDAP queries.

The task is performed on admin-laptop.

14. Return to the KUMA web console

15. Go to Resources | Active services

16. Click the name of the [Lab] KATA service to open its settings

212
Lab 11. Configure event enrichment using Active Directory KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

17. Switch to the Event

enrichment section

18. Click + Add enrichment

with LDAP data

19. In the LDAP accounts

mapping field, enter abc.lab
and click Add: "abc.lab"

20. Make sure the abc.lab

domain has been added

21. Click Apply default

mapping

213
Lab 11. Configure event enrichment using Active Directory KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

22. Study the table of mappings

between the KUMA event
field to look up and LDAP
attribute to receive fields
and the KUMA event field to
write to field

This table establishes a mapping between the KUMA event fields and account attributes
obtained from LDAP, whose values will be checked during the enrichment process. If a
value of a KUMA event field matches an attribute from Active Directory, the corresponding

Windows account data will be used to enrich the KUMA event and will be added to the
field specified in the KUMA event field to write to field.

23. Switch to the Setup

validation section

24. Click Save and restart

services to apply the
settings

25. Click Save to close the

service settings

Task C: Make sure KATA events contain detailed information

about the user
Make sure the kata-cn virtual machine is powered on.

Send [email protected] an email containing a link to a test page that imitates a malicious site. Find the
corresponding event from Kaspersky Anti Targeted Attack in the KUMA console and make sure it

214
Lab 11. Configure event enrichment using Active Directory KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

contains information about the ABC\Alex domain user.

The task is performed on admin-laptop.

26. Open PowerShell and run the following command (type it on a single line) to send an email:

Send-MailMessage -From [email protected] -To [email protected] -Subject

"Salary review" -Body "http://www.kaspersky.com/test/wmuf"
-SmtpServer 10.28.0.10

27. In the KUMA console, find the events that have arrived at the [Lab] KATA collector

Open Resources | Active services, select the checkbox in the row with the [Lab] KATA

collector service and click Go to events.

28. Find and open the event that has URL from mail detected in the Name column and [email protected]
in the DestinationUserName column

If the event does not arrive, try sending the email again using 10.28.0.51 as the IP

address of the KATA SMTP server.

215
Lab 11. Configure event enrichment using Active Directory KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

29. Click the identifier in the

DestinationAccountID field

216
Lab 11. Configure event enrichment using Active Directory KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

30. Review the account

information

Conclusion

This lab demonstrates how to add account information from Active Directory to KUMA, how to
configure LDAP enrichment in collector service settings, and where to find this information in the
events that arrive.

217
Lab 12. Configure enrichment with CyberTrace data KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Lab 12. Configure enrichment with CyberTrace data

Scenario

You want to enrich data in KUMA with information from data feeds provided by Kaspersky
CyberTrace. This will allow analysts to see additional information and the context of threats
associated with the indicator from the KUMA event.

Configure an enrichment rule and connection to CyberTrace in the KUMA settings. Enable data
enrichment from CyberTrace for the KUMA event normalizer.

Contents

Task A: Configure integration with the CyberTrace web user interface

Task B: Configure KUMA’s connection to CyberTrace

Task C: Add an event enrichment rule to the collector

Task D: Make sure enrichment works

Task A: Configure integration with the CyberTrace web user

interface
Configure integration between KUMA and the Kaspersky CyberTrace web user interface. This will
allow you to work with both Kaspersky Unified Messaging and Analysis Platform and Kaspersky
CyberTrace from the KUMA web console.

The cybertrace, dc, kata-cn, ksc, kuma-core, kuma-storage-1, kuma-storage-2 and admin-
laptop machines must be powered on.

The task is performed on admin-laptop.

Start the cybertrace virtual machine, which is required for this lab.

218
Lab 12. Configure enrichment with CyberTrace data KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

1. Download a CyberTrace key file

Ask the trainer where to find the key file for Kaspersky CyberTrace.

2. Start Google Chrome and go to https://cybertrace.abc.lab

If a warning about an untrusted Kaspersky Endpoint Security certificate appears, click I


understand the risks and wish to continue and then Confirm.

3. Log in as admin, password

Ka5per$Ky

4. Open Settings | Licensing

5. Click Add new license key

6. Click Browse

7. Specify the CyberTrace key

file

8. Click Open, then Add and

Close

219
Lab 12. Configure enrichment with CyberTrace data KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

9. Return to the KUMA web console

10. Open Resources

11. Click Secrets

12. Select the Main | Lab folder in the left pane

13. Click Add secret

14. Specify credentials for

accessing Kaspersky
CyberTrace:

a. Name: [Lab]
[email protected]
ab

b. Tenant: Main

c. Kind: credentials

d. User: admin

e. Password: Ka5per$Ky

15. Click Create new to create

and save the resource

16. In the KUMA web console, open the Settings section

17. Go to the Kaspersky CyberTrace settings section

18. Specify the CyberTrace web console connection settings:

a. Host: 10.28.0.13

b. Port: 443

c. Secret: [Lab] [email protected]

This is the secret with access credentials that we just created.


19. Click Save to save the connection

220
Lab 12. Configure enrichment with CyberTrace data KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

20. Notice that the CyberTrace section has appeared on the menu in the KUMA web console; open it
and wait for the CyberTrace console to load

221
Lab 12. Configure enrichment with CyberTrace data KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

21. Open Settings | Service

22. Review the settings in the Connection settings section

23. Make sure the following values are set in the Service listens on area:

a. IP address: 0.0.0.0

b. Port: 9999

Memorize the port value — we will need it in the next task.


Task B: Configure KUMA’s connection to CyberTrace
Create a new CyberTrace enrichment rule and specify the CyberTrace server connection settings in it.

The task is performed on admin-laptop.

24. In the KUMA web console,

open the Resources |
Enrichment rules section

25. In the left pane, select the

Lab folder

26. Click the Add enrichment

rule button in the upper-left
corner

If this folder is absent, create it.


222
Lab 12. Configure enrichment with CyberTrace data KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

27. Configure the enrichment

settings:

a. Name: [Lab] СyberTrace

b. Source kind: cybertrace

c. URL: 10.28.0.13:9999

223
Lab 12. Configure enrichment with CyberTrace data KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

28. Click + Add mapping four times to add four new entries to the Mapping section

29. Fill in the KUMA field and CyberTrace indicator fields with the following values:

SourceAddress ip

DestinationAddress ip

FilePath url

DeviceCustomString4 hash

This table maps KUMA event fields to the CyberTrace indicator fields that will be
compared during the enrichment process. If the hash, IP address or URL from a KUMA

event matches a CyberTrace indicator, then CyberTrace data will be used to enrich the
KUMA event.

30. Leave other settings unchanged

31. Click Create new in the lower-left corner to create and save the resource

Task C: Add an event enrichment rule to the collector

Add an enrichment rule to the [OOTB] CEF WMI collector and reload its settings.

The task is performed on admin-laptop.

224
Lab 12. Configure enrichment with CyberTrace data KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

32. In the KUMA web console, open the Resources | Active services section

33. Click the name of the [OOTB] CEF WMI service to open the collector settings

34. Switch to the Event

enrichment section

35. Scroll down the list and click

+ Add enrichment

36. In the Enrichment rule drop-

down list, select the [Lab]
CyberTrace resource

37. Make sure the Event

enrichment section now
displays settings from the
[Lab] CyberTrace resource

225
Lab 12. Configure enrichment with CyberTrace data KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

38. Switch to the Setup

validation section

39. Click Save and update

service configurations to
save the resource settings

Task D: Make sure enrichment works

Prepare and send a test event to the collector. Check that the event in the storage has been enriched
with CyberTrace data.

The task is performed on admin-laptop.

40. In the KUMA web console, open the CyberTrace section

41. Go to the Indicators section in the Kaspersky CyberTrace console

42. In the search field, type:

ioc_type: IP

Doing this will cause only IP addresses to be displayed in the list of indicators of

compromise.

43. Copy an IP address that CyberTrace treats as an indicator of compromise to the clipboard

226
Lab 12. Configure enrichment with CyberTrace data KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

44. Open the window with the SSH session to the kuma-core.abc.lab server

If you closed PuTTY, run it and connect to kuma-core.abc.lab as admin with the

password Ka5per$Ky.

45. Go to the ~/events directory

cd events/

46. In the mcedit editor, open the event07 file:

mcedit event07

47. Paste the IP address copied from CyberTrace at the very end of the test event (the dst field). As
a result, it should look like this:

CEF:0||netflow|IPFIX|||4|deviceInboundInterface=11
deviceOutboundInterface=89 src=10.28.0.150 spt=151354 in=149
proto=TCP flexNumber1=1 flexNumber1Label=packets dpt=53
dst=<address from the clipboard>

To finish editing and exit the mcedit editor, press F10.


48. Select Yes to save the changes

227
Lab 12. Configure enrichment with CyberTrace data KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

49. Run the following command to replay recorded events from the event07 file. Pay attention to the
parameter at the end:

sudo /opt/kaspersky/kuma/kuma tools load --raw --events event07

--cfg cef.cfg --replay 1 --limit 1

50. Return to the KUMA web console

51. Find the event that arrived at the [OOTB] CEF WMI collector.

Open Resources | Active services, select the checkbox in the row with the [OOTB] CEF
WMI collector service and click Go to events. Look for the event where the

DestinationAddress field contains the IP address that you specified in the event07 file.

52. To open the new event, click on an empty space in its row

228
Lab 12. Configure enrichment with CyberTrace data KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

53. Scroll down the event card

54. Notice that the Indicator

category field has appeared
in the normalized event

55. Click KL_IP_Reputation to

expand the section with the
detected threat’s context

229
Lab 12. Configure enrichment with CyberTrace data KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

56. Review the data obtained

through enrichment

Conclusion

The lab demonstrates how to set up integration between KUMA and CyberTrace and enrich KUMA
events with CyberTrace data.

230
Lab 13. Configure cold storage for events in KUMA KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Lab 13. Configure cold storage for events in KUMA

Scenario

You want to optimize event storage in Kaspersky Unified and Analysis Platform by moving some
events to low-performance hardware that is less expensive.

Dedicated cheap disks are already connected to kuma-storage-1.abc.lab and kuma-storage-2.abc.lab

servers. You need to format these disks and mount them to the ClickHouse cluster nodes; then
configure the logic for moving events to cold storage (slower disks) in the settings of the [OOTB]
Storage service.

Contents

Task A: Mount disks for cold data storage

Task B: Configure cold data storage

Task C: Make sure events arrive at the cold storage

Task A:Mount disks for cold data storage

New disks for cold storage are already connected to the ClickHouse cluster nodes, but to make them
usable, you need to create partitions, format and mount them.

The dc, kata-cn, ksc, kuma-core, kuma-storage-1, kuma-storage-2 and admin-laptop machines
must be powered on.

The task is performed on admin-laptop.

231
Lab 13. Configure cold storage for events in KUMA KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

1. Start PuTTY (you can find

shortcuts for it on the
desktop, in the Start menu
and on the taskbar)

2. To connect to the first

Kaspersky Unified Monitoring
and Analysis storage server,
in the Host Name (or IP
address) field, enter kuma-
storage-1

3. Click Open

4. Log in to the admin account

with the password
Ka5per$Ky

5. In AWS, an unformatted 30GB drive is connected to the kuma-storage-1 virtual machine; find out
its name using the following command (the drive name will be specified at the beginning of the
line with the command output; memorize it):

lsblk | grep 30

If the lab is performed on Vmware ESXi with Oracle storages, the disk is named sdb; you

don’t need to check this — just use the sdb name in further commands.

6. Format the cheap low-end disk designed for cold storage of events:

sudo fdisk /dev/<disk_name>

232
Lab 13. Configure cold storage for events in KUMA KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Enter the password Ka5per$Ky to elevate privileges.


7. Run the g command to create a new GUID partition table (GPT)

8. Run the n command to create a new partition

9. Press ENTER three times without entering any data when prompted for the partition number and
the first and last sectors

10. Run the w command to write the configured changes to the disk

11. If your lab environment is deployed in AWS, run the following command to find out the name of
the created partition:

lsblk | grep 30

12. Write down or save the partition name. You will need it when editing the fstab file

233
Lab 13. Configure cold storage for events in KUMA KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

If the lab is performed on Vmware ESXi with Oracle storages, the partition will be named

sdb1; you don’t need to check this — just use the sdb1 name in further commands.

13. Format the partition to an xfs file system using its name from the previous step:

sudo mkfs -t xfs /dev/<partition_name>

In a VMWare ESXi environment with Oracle, the command will look like this: sudo mkfs

-t xfs /dev/sdb1.

14. Create the /media/backup directory that the cold storage disk will be mounted to:

sudo mkdir –p /media/backup

15. Mount the created partition to the /media/backup folder:

sudo mount /dev/<partition_name> /media/backup

In a VMWare ESXi environment with Oracle, the command will look like this: sudo

mount /dev/sdb1 /media/backup.

16. Specify the kuma user as the owner of /media/backup:

sudo chown kuma /media/backup

234
Lab 13. Configure cold storage for events in KUMA KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

17. Add the configuration of the mounted disk to /etc/fstab to ensure that it persists after the operating
system restarts on kuma-storage-1.abc.lab. To do this, open the file with the command:

sudo mcedit /etc/fstab

18. Add the following line at the end of the file:

/dev/<partition_name> /media/backup xfs

defaults 0 2

In a VMWare ESXi environment with Oracle, the line will look like this: /dev/sdb1

/media/backup xfs defaults 0 2.

The file contents in the screenshot may differ from the file contents in your lab
environment. It is important to correctly add the new line to the end of the file. Keep in

mind that columns in this file are separated by tabs or spaces.

It is critical that you edit the fstab file without introducing any typos. If you make a typo, a
problem is very likely to arise the next time the virtual machine starts. Check each

character carefully, including slashes.

19. Press F10 and select Yes to save and close the file

20. Close the PuTTY window with the admin@kuma-storage-1 user session. We won’t need it
anymore

235
Lab 13. Configure cold storage for events in KUMA KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

21. Start PuTTY (you can find

shortcuts for it on the
desktop, in the Start menu
and on the taskbar)

22. To connect to the second

Kaspersky Unified Monitoring
and Analysis storage server,
in the Host Name (or IP
address) field, enter kuma-
storage-2

23. Click Open

24. Log in to the admin account

with the password
Ka5per$Ky

25. In AWS, an unformatted 30GB drive is connected to the kuma-storage-2 virtual machine; find out
its name using the following command (the drive name may differ from the drive name on kuma-
storage-1; it will be specified at the beginning of the command output; memorize it):

lsblk | grep 30

If the lab is performed on Vmware ESXi with Oracle storages, the disk is named sdb; you

don’t need to check this — just use the sdb name in further commands.

26. Format the cheap low-end disk designed for cold storage of events:

sudo fdisk /dev/<disk_name>

In a VMWare ESXi environment with Oracle, the command will look like this: sudo

fdisk /dev/sdb.

236
Lab 13. Configure cold storage for events in KUMA KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Enter the password Ka5per$Ky to elevate privileges.


27. Run the g command to create a new GUID partition table (GPT)

28. Run the n command to create a new partition

29. Press ENTER three times without entering any data when prompted for the partition number and
the first and last sectors

30. Run the w command to write the configured changes to the disk

237
Lab 13. Configure cold storage for events in KUMA KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

31. If your lab environment is deployed in AWS, run the following command to find out the name of
the created partition:

lsblk | grep 30

32. Write down or save the partition name. You will need it when editing the fstab file

If the lab is performed on Vmware ESXi with Oracle storages, the partition will be named

sdb1; you don’t need to check this — just use the sdb1 name in further commands.

33. Format the partition to an xfs file system using its name from the previous step:

sudo mkfs -t xfs /dev/<partition_name>

In a VMWare ESXi environment with Oracle, the command will look like this: sudo mkfs

-t xfs /dev/sdb1.

34. Create the /media/backup directory that the cold storage disk will be mounted to:

sudo mkdir –p /media/backup

35. Mount /dev/<partition_name> to the /media/backup folder:

sudo mount /dev/<partition_name> /media/backup

In a VMWare ESXi environment with Oracle, the command will look like this: sudo

mount /dev/sdb1 /media/backup.

238
Lab 13. Configure cold storage for events in KUMA KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

36. Specify the kuma user as the owner of /media/backup:

sudo chown kuma /media/backup

37. Add the configuration of the mounted disk to /etc/fstab to ensure that it persists after the operating
system restarts on kuma-storage-2.abc.lab.

sudo mcedit /etc/fstab

38. Add the following line at the end of the file:

/dev/<partition_name> /media/backup xfs

defaults 0 2

In a VMWare ESXi environment with Oracle, the line will look like this: /dev/sdb1

/media/backup xfs defaults 0 2.

The file contents in the screenshot may differ from the file contents in your lab
environment. It is important to correctly add the new line to the end of the file. Keep in

mind that columns in this file are separated by tabs or spaces.

It is critical that you edit the fstab file without introducing any typos. If you make a typo, a
problem is very likely to arise the next time the virtual machine starts. Check each

character carefully, including slashes.

39. Press F10 and select Yes to save and close the file

40. Minimize the PuTTY window with the admin@kuma-storage-2 user session. We will need it later

Task B: Configure cold data storage

Configure how to store events in the [OOTB] Storage, taking into account the newly added disks.

239
Lab 13. Configure cold storage for events in KUMA KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

The task is performed on admin-laptop.

41. Return to the KUMA web console

42. Go to Resources | Active services

43. Select an [OOTB] Storage service (any except the keeper, which is installed on kuma-
core.abc.lab) and click Go to partitions

44. Notice the available partitions, stored events and values in the Transfer to cold storage column

240
Lab 13. Configure cold storage for events in KUMA KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

These are dates when events will be automatically moved to cold storage. Since we have
not yet configured cold storage on the KUMA side, this is actually the date when the

corresponding events will be deleted.

45. Close the list of ClickHouse

partitions

46. Open Resources | Storages

47. Click the [OOTB] Storage

resource to open its settings

241
Lab 13. Configure cold storage for events in KUMA KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

48. Notice how the retention

period is configured for audit
events and all other KUMA
events

At this point, these settings specify only the retention time for the main storage.

49. Scroll down the resource
settings card to the Disks for
cold storage area

50. Click Add disk

242
Lab 13. Configure cold storage for events in KUMA KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

51. Scroll up the window and

notice that additional fields
for cold storage of events
have appeared in the area
where the event retention
period is configured

52. Specify the following event

storage settings:

Retention 1
period

Cold retention 31
period

Audit 365
retention
period

Audit cold 0
retention
period

As a result, KUMA audit events will be stored only on the fast drives of the main storage
for 365 days, after which they will be deleted from the system. All other events will be

stored for 1 day on the fast drives of the main storage, then they will be transferred to the
slow disks of the cold storage and retained for 31 days more.

53. Scroll down the window. For In the Path field, don’t forget the trailing slash / at the

the added disk in the lower end of the disk path.
part of the window, specify
the following parameters for
the disks that provide cold
storage of events:

a. FQDN: Local

b. Name: Backup

c. Path: /media/backup/

243
Lab 13. Configure cold storage for events in KUMA KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

54. Click Save

55. Go to Resources | Active

services

56. Select the checkboxes next

to the [OOTB] Storage
services of all three cluster
nodes

57. Click Restart

58. Click OK to confirm restarting

the services

59. Click the Refresh button (the icon next to the search box) periodically to monitor the status of
storage services

60. Wait for the services to restart and the Status to become green, which means that the service
has started and is running without errors.

61. Select an [OOTB] Storage and click Go to partitions

62. Notice the available partitions, stored events and values in the Transfer to cold storage column

244
Lab 13. Configure cold storage for events in KUMA KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

You may have a smaller list of partitions — partitions are created every day. The dates
have changed according to the current settings of the [OOTB] Storage service. For Kuma

Default partitions, the date of transfer to the cold storage should be tomorrow and storage
expiration should be next month (+31 days from today).

Task C: Make sure events arrive at the cold storage

Make sure historical data has been moved to cold storage according to the configured settings.
Having said that, the event-handling logic remains the same regardless of where the data is located.

The task is performed on admin-laptop.

245
Lab 13. Configure cold storage for events in KUMA KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

63. Open the window with the SSH session to the kuma-storage-2.abc.lab server

If you closed PuTTY, run it and connect to kuma-storage-2 as admin with the password

Ka5per$Ky.

64. Run the following command to make sure that after new settings were applied, database
partitions were created into which events that meet the configured cold storage criteria have
already been moved:

sudo /opt/kaspersky/kuma/clickhouse/bin/client.sh -d kuma

--multiline --query "SELECT partition, disk_name, sum(rows)
FROM system.parts WHERE database ='kuma' GROUP BY partition,
disk_name;"

Events are moved to cold storage when they expire in primary (hot) storage. In our lab
environment, a day must pass before this occurs. If you install KUMA and complete this
lab on the same day, new partitions will be created only the next day, because sufficiently
old events simply do not exist in the storage. If the storage contains events for the

previous day (that is, you started completing the labs yesterday), the backup partitions
may appear some time later today. You can proceed to the next lab, and return to this one
in about half an hour.

65. Return to the KUMA web console

66. Go to Resources | Active services

67. Select an [OOTB] Storage and click Go to partitions

68. Switch to the Cold storage tab

69. Notice the available data about new partitions (size on disk, number of events, event transfer date
and time)

246
Lab 13. Configure cold storage for events in KUMA KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

70. Close the window with the list of ClickHouse partitions

71. Switch to the Events section

72. Set the time period for events: last month, excluding the current date when you are performing
this task

73. Click Apply

In our example, we chose the interval of June 1-17, because the lab was performed on

June 18.

74. In the query field, add the following condition to display only non-audit events:

SELECT * FROM ‘events’ WHERE Type != 4 ORDER BY Timestamp DESC

LIMIT 250

75. Click Run query

76. Notice that all the matching events have been found, and the logic and syntax of the search query
do not change regardless of the partition where events are located

247
Lab 13. Configure cold storage for events in KUMA KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

By doing this, only events from the cold storage will be displayed in the search results

(non-audit events over the last month, excluding the current date).

Conclusion

This lab demonstrates how to optimize storage in Kaspersky Unified and Analysis Platform by
creating additional database partitions and storing historical data on cheaper low-performance
hardware.

248
Lab 14. Create a simple correlation rule KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Lab 14. Create a simple correlation rule

Scenario

You want to receive alerts when the IDS technology of Kaspersky Anti Targeted Attack detects a
dangerous object in the traffic of computers that belong to the High business impact asset category.

Contents

Task A: View a KATA IDS event

Task B: Create a simple correlation rule

Task C: Add the rule to the correlator settings

Task D: Test the rule

Task A: View a KATA IDS event

Trigger a KATA IDS alert by sending a DNS query to resolve the bandtester.com name. Search the
KUMA web console for this event and find out the values of the DeviceProduct and
DeviceEventClassID attributes.

The dc, kata-cn, ksc, kuma-core, kuma-storage-1, kuma-storage-2 and admin-laptop machines
must be powered on.

The task is performed on admin-laptop.

1. Start PowerShell and run the

following command: nslookup
bandtester.com

249
Lab 14. Create a simple correlation rule KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

2. In the Resources section, click Active services. Select the row with the [Lab] KATA collector
service and click Go to events.

Kaspersky Anti Targeted Attack events should appear in the list, including several events

named IDS event detected.

3. Open the latest IDS event detected event that has destination address 10.28.0.10

If the DestinationAddress column is not displayed in the search results, click the gear

icon to add it.

4. Pay attention to the values of the DeviceProduct and DeviceEventClassID fields

To generate alerts for such events, you need to configure a condition that unambiguously
describes events of this type. The following fields come in handy: DeviceProduct: KATA,

and DeviceEventClassId: ids.

5. Also, pay attention to the SourceAssetID field

It is the result of an implicit enrichment (i.e. not as a result of applying an enrichment rule)
of an event with data about assets. This means that when configuring a correlation rule,

you can add a condition that checks if the computer belongs to a particular asset category.

6. And note the DeviceCustomString1 field that contains the name of the detected threat

7. Close the browser tab with the event search

250
Lab 14. Create a simple correlation rule KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Task B: Create a simple correlation rule

Create a simple correlation rule that will be applied if all of the specified conditions are met.

251
Lab 14. Create a simple correlation rule KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

The task is performed on admin-laptop.

8. Go to Resources |
Correlation rules

9. In the tree on the left, select

the Main folder

10. Create a new folder named

Lab

11. Open the Lab folder

12. To create a new rule, click

the + Add button at the top

13. Configure the rule

parameters:

a. Name: [Lab] KATA IDS

detection

b. Kind: Simple

c. Propagated fields:
DeviceCustomString1

d. Severity: Medium

252
Lab 14. Create a simple correlation rule KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform


A simple rule is applied every time when an event that matches the specified conditions is
detected.

To speed up field selection, type a part of the field name in the combo box: this will narrow
down the list to the matching fields. When you see the necessary field in the list, select it.

You can do this several times for different fields.

Generally, KATA IDS alerts are not very important when considered by themselves. But
we will specify an additional condition that these detections relate to highly important

assets.

14. To configure rule-triggering conditions, switch to the Selectors tab

15. Click + Add condition to create a condition:

If DeviceProduct = KATA

In this condition, KATA is a constant


16. Click Add condition again to create another condition:

If DeviceEventClassID = ids

In this condition, ids is a constant.


17. Click Add condition again to create the third condition:

If SourceAssetId inCategory Main/Categorized assets/Business

impact/High business impact

253
Lab 14. Create a simple correlation rule KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

18. Click </> Code to switch to code entry mode

19. Familiarize yourself with the code

Your category ID may be different


254
Lab 14. Create a simple correlation rule KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

20. Switch to the Actions tab

21. Select Output and Loop to

correlator

22. Click Create new

Output sends the correlation event to the storage, and Loop to correlator sends it back
to the correlator’s input. Loop enables you to cascade correlation rules when the result of

triggering one rule is a condition for another rule.

23. Make sure the Lab folder

contains the [Lab] KATA IDS
detection rule

Task C: Add the rule to the correlator settings

To apply the rule, add it to the settings of the correlator service and update its configuration.

The task is performed on admin-laptop.

24. In the KUMA web console, open the Resources | Active services section

25. Click on the name of the [OOTB] Correlator service

255
Lab 14. Create a simple correlation rule KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

26. In the window that opens, switch to the Correlation section and click Link

27. Select the created correlation

rule

28. Click Link

256
Lab 14. Create a simple correlation rule KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

29. Make sure [Lab] KATA IDS

detection has appeared in
the list of correlation rules

30. Switch to the Setup

validation section and click
Save and update service
configurations

31. Click Save to close the

correlator settings

Task D: Test the rule

Repeat the DNS query to the dangerous domain and make sure the created rule generates an alert.
Review its contents.

The task is performed on admin-laptop.

32. Open the PowerShell window and repeat the command

nslookup bandtester.com

257
Lab 14. Create a simple correlation rule KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

33. In the KUMA web console, open the Alerts section

34. Make sure a [Lab] KATA IDS detection alert has appeared on the list

The alert should appear in a few seconds.


35. Open the alert

36. Pay attention to the list of Related events

37. Pay attention to the list of Related endpoints

258
Lab 14. Create a simple correlation rule KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

38. Scroll up the alert card

39. In the Assign to list, select

Me

Conclusion

This lab demonstrates how to create a simple correlation rule (one where each event that meets the
specified conditions triggers the rule), how to configure conditions for a correlation rule, how to add a
computer category to the conditions, where to find the results of correlation rules’ operation.

It is the correlator service that applies correlation rules. When a rule is triggered, the service creates a
correlation event. The kuma-core service generates alerts when correlation events appear. All
correlation events related to the same rule are added to the same alert. If an analyst closes an alert, a
new alert will be created when new correlation events of this type appear.

Subsequent labs will demonstrate how to create more complex correlation rules.

259
Lab 15. Create a standard correlation rule KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Lab 15. Create a standard correlation rule

Scenario

KATA URL reputation technology generates a large number of detections, most of which are not very
important. You only want to receive alerts from KUMA when the same computer establishes multiple
connections to a dangerous URL in a short period of time.

Contents

Task A: Study a KATA URL Reputation event

Task B: Configure a standard correlation rule

Task C: Add the rule to the correlator settings

Task D: Test the rule

Task A: Study a KATA URL Reputation event

To trigger KATA URL reputation technology, access the test malicious address
http://www.kaspersky.com/test/wmuf. Examine the event to find out which fields are suitable for
configuring a correlation rule.

The dc, kata-cn, ksc, kuma-core, kuma-storage-1, kuma-storage-2 and admin-laptop machines
must be powered on.

The task is performed on admin-laptop.

1. Start PowerShell and run the following command:

curl http://www.kaspersky.com/test/wmuf

260
Lab 15. Create a standard correlation rule KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

2. Return to the KUMA web console

3. Find the events that have arrived at the [Lab] KATA collector

Open Resources | Active services, select the checkbox in the row with the [Lab] KATA

collector service and click Go to events.

4. Find an event named URL from web detected and open it

261
Lab 15. Create a standard correlation rule KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

5. Note which field values

unambiguously identify this
type of event

6. Note the fields where KATA

writes the malicious address
and address of the source
computer

In this example, we will use the DeviceProduct and DeviceEventClassId fields, which

have the KATA and url_web values respectively.

RequestUrl and SourceAddress — we will group events by these attributes to count


connections to the same URL from the same computer.

Task B: Configure a standard correlation rule

Create a rule that will be applied when three connections from the same computer to the same
dangerous URL are detected within 30 seconds.

The task is performed on admin-laptop.

262
Lab 15. Create a standard correlation rule KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

7. Go to Resources |
Correlation rules

8. In the tree on the left, select

the Lab folder

9. Click + Add to create a new

rule

10. Specify the following

parameters:

a. Name: [Lab] Multiple

connections to a
malicious URL from the
same host

b. Kind: standard

c. Identical fields:
SourceAddress,
RequestUrl

d. Window, sec: 30

e. Severity: Medium

The rule will group events where the SourceAddress and RequestUrl fields coincide and
count them separately for each group. The correlation event will only contain a link to the

first event that meets the criteria. This is quite reasonable since the rule deals with events
of the same type.

263
Lab 15. Create a standard correlation rule KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

11. Switch to the Selectors tab

12. Configure the selector

parameters:

a. Alias: KATA url_web

detections

b. Selector threshold (event

count): 3

13. Select the Save filter checkbox under the Filter field

14. Name the filter [Lab] KATA url from web

15. Click Add condition

16. Configure additional parameters of the condition:

If DeviceProduct = KATA

In this condition, KATA is a constant


17. Click Add condition again

18. Configure additional parameters of the condition:

If DeviceEventClassID = url_web

In this condition, url_web is a constant.


264
Lab 15. Create a standard correlation rule KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

19. Switch to the Actions tab

20. Switch to the On every

threshold subtab and select
Output and Loop to
correlator

21. Click Create new

22. In the list of rules, make sure

the Lab folder contains the
[Lab] Multiple connections to
a malicious URL from the
same host rule

265
Lab 15. Create a standard correlation rule KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Task C: Add the rule to the correlator settings

To apply the rule, add it to the settings of the correlator service and update its configuration.

The task is performed on admin-laptop.

23. In the KUMA web console,

open the Resources | Active
services section

24. Click on the name of the

[OOTB] Correlator service

25. On the page that opens,

switch to the Correlation
section and click Link

26. Select the created [Lab]

Multiple connections to a
malicious URL from the same
host correlation rule and click
Link

266
Lab 15. Create a standard correlation rule KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

27. Make sure the [Lab] Multiple

connections to a malicious
URL from the same host rule
has appeared on the list of
correlation rules

28. Switch to the Setup

validation section and click
Save and update service
configurations

29. Click Save to exit the

correlator settings

Task D: Test the rule

Connect to the http://www.kaspersky.com/test/wmuf test URL three times in a row. Find an alert about
dangerous activity in the KUMA web console. Review the alert and close it as responded to. Learn
how to display closed alerts in the console.

The task is performed on admin-laptop.

267
Lab 15. Create a standard correlation rule KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

30. Open the PowerShell window and run the following command

1..3 | % {curl http://www.kaspersky.com/test/wmuf}

This command repeats the curl http://www.kaspersky.com/test/wmuf request three times.


31. Open the KUMA web console and switch to the Alerts section

32. Make sure the [Lab] Multiple connections to a malicious URL from the same host alert has
appeared on the list

The alert should appear in a few seconds.

33. Open the alert

34. Pay attention to the list of related events

There is only one related event, which corresponds to the correlation rule setting Base

event keep policy: first.

35. Click the Close alert button to close the alert and remove it from the list

268
Lab 15. Create a standard correlation rule KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

36. In the confirmation window,

select Responded and click
OK

37. Return to the list of alerts and make sure the closed alert is not displayed

38. Note that the Status heading is highlighted yellow, which means that a filter has been configured
for this header

39. Click the heading to view the

filter settings

40. Notice that closed alerts are

hidden by default, but you
can select to display them

269
Lab 15. Create a standard correlation rule KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Conclusion

This lab demonstrates how to create a standard correlation rule that reacts to a combination of
events, how to close an alert and where to find closed alerts if necessary.

270
Lab 16. Configure an alert for events logged in a specific order KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Lab 16. Configure an alert for events logged in a

specific order
Scenario

You want to generate a higher priority alert if Kaspersky Anti Targeted Attack detects a connection to a
malicious URL that has been previously detected in email.

Contents

Task A: Prepare filters to select url_web and url_mail events from KATA

Task B: Create a standard correlation rule with an order by filter

Task C: Add the rule to the correlator settings

Task D: Test the rule

Task A: Prepare filters to select url_web and url_mail events

from KATA
In the previous lab, we configured conditions for an event selector within a correlation rule. If you need
to use the same conditions in different rules, it makes sense to create them as named filter resources.

Create two filters: for url_web events from KATA and url_mail events from KATA.

The dc, kata-cn, ksc, kuma-core, kuma-storage-1, kuma-storage-2 and admin-laptop machines
must be powered on.

The task is performed on admin-laptop.

271
Lab 16. Configure an alert for events logged in a specific order KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

1. In the KUMA web console,

go to Resources | Filters

2. In the tree on the left, select

the Main folder

3. Click + Add folder to create

a subfolder named Lab

4. Select the created Lab folder

5. Click + Add to create a new

filter

6. Name the filter [Lab] KATA url from mail detection

7. Click </> Code to switch to code entry mode

8. Enter the following two lines of code:

DeviceProduct='KATA'
AND DeviceEventClassID='url_mail'

272
Lab 16. Configure an alert for events logged in a specific order KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

9. Click Create new

10. Make sure the filter has

appeared on the list

11. Click + Add to create another

filter

12. Name the filter [Lab] KATA url from web detection

13. Click </> Code to switch to code entry mode

14. Enter the following two lines of code:

DeviceProduct='KATA'
AND DeviceEventClassID='url_web'

15. Click Create new

16. Make sure there are now two

filters in the Lab folder

273
Lab 16. Configure an alert for events logged in a specific order KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Task B: Create a standard correlation rule with an order by filter

Create a correlation rule that will be applied if a dangerous link is detected in an email message
(‘KATA url from mail’) and then the same dangerous address is detected in web traffic within 30
seconds (‘KATA url from web’).

The task is performed on admin-laptop.

17. In the KUMA web console,

go to Resources |
Correlation rules

18. In the tree on the left, select

the Lab folder

19. Click + Add to create a new

rule

20. Specify the following

parameters:

a. Name: [Lab] Сonnection

to URL earlier detected
in mail

b. Kind: standard

c. Identical fields:
RequestUrl

d. Window, sec: 30

e. Base event keep policy:

all

f. Severity: Critical

g. Order by: Timestamp

274
Lab 16. Configure an alert for events logged in a specific order KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

The rule correlates events where the same dangerous URL is detected in different types
of traffic, i.e. in different types of events. That’s why we specified RequestUrl in Identical

fields. We also enabled saving all events, since the rule correlates events of different
types and they may all be interesting to analyze.

21. To configure rule-triggering

conditions, switch to the
Selectors tab

22. Configure the first selector:

a. Alias: KATA url in mail

b. Selector threshold (event

count): 1

c. In the Filter list, select the

preconfigured [Lab] KATA
url from mail detection
filter

23. Click Add selector at the

bottom of the first selector
area to add a selector for
another event type

24. Configure the second

selector:

a. Alias: KATA url in web

b. Selector threshold (event

count): 1

c. In the Filter list, select the

preconfigured [Lab] KATA
url from web detection
filter

275
Lab 16. Configure an alert for events logged in a specific order KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

25. On the Actions tab, open the

On every threshold subtab
and select Output and Loop
to correlator

26. Click the Create new button

below the correlation rule
settings

27. In the list of rules, make sure

the Lab folder contains the
[Lab] Connection to URL
earlier detected in mail rule

Task C: Add the rule to the correlator settings

To apply the rule, add it to the settings of the correlator service and update its configuration.

The task is performed on admin-laptop.

28. In the KUMA console, go to Resources | Active services

276
Lab 16. Configure an alert for events logged in a specific order KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

29. Click on the name of the

[OOTB] Correlator service

30. On the page that opens,

switch to the Correlation
section and click Link

31. Select the created correlation

rule and click Link

32. Make sure the [Lab]

Connection to URL earlier
detected in mail rule has
appeared on the list of
correlation rules

277
Lab 16. Configure an alert for events logged in a specific order KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

33. Switch to the Setup

validation section and click
Save and update service
configurations

34. Click Save to exit the

correlator settings

Task D: Test the rule

Send an email message with a dangerous link, wait for 10 seconds and then send an HTTP request
to the same URL. Make sure the correlation rule created in previous tasks generates an alert in the
KUMA web console. Review the alert and close it as responded to.

The task is performed on admin-laptop.

35. In the PowerShell window, run the following command (type it in a single line):

Send-MailMessage -From [email protected] -To [email protected] -Subject

"Check this" -Body "http://www.kaspersky.com/test/wmuf"
-SmtpServer 10.28.0.10

36. In 5 seconds, run the following command

curl http://www.kaspersky.com/test/wmuf

Note that the URL must be the same in both commands.


278
Lab 16. Configure an alert for events logged in a specific order KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

37. In the KUMA web console, open the Alerts section

38. Make sure a [Lab] Connection to URL earlier detected in mail alert has appeared on the list

The alert should appear after a few seconds. If it does not appear, try changing the email
subject arbitrarily and repeating the commands a couple of times with an interval of 5

seconds.

39. Open the alert’s properties

40. Pay attention to the list of related events; they are grouped by the RequestUrl field

41. Expand the group with RequestUrl http://www.kaspersky.com/test/wmuf

The correlation event includes both events that triggered the alert, which corresponds to

the correlation rule settings Base event keep policy: all.

42. Click the Close alert button, select the Responded reason, and click OK

279
Lab 16. Configure an alert for events logged in a specific order KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Conclusion

This lab demonstrates how to correlate events of different types.

280
Lab 17. Create a correlation rule using a local variable KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Lab 17. Create a correlation rule using a local variable

Scenario

You want to receive alerts if KATA URL reputation technology detects something on specific days of
the week. For example, we consider some situations to be normal on weekdays but suspicious if they
occur on weekends. To achieve this, we will need to perform additional actions on the data contained
in source events. KUMA provides variables and functions for this purpose.

Contents

Task A: Configure a simple correlation rule using a local variable

Task B: Add the rule to the correlator settings

Task C: Test the rule

Task A: Configure a simple correlation rule using a local variable

Change the correlation rule that will be triggered if the KATA URL reputation event is logged on the
day of the week when you do this lab.

The dc, kata-cn, ksc, kuma-core, kuma-storage-1, kuma-storage-2 and admin-laptop machines
must be powered on.

The task is performed on admin-laptop.

281
Lab 17. Create a correlation rule using a local variable KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

1. In the KUMA web console,

open the Resources |
Correlation rules section

2. In the tree on the left, select

the Lab folder

3. Select the [Lab] KATA IDS

detection rule

4. Click Duplicate

5. Specify the following

parameters:

a. Name: [Lab] KATA IDS

detection on weekdays

b. Propagated fields:
DeviceCustomString1,
DeviceCustomString2,
$weekday

Enter the value $weekday manually and click Add "$weekday". We will write the day on

which the event is logged into this variable.

6. Switch to the Selectors tab

7. Go to the Local variables tab

8. Click + Add

9. Set the following parameters to declare the weekday variable:

a. Variable: weekday

b. Value: extract_from_timestamp(DeviceReceiptTime, ‘wd’)

The extract_from_timestamp function allows you to get an atomic representation of time

(in the form of year, month, day of the week, etc.) from time fields. In this case, the

function will return the day of the week corresponding to the date specified in the
DeviceReceiptTime field of the normalized event.

282
Lab 17. Create a correlation rule using a local variable KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

10. Return to the Settings tab

11. Click </> Code to switch to code entry mode

12. Change the conditions as follows:

DeviceProduct='KATA'
AND DeviceEventClassID='ids'
AND $weekday=[
'current_day_of_the_week_in_English',
'Saturday',
'Sunday'
]

We are specifying today’s day of the week in order to demonstrate how the rule works and
the creation of an alert. In real life, specify days in accordance with the intended detection
logic, for example, Saturday and Sunday to receive alerts about events that occur only on

weekends. This lab is expected to run on a weekday, so we add the current day of the
week, e.g. Wednesday, to the selector conditions.

283
Lab 17. Create a correlation rule using a local variable KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

13. Switch to the Actions tab

14. In the Enrichment section,

click the + Add enrichment
button and fill in the
parameters:

a. Source kind: event

b. Source field: $weekday

c. Target field:
DeviceCustomString2

284
Lab 17. Create a correlation rule using a local variable KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

15. In the Enrichment area, click

the + Add enrichment
button again and fill in the
parameters:

a. Source kind: constant

b. Target field:
DeviceCustomString2La
bel

c. Constant: Weekday

16. Click Create new to save the

rule

Technically, this enrichment is not required for the rule to work. We’ve added it to simplify
the analyst’s work. The analyst will immediately see the day of the week the event
occurred on. There will be no need to check the calendar. The name of the day of the

week will be saved in the DeviceCustomString2 field. We use the
DeviceCustomString2Label field to specify a meaningful name for the analyst’s
convenience.

285
Lab 17. Create a correlation rule using a local variable KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Task B: Add the rule to the correlator settings

To apply the rule, add it to the settings of the correlator service and update its configuration.

The task is performed on admin-laptop.

17. In the KUMA web console, open the Resources | Active services section

18. Click on the name of the [OOTB] Correlator service

19. In the window that opens,

switch to the Correlation
section and click Link

20. Select the created correlation

rule and click Link

286
Lab 17. Create a correlation rule using a local variable KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

21. Make sure [Lab] KATA IDS

detection on weekdays has
appeared in the list of
correlation rules

22. Switch to the Setup

validation section and click
Save and update service
configurations

23. Click Save to exit the

correlator settings

Task C: Test the rule

Repeat the DNS query to the dangerous domain and make sure the created rule generates an alert.
Review its contents.

The task is performed on admin-laptop.

24. Open the PowerShell window and repeat the command

nslookup bandtester.com

287
Lab 17. Create a correlation rule using a local variable KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

25. In the KUMA web console, open the Alerts section

26. Make sure a [Lab] KATA IDS detection on weekdays alert has appeared on the list

The alert should appear in a few seconds.


27. Open the [Lab] KATA IDS detection on weekdays alert

28. Pay attention to the list of Related events

29. Click on an entry in the Related events area to open the properties of the corresponding
correlation event

30. Notice that the value of the local variable weekday is written in the DeviceCustomString2 field
of the correlation event

When the URL was accessed, KATA generated several events at once, so we have

several correlation events in the alert.

288
Lab 17. Create a correlation rule using a local variable KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

31. Close the correlation event and alert card

If other correlation rules have been triggered, close the corresponding alerts too.

Conclusion

The lab demonstrates how you can use variables and functions in KUMA correlation rules to
transform the initial data.

289
Lab 18. Create an operational correlation rule to fill an active list KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Lab 18. Create an operational correlation rule to fill an

active list
Scenario

You want to improve detection of cases when a user clicks a malicious link that has previously been
detected in an email message. In particular, you want the rule to be applied even if several hours have
passed (but no more than a day) between the message delivery and clicking the link. To do this, you
need to maintain a list of dangerous addresses found in email over the last 24 hours.

Contents

Task A: Prepare an active list for malicious addresses found in email

Task B: Create an operational correlation rule to fill the active list

Task C: Add the rule to the correlator settings

Task D: Test the rule

Task A: Prepare an active list for malicious addresses found in

email
Active lists pertain to resources. Create an active list that will contain URL addresses.

Later, we will create a rule that will fill this list with addresses from KATA url_mail events.

The dc, kata-cn, ksc, kuma-core, kuma-storage-1, kuma-storage-2 and admin-laptop machines
must be powered on.

The task is performed on admin-laptop.

290
Lab 18. Create an operational correlation rule to fill an active list KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

1. In the KUMA web console,

open the Resources | Active
lists section

2. Select the Main folder in the

tree on the left

3. Create a new subfolder

named Lab

4. Select the Lab folder

5. Click + Add to create an

active list

6. Specify the following

parameters:

a. Name: [Lab] Malicious

URLs detected in mail

b. Tenant: Main

c. TTL: 86400

This value in seconds corresponds to 24 hours.


7. Click Create new to save the list

Task B: Create an operational correlation rule to fill the active list

Create an operational correlation rule that will fill our active list with the values of RequestUrl attribute
from KATA url_mail events.

The task is performed on admin-laptop.

291
Lab 18. Create an operational correlation rule to fill an active list KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

8. In the KUMA web console,

open the Resources |
Correlation rules section

9. Select the Lab folder in the

tree on the left

10. Click + Add to create a new

rule

11. Specify the following

parameters:

a. Name: [Lab] [tech] KATA

url from mail

b. Kind: operational

12. Switch to the Selectors tab

to configure rule-triggering
conditions

13. In the Filter list, select the

preconfigured [Lab] KATA url
from mail detection filter

14. Switch to the Actions tab

15. Click + Add active list action and fill in the parameters:

a. Name: [Lab] Malicious URLs detected in mail

b. Operation: Set

c. Key fields: RequestUrl

d. Mapping: URL; RequestUrl

16. Click Create new to create and save the rule

292
Lab 18. Create an operational correlation rule to fill an active list KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

17. Make sure the new rule has appeared on the list

Task C: Add the rule to the correlator settings

To apply the rule, add it to the settings of the correlator service and update its configuration.

The task is performed on admin-laptop.

18. In the KUMA web console, open the Resources | Active services section

19. Click on the name of the [OOTB] Correlator service

20. On the page that opens,

switch to the Correlation
section and click Link

293
Lab 18. Create an operational correlation rule to fill an active list KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

21. Select the created [Lab]

[tech] KATA url from mail
correlation rule

22. Click Link

23. Make sure the rule has

appeared on the list of
correlation rules

24. Switch to the Setup

validation section and click
Save and update service
configurations

25. Click Save to exit the

correlator settings

Task D: Test the rule

Send another email, the same as in the previous task. Open the active list created in task B using the
three-dot menu of the correlator service and make sure the address from the email has been added to
the list.

294
Lab 18. Create an operational correlation rule to fill an active list KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

The task is performed on admin-laptop.

26. Open the PowerShell window and run the following command (type it in a single line):

Send-MailMessage -From [email protected] -To [email protected] -Subject

"Check this" -Body "http://www.kaspersky.com/test/wmuf"
-SmtpServer 10.28.0.10

27. In the KUMA web console, go to Resources | Active services

28. Select the checkbox next to the correlator service and click the Go to active lists button at the
top

29. Notice that the [Lab]

Malicious URLs detected in
mail list has 1 in the Records
column

30. Click the name of the [Lab]

Malicious URLs detected in
mail list

If the number of entries is 0, try sending the email again.


295
Lab 18. Create an operational correlation rule to fill an active list KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

31. Make sure the list contains a record with the Key field that begins with
http://www.kaspersky.com/test/wmuf

32. Click the record and make sure the URL field contains the test pseudo-dangerous address

Conclusion

This lab demonstrates how to create an active list and fill it with data from events. You can use this
data in other correlation rules, too.

In this lab, we used an operational rule to fill a list. Such a rule can only change contents of active
lists; it does not create correlation events or alerts.

Not only operational, but also simple and standard correlation rules can fill active lists. You can export
and import the contents of lists.

296
Lab 19. Create a correlation rule using an active list KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Lab 19. Create a correlation rule using an active list

Scenario

You want to receive alerts if a malicious link detected in traffic has previously been encountered in an
email. You have already created an active list for dangerous links detected in email. Now, create a
correlation rule that will be applied if a dangerous link detected in traffic is also present in the active
list.

Contents

Task A: Create a correlation rule that uses an active list

Task B: Reload the correlator settings

Task C: Test the rule

Task A: Create a correlation rule that uses an active list

Modify the correlation rule to be applied when a dangerous link from a KATA event has previously
been detected in email. Configure it to check if a dangerous link from a KATA url_web event is present
in the active list of dangerous addresses that have been detected in email. We created and filled this
list in the previous lab.

The dc, kata-cn, ksc, kuma-core, kuma-storage-1, kuma-storage-2 and admin-laptop machines
must be powered on.

The task is performed on admin-laptop.

297
Lab 19. Create a correlation rule using an active list KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

1. In the KUMA web console,

open the Resources |
Correlation rules section

2. In the tree on the left, select

the Lab folder

3. Click + Add

4. Specify the following

parameters:

a. Name: [Lab] Connection

to url earlier detected in
mail (active list)

b. Kind: simple

c. Propagated fields:
RequestUrl,
SourceAddress

d. Severity: Critical

5. Switch to the Selectors tab

6. Select the Save filter

checkbox

7. Specify the name of the new

filter [Lab] url_web matches
url_mail from active list

8. Set the filter conditions as

shown in the screenshot

298
Lab 19. Create a correlation rule using an active list KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform


KATA and url_web are constants, and [Lab] Malicious URLs detected in mail is an active
list.

9. Examine the conditions in code entry mode

The active list ID will be different in your code.


10. Open the Actions tab of the
correlation rule

11. Select Output and Loop to

correlator

12. Click the Create new button

below the correlation rule
settings

Task B: Add the rule to the correlator

Delete the old rule and add a new one

The task is performed on admin-laptop.

299
Lab 19. Create a correlation rule using an active list KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

13. In the KUMA web console, open the Resources | Active services section

14. Click on the name of the [OOTB] Correlator service

15. In the window that opens,

switch to the Correlation
section

16. Select the [Lab] Connection

to url earlier detected in mail
rule

17. Click Delete

18. Click Link

19. Select the new [Lab]

Connection to URL earlier
detected in mail (active list)
rule

20. Click Link

21. Make sure the new rule has

appeared on the list

22. Switch to the Setup

validation section and click
Save and update service
configurations

300
Lab 19. Create a correlation rule using an active list KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Task C: Test the rule

Access the test pseudo-malicious address http://www.kaspersky.com/test/wmuf/ and make sure the
KUMA console displays the corresponding alert.

The task is performed on admin-laptop.

23. Open the PowerShell window and run the following command (type it in a single line):

curl http://www.kaspersky.com/test/wmuf

24. Open the KUMA web console and switch to the Alerts section

25. Make sure a [Lab] Connection to URL earlier detected in mail (active list) alert has appeared on
the list

26. Select the alert and click the Close alert button below the list

27. Select the Responded reason and click OK

Conclusion

This lab demonstrates how to use active lists when you create conditions for a correlation rule.

301
Lab 20. Run retrospective scanning KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Lab 20. Run retrospective scanning

Scenario

You want to detect situations when an RCE attack is performed sequentially on networked devices,
followed by PowerShell being launched on the attacked device. Also, you want to find out if this has
happened in the past. Do this using retrospective scanning.

Contents

Task A: Simulate an incident

Task B: Create a standard correlation rule

Task C: Add the rule to the correlator settings

Task D: Perform retrospective scanning

Task A: Simulate an incident

Add events that emulate a successful attack on the admin-laptop.abc.lab device to the KUMA storage.

The dc, kata-cn, ksc, kuma-core, kuma-storage-1, kuma-storage-2 and admin-laptop machines
must be powered on.

The task is performed on admin-laptop.

1. Open the window with the SSH session to the kuma-core.abc.lab server.

If you closed the previous session, start PuTTY, connect to the kuma-core.abc.lab server,

and log in as admin with the password Ka5per$Ky.

302
Lab 20. Run retrospective scanning KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

2. Go to the ~/events directory, if necessary:

cd ~/events

3. Run the command to send the prepared event from the event15 file. Note that the --limit 1
parameter must be specified in the command:

sudo /opt/kaspersky/kuma/kuma tools load --raw --events event15

--cfg cef.cfg --replay 1 --limit 1

Enter the password Ka5per$Ky to elevate privileges.


4. Send the next event, this time from the event16 file. Note that the --limit 1 key must also be
specified in the command:

sudo /opt/kaspersky/kuma/kuma tools load --raw --events event16

--cfg cef.cfg --replay 1 --limit 1

5. Return to the KUMA web console

6. Find the events that have arrived at the [OOTB] CEF WMI collector

Open Resources | Active services, select the checkbox in the row with the [OOTB] CEF

WMI collector service and click Go to events.

303
Lab 20. Run retrospective scanning KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

7. Find and open events with the netflow and Windows 10 values in the DeviceProduct field

8. Review their contents

304
Lab 20. Run retrospective scanning KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

9. Notice that the name and IP

address of the attacked host
are written into different fields
of these normalized events
(as a destination in one case
and as a source in the other)

Task B: Create a standard correlation rule

Create a correlation rule that will be triggered when an event about an exploited RCE vulnerability is
followed by an event about the powershell.exe process being started on the attacked device.

Since the name and IP address of the attacked host are written into different fields after normalization
(the host is first reported as a destination and then as a source), we cannot correlate such events
using identical fields. You will need to write values from the initial event fields into the local variable
$host in each selector, and then group events by the values written to the local $host variable.

305
Lab 20. Run retrospective scanning KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

The task is performed on admin-laptop.

10. In the KUMA web console,

open the Resources |
Correlation rules section

11. In the tree on the left, select

the Lab folder

12. Click + Add to create a new

rule

13. Specify the following

parameters:

a. Name: [Lab] RCE +

powershell run

b. Tenant: Main

c. Kind: standard

14. Set additional options for

standard rules:

a. Identical fields: $host

(type $host manually)

b. Window, sec: 10

c. Base event keep policy:

first

d. Severity: Critical

We will write the address of the attacked device from the events informing about the RCE

attack and powershell.exe launch into the $host variable.

306
Lab 20. Run retrospective scanning KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

15. Switch to the Selectors tab

to configure rule-triggering
conditions

16. Configure the first selector:

a. Alias: RCE

b. Selector threshold (event

count): 1

c. Switch to code entry

mode and set the
following condition:

Message='RCE
Vulnerability
Execution'

17. In the Selector ‘RCE’

section, switch to the Local
variables tab

18. Click + Add

19. Specify the following

parameters to declare the
$host variable for the RCE
selector:

a. Variable: host

b. Value:
DestinationHostName

For the RCE attack event, write the value from the DestinationHostName field into the

$host variable.

307
Lab 20. Run retrospective scanning KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

20. Click Add selector at the

bottom of the first selector
area to add a selector for
another event type

21. Configure the second

selector:

a. Alias: Powershell launch

b. Selector threshold (event

count): 1

c. Switch to code entry

mode and set the
following condition:

Message='Powers
hell launch'

22. In the Selector ‘Powershell

launch’ section, switch to the
Local variables tab

23. Click + Add

24. Specify the following

parameters to declare the
host variable for the
Powershell launch selector:

a. Variable: host

b. Value: SourceHostName

308
Lab 20. Run retrospective scanning KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform


For the powershell.exe launch event, write the value from the SourceHostName field into
the $host variable.

25. Switch to the Actions tab

26. Open the On every

threshold subtab

27. Select Output and Loop to

correlator

28. In the Enrichment section,

click the + Add enrichment
button and fill in the
parameters:

a. Source kind: event

b. Source field: $host

c. Target field:
DeviceHostName

29. Click the Create new button

below the correlation rule
settings

30. Make sure the Lab folder

contains the [Lab] RCE +
Powershell run rule

We’ve further enriched the correlation event with the value of the $host variable. If the rule
is triggered, the value of the $host variable will be written into the DeviceHostName field

of the correlation event.

Task C: Add the rule to the correlator settings

Add the created rule to the correlator’s settings and reload its service.

The task is performed on admin-laptop.

309
Lab 20. Run retrospective scanning KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

31. In the KUMA console, go to

Resources | Active
services

32. Click on the name of the

[OOTB] Correlator service

33. On the page that opens,

switch to the Correlation
section and click Link

34. Select the created [Lab] RCE

+ Powershell run correlation
rule

35. Click Link

36. Make sure the rule has

appeared on the list of
correlation rules

310
Lab 20. Run retrospective scanning KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

37. Switch to the Setup

validation section and click
Save and update service
configurations

38. Click Save to exit the

correlator settings

Task D: Perform retrospective scanning

Use the created rule in retrospective scanning.

The task is performed on admin-laptop.

39. In the KUMA web console, open the Events section

40. Change the event search period to 1 hour

41. Open the three-dot menu (…) in the upper-right corner and select Retroscan

Retrospective scanning takes into account the specified storage, time period and search

criteria.

311
Lab 20. Run retrospective scanning KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

42. In the Correlator field, select

the [OOTB] Correlator
service

43. Under Correlation rules,

select the rule created in this
lab: [Lab] RCE + Powershell
run

44. Select the Create alerts

checkbox

45. Click Create new

You can select from among the rules that are specified in the correlator settings.

46. Switch to the Task Manager
section

47. Wait for the Retroscan task

to become Completed

48. Click the task name and

select Go to events

49. A new tab with events will open. Make sure the search results contain detected events

50. Open an event

51. Pay attention to the event type Correlated and the name of the correlation rule

52. Notice that the correlation event was enriched with the value of the $host variable, which was
written into the DeviceHostName field of the correlation event

53. To open the corresponding alert, click Detailed view

312
Lab 20. Run retrospective scanning KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

The correlator outputs correlated events. The KUMA core service then creates alerts from

them.

54. A new tab will open with the Alerts section selected and the alert open. Study the information in
the Related events and Related endpoints sections

55. Make sure correlation was applied to the historical events that were generated during the first
task

Conclusion

313
Lab 20. Run retrospective scanning KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

This lab demonstrates how to use retrospective scanning.

314
Lab 21. Configure a response by running a Kaspersky Security KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Center task

Lab 21. Configure a response by running a Kaspersky

Security Center task
Scenario

You want to scan critical areas on computers related to alerts.

Contents

Task A: Prepare a critical areas scan task in Kaspersky Security Center

Task B: Run the task via the computer properties in the KUMA web console

Task C: Configure an automated response to an alert

Task D: Add supplementary fields to the correlation rule

Task E: Reload the correlator settings

Task F: Make sure the automated response works

Task A: Prepare a critical areas scan task in Kaspersky Security

Center
Create a malware scan task for Kaspersky Endpoint Security in Kaspersky Security Center. Make it a
task for a set of computers, select memory and startup objects for the scope and name it KUMA
response – critical areas scan. It is important that the task name starts with KUMA.

The dc, kata-cn, ksc, kuma-core, kuma-storage-1, kuma-storage-2 and admin-laptop machines
must be powered on.

The task is performed on admin-laptop.

315
Lab 21. Configure a response by running a Kaspersky Security KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Center task

1. In a new web browser

window, open the Kaspersky
Security Center web console
at https://ksc.abc.lab:8080

2. Log in to the system as

Administrator with the
password Ka5per$Ky

3. Go to Devices | Tasks

4. Click the + Add button to create a task

316
Lab 21. Configure a response by running a Kaspersky Security KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Center task

5. On the New task page of the

task creation wizard, specify
the following parameters:

a. Application: Kaspersky
Endpoint Security for
Windows

b. Task type: Malware Scan

c. Task name: KUMA

response - scan critical
areas

6. Under Select devices to

which the task will be
assigned, select Specify
device addresses manually
or import addresses from a
list

7. Click Next

It is important that the task name starts with KUMA.


317
Lab 21. Configure a response by running a Kaspersky Security KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Center task

8. Click the Add devices button

above the empty list of target
devices

9. In the Add devices pane, in

the drop-down menu, choose
Select networked devices
detected by Administration
Server

10. Select the Managed devices

group and click Add at the
bottom

11. Make sure managed devices

have appeared in the list and
click Next

318
Lab 21. Configure a response by running a Kaspersky Security KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Center task

12. Leave the default account

and click Next

13. Select Open task details

when creation is complete
and click Finish

14. In the task properties, switch to the Application settings tab

15. In the Scan scope list, leave the Kernel memory, Running processes and startup objects
and Disk boot sectors options enabled

16. Click Save

319
Lab 21. Configure a response by running a Kaspersky Security KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Center task

Task B: Run the task via the computer properties in the KUMA
web console
In the Assets section, find the admin-laptop computer and run the created Kaspersky Security
Center task there.

The task is performed on admin-laptop.

320
Lab 21. Configure a response by running a Kaspersky Security KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Center task

17. In the KUMA web console,

open the Assets section

18. Expand the Main | Business

impact node and select the
High business impact
category

19. Click the ADMIN-LAPTOP

computer

20. Expand the Start task drop-

down list

21. Click KSC response

321
Lab 21. Configure a response by running a Kaspersky Security KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Center task

22. Select the KUMA response –

scan critical areas task and
click Start

23. Click the Kaspersky Endpoint Security icon in the notification area to open the local interface of
Kaspersky Endpoint Security for Windows

24. In the main window of Kaspersky Endpoint Security, click the Reports tile

25. In the Reports window, scroll to the bottom of the left pane and select Scan

26. Make sure the scan task has started on the computer

27. In the local interface, the running task is displayed as Custom scan

322
Lab 21. Configure a response by running a Kaspersky Security KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Center task

Task C: Configure an automated response to an alert

Response to an alert is also a resource. Create a response resource for running a Kaspersky Security
Center task and specify it in the settings of the correlator service.

The task is performed on admin-laptop.

28. In the KUMA web console,

open the Resources |
Response rules section

29. Click + Add

323
Lab 21. Configure a response by running a Kaspersky Security KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Center task

30. Configure a response:

a. Name: [Lab] [KES] Scan

critical areas

b. Tenant: Main

c. Kind: Response via KSC

d. KSC task: KUMA

response – scan critical
areas

e. Event Field:
SourceAssetID

This field contains the identifier of the computer where the task will run. To run it on the

DestinationAccessID computer too, you need to create another response rule.

31. In the Filter parameters

area, select the Save filter
checkbox

32. For the filter name, type [Lab]

Critical priority events

33. Switch to code entry mode

and set the following
condition

Priority=4

34. Click Create new

324
Lab 21. Configure a response by running a Kaspersky Security KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Center task

Here priority is a ratio calculated using the following formula: priority = (correlation rule
priority + maximum weight of affected hosts) / 2. If none of the affected hosts is registered

in KUMA as an asset, then the priority will be equal to the rule priority. None – 0; Low – 1;
Normal – 2; High – 3; Critical – 4.

35. Go to Resources | Active

services

36. Click [OOTB] Correlator

37. Switch to the Response

section

38. Click + Add response rule

39. Select the [Lab] [KES] Scan

critical areas response rule

325
Lab 21. Configure a response by running a Kaspersky Security KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Center task

40. Switch to the Setup

validation section and click
Save and update service
configurations

41. Click Save to exit the

correlator settings

Task D: Add supplementary fields to the correlation rule

We have set up an automated response that will react to high-priority correlation events and will be
carried out on computers specified in the SourceAssetID field. For the correlator to be able to check
the automated response conditions and run the task, it needs data of these fields in the correlation
event. In this task, you will add them to the [Lab] Connection to URL earlier detected in mail rule.

The task is performed on admin-laptop.

42. Go to Resources |
Correlation rules

43. Open the [Lab] Connection to

URL earlier detected in mail
(active list) rule

326
Lab 21. Configure a response by running a Kaspersky Security KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Center task

44. In the Propagated fields

box, add the SourceAssetID
and Priority fields

45. Click Save

Task E: Update the correlator settings

Update the correlator service settings to apply the changes. We haven’t created new rules, so you
don’t need to change the correlator settings.

The task is performed on admin-laptop.

46. In the KUMA web console, open the Resources | Active services section

47. Select the checkbox for the [OOTB] Correlator service and click the Update configuration
button above the list

327
Lab 21. Configure a response by running a Kaspersky Security KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Center task

48. In the window for confirming

the service configuration
update, click OK

Task F: Make sure the automated response works

Generate another [Lab] Connection to URL earlier detected in mail (active list) alert and make sure
the automated response works.

The task is performed on admin-laptop.

49. Open the PowerShell window and run the following command

curl http://www.kaspersky.com/test/wmuf/

50. Open the Alerts section in the KUMA web console and make sure a new [Lab] Connection to
URL earlier detected in mail alert with Critical priority has appeared

51. Open Kaspersky Endpoint Security reports and switch to the Scan section

52. Make sure the on-demand scan task has started again

328
Lab 21. Configure a response by running a Kaspersky Security KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Center task

Conclusion

This lab demonstrates how to run Kaspersky Endpoint Security tasks configured in Kaspersky
Security Center from the KUMA console. It also shows how to set up an automated response,
including starting Kaspersky Security Center tasks, when a correlation event occurs.

329
Lab 22. Configure a response by running a Kaspersky Endpoint KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Detection and Response task

Lab 22. Configure a response by running a Kaspersky

Endpoint Detection and Response task
Scenario

You want to run Kaspersky Endpoint Detection and Response tasks on affected devices in case of a
dangerous situation. To do this, you need to configure integration with KATA EDR. It will then be
possible to respond to detected incidents by running Kaspersky Endpoint Agent tasks from KUMA.

Contents

Task A: Create a secret resource for integration with KATA

Task B: Configure integration between KUMA and KATA EDR

Task C: Run the task via the computer properties in the KUMA web console

Task A: Create a secret resource for integration with KATA

Create a new kata/edr secret resource for connections to kata-cn.abc.lab.

The dc, kata-cn, ksc, kuma-core, kuma-storage-1, kuma-storage-2 and admin-laptop machines
must be powered on.

The task is performed on admin-laptop.

1. In the KUMA web console,

open the Resources |
Secrets section

2. Select the Main | Lab folder

in the left pane

3. Click + Add

330
Lab 22. Configure a response by running a Kaspersky Endpoint KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Detection and Response task

4. Specify the following

parameters for the secret
resource:

a. Name: [Lab] cert for

kata-cn.abc.lab

b. Tenant: Main

c. Kind: kata/edr

5. Click Generate and

download a certificate… to
protect the connection
between KUMA and KATA
EDR servers

6. The certificate.zip archive

will download. Unpack it.
There should be two files
inside

7. In the KUMA web console,

click Upload certificate file

8. Select the cert.pem file in the

directory where the
certificate.zip file was
unpacked

9. Click Upload private key

10. Select the key.pem file in the

directory where the
certificate.zip file was
unpacked

11. Click Create new to create

and save the resource

331
Lab 22. Configure a response by running a Kaspersky Endpoint KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Detection and Response task

12. Make sure a new secret has

appeared on the list: [Lab]
cert for kata-cn.abc.lab

Task B: Configure integration between KUMA and KATA EDR

Configure integration between KUMA and KATA EDR. This will allow you to create and run KATA EDR
response tasks from the KUMA interface.

The task is performed on admin-laptop.

13. In the KUMA web console, open the Settings section

14. Go to the Kaspersky Endpoint Detection and Response subsection

332
Lab 22. Configure a response by running a Kaspersky Endpoint KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Detection and Response task

15. Clear the Distributed

solution checkbox

16. Set the KATA EDR

connection parameters:

a. Host: kata-cn.abc.lab

b. Port: 443

c. Secret: [Lab] cert for

kata-cn.abc.lab

17. Click Save

18. Make sure the Settings

saved pop-up window
appears

19. In a new web browser window, open the Kaspersky Anti Targeted Attack Central Node web
console at https://kata-cn.abc.lab:8443

If a browser warning about an insecure connection appears, select Advanced and then

Proceed to kata-cn.abc.lab (unsafe).

20. On the login page, select the

Local administrator
checkbox

21. Log in to the system as

Administrator with the
password Ka5per$Ky

333
Lab 22. Configure a response by running a Kaspersky Endpoint KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Detection and Response task

22. Open the External systems section

23. In the Server list, find the entry that corresponds to the new KUMA system with the Pending
status. Click Accept

24. The status of the new connection should change to Authorized

Task C: Run a task via the computer properties in the KUMA web
console
Use the KEDR functionality to respond to the [Lab] RCE + Powershell run alert that was generated in
one of the previous labs.

The task is performed on admin-laptop.

25. In the KUMA web console, open the Alerts section

26. In the list of alerts, find [Lab] RCE + Powershell run and open it

27. Pay attention to the list of Related endpoints

334
Lab 22. Configure a response by running a Kaspersky Endpoint KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Detection and Response task

28. Click the admin-laptop.abc.lab computer

29. In the Start task drop-down list, select KEDR response

335
Lab 22. Configure a response by running a Kaspersky Endpoint KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Detection and Response task

30. In the Task type drop-down

list, select Enable network
isolation

31. Set the Isolation timeout to

1

32. Click + Add exclusion to

specify exclusions

33. Configure the following

parameters for
Exclusion #1:

a. Traffic direction:
Outbound

b. Asset IP: 10.28.0.61

c. Remote ports: 7210 —

7220

34. Click + Add exclusion to

create one more exclusion

35. Configure the following

parameters for
Exclusion #2:

a. Traffic direction:
Outbound

b. Asset IP: 10.28.0.61

c. Remote ports: 5140 —

5140

336
Lab 22. Configure a response by running a Kaspersky Endpoint KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Detection and Response task

36. Click + Add exclusion to

create one more exclusion

37. Configure the following

parameters for
Exclusion #3:

a. Traffic direction: Inbound

b. Asset IP: 10.28.0.254

c. Remote ports: 3389

38. Click Start to run the task

39. Make sure the Task started

pop-up window appears,
which informs you that the
task has been launched
successfully

40. Wait for a notification from

Kaspersky Endpoint Agent
that access to the network is
restricted

41. Close the Kaspersky Endpoint Agent notification window and return to the KUMA web console

The web console remains accessible thanks to the exceptions specified in the network

isolation task settings.

42. Close the card for admin-laptop.abc.lab

43. Click on the arrow in the Related events section to expand the list of base events related to the
correlation event

337
Lab 22. Configure a response by running a Kaspersky Endpoint KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Detection and Response task

338
Lab 22. Configure a response by running a Kaspersky Endpoint KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Detection and Response task

44. Click on the Powershell

launch event to open its card

45. Notice that the

powershell.exe start
parameters are specified in
the FilePath field of the base
event

46. Copy the path and name of

the suspicious script passed
in the command line after the
-Command parameter

47. Start Notepad and paste the data from the clipboard there

339
Lab 22. Configure a response by running a Kaspersky Endpoint KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Detection and Response task

To find Notepad, open the Start menu and type "notepad".


48. Remove line breaks so that the path is a single line without spaces

49. Copy the path to clipboard

50. Return to the KUMA web console and close the event card

51. In the Related endpoints section, click admin-laptop.abc.lab again

52. In the Start task drop-down list, select KEDR response

53. In the Task type drop-down list, select Run program

54. Configure the task settings:

a. File path: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

b. Command line parameters: Get-FileHash <the full path along with the script name from
the alert>

55. Click Start to run the task

340
Lab 22. Configure a response by running a Kaspersky Endpoint KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Detection and Response task

This lets us remotely calculate the hash sum of the script that was run during the incident.

56. In the KUMA web console, open the Task manager section

57. Make sure the Run program via KEDR task created by the Administrator has appeared in the list
of tasks

58. Wait for the Run program via KEDR task to become Completed

59. Click the task name and select Show results

60. In the task results card, click on the icon to the right of the Standard stream output field to
download a file with the output of the Get-FileHash command

341
Lab 22. Configure a response by running a Kaspersky Endpoint KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Detection and Response task

61. Copy the calculated hash of the malicious script from the downloaded output.txt file to the
clipboard

62. In the KUMA web console, open the Assets section

63. Expand the Main | Business impact node and select the High business impact category

64. Click the ADMIN-LAPTOP computer

342
Lab 22. Configure a response by running a Kaspersky Endpoint KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Detection and Response task

65. In the Start task drop-down list, select KEDR response

66. In the Task type drop-down list, select Add prevention rule

67. Configure the task settings:

a. Asset: All assets

b. File hash #1: <paste the script hash from the clipboard>

68. Click Start to run the task

343
Lab 22. Configure a response by running a Kaspersky Endpoint KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Detection and Response task

69. Make sure the Task started

pop-up window appears,
which informs you that the
task has been launched
successfully

70. Wait for 2 minutes

71. Right-click the Start menu

and select Sign out

72. Log in to the system as

abc\Administrator with the
password Ka5per$Ky again

344
Lab 22. Configure a response by running a Kaspersky Endpoint KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Detection and Response task

73. After logging in to the

system, wait for a Kaspersky
Endpoint Agent notification
that a malicious script has
been blocked on the
computer (10-15 seconds)

74. Start Google Chrome and go to https://kuma-core.abc.lab:7220

If a browser warning about an insecure connection appears, select Advanced and then

Proceed to kuma-core.abc.lab (unsafe)

If the page does not open, try using the IP address https://10.28.0.61:7220 instead of the

FQDN.

75. Log in as admin with the

password Ka5per$Ky

76. In the KUMA web console, open the Assets section

77. Expand the Main | Business impact node and select the High business impact category

78. Click the ADMIN-LAPTOP computer

345
Lab 22. Configure a response by running a Kaspersky Endpoint KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Detection and Response task

79. In the Start task drop-down list, select KEDR response

80. In the Task type drop-down

list, select Disable network
isolation

81. Click Start to run the task

346
Lab 22. Configure a response by running a Kaspersky Endpoint KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform
Detection and Response task

82. Make sure the Task started

pop-up window appears,
which informs you that the
task has been launched
successfully

83. Wait for a minute and make

sure network access has
been fully restored on the
device: open an external
website in the browser, for
example
https://www.kaspersky.com

Conclusion

The lab demonstrates how to run Kaspersky Endpoint Detection and Response tasks from the KUMA
console to respond to detected information security incidents.

347
Lab 23. Study reports KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Lab 23. Study reports

Scenario

You want to organize the Dashboard to monitor the general security situation of the network. In
addition to the data that illustrates operation of Kaspersky Unified Monitoring and Analysis, you want
to know who opens the management interface of Kaspersky Unified Monitoring and Analysis and from
which computers. Create a new dashboard layout and configure a widget to display the web console
connection statistics.

You also want to regularly receive a report with information about triggered correlation rules by email.
Do this using a standard report template for an overview of security events.

Contents

Task A: Study and modify the preconfigured dashboard layouts

Task B: Create a new layout with a widget about audit events

Task C: Create a report based on an existing template

Task A: Study and modify the preconfigured dashboard layouts

Set the layout with security events as default. Set the dashboard refresh period to 1 minute.

The dc, kata-cn, ksc, kuma-core, kuma-storage-1, kuma-storage-2 and admin-laptop machines
must be powered on.

The task is performed on admin-laptop.

1. In the KUMA web console, open the Dashboard section

By default, no layout has priority, and the layout whose name comes first alphabetically is

displayed.

348
Lab 23. Study reports KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

2. Study the information displayed on the dashboard

Almost everything is configurable: widgets’ size and position, chart types, displayed

information, time span and the refresh rate.

3. Expand the list of layouts in the upper-right corner

4. Hover over Alerts Overview and click on the pencil icon

5. Set the refresh interval to 1 minute

6. Click Save to save the layout

Task B: Create a new layout with a widget about audit events

Create a new layout for audit events. Add a widget with information about the IP addresses that
connected to the KUMA web console.

The task is performed on admin-laptop.

349
Lab 23. Study reports KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

7. In the Dashboard section, expand the list of layouts in the upper right corner and select + Create
layout

8. Specify the following parameters:

a. Tenants: Main

b. Time period: 7 days

c. Refresh every: 1 minute

d. Layout name: Audit overview

9. Click Add widget and select Events

350
Lab 23. Study reports KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

10. Specify the following widget parameters:

a. Graph: Bar chart

b. Tenant: Main

c. Time period: As layout

d. Storage: [OOTB] Storage

11. Click on the button to the left of the query text to open the query builder

351
Lab 23. Study reports KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

12. In the Select area, expand the first list on the second row and choose SourceAddress

13. In the Group By area, clear the default Name choice and select SourceAddress instead

14. In the Where area, click the Add condition button

15. Fill in the first condition

a. Left operand: Type

b. Operation: =

c. Right operand: Audit

This condition selects audit events.


352
Lab 23. Study reports KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

16. Click Add condition again

17. Fill in the second condition: ..

a. Left operand: DeviceAction

b. Operation: =

c. Right operand: user login

This condition will filter out audit events unrelated to user activity, such as service status

changes.

18. Click Apply

19. Open the section with the wrench icon to complete setting up the widget

20. Rename the widget Source IP addresses connected to the web interface

21. Turn the Horizontal switch On

22. Click Preview to have a look at the result

Notice that all connections to the console have been established from the same IP

address so far.

353
Lab 23. Study reports KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

23. Click Add to save the widget on the layout

24. Resize the widget to the full width of the console

To do this, hover the mouse over the bottom right corner of the widget until the pointer
turns into a diagonal arrow; press the left mouse button and hold it while stretching the

widget to the desired size.

25. Click the Save button in the lower-left corner to save the layout

354
Lab 23. Study reports KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Switch to the ksc machine.

26. Log in to the ksc machine as abc\administrator with the password Ka5per$Ky

27. Run the Google Chrome browser and go to the KUMA web console at https://kuma-
core.abc.lab:7220/

If a browser warning about an insecure connection appears, select Advanced and then

Proceed to kuma-core.abc.lab (unsafe).

28. Log in to the system under the admin account with the password Ka5per$Ky

29. In the Dashboard section, select the Audit Overview layout

30. Make sure the widget shows two connection addresses now

355
Lab 23. Study reports KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Task C: Create a report based on an existing template

Сopy the Alerts Overview report template and name the copy Daily Alerts Overview. Modify the
settings of the new template as follows: set the report period to 1 day and select to store generated
reports for 1 month. Configure the report to be created daily at midnight and emailed to the
administrator; also, replace the logo in the template with a custom one. Generate the report manually
and check the result.

The task is performed on admin-laptop.

31. In the KUMA web console, go to Settings | Common

32. Scroll down to the SMTP server settings area

356
Lab 23. Study reports KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

33. Specify the following parameters:

a. Host: 10.28.0.10

b. Port: 25

c. From: [email protected]

34. Click Save

35. In the KUMA web console, open the Reports section and switch to the Templates tab

36. Examine the default templates

Although the templates have the same names as the layouts on the Dashboard, they are

separate entities.

357
Lab 23. Study reports KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

37. Click the name of the Alerts

Overview template and
select Duplicate report
template

The page for editing a new template will open.


38. Notice that report templates consist of the same widgets as layouts on the Dashboard

39. Configure the general template settings at the top of the page:

a. Tenants: Main

b. Time period: Custom → 3 days

c. Retention: Keep for 1 month(s)

d. Template name: Daily Alerts Overview

358
Lab 23. Study reports KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

40. Click on the Delete button below the logo in the report header

41. Click Upload logo to replace the logo in the report header with a custom one

42. Click Upload and select the *.png logo file

The path of the logo file is


C:\users\administrator\Desktop\KUMA\green_Kaspersky.TechEdu.png.

43. Click Save to save the logo

44. Make sure the Kaspersky.TechEdu logo is displayed correctly in the report template

45. Click Save to save the new template

359
Lab 23. Study reports KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

46. Click the name of the Daily Alerts Overview template and select Edit schedule

47. Configure automatic

generation of the report:

a. Schedule: On

b. Recur every: 1 day

c. Time: 00:00

48. In the Send to area, click

Add, then click + Add group
and enter [email protected]

49. Click Save

50. Click Save again to apply the schedule

51. Click the name of the Daily Alerts Overview template and select Run report

360
Lab 23. Study reports KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

A browser tab with the Generated Reports page of the web console will open

automatically.

52. Notice that a Daily Alerts Overview report has appeared at the top of the list.

If it does not appear, refresh the page


53. Click the generated Daily Alerts Overview report and select Open report

A new browser tab with the report will open.


54. Notice that the Daily Alerts Overview report template is generally the same as the Alerts
Overview layout on the Dashboard

361
Lab 23. Study reports KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Conclusion

This lab demonstrates how to use the dashboard and reports in the KUMA web console. In particular,
it shows how to create new dashboard layouts and report templates, how to add new widgets based
on event search and how to set up scheduled reporting.

362
Lab 24. Send a request to KUMA via the REST API (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Lab 24. Send a request to KUMA via the REST API

(optional)
Scenario

You want to test sending requests to KUMA via the REST API for further integration with external
systems. To do this, you need to create a token in KUMA, and then use this token to send requests.

Contents

Task A: Create a token for sending requests to KUMA via the REST API

Task B: Find and close KUMA alerts via the REST API

Task A: Create a token for sending requests to KUMA via the

REST API
Create a token for the Administrator to access KUMA via the REST API.

The dc, kata-cn, ksc, kuma-core, kuma-storage-1, kuma-storage-2 and admin-laptop machines
must be powered on.

The task is performed on admin-laptop.

363
Lab 24. Send a request to KUMA via the REST API (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

1. In the KUMA web console,

click the Administrator
username in the lower left
corner and select Profile

364
Lab 24. Send a request to KUMA via the REST API (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

2. In the Using KUMA via API

area, click Generate token

3. Select the No expiration

date checkbox

4. Click Generate token

365
Lab 24. Send a request to KUMA via the REST API (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

5. Copy the token specified in

the Token field to the
clipboard and save it in
Notepad. You will need it in
the next task

A token is a secret and should not be stored and transmitted in plaintext. We save it in

Notebook only for convenience during lab work.

366
Lab 24. Send a request to KUMA via the REST API (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

6. Click the API access rights

button to specify permissions
for the created token. Clear
all checkboxes except:

a. GET /alerts

b. POST /alerts/close

7. Click Save in the API access

rights window

8. Click Save in the User window

9. Open the Administrator account settings again

10. Notice that the token is no longer visible even to the user who created it

Task B: Task B: Find and close KUMA alerts via the REST API
Get acquainted with the syntax of KUMA REST API requests, send a GET request via Postman to
retrieve the list of active alerts, and then close one of them using a POST request.

The task is performed on admin-laptop.

367
Lab 24. Send a request to KUMA via the REST API (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

11. Launch Postman

For example, right-click the Start menu, begin typing Postman in the search bar, and

under the Postman app, select Run as administrator.

12. Click the + to create a new tab with a query

13. Make sure the GET method is selected in the query field

14. In the query field, enter the following URL: https://kuma-core.abc.lab:7223/api/v1/alerts/

15. Under the query string, on the Params tab, fill in the first row of the Query Params table:

a. In the key column, specify status

b. In the Value column, specify new

368
Lab 24. Send a request to KUMA via the REST API (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

16. Switch to the Auth tab below the query field

17. In the Type drop-down list, select Bearer Token

18. Paste the token generated in the last task into the Token field

19. Click Send

If a warning about an untrusted certificate appears, click Disable SSL Verification and

click Send again.

369
Lab 24. Send a request to KUMA via the REST API (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

20. Make sure the request has

been sent successfully and
the server returns 200 OK

21. Review the data from the API

response

22. Scroll down the response to

the [Lab] RCE + Powershell
run alert

23. Copy the value specified in

the id field of this alert
without quotes

370
Lab 24. Send a request to KUMA via the REST API (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

24. Change the method in the query string from GET to POST

25. Change the URL in the query string to https://kuma-core.abc.lab:7223/api/v1/alerts/close

26. Under the query string, switch to the Body tab

27. Select the raw option

28. In the text box, enter

{
“id” : “<insert the id in quotes>”,
“reason” : “responded”
}

29. Click Send

30. Make sure the request has

been sent successfully and
the server returned 204 No
content

31. Return to the KUMA web console

32. Go to Alerts

33. Make sure the [Lab] RCE + Powershell run alert is not in the list

371
Lab 24. Send a request to KUMA via the REST API (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

34. Click on the name of the Status column and select Closed in the filter to display closed alerts as
well

35. Make sure the [Lab] RCE + Powershell run alert has the Closed, responded status after the
request is executed

Conclusion

The lab demonstrates how to get data about KUMA alerts via the REST API and close them.

372
Lab 25. Configure the Event router service (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Lab 25. Configure the Event router service (optional)

Scenario

Suppose one of the collectors is behind a thin channel and you want to optimize the data flow
between the collector and its destinations (correlator and storage). You need to configure and install
the Event router service and reconfigure the destinations.

Contents

Task A: Create a configuration for the Event router service

Task B: Install the Event router service

Task C: Configure event streams to pass through the Event router service

Task D: Make sure events arrive

Task A: Create a configuration for the Event router service

Create an Event router resource and service.

The dc, ksc, kuma-core, kuma-storage-1, kuma-storage-2 and admin-laptop machines must be
powered on.

The task is performed on admin-laptop.

1. In the KUMA web console, go to Resources | Event routers

2. Click + Add

373
Lab 25. Configure the Event router service (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

3. In the Event router name

field, specify [Lab] Event
router

4. Switch to the Routing

section

5. Click + Add

374
Lab 25. Configure the Event router service (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

6. In the Destination field,

expand the drop-down list
and select [OOTB] Correlator

7. Click Save

8. Click + Add again

9. Add the [OOTB] Storage

destination in the same way

10. Switch to the Setup

validation section

11. Click Create and save

service

12. Copy the command for

installing the service using
the icon in the lower right
corner of the code block

13. Click Save

Task B: Install the Event router service

Install the Event router service on kuma-storage-1.

The task is performed on admin-laptop.

375
Lab 25. Configure the Event router service (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

14. In PuTTY, connect to kuma-

storage-1

15. To log in, use the username admin and password Ka5per$Ky

16. Paste the installation command from the clipboard, add sudo to the beginning of the line, and
execute the command

sudo /opt/kaspersky/kuma/kuma eventRouter --core https://kuma-

core.abc.lab:7210 --id <ID from the copied command> --api.port
<port from the copied command> --install

376
Lab 25. Configure the Event router service (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

17. Return to the KUMA web console and open Resources | Active services

18. Make sure the status of the [Lab] Event router service is green

Task C: Configure event streams to pass through the Event

router service
Reconfigure the destinations in the [OOTB] CEF WMI collector

The task is performed on admin-laptop.

19. In the KUMA web console, go to Resources

20. Click Destinations

21. Click + Add

22. In the Name field, specify

[Lab] Event router

23. In the Kind field, select

eventRouter

24. In the URL field that appears,

select kuma-storage-
1.abc.lab:7236

377
Lab 25. Configure the Event router service (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

You do not need to manually enter this value. As soon as you place the cursor in the URL
field, you will be prompted to select the Event router service you’ve created. Your port

number may be different.

25. Click Create new

26. In the KUMA web console,

go to Resources | Active
services

27. Click the name of the

[OOTB] CEF WMI collector
in the list of services to open
its settings

28. Switch to the Routing

section

29. Select the checkboxes for

both destinations

30. Click Delete

378
Lab 25. Configure the Event router service (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

31. Click + Add

32. Expand the Destination

drop-down list

33. Select [Lab] Event router

34. Click Save

35. Click Save again

379
Lab 25. Configure the Event router service (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

36. Select the [OOTB] CEF WMI collector service

37. Click Update configuration

38. Click OK to confirm the correlator configuration update

Task D: Make sure events arrive

Verify that events are arriving at the [OOTB] CEF WMI collector

The task is performed on admin-laptop.

39. In the KUMA web console, open Resources | Active services and select the checkbox in the
row with the [OOTB] CEF WMI collector service

40. Click Go to events

41. Make sure new events continue to arrive at the collector

380
Lab 25. Configure the Event router service (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

The stream of events from the agent is quite intensive, so new events should arrive

almost every second.

Conclusion

In this lab, you configured and installed the Event router service. By doing this, you optimized the
traffic between the collector and its destinations. Events flow in a single stream from the collector to
the Event router service, and then split into two identical streams: one goes to the storage, the other
to the correlator. This is useful functionality when the collector is located behind a thin channel, for
example, in a regional branch of an organization.

381
Lab 26. Create a rule based on an entropy calculation (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Lab 26. Create a rule based on an entropy calculation

(optional)
Scenario

You want to use an entropy calculation to monitor situations when a user enters the password instead
of the user name. This happens sometimes. When it does, the password should be considered
compromised, because the user name may be transmitted in cleartext and appear in logs. In this
example, an entropy calculation can help the correlator to distinguish a password from a user name.
To implement this scenario in this lab, you will need to expand the KUMA event schema, convert the
data of one of the fields of a received event, and write the conversion result to a new field.

Contents

Task A: Configure a normalizer

Task B: Create a correlation rule

Task C: Test the correlation rule

Task A: Configure a normalizer

Add an entropy calculation for the string containing the user name to the normalizer. To save the
calculated result, add a new field to the KUMA event schema.

The dc, ksc, kuma-core, kuma-storage-1, kuma-storage-2 and admin-laptop machines must be
powered on.

The task is performed on admin-laptop.

382
Lab 26. Create a rule based on an entropy calculation (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

1. In the KUMA web console, go to Resources

2. Click the Normalizers tile

3. Expand the tree on the left and select the [OOTB] node

4. Find the [OOTB] Microsoft Products for KUMA 3 normalizer and select its checkbox

5. Click Duplicate

383
Lab 26. Create a rule based on an entropy calculation (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

6. Find the normalizer for

EventID 4625

7. Click it to open

8. Scroll down the window a little. In the Mapping area, click the + Add row button

384
Lab 26. Create a rule based on an entropy calculation (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

9. In the added row, specify 0 in the Source column

10. In the KUMA field column, type F.user_name_entropy

11. Click Add F.user_name_entropy

We have created a new field and thus extended the KUMA event schema. F. at the
beginning of a field name defines its type as a float. We will compute the entropy of the

string containing the user name and save it in this new field.

12. Switch to the Enrichment tab

385
Lab 26. Create a rule based on an entropy calculation (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

13. Click + Add enrichment

14. In the Source kind field, select event

15. In the Source field, select DestinationUserName

16. In the Target field, select F.user_name_entropy

17. Click Add F.user_name_entropy

18. Click + Add conversion

19. In the Kind field, specify entropy

20. Click OK

386
Lab 26. Create a rule based on an entropy calculation (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

21. Click Create new

22. Make sure a new normalizer has appeared on the list: [OOTB] Microsoft Products for KUMA 3
- copy

23. Go to Resources | Active services

387
Lab 26. Create a rule based on an entropy calculation (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

24. Open the settings of the

[OOTB] CEF WMI collector

25. Switch to the Event parsing

section

26. Switch to the Parsing

settings tab

388
Lab 26. Create a rule based on an entropy calculation (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

27. For the 10.28.0.150 address,

change the normalizer to
[OOTB] Microsoft Products
for KUMA 3 - copy

28. Click Save

This normalizer is quite resource intensive. It may "hang" for a long time during the saving

process. Please be patient.

29. Select the checkbox for the [OOTB] CEF WMI collector

30. Click Update configuration

31. Click OK to confirm the configuration update

Task B: Create a correlation rule

Create a correlation rule that generates an alert when there is a suspicion that an account password
has been compromised and ended up in logs.

The dc, ksc, kuma-core, kuma-storage-1, kuma-storage-2 and admin-laptop machines must be
powered on.

389
Lab 26. Create a rule based on an entropy calculation (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

The task is performed on admin-laptop.

32. Go to Resources | Correlation rules

33. Open the Lab folder

34. Click + Add

35. In the Name field, specify

[Lab] Password disclosure

36. In the Kind field, select

simple

37. In the Propagated fields

field, specify
DestinationHostName

38. In the Severity drop-down

list, choose High

390
Lab 26. Create a rule based on an entropy calculation (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

39. Switch to the Selectors tab

40. Click </> Code

41. Enter the code of the selector condition:

DeviceEventClassID = 4625
AND F.user_name_entropy >= 3.2

For this lab, the value 3.2 was determined empirically. If you implement such rule logic in
real conditions, then the threshold value should also be selected empirically. Rules for

generating user names and password complexity requirements may vary.

42. Switch to the Actions tab

43. Select the Output checkbox

44. Click Create new

391
Lab 26. Create a rule based on an entropy calculation (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

45. Reopen the [Lab] Password

disclosure rule you just
created

46. Switch to the Correlators tab

392
Lab 26. Create a rule based on an entropy calculation (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

47. Click + Add

48. Expand the tree and select

[OOTB] Correlator

49. Click OK

50. Click Save

51. Go to Resources | Active services

52. Select the [OOTB] Correlator checkbox

53. Click Update configuration

393
Lab 26. Create a rule based on an entropy calculation (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

Task С: Test the correlation rule

Test the correlation rule.

The dc, ksc, kuma-core, kuma-storage-1, kuma-storage-2 and admin-laptop machines must be
powered on.

The task is performed on admin-laptop.

54. Hold down Shift and right-

click the Notepad++ icon in
the taskbar

55. In the shortcut menu, select

Run as different user

394
Lab 26. Create a rule based on an entropy calculation (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

56. In the User name field, type

Ka5per$Ky!#%

57. Click OK

58. The login will fail. Click

Cancel

59. Open the KUMA web console

and switch to the Alerts
section

60. Make sure a new Password

disclosure alert has been
created

61. Open the alert

62. Expand the Related events section

63. Open the base event

395
Lab 26. Create a rule based on an entropy calculation (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

396
Lab 26. Create a rule based on an entropy calculation (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

64. Examine the event fields

397
Lab 26. Create a rule based on an entropy calculation (optional) KL 034.3.2. Kaspersky Unified Monitoring and Analysis Platform

65. Notice the

DestinationUserName field
— the password entered in
the User name field ended
up in cleartext in the
Windows log

66. Notice the new field you

created in the Extension
fields section. It contains the
result of the entropy
calculation

Conclusion

In this lab, you learned how to detect compromised passwords using an extended KUMA event
schema and enrichment with an entropy calculation.

398