The new version of Kaspersky Unified Monitoring and Analysis Platform introduces the following features and improvements:
Redesigned interface for writing conditions in filters and correlation rule selectors. In addition to the builder mode, a new mode allows writing conditions as code. Filter and selector conditions are automatically translated between builder mode and code mode.
In KUMA 3.0.2, CEF remains the basis of the KUMA event schema, but now you can create custom fields. This functionality allows you to implement an arbitrary taxonomy. Field names that are familiar to users help write search queries quicker. Custom fields are typed and must begin with a prefix that determines the type of the field: S for string, N for numeric, F for floating-point. Array types are SA for an array of strings, NA for an array of numbers, FA for an array of floating-point numbers. Array fields can be used only in JSON and KV normalizers.
The following event normalization options are now available:
1 collector — 1 normalizer
We recommend using this method if you have many events of the same type or many IP addresses from which events of the same type may originate. You can configure one collector with only one normalizer, which is optimal in terms of performance.
1 collector — multiple normalizers linked to IP
This method is available for collectors with a connector of UDP, TCP, or HTTP type. If a UDP, TCP, or HTTP connector is specified in the collector at the 'Transport' step, then at the 'Event parsing' step, you can specify multiple IP addresses on the 'Parsing settings' tab and choose the normalizer that you want to use for events coming from the specified addresses. The following types of normalizers are available: json, cef, regexp, syslog, csv, kv, xml. For normalizers of the Syslog and regexp types, you can specify extra normalization conditions depending on the value of the DeviceProcessName field.
Now you can publish correlation rules on correlators using the correlation rule menu. Now you can select one or more rules and link them to one or more correlators. The list of correlators is represented by a tree structure of correlator resources. An analyst managing correlation rules of the Shared tenant can publish rules on correlators of all tenants available to that analyst.
Context tables are a new entity in the correlator. You can manage context tables in a similar way as active lists. Functionality of context tables:
KUMA supports obtaining KEDR events using the kata/edr connector. The kata/edr connector differs from kafka in that it allows integration with KATA 5.1, and configuring it takes less time and effort. You can use collector and filter settings to make the request more specific—you can specify how many events you want to receive in one request, which events and how frequently you want to receive.
Assets imported from KSC or KICS whose agents no longer connect to KSC or KICS, are marked as archived in KUMA and can be deleted after a user-defined period.
The KUMA distribution kit includes the kuma-ptvm utility, which consists of an executable file and a configuration file. The utility is supported on Windows and Linux operating systems. The utility allows you to connect to the MaxPatrol VM API to get data about devices and their attributes, including vulnerabilities, and also lets you edit asset data and import data using the KUMA API.
New roles: Access to shared resources, Interaction with NCIRCC, Interaction with CII.
When kuma-core.service is restarted, the predefined report templates and dashboard layout templates are restored to their original condition if they were previously deleted.
Specifying the user's email address in the template is no longer grounds for providing access to a report generated from that template. Such a report is available to the user for viewing if all tenants specified in the template are available for the user's role.