What's new

Kaspersky Unified Monitoring and Analysis Platform introduces the following features and improvements:

• Added support for the following operating systems:
  • Oracle Linux 9.2
  • Astra Linux 1.7.4
• Filter conditions and correlation rules can be written as code.

  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. Filter conditions can be composed in the following modes:

  • The Builder allows composing conditions using the keyboard. As you start typing filter conditions, KUMA suggests matching options, for example, from event fields ("e:"), dictionaries ("d:"), active lists ("a:"), and so on, after which you can select the option you want. You can narrow down the range of options by typing the appropriate prefix, for example, "e:SourceAddress". Condition types are highlighted in different colors.
  • Code mode lets you quickly edit conditions, select and copy blocks of code to move filters or selector conditions between filters and correlation rules. For linked resources, the ID is specified automatically. Fields with the names and IDs of linked resources are not available for editing.
• Extended event schema.

  In KUMA 3.0.3, CEF remains the main technology 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 their names must begin with a prefix that determines their type: S for string, N for integer, F for floating point number. For arrays, the prefixes are SA for an array of strings, NA for an array of integers, FA for an array of floating point numbers. Array fields can be used only in JSON and KV normalizers.

• Automatic identification of the event source.

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

• Linking a correlator from the rule list section.

  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.

• Using context tables.

  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:

  • The list of key fields is defined by the user.
  • Data in context tables is typed (integer, float, string, boolean, timestamp, IP).
  • Arrays are supported for all data types listed above.
  • Array fields of context tables can be used in correlation rules: you can count unique values, calculate the length of the array, or reference a specific element of the array.
• Added "index_of" and "last_index_of" functions.

  These functions return the position of the character in a string. Using the "index_of" and "last_index_of" functions together with the "substring" function allows obtaining a substring in correlation rules without using regular expressions. Using these functions instead of regular expressions reduces the load on the correlator.

• The kata/edr connector for telemetry from KEDR hosts.

  KUMA supports obtaining KEDR events using the kata/edr connector. The kata/edr connector differs from the kafka connector in that it allows integration with KATA 5.1, and configuring it takes less time and effort. You can use collector and filter parameters 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.

• Archiving and deleting assets.

  Assets imported from KSC or KICS for Networks 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 FQDN field in assets can contain an array of values.
• The CEF format is added for sending events to third-party systems.
• Importing asset information from MaxPatrol VM.

  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.

• Predefined layouts for the main B2B products by Kaspersky (KATA, KSC, KSMG, KWTS) let you visualize data as soon as the corresponding event sources are connected.
• Hierarchical structure is no longer supported. When upgrading from version 2.1.3 to 3.0.x, all KUMA hosts become stand-alone.
• Now you can send test events.
• Integration with Telegram, UserGate, KWTS, KSMG, RedCheck is now supported.
• Logs: When upgrading from 2.1.3 to 3.0.3, the old Core logs are preserved and the new Core logs are created beside them. After the upgrade, the list of logs looks as follows:
  • /opt/kaspersky/kuma/core/log/core — version 2.1.3 logs.
  • /opt/kaspersky/kuma/core/log/stdout.log — version 3.0.3 logs; the standard output stream of the service is redirected here.
  • /opt/kaspersky/kuma/core/log/stderr.log — version 3.0.3 logs; the standard error stream of the service is redirected here.
• Role-based access model was changed.

  KUMA 3.0.3 introduces the following changes:

  • Administrator → Tenant administrator: can now delete predefined report templates and predefined dashboard layouts.
  • Analyst → Tier 2 analyst: can now view and generate all reports, their own and those of other users, provided that all tenants specified in the report template are available to this role. Can edit predefined templates, edit the predefined report generation settings, can delete predefined report templates and predefined dashboard layouts.
  • First line analyst → Tier 1 analyst: can now view and generate all reports, their own and those of other users, provided that all tenants specified in the report template are available to this role.
  • Operator → Junior analyst.
  • 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.
• Normalizers for the event sources are added.
• The Appendices section of Help provides a list of deprecated KUMA resources and a possible way to replace them.
• Bugs of previous versions were fixed.