About Kaspersky Unified Monitoring and Analysis Platform

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

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

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

What's new

• The capability to automatically and manually update the repository is implemented in order to receive packages with new correlation rules and connectors for log sources.
• The cold storage of events is implemented.
• To reduce the number of simultaneous insert queries to ClickHouse tables, in version 2.1.3 or later, you can configure buffering of insert queries for the Storage resource.
• In version 2.1.3 or later, KUMA uses a new driver for connecting to oracle.
• New connectors are added: SNMP traps, 1C log, 1C xml.
• Version 2.1.3 introduces numbering of tags for the xml normalizer.
• Integration with Kaspersky Automated Security Awareness Platform is implemented.
• A new response type is added: Active Directory response rule.
• The list of formats for generating reports is expanded. The following formats are now available: HTML, PDF, CSV, split CSV, Excel.
• RuCERT integration is expanded.
• The capability is added to create common (universal) dashboard layouts for all tenants and fill them with data on the tenants available to the current user. Thus, the number of layouts used in the system can be significantly reduced, and there is no need to create separate standard layouts for each tenant.
• The integration with Active Directory Federation Services is added for logging in without a user name and password (Single Sign On (SSO) scenario).
• The support of the FreeIPA domain is added for logging in the system.
• Added the capability to receive custom attributes of Active Directory accounts from LDAP and enrich events with the custom attributes of AD accounts.

  Before configuring event enrichment using custom attributes, make sure that custom attributes are configured in AD.

  To enrich events with accounts using custom attributes:

  1. Add Custom AD Account Attributes in the LDAP connection settings.

     Standard imported attributes from AD cannot be added as custom attributes. For example, if you want to add the standard accountExpires

     attribute

     as a custom attribute, KUMA will return an error when saving the connection settings.

     The following account attributes can be requested from Active Directory:

     • accountExpires
     • badPasswordTime
     • cn
     • co
     • company
     • department
     • description
     • displayName
     • distinguishedName
     • division
     • employeeID
     • givenName
     • l
     • lastLogon
     • lastLogonTimestamp
     • Mail
     • mailNickname
     • managedObjects
     • manager
     • memberOf (this attribute can be used for search during correlation)
     • mobile
     • name
     • objectCategory
     • objectGUID (this attribute always requested from Active Directory even if a user doesn't specify it)
     • objectSID
     • physicalDeliveryOfficeName
     • pwdLastSet
     • sAMAccountName
     • sAMAccountType
     • sn
     • streetAddress
     • telephoneNumber
     • title
     • userAccountControl
     • UserPrincipalName
     • whenChanged
     • whenCreated

     After you add custom attributes in the LDAP connection settings, the LDAP attribute to receive drop-down list in the collector automatically includes the new attributes. Custom attributes are identified by a question mark next to the attribute name. If you added the same attribute for multiple domains, the attribute is listed only once in the drop-down list. You can view the domains by moving your cursor over the question mark. Domain names are displayed as links. If you click a link, the domain is automatically added to LDAP accounts mapping if it was not previously added.

     If you deleted a custom attribute in the LDAP connection settings, manually delete the row containing the attribute from the mapping table in the collector. Account attribute information in KUMA is updated each time you import accounts.  

  2. Import accounts.
  3. In the collector, in the LDAP mapping table, define the rules for mapping KUMA fields to LDAP attributes.
  4. Restart the collector.

     After the collector is restarted, KUMA begins enriching events with accounts.

      

• The capabilities for working with assets are expanded: it is now possible to add custom fields to assets, to search for assets by the field names, and to export search results to a file.
• In the event search section, event field presets are added allowing you to quickly configure the lookup table columns according to the analyzed logs.
• System fault tolerance is improved.
• The information about assets now displays additional information about protecting the hosts running KES for Windows and KES for Linux. The information is available if you've imported the asset from KSC.
• For KATA/EDR triggering events, a link is added that allows you to go to the corresponding alert card in the KATA/EDR management console.
• The capability is implemented to use the hex, base64, and base64url conversions to process binary values in logs at the event receiving stage.
• Correlation capabilities have been expanded:
  • The list of variable functions is expanded. There are now opportunities to transform keys or define conditions.
  • Ability to manage rule application sequence in the correlator is added.
• Alert segmentation rules are added.
• Normalizers for the event sources are added.
• A new first line analyst role is added. Users with this role are able to create their own content in the system but cannot edit the resources created by other users.
• System logging and the ability to export application component logs to files are improved.

Distribution kit

The distribution kit includes the following files:

• kuma-ansible-installer-<build number>.tar.gz is used to install KUMA components without the capability of deployment in a fault-tolerant configuration.
• kuma-ansible-installer-ha-<build number>.tar.gz is used to install KUMA components with the capability of deployment in a fault-tolerant configuration.
• files containing information about the version (release notes) in Russian and English.

Hardware and software requirements

Recommended hardware requirements

This section lists the hardware requirements for processing a data stream of up to 40,000 events per second (EPS). The KUMA load value depends on the type of events being parsed and the efficiency of the normalizer.

Consider that for event processing efficiency, the CPU core count is more important than the clock rate. For example, eight CPU cores with a medium clock rate can process events more efficiently than four CPU cores with a high clock rate. The following table lists the hardware and software requirements of KUMA components.

Consider also that the amount of RAM utilized by the collector depends on configured enrichment methods (DNS, accounts, assets, enrichment with data from Kaspersky CyberTrace) and whether aggregation is used (RAM consumption is influenced by the data aggregation window setting, the number of fields used for aggregation of data, volume of data in fields being aggregated).

For example, with an event stream of 1,000 EPS and event enrichment disabled (event enrichment is disabled, event aggregation is disabled, 5,000 accounts, 5,000 assets per tenant), one collector requires the following resources:

• 1 CPU core or 1 virtual CPU
• 512 MB of RAM
• 1 GB of disk space (not counting event cache)

For example, to support 5 collectors that do not perform event enrichment, you must allocate the following resources: 5 CPU cores, 2.5 GB of RAM, and 5 GB of free disk space.

Installation of KUMA is supported in the following virtual environments:

• VMware 6.5 or later
• Hyper-V for Windows Server 2012 R2 or later
• QEMU-KVM 4.2 or later
• Software package of virtualization tools "Brest" RDTSP.10001-02

Kaspersky recommendations for storage servers

We recommend putting ClickHouse on solid state drives (SSD). SSDs help improve data access speed. Hard drives can be used to store data using the HDFS technology.

To connect a data storage system to storage servers, you must use high-speed protocols, such as Fibre Channel or iSCSI 10G. We do not recommend using application-level protocols such as NFS and SMB to connect data storage systems.

On ClickHouse cluster servers, using the ext4 file system is recommend.

If you are using RAID arrays, it is recommended to use RAID 0 for high performance, or RAID 10 for high performance and fault tolerance.

To ensure fault tolerance and performance of the data storage subsystem, we recommend making sure that ClickHouse nodes are deployed strictly on different disk arrays.

If you are using a virtualized infrastructure to host system components, we recommend deploying ClickHouse cluster nodes on different hypervisors. In this case, it is necessary to prevent two virtual machines with ClickHouse from working on the same hypervisor.

For high-load KUMA installations, we recommend installing ClickHouse on physical servers.

Requirements for devices for installing agents

To have data sent to the KUMA collector, you must install agents on the network infrastructure devices. Device requirements are listed in the following table.

Requirements for client devices for managing the KUMA web interface

CPU: Intel Core i3 8th generation

RAM: 8 GB

Supported browsers:

• Google Chrome 102 or later.
• Mozilla Firefox 103 or later.

Device requirements for installing KUMA on Kubernetes

The minimum configuration of a Kubernetes cluster for deployment of a fault-tolerant KUMA configuration includes the following:

• 1 load balancer node (not part of the cluster).
• 3 controller nodes.
• 2 worker nodes.

The minimum hardware requirements for devices for installing KUMA on Kubernetes are listed in the table below.

KUMA interface

The program is managed through the web interface.

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

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

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

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

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

Compatibility with other applications

Kaspersky Endpoint Security for Linux

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