Name

Required setting.

Unique name of the resource. Must contain 1 to 128 Unicode characters.

Tenant

Required setting.

The name of the tenant that owns the resource.

Source kind

Required setting.

Drop-down list for selecting the type of incoming events. Depending on the selected type, the following additional settings will be displayed:

• constant

  This type of enrichment is used when a constant needs to be added to an event field. Available enrichment type settings are listed in the table below.

  Available enrichment type settings

  Setting	Description
  Constant	The value to be added to the event field. Maximum length of the value: 255 Unicode characters. If you leave this field blank, the existing event field value is removed.
  Target field	The KUMA event field that you want to populate with the data.

  If you are using the event enrichment functions for extended schema fields of String, Number, or Float type with a constant, the constant is added to the field.

  If you are using the event enrichment functions for extended schema fields of Array of strings, Array of numbers, or Array of floats type with a constant, the constant is added to the elements of the array.

• dictionary

  This type of enrichment is used if you need to add a value from the dictionary of the Dictionary type. Available enrichment type settings are listed in the table below.

  Available enrichment type settings

  Setting	Description
  Dictionary name	The dictionary from which the values are to be taken.
  Key fields	Event fields whose values are to be used for selecting a dictionary entry. To add an event field, click Add field. You can add multiple event fields.

  If you are using event enrichment with the dictionary type selected as the Source kind setting, and an array field is specified in the Key enrichment fields setting, when an array is passed as the dictionary key, the array is serialized into a string in accordance with the rules of serializing a single value in the TSV format.

  Example: The Key fields setting of the enrichment uses the SA.StringArrayOne extended schema field. The SA.StringArrayOne extended schema field contains the values "a", "b", "c". The following values are passed to the dictionary as the key: ['a','b','c'].

  If the Key enrichment fields setting uses an extended schema array field and a regular event schema field, the field values are separated by the | character when the dictionary is queried.

  Example: The Key enrichment fields setting uses the SA.StringArrayOne extended schema field and the Code string field. The SA.StringArrayOne extended schema field contains the values "a", "b", "c", and the Code string field contains the myCode sequence of characters. The following values are passed to the dictionary as the key: ['a','b','c']|myCode.

• table

  This type of enrichment is used if you need to add a value from the dictionary of the Table type. Available enrichment type settings are listed in the table below.

  Available enrichment type settings

  Setting	Description
  Dictionary name	The dictionary from which the values are to be taken.
  Key fields	Event fields whose values are to be used for selecting a dictionary entry. To add an event field, click Add field. You can add multiple event fields.
  Mapping	Event fields for data transfer: Dictionary field specifies dictionary fields from which data is to be transmitted. The available fields depend on the selected dictionary resource. KUMA field specifies event fields to which data is to be transmitted. For some of the selected fields (*custom* and *flex*), in the Label column, you can specify a name for the data written there.

  The first field in the table (Dictionary field) is taken as the key with which the fields selected from the event as key fields are matched (KUMA field). As the key in the Dictionary field, you must select an indicator of compromise by which the enrichment is to be performed, for example, IP address, URL, or hash. In the rule, you must select the event field that corresponds to the selected indicator of compromise in the dictionary field.

  If you want to select multiple key fields, you can specify them using | as a separator (when specifying in the web interface or importing as a CSV file), for example, <IP address>|<user name>.

  You can add new table rows or delete table rows. To add a new table row, click Add new element. To delete a row in the table, click the button.

• event

  This type of enrichment is used when you need to write a value from another event field to the current event field. Settings of this type of enrichment:

  • In the Target field drop-down list, select the KUMA event field to which you want to write the data.
  • In the Source field drop-down list, select the event field whose value will be written to the target field.
  • Under Conversion, you can create rules for modifying the original data before it is written to the KUMA event fields. The conversion type can be selected from the drop-down list. You can use the Add conversion and Delete buttons to add or delete a conversion, respectively. The order of conversions is important.

    Available conversions

    Conversions are modifications that are applied to a value before it is written to the event field. You can select one of the following conversion types from the drop-down list:

    • entropy is used for converting the value of the source field using the information entropy calculation function and placing the conversion result in the target field of the float type. The result of the conversion is a number. Calculating the information entropy allows detecting DNS tunnels or compromised passwords, for example, when a user enters the password instead of the login and the password gets logged in plain text.
    • lower—is used to make all characters of the value lowercase
    • upper—is used to make all characters of the value uppercase
    • regexp – used to convert a value using a specified RE2 regular expression. When you select this type of conversion, a field is displayed in which you must specify the RE2 regular expression.
    • substring is used to extract characters in a specified range of positions. When you select this type of conversion, the Start and End fields are displayed, in which you must specify the range of positions.
    • replace—is used to replace specified character sequence with the other character sequence. When you select this type of conversion, the following fields are displayed:
      • Replace chars specifies the sequence of characters to be replaced.
      • With chars is the character sequence to be used instead of the character sequence being replaced.
    • trim removes the specified characters from the beginning and from the end of the event field value. When you select this type of conversion, the Chars field is displayed in which you must specify the characters. For example, if a trim conversion with the Micromon value is applied to Microsoft-Windows-Sysmon, the new value is soft-Windows-Sys.
    • append appends the specified characters to the end of the event field value. When you select this type of conversion, the Constant field is displayed in which you must specify the characters.
    • prepend prepends the specified characters to the beginning of the event field value. When you select this type of conversion, the Constant field is displayed in which you must specify the characters.
    • replace with regexp is used to replace RE2 regular expression results with the specified character sequence. When you select this type of conversion, the following fields are displayed:
      • Expression is the RE2 regular expression whose results you want to replace.
      • With chars is the character sequence to be used instead of the character sequence being replaced.
    • Converting encoded strings to text:
      • decodeHexString—used to convert a HEX string to text.
      • decodeBase64String—used to convert a Base64 string to text.
      • decodeBase64URLString—used to convert a Base64url string to text.

      When converting a corrupted string or if conversion error occur, corrupted data may be written to the event field.

      During event enrichment, if the length of the encoded string exceeds the size of the field of the normalized event, the string is truncated and is not decoded.

      If the length of the decoded string exceeds the size of the event field into which the decoded value is to be written, the string is truncated to fit the size of the event field.

    • Converting the IP address to the IPv4 format:
      • ipDecimalToDotted converts an IP address in decimal format to an IP address in IPv4 format, in which octets are separated by dots.
      • ipHexToDotted converts a hexadecimal IP address to a decimal IP address in IPv4 format, in which octets are separated by dots.

    Conversions when using the extended event schema

    Whether or not a conversion can be used depends on the type of extended event schema field being used:

    • For an additional field of the String type, all types of conversions are available.
    • For fields of the Number and Float types, the following types of conversions are available: regexp, substring, replace, trim, append, prepend, replaceWithRegexp, decodeHexString, decodeBase64String, and decodeBase64URLString.
    • For fields of Array of strings, Array of numbers, and Array of floats types, the following types of conversions are available: append and prepend.

     

• template

  This type of enrichment is used when you need to write the result of processing Go templates into the event field. We recommend matching the value and the size of the field. Available enrichment type settings are listed in the table below.

  Available enrichment type settings

  Setting	Description
  Template	The Go template. Event field names are passed in the {{.EventField}} format, where EventField is the name of the event field from which the value must be passed to the script, for example, {{.DestinationAddress}} attacked from {{.SourceAddress}}.
  Target field	The KUMA event field that you want to populate with the data.

  If you are using an enrichment of events in which the Source kind is template, and the target field has the String type, and the source field is an extended event schema field containing an array of strings, you can use one of the following examples for the template:

  • {{.SA.StringArrayOne}}
  • {{- range $index, $element := . SA.StringArrayOne -}}

    {{- if $index}}, {{end}}"{{$element}}"{{- end -}}

  To convert the data in an array field in a template into the TSV format, use the toString function, for example:

  template {{toString.SA.StringArray}}

• dns

  This type of enrichment is used to send requests to a private network DNS server to convert IP addresses into domain names or vice versa. IP addresses are converted to DNS names only for private addresses: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 100.64.0.0/10.

  Available settings:

  • URL—in this field, you can specify the URL of a DNS server to which you want to send requests. You can use the Add URL button to specify multiple URLs.
  • RPS—maximum number of requests sent to the server per second. The default value is 1,000.
  • Workers is the number of workers that the service can run simultaneously to process events in parallel. Specify a positive integer number from 0 to 999. If 0 is specified, the number of logical CPU cores is used.
  • Max tasks—maximum number of simultaneously fulfilled requests. By default, this value is equal to the number of vCPUs of the KUMA Core server.
  • Cache TTL—the lifetime (in seconds) of the values stored in the cache. The default value is 60 (seconds).
  • Cache disabled—you can use this toggle switch to enable or disable caching. Caching is enabled by default.
  • Cache update disabled—if cache update is enabled, then after the cache TTL expires, the collector sends repeat queries to the DNS server to update the information stored in the cache. This setting is available only when cache is enabled. By default, cache update is enabled.
  • The Recursion desired setting is available starting with KUMA 3.4.1. You can use this toggle switch to make a KUMA collector send recursive queries to authoritative DNS servers for the purposes of enrichment. The default value is Disabled.
• cybertrace

  For systems with a high load on the collector or correlator, we recommend using the cybertrace-http enrichment type. This type returns a structured response in JSON format and correctly distinguishes between strings and arrays of custom attributes, preventing parsing errors.

  When enriched through cybertrace, the collector gets an unstructured response. If the value of a custom attribute in CyberTrace contains square brackets (for example, [str1, str2]), KUMA treats it as an array, not a string.

  This type of enrichment is used to add information from CyberTrace data streams to event fields.

  Available settings:

  • URL (required)—in this field, you can specify the URL of a CyberTrace server to which you want to send requests. The default CyberTrace port is 9999.
  • Number of connections—maximum number of connections to the CyberTrace server that can be simultaneously established by KUMA. By default, this value is equal to the number of vCPUs of the KUMA Core server.
  • RPS—maximum number of requests sent to the server per second. The default value is 1,000.
  • Timeout—amount of time to wait for a response from the CyberTrace server, in seconds. The default value is 30.
  • Maximum number of events in the enrichment queue—maximum number of events stored in the enrichment queue for re-sending. The default value is 1,000,000.
  • Mapping (required)—this settings block contains the mapping table for mapping KUMA event fields to CyberTrace indicator types. The KUMA field column shows the names of KUMA event fields, and the CyberTrace indicator column shows the types of CyberTrace indicators.

    Available types of CyberTrace indicators:

    • ip
    • url
    • hash

    In the mapping table, you must provide at least one string. You can use the Add row button to add a string, and can use the button to remove a string.

• cybertrace-http

  This is a new streaming event enrichment type in CyberTrace that allows you to send a large number of events with a single request to the CyberTrace API. Recommended for systems with a lot of events. The performance of cybertrace-http is superior to that of the cybertrace type.

  Limitations:

  • The cybertrace-http enrichment type cannot be used for retroscan in KUMA.
  • If the cybertrace-http enrichment type is being used, detections are not saved in CyberTrace history in the Detections window.

  Available settings:

  • Name (required) is a unique name for the enrichment rule. Up to 5000 Unicode characters.
  • Tenant (required) is the name of the tenant in which you plan to work with CyberTrace.
  • URL (required)—in this field, you can specify the URL of a CyberTrace server to which you want to send requests and the port that CyberTrace API is using. The default port is 443.
  • Secret (required) is a drop-down list in which you can select the secret which stores the credentials for the connection.
  • Timeout—amount of time to wait for a response from the CyberTrace server, in seconds. The default value is 30.
  • Key fields (required) is the list of event fields used for enriching events with data from CyberTrace.
  • Maximum number of events in the enrichment queue—maximum number of events stored in the enrichment queue for re-sending. The default value is 1,000,000. After reaching 1 million events received from the CyberTrace server, events stop being enriched until the number of received events is reduced to less than 500,000.
  • Major version of CyberTrace selects the CyberTrace version. Possible values: <5, ≥ 5.0. If version ≥ 5.0 is selected, requests are executed in the General tenant in CyberTrace and use the new version of the API provided by Kaspersky CyberTrace 5.0 and later. If you select <5, requests use the Kaspersky CyberTrace 4.x API. The default value is <5.
  • The Debug toggle switch enables resource logging. The toggle switch is turned off by default.
  • Tags for resource search.
• timezone

  This type of enrichment is used in collectors and correlators to assign a specific timezone to an event. Timezone information may be useful when searching for events that occurred at unusual times, such as nighttime.

  When this type of enrichment is selected, the required timezone must be selected from the Timezone drop-down list.

  Make sure that the required time zone is set on the server hosting the enrichment-utilizing service. For example, you can do this by using the timedatectl list-timezones command, which shows all time zones that are set on the server. For more details on setting time zones, please refer to your operating system documentation.

  When an event is enriched, the time offset of the selected timezone relative to Coordinated Universal Time (UTC) is written to the DeviceTimeZone event field in the +-hh:mm format. For example, if you select the Asia/Yekaterinburg timezone, the value +05:00 will be written to the DeviceTimeZone field. If the enriched event already has a value in the DeviceTimeZone field, it will be overwritten.

  By default, if the timezone is not specified in the event being processed and enrichment rules by timezone are not configured, the event is assigned the timezone of the server hosting the service (collector or correlator) that processes the event. If the server time is changed, the service must be restarted.

  Permissible time formats when enriching the DeviceTimeZone field

  When processing incoming raw events in the collector, the following time formats can be automatically converted to the +-hh:mm format:

  Time format in a processed event	Example
  +-hh:mm	-07:00
  +-hhmm	-0700
  +-hh	-07

  If the date format in the DeviceTimeZone field differs from the formats listed above, the collector server timezone is written to the field when an event is enriched with timezone information. You can create custom normalization rules for non-standard time formats.

• geographic data

  This type of enrichment is used to add IP address geographic data to event fields. Learn more about linking IP addresses to geographic data.

  When this type is selected, under Mapping geographic data to event fields, you must specify from which event field the IP address will be read, select the required attributes of geographic data, and define the event fields in which geographic data will be written:

  1. In the Event field with IP address drop-down list, select the event field from which the IP address is read. Geographic data uploaded to KUMA is matched against this IP address.

     You can use the Add event field with IP address button to specify multiple event fields with IP addresses that require geographic data enrichment. You can delete event fields added in this way by clicking the Delete event field with IP address button.

     When the SourceAddress, DestinationAddress, and DeviceAddress event fields are selected, the Apply default mapping button becomes available. You can use this button to add preconfigured mapping pairs of geographic data attributes and event fields.

  2. For each event field you need to read the IP address from, select the type of geographic data and the event field to which the geographic data should be written.

     You can use the Add geodata attribute button to add field pairs for Geodata attribute – Event field to write to. You can also configure different types of geographic data for one IP address to be written to different event fields. To delete a field pair, click .

     • In the Geodata attribute field, select which geographic data corresponding to the read IP address should be written to the event. Available geographic data attributes: Country, Region, City, Longitude, Latitude.
     • In the Event field to write to, select the event field which the selected geographic data attribute must be written to.

     You can write identical geographic data attributes to different event fields. If you configure multiple geographic data attributes to be written to the same event field, the event will be enriched with the last mapping in the sequence.

   

   

• check DLL Hijacking

  DLL Hijacking is an attack technique that involves delivering vulnerable legitimate software along with a malicious dynamic link library (DLL) to the target system. To detect such attacks, KUMA uses the AI module. The AI module analyzes the launch and runtime parameters of applications and identifies suspicious launches of legitimate software with malicious libraries.

  To get a status, KUMA sends a request to KSN with information from event fields. In response to the request, KSN sends the analysis result.

  You can configure DLL Hijacking attack detection in the collector or correlator.

  To use enrichment such as check DLL Hijacking, your license must include the AI module. The General administrator must also accept the additional KSN license agreement in the Kaspersky Security Network section (Settings → Integrations → AI services → Kaspersky Security Network).

  Available settings:

  • Workers is the number of workers that the service can run simultaneously to process events in parallel. Specify a positive integer number from 0 to 999. If 0 is specified, the number of logical CPU cores is used.
  • Maximum cache size is the maximum cache size for KSN responses, in megabytes. The default value is 128 MB.

    Each KSN response has its own lifetime, during which it is retained in the cache. If KUMA sends a second request for a DLL file for which KSN has already issued a response, and the lifetime of that response has not yet expired, the request is not actually sent to KSN, but the response is taken from the cache.

  • If the Maximum number of events in enrichment queue is exceeded, new events are not processed. The default value is 1,000,000. 0 means that event processing stops if the queue contains any number of events.
  • Perform a repeat request. KSN may return the Unclassified status. This status means that KSN has accepted the request and is currently processing it, but there is no status yet. Processing may take a long time, so the request must be re-sent. If this setting is enabled, specify additional settings:
    • If the Create duplicates setting is enabled, KUMA creates a duplicate event and uses it for repeated requests to KSN. In this case, the main event is routed in accordance with the workflow. A duplicate event is written to the database when one of the following conditions is satisfied:
      • A status other than Unclassified is received from KSN.
      • The disk buffer configured using the Buffer size setting is full.
      • The Request count is exceeded.

      If this setting is disabled, KUMA continues to send requests using the main event. The event is written to the database when one of the following conditions is satisfied:

      • A status other than Unclassified is received from KSN.
      • The disk buffer configured using the Buffer size setting is full.
      • The Request count is exceeded.
    • The Request count is the maximum number of requests to KSN. If, after the specified number of requests, a status other than Unclassified is not received, the event is written to the database with the Unclassified status. The default setting is 10.
    • Poll interval is the interval between requests, in minutes. The default value is 1 minute. The minimum value is 1 minute.
    • Buffer size is the size of the disk buffer for events awaiting a repeat request, in megabytes. The default value is 10240 MB. The minimum value is 10 MB.
  • Proxy specifies proxy server settings, if one is needed to connect to the KSN server. You can select one of the available proxy servers or create a new proxy server. By default, a proxy server is not used.
  • The Mapping contains a list of parameters that must be sent in a KSN request to get a status, and a list of the corresponding KUMA event fields. List of parameters in the request:
    • dll hash (md5). Recommended field for mapping: OldFileHash.
    • dll path. Full path including the file name; recommended field for mapping: OldFilePath. The path may contain personal data, so KUMA sends this parameter to KSN in an anonymized form. For example:

      Path before anonymization: C:\Windows\Device\HarddiskVolume1\Users\Alex\malware.dll

      The same path in anonymized form: device\harddiskvolume1\users\username

    • process hash (md5). Recommended field for mapping: FileHash.
    • process path. Full path including the file name. The path may contain personal data, so KUMA sends this parameter to KSN in an anonymized form. For example:

      Path before anonymization: C:\Windows\Device\HarddiskVolume1\Users\Alex\malware.dll

      The same path in anonymized form: device\harddiskvolume1\users\username

    • dll name. Recommended field for mapping: OldFileName.
    • process name. Recommended field for mapping: FileName.
    • process signature. Optional; recommended field for mapping: FileID.
    • dll size. Optional; recommended field for mapping: OldFileSize.

    For each required parameter, specify a corresponding KUMA event field in the table.

Debug

You can use this toggle switch to enable the logging of service operations. Logging is disabled by default.

Description

Resource description: up to 4,000 Unicode characters.

Filter

Group of settings in which you can specify the conditions for identifying events that must be processed by this resource. You can select an existing filter from the drop-down list or create a new filter.

Creating a filter in resources

Enrichment rule name

Description

[OOTB] KATA alert

Used to enrich events received from KATA in the form of a hyperlink to an alert.

The hyperlink is put in the DeviceExternalId field.

If you want the DeviceExternalID value to be displayed as a link in the event properties, make sure that the Template field for the DeviceAddress parameter contains a URL or fully qualified domain name followed by the "/" character, for example: https://example.com:8443/ or https://example.com/.