Starting the Correlator Installation Wizard

To start the Correlator Installation Wizard:

• In the KUMA Console, under Resources, click Add correlator.
• In the KUMA Console, under Resources → Correlators, click Add correlator.

Follow the instructions of the Wizard.

Aside from the first and last steps of the Wizard, the steps of the Wizard can be performed in any order. You can switch between steps by clicking the Next and Previous buttons, as well as by clicking the names of the steps in the left side of the window.

After the Wizard completes, a resource set for the correlator is created in the KUMA Console under Resources → Correlators, and a correlator service is added under Resources → Active services.

Step 1. General correlator settings

This is a required step of the Installation Wizard. At this step, you specify the main settings of the correlator: the correlator name and the tenant that will own it.

To define the main settings of the correlator:

• In the Name field, enter a unique name for the service you are creating. The name must contain 1 to 128 Unicode characters.
• In the Tenant drop-down list, select the tenant that will own the correlator. The tenant selection determines what resources will be available when the collector is created.

  If you return to this window from another subsequent step of the Installation Wizard and select another tenant, you will have to manually edit all the resources that you have added to the service. Only resources from the selected tenant and shared tenant can be added to the service.

• If required, specify the number of processes that the service can run concurrently in the Workers field. By default, the number of worker processes is the same as the number of vCPUs on the server where the service is installed.
• If necessary, use the Debug drop-down list to enable logging of service operations.
• You can optionally add up to 256 Unicode characters describing the service in the Description field.

The main settings of the correlator are defined. Proceed to the next step of the Installation Wizard.

Step 2. Global variables

If tracking values in event fields, active lists, or dictionaries is not enough to cover some specific security scenarios, you can use global and local variables. You can use them to take various actions on the values received by the correlators by implementing complex logic for threat detection. Variables can be assigned a specific function and then queried from correlation rules as if they were ordinary event fields, with the triggered function result received in response.

To add a global variable in the correlator,

click the Add variable button and specify the following parameters:

• In the Variable window, enter the name of the variable.

  Variable naming requirements

  • Must be unique within the correlator.
  • Must contain 1 to 128 Unicode characters.
  • Must not begin with the character $.
  • Must be written in camelCase or CamelCase.
• In the Value window, enter the variable function.

  Description of variable functions.

The global variable is added. It can be queried from correlation rules by adding the $ character in front of the variable name. There can be multiple variables. Added variables can be edited or deleted by using the icon.

Proceed to the next step of the Installation Wizard.

Step 3. Correlation

This is an optional but recommended step of the Installation Wizard. On the Correlation tab of the Installation Wizard, select or create correlation rules. These resources define the sequences of events that indicate security-related incidents. When these sequences are detected, the correlator creates a correlation event and an alert.

If you have added global variables to the correlator, all added correlation rules can query them.

Correlation rules that are added to the set of resources for the correlator are displayed in the table with the following columns:

• Correlation rules—name of the correlation rule resource.
• Type—type of correlation rule: standard, simple, operational. The table can be filtered based on the values of this column by clicking the column header and selecting the relevant values.
• Actions—list of actions that will be performed by the correlator when the correlation rule is triggered. These actions are indicated in the correlation rule settings. The table can be filtered based on the values of this column by clicking the column header and selecting the relevant values.

  Available values:

  • Output—correlation events created by this correlation rule are transmitted to other correlator resources: enrichment, response rule, and then to other KUMA services.
  • Edit active list—the correlation rule changes the active lists.
  • Loop to correlator—the correlation event is sent to the same correlation rule for reprocessing.
  • Categorization—the correlation rule changes asset categories.
  • Event enrichment—the correlation rule is configured to enrich correlation events.
  • Do not create alert—when a correlation event is created as a result of a correlation rule triggering, no alert is created for that. If you do not want to create an alert when a correlation rule is triggered, but you still want to send a correlation event to the storage, select the Output and No alert check boxes. If you select only the No alert check box, a correlation event is not saved in the storage.
  • Shared resource—the correlation rule or the resources used in the correlation rule are located in a shared tenant.

You can use the Search field to search for a correlation rule. Added correlation rules can be removed from the set of resources by selecting the relevant rules and clicking Delete.

Selecting a correlation rule opens a window with its settings, which can be edited and then saved by clicking Save. If you click Delete in this window, the correlation rule is unlinked from the set of resources.

Click the Move up and Move down buttons to change the position of the selected correlation rules in the table. It affects their execution sequence when events are processed. By clicking the Move operational to top button, you can move correlation rules of the operational type to the beginning of the correlation rules list.

To link the existing correlation rules to the set of resources for the correlator:

1. Click Link.

   The resource selection window opens.

2. Select the relevant correlation rules and click OK.

The correlation rules will be linked to the set of resources for the correlator and will be displayed in the rules table.

To create a new correlation rule in a set of resources for a correlator:

1. Click Add.

   The correlation rule creation window opens.

2. Specify the correlation rule settings and click Save.

The correlation rule will be created and linked to the set of resources for the correlator. It is displayed in the correlation rules table and in the list of resources under Resources → Correlation rules.

Proceed to the next step of the Installation Wizard.

Step 4. Enrichment

Expand all | Collapse all

This is an optional step of the Installation Wizard. On the Enrichment tab of the Installation Wizard, you can select or create enrichment rules and indicate which data from which sources you want to add to correlation events that the correlator creates. There can be more than one enrichment rule. You can add them by clicking the Add button and can remove them by clicking the button.

To add an existing enrichment rule to a set of resources:

1. Click Add.

   This opens the enrichment rule settings block.

2. In the Enrichment rule drop-down list, select the relevant resource.

The enrichment rule is added to the set of resources for the correlator.

To create a new enrichment rule in a set of resources:

1. Click Add.

   This opens the enrichment rule settings block.

2. In the Enrichment rule drop-down list, select Create new.
3. In the Source kind drop-down list, select the source of data for enrichment and define its corresponding settings:
   • constant

     This type of enrichment is used when a constant needs to be added to an event field. Settings of this type of enrichment:

     • In the Constant field, specify the value that should be added to the event field. The value may not be longer than 255 Unicode characters. If you leave this field blank, the existing event field value will be cleared.
     • In the Target field drop-down list, select the KUMA event field to which you want to write 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.

     When this type is selected in the Dictionary name drop-down list, you must select the dictionary that will provide the values. In the Key fields settings block, you have to click the Add field button and select the event fields whose values will be used for dictionary entry selection.

     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 enrichment fields" setting uses the SA.StringArrayOne extended schema field. The SA.StringArrayOne extended schema field contains 3 elements: "a", "b" and "c". The following value is 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 two fields: the SA.StringArrayOne extended schema field and the Code field. The SA.StringArrayOne extended schema field contains 3 elements: "a", "b", and "c"; the Code string field contains the character sequence "myCode". The following value is passed to the dictionary as the key: ['a','b','c']|myCode.

   • 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.
     • In the Conversion settings block, 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 click the Add conversion and Delete buttons to add or delete a conversion, respectively. The order of conversions is important.

       Available conversions

       Conversions are changes that can be applied to a value before it gets written to the event field. The conversion type is selected from a drop-down list.

       Available conversions:

       • 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 the regular expression RE2. When this conversion type is selected, the field appears where regular expression should be added.
       • substring—is used to extract characters in the position range specified in the Start and End fields. These fields appear when this conversion type is selected.
       • replace—is used to replace specified character sequence with the other character sequence. When this type of conversion is selected, new fields appear:
         • Replace chars—in this field you can specify the character sequence that should be replaced.
         • With chars—in this field you can specify the characters sequence should be used instead of replaced characters.
       • trim—used to simultaneously remove the characters specified in the Chars field from the leading and end positions of the value. The field appears when this type of conversion is selected. For example, a trim conversion with the Micromon value applied to Microsoft-Windows-Sysmon results in soft-Windows-Sys.
       • append is used to add the characters specified in the Constant field to the end of the event field value. The field appears when this type of conversion is selected.
       • prepend—used to prepend the characters specified in the Constant field to the start of the event field value. The field appears when this type of conversion is selected.
       • replace with regexp—is used to replace RE2 regular expression results with the character sequence.
         • Expression—in this field you can specify the regular expression which results that should be replaced.
         • With chars—in this field you can specify the characters sequence should be used instead of replaced characters.
       • 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, such a string is truncated to fit the size of the event field.

       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, decodeBase64URLString.
       • For fields of "Array of strings", "Array of numbers", and "Array of floats" types, the following types of conversions are available: append, prepend.

   • template

     This type of enrichment is used when you need to write a value obtained by processing Go templates into the event field. Settings of this type of enrichment:

     • Put the Go template into the Template field.

       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.

       Example: Attack on {{.DestinationAddress}} from {{.SourceAddress}}.

     • In the Target field drop-down list, select the KUMA event field to which you want to write the data.

     To convert the data in an array field in a template into the TSV format, you must use the toString function.

     If you are using enrichment of events that have the "Template" type selected as the "Source kind" setting, in which 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.

     Example:

     {{.SA.StringArrayOne}}

     Example:

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

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

   • 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 click 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—maximum number of requests per one point in time. The default value is 1.
     • 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 of the values stored in the cache. The default value is 60.
     • Cache disabled—you can use this drop-down list to enable or disable caching. Caching is enabled by default.
   • cybertrace

     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.
     • 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.
     • 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 click the Add row button to add a string, and can click the button to remove a string.

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

4. Use the Debug drop-down list to indicate whether or not to enable logging of service operations. Logging is disabled by default.
5. In the Filter section, you can specify conditions to identify events that will be processed using the enrichment rule. You can select an existing filter from the drop-down list or create a new filter.

   Creating a filter in resources

   1. In the Filter drop-down list, select Create new.
   2. If you want to keep the filter as a separate resource, select the Save filter check box.

      In this case, you will be able to use the created filter in various services.

      This check box is cleared by default.

   3. If you selected the Save filter check box, enter a name for the created filter resource in the Name field. The name must contain 1 to 128 Unicode characters.
   4. In the Conditions settings block, specify the conditions that the events must meet:
      1. Click the Add condition button.
      2. In the Left operand and Right operand drop-down lists, specify the search parameters.

         Depending on the data source selected in the Right operand field, you may see fields of additional parameters that you need to use to define the value that will be passed to the filter. For example, when choosing active list you will need to specify the name of the active list, the entry key, and the entry key field.

      3. In the operator drop-down list, select the relevant operator.

         Filter operators

         • =—the left operand equals the right operand.
         • <—the left operand is less than the right operand.
         • <=—the left operand is less than or equal to the right operand.
         • >—the left operand is greater than the right operand.
         • >=—the left operand is greater than or equal to the right operand.
         • inSubnet—the left operand (IP address) is in the subnet of the right operand (subnet).
         • contains—the left operand contains values of the right operand.
         • startsWith—the left operand starts with one of the values of the right operand.
         • endsWith—the left operand ends with one of the values of the right operand.
         • match—the left operand matches the regular expression of the right operand. The RE2 regular expressions are used.
         • hasBit—checks whether the left operand (string or number) contains bits whose positions are listed in the right operand (in a constant or in a list).

           The value to be checked is converted to binary and processed right to left. Chars are checked whose index is specified as a constant or a list.

           If the value being checked is a string, then an attempt is made to convert it to integer and process it in the way described above. If the string cannot be converted to a number, the filter returns False.

         • hasVulnerability—checks whether the left operand contains an asset with the vulnerability and vulnerability severity specified in the right operand.

           If you do not specify the ID and severity of the vulnerability, the filter is triggered if the asset in the event being checked has any vulnerability.

         • inActiveList—this operator has only one operand. Its values are selected in the Key fields field and are compared with the entries in the active list selected from the Active List drop-down list.
         • inDictionary—checks whether the specified dictionary contains an entry defined by the key composed with the concatenated values of the selected event fields.
         • inCategory—the asset in the left operand is assigned at least one of the asset categories of the right operand.
         • inActiveDirectoryGroup—the Active Directory account in the left operand belongs to one of the Active Directory groups in the right operand.
         • TIDetect—this operator is used to find events using CyberTrace Threat Intelligence (TI) data. This operator can be used only on events that have completed enrichment with data from CyberTrace Threat Intelligence. In other words, it can only be used in collectors at the destination selection stage and in correlators.
         • inContextTable—presence of the entry in the specified context table.
         • intersect—presence in the left operand of the list items specified in the right operand.
      4. If necessary, select the do not match case check box. When this check box is selected, the operator ignores the case of the values.

         The selection of this check box does not apply to the InSubnet, InActiveList, InCategory or InActiveDirectoryGroup operators.

         This check box is cleared by default.

      5. If you want to add a negative condition, select If not from the If drop-down list.
      6. You can add multiple conditions or a group of conditions.
   5. If you have added multiple conditions or groups of conditions, choose a search condition (and, or, not) by clicking the AND button.
   6. If you want to add existing filters that are selected from the Select filter drop-down list, click the Add filter button.

      You can view the nested filter settings by clicking the button.

The new enrichment rule was added to the set of resources for the correlator.

Proceed to the next step of the Installation Wizard.

Step 5. Response

Expand all | Collapse all

This is an optional step of the Installation Wizard. On the Response tab of the Installation Wizard, you can select or create response rules and indicate which actions must be performed when the correlation rules are triggered. There can be multiple response rules. You can add them by clicking the Add button and can remove them by clicking the button.

To add an existing response rule to a set of resources:

1. Click Add.

   The response rule settings window opens.

2. In the Response rule drop-down list, select the relevant resource.

The response rule is added to the set of resources for the correlator.

To create a new response rule in a set of resources:

1. Click Add.

   The response rule settings window opens.

2. In the Response rule drop-down list, select Create new.
3. In the Type drop-down list, select the type of response rule and define its corresponding settings:
   • KSC response—response rules for automatically launching the tasks on Kaspersky Security Center assets. For example, you can configure automatic startup of a virus scan or database update.

     Tasks are automatically started when KUMA is integrated with Kaspersky Security Center. Tasks are run only on assets that were imported from Kaspersky Security Center.

     Response settings

     • Kaspersky Security Center task (required)—name of the Open Single Management Platform task that you want to start. Tasks must be created beforehand, and their names must begin with "KUMA ". For example, "KUMA antivirus check".

       Types of Open Single Management Platform tasks that can be started using KUMA:

       • Update
       • Virus scan
     • Event field (required)—defines the event field of the asset for which the Open Single Management Platform task must be started. Possible values:
       • SourceAssetID
       • DestinationAssetID
       • DeviceAssetID

     To send requests to Open Single Management Platform, you must make sure that the Open Single Management Platform is reachable over UDP.

   • Run script—response rules for automatically running a script. For example, you can create a script containing commands to be executed on the KUMA server when selected events are detected.

     The script file is stored on the server where the correlator service using the response resource is installed: /opt/kaspersky/kuma/correlator/<Correlator ID>/scripts.

     The kuma user of this server requires the permissions to run the script.

     Response settings

     • Timeout—the number of seconds the system will wait before running the script.
     • Script name (required)—the name of the script file.

       If the script Response resource is linked to the Correlator service, but the is no script file in the /opt/kaspersky/kuma/correlator/<Correlator ID>/scripts folder, the service will not start.

     • Script arguments—parameters or event field values that must be passed to the script.

       If the script includes actions taken on files, you should specify the absolute path to these files.

       Parameters can be written with quotation marks (").

       Event field names are passed in the {{.EventField}} format, where EventField is the name of the event field which value must be passed to the script.

       Example: -n "\"usr\": {{.SourceUserName}}"

   • KEDR response—response rules for automatically creating prevention rules, starting network isolation, or starting the application on Kaspersky Endpoint Detection and Response and Kaspersky Security Center assets.

     Automatic response actions are carried out when KUMA is integrated with Kaspersky Endpoint Detection and Response.

     Response settings

     • Event field (required)—event field containing the asset for which the response actions are needed. Possible values:
       • SourceAssetID
       • DestinationAssetID
       • DeviceAssetID
     • Task type—response action to be performed when data matching the filter is received. The following types of response actions are available:
       • Enable network isolation.

         When selecting this type of response, you need to define values for the following settings:

         • Isolation timeout—the number of hours during which the network isolation of an asset will be active. You can indicate from 1 to 9,999 hours.

           If necessary, you can add an exclusion for network isolation.

           To add an exclusion for network isolation:

           1. Click the Add exclusion button.
           2. Select the direction of network traffic that must not be blocked:
              • Inbound.
              • Outbound.
              • Inbound/Outbound.
           3. In the Asset IP field, enter the IP address of the asset whose network traffic must not be blocked.
           4. If you selected Inbound or Outbound, specify the connection ports in the Remote ports and Local ports fields.
           5. If you want to add more than one exclusion, click Add exclusion and repeat the steps to fill in the Traffic direction, Asset IP, Remote ports and Local ports fields.
           6. If you want to delete an exclusion, click the Delete button under the relevant exclusion.

           When adding exclusions to a network isolation rule, Kaspersky Endpoint Detection and Response may incorrectly display the port values in the rule details. This does not affect application performance. For more details on viewing a network isolation rule, please refer to the Kaspersky Anti Targeted Attack Platform Help Guide.

       • Disable network isolation.
       • Add prevention rule.

         When selecting this type of response, you need to define values for the following settings:

         • Event fields to extract hash from—event fields from which KUMA extracts SHA256 or MD5 hashes of the files that must be prevented from starting.

           The selected event fields and the values selected in the Event field must be added to the inherited fields of the correlation rule.

         • File hash #1—SHA256 or MD5 hash of the file to be blocked.

         At least one of the above fields must be completed.

       • Delete prevention rule.
       • Run program.

         When selecting this type of response, you need to define values for the following settings:

         • File path—path to the file of the process that you want to start.
         • Command line parameters—parameters with which you want to start the file.
         • Working directory—directory in which the file is located at the time of startup.

         When a response rule is triggered for users with the Main administrator role, the Run program task will be displayed in the Task manager section of the program web interface. Scheduled task is displayed for this task in the Created column of the task table. You can view task completion results.

         All of the listed operations can be performed on assets that have Kaspersky Endpoint Agent for Windows. On assets that have Kaspersky Endpoint Agent for Linux, the program can only be started.

         At the software level, the capability to create prevention rules and network isolation rules for assets with Kaspersky Endpoint Agent for Linux is unlimited. KUMA and Kaspersky Endpoint Detection and Response do not provide any notifications about unsuccessful application of these rules.

   • Response via KICS for Networks—response rules for automatically starting tasks on KICS for Networks assets. For example, you can change the asset status in KICS for Networks.

     Tasks are automatically started when KUMA is integrated with KICS for Networks.

     Response settings

     • Event field (required)—event field containing the asset for which the response actions are needed. Possible values:
       • SourceAssetID
       • DestinationAssetID
       • DeviceAssetID
     • KICS for Networks task—response action to be performed when data matching the filter is received. The following types of response actions are available:
       • Change asset status to Authorized.
       • Change asset status to Unauthorized.

       When a response rule is triggered, KUMA will send KICS for Networks an API request to change the status of the specified device to Authorized or Unauthorized.

   • Response via Active Directory—response rules for changing the permissions of Active Directory users. For example, block a user.

     Tasks are started if integration with Active Directory is configured.

     Response settings

     • Account ID source—event field, source of the Active Directory account ID value. Possible values:
       • SourceAccountID
       • DestinationAccountID
     • AD command—command that is applied to the account when the response rule is triggered. Available values:
       
       • Add account to group
       • Remove account from group
       • Reset account password
       • Block account

• In the Workers field, specify the number of processes that the service can run simultaneously.

  By default, the number of workers is the same as the number of virtual processors on the server where the service is installed.

  This field is optional.

1. In the Filter section, you can specify conditions to identify events that will be processed using the response rule. You can select an existing filter from the drop-down list or create a new filter.

   Creating a filter in resources

   1. In the Filter drop-down list, select Create new.
   2. If you want to keep the filter as a separate resource, select the Save filter check box.

      In this case, you will be able to use the created filter in various services.

      This check box is cleared by default.

   3. If you selected the Save filter check box, enter a name for the created filter resource in the Name field. The name must contain 1 to 128 Unicode characters.
   4. In the Conditions settings block, specify the conditions that the events must meet:
      1. Click the Add condition button.
      2. In the Left operand and Right operand drop-down lists, specify the search parameters.

         Depending on the data source selected in the Right operand field, you may see fields of additional parameters that you need to use to define the value that will be passed to the filter. For example, when choosing active list you will need to specify the name of the active list, the entry key, and the entry key field.

      3. In the operator drop-down list, select the relevant operator.

         Filter operators

         • =—the left operand equals the right operand.
         • <—the left operand is less than the right operand.
         • <=—the left operand is less than or equal to the right operand.
         • >—the left operand is greater than the right operand.
         • >=—the left operand is greater than or equal to the right operand.
         • inSubnet—the left operand (IP address) is in the subnet of the right operand (subnet).
         • contains—the left operand contains values of the right operand.
         • startsWith—the left operand starts with one of the values of the right operand.
         • endsWith—the left operand ends with one of the values of the right operand.
         • match—the left operand matches the regular expression of the right operand. The RE2 regular expressions are used.
         • hasBit—checks whether the left operand (string or number) contains bits whose positions are listed in the right operand (in a constant or in a list).

           The value to be checked is converted to binary and processed right to left. Chars are checked whose index is specified as a constant or a list.

           If the value being checked is a string, then an attempt is made to convert it to integer and process it in the way described above. If the string cannot be converted to a number, the filter returns False.

         • hasVulnerability—checks whether the left operand contains an asset with the vulnerability and vulnerability severity specified in the right operand.

           If you do not specify the ID and severity of the vulnerability, the filter is triggered if the asset in the event being checked has any vulnerability.

         • inActiveList—this operator has only one operand. Its values are selected in the Key fields field and are compared with the entries in the active list selected from the Active List drop-down list.
         • inDictionary—checks whether the specified dictionary contains an entry defined by the key composed with the concatenated values of the selected event fields.
         • inCategory—the asset in the left operand is assigned at least one of the asset categories of the right operand.
         • inActiveDirectoryGroup—the Active Directory account in the left operand belongs to one of the Active Directory groups in the right operand.
         • TIDetect—this operator is used to find events using CyberTrace Threat Intelligence (TI) data. This operator can be used only on events that have completed enrichment with data from CyberTrace Threat Intelligence. In other words, it can only be used in collectors at the destination selection stage and in correlators.
         • inContextTable—presence of the entry in the specified context table.
         • intersect—presence in the left operand of the list items specified in the right operand.
      4. If necessary, select the do not match case check box. When this check box is selected, the operator ignores the case of the values.

         The selection of this check box does not apply to the InSubnet, InActiveList, InCategory or InActiveDirectoryGroup operators.

         This check box is cleared by default.

      5. If you want to add a negative condition, select If not from the If drop-down list.
      6. You can add multiple conditions or a group of conditions.
   5. If you have added multiple conditions or groups of conditions, choose a search condition (and, or, not) by clicking the AND button.
   6. If you want to add existing filters that are selected from the Select filter drop-down list, click the Add filter button.

      You can view the nested filter settings by clicking the button.

The new response rule was added to the set of resources for the correlator.

Proceed to the next step of the Installation Wizard.

Step 6. Routing

This is an optional step of the Installation Wizard. On the Routing tab of the Installation Wizard, you can select or create destinations with settings indicating the forwarding destination of events created by the correlator. Events from a correlator are usually redirected to storage so that they can be saved and later viewed if necessary. Events can be sent to other locations as needed. There can be more than one destination point.

To add an existing destination to a set of resources for a correlator:

1. In the Add destination drop-down list, select the type of destination resource you want to add:
   • Select Storage if you want to configure forwarding of processed events to the storage.
   • Select Correlator if you want to configure forwarding of processed events to a correlator.
   • Select Other if you want to send events to other locations.

     This type of resource includes correlator and storage services that were created in previous versions of the program.

   The Add destination window opens where you can specify parameters for events forwarding.

2. In the Destination drop-down list, select the necessary destination.

   The window name changes to Edit destination, and it displays the settings of the selected resource. The resource can be opened for editing in a new browser tab by clicking the button.

3. Click Save.

The selected destination is displayed on the Installation Wizard tab. A destination resource can be removed from the resource set by selecting it and clicking Delete in the opened window.

To add a new destination to a set of resources for a correlator:

1. In the Add destination drop-down list, select the type of destination resource you want to add:
   • Select Storage if you want to configure forwarding of processed events to the storage.
   • Select Correlator if you want to configure forwarding of processed events to a correlator.
   • Select Other if you want to send events to other locations.

     This type of resource includes correlator and storage services that were created in previous versions of the program.

   The Add destination window opens where you can specify parameters for events forwarding.

2. Specify the settings on the Basic settings tab:
   • In the Destination drop-down list, select Create new.
   • In the Name field, enter a unique name for the destination resource. The name must contain 1 to 128 Unicode characters.
   • Click the Disabled toggle button to specify whether events will be sent to this destination. By default, sending events is enabled.
   • Select the Type for the destination resource:
     • Select storage if you want to configure forwarding of processed events to the storage.
     • Select correlator if you want to configure forwarding of processed events to a correlator.
     • Select nats-jetstream, tcp, http, kafka, or file if you want to configure sending events to other locations.
   • Specify the URL to which events should be sent in the hostname:<API port> format.

     You can specify multiple destination addresses by clicking the URL button for all types except nats-jetstream and file.

   • For the nats-jetstream and kafka types, use the Topic field to specify which topic the data should be written to. The topic must contain Unicode characters. The Kafka topic is limited to 255 characters.
3. If necessary, specify the settings on the Advanced settings tab. The available settings vary based on the selected destination resource type:
   • Compression is a drop-down list where you can enable Snappy compression. By default, compression is disabled.
   • Proxy is a drop-down list for proxy server selection.
   • The Buffer size field is used to set buffer size (in bytes) for the destination. The default value is 1 MB, and the maximum value is 64 MB.
   • Timeout field is used to set the timeout (in seconds) for another service or component response. The default value is 30.
   • Disk buffer size limit field is used to specify the size of the disk buffer in bytes. The default size is 10 GB.
   • Cluster ID is the ID of the NATS cluster.
   • TLS mode is a drop-down list where you can specify the conditions for using TLS encryption:
     • Disabled (default)—do not use TLS encryption.
     • Enabled—encryption is enabled, but without verification.
     • With verification—use encryption with verification that the certificate was signed with the KUMA root certificate. The root certificate and key of KUMA are created automatically during program installation and are stored on the KUMA Core server in the folder /opt/kaspersky/kuma/core/certificates/.

     When using TLS, it is impossible to specify an IP address as a URL.

   • URL selection policy is a drop-down list in which you can select a method for determining which URL to send events to if several URLs have been specified:
     • Any. Events are sent to one of the available URLs as long as this URL receives events. If the connection is broken (for example, the receiving node is disconnected) a different URL will be selected as the events destination.
     • Prefer first. Events are sent to the first URL in the list of added addresses. If it becomes unavailable, events are sent to the next available node in sequence. When the first URL becomes available again, events start to be sent to it again.
     • Balanced means that packages with events are evenly distributed among the available URLs from the list. Because packets are sent either on a destination buffer overflow or on the flush timer, this URL selection policy does not guarantee an equal distribution of events to destinations.
   • Delimiter is used to specify the character delimiting the events. By default, \n is used.
   • Path—the file path if the file destination type is selected.
   • Buffer flush interval—this field is used to set the time interval (in seconds) at which the data is sent to the destination. The default value is 100.
   • Workers—this field is used to set the number of services processing the queue. By default, this value is equal to the number of vCPUs of the KUMA Core server.
   • You can set health checks using the Health check path and Health check timeout fields. You can also disable health checks by selecting the Health Check Disabled check box.
   • Debug—a toggle switch that lets you specify whether resource logging must be enabled. By default, this toggle switch is in the Disabled position.
   • The Disk buffer disabled drop-down list is used to enable or disable the use of a disk buffer. By default, the disk buffer is disabled.
   • In the Filter section, you can specify the conditions to define events that will 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

     1. In the Filter drop-down list, select Create new.
     2. If you want to keep the filter as a separate resource, select the Save filter check box.

        In this case, you will be able to use the created filter in various services.

        This check box is cleared by default.

     3. If you selected the Save filter check box, enter a name for the created filter resource in the Name field. The name must contain 1 to 128 Unicode characters.
     4. In the Conditions settings block, specify the conditions that the events must meet:
        1. Click the Add condition button.
        2. In the Left operand and Right operand drop-down lists, specify the search parameters.

           Depending on the data source selected in the Right operand field, you may see fields of additional parameters that you need to use to define the value that will be passed to the filter. For example, when choosing active list you will need to specify the name of the active list, the entry key, and the entry key field.

        3. In the operator drop-down list, select the relevant operator.

           Filter operators

           • =—the left operand equals the right operand.
           • <—the left operand is less than the right operand.
           • <=—the left operand is less than or equal to the right operand.
           • >—the left operand is greater than the right operand.
           • >=—the left operand is greater than or equal to the right operand.
           • inSubnet—the left operand (IP address) is in the subnet of the right operand (subnet).
           • contains—the left operand contains values of the right operand.
           • startsWith—the left operand starts with one of the values of the right operand.
           • endsWith—the left operand ends with one of the values of the right operand.
           • match—the left operand matches the regular expression of the right operand. The RE2 regular expressions are used.
           • hasBit—checks whether the left operand (string or number) contains bits whose positions are listed in the right operand (in a constant or in a list).

             The value to be checked is converted to binary and processed right to left. Chars are checked whose index is specified as a constant or a list.

             If the value being checked is a string, then an attempt is made to convert it to integer and process it in the way described above. If the string cannot be converted to a number, the filter returns False.

           • hasVulnerability—checks whether the left operand contains an asset with the vulnerability and vulnerability severity specified in the right operand.

             If you do not specify the ID and severity of the vulnerability, the filter is triggered if the asset in the event being checked has any vulnerability.

           • inActiveList—this operator has only one operand. Its values are selected in the Key fields field and are compared with the entries in the active list selected from the Active List drop-down list.
           • inDictionary—checks whether the specified dictionary contains an entry defined by the key composed with the concatenated values of the selected event fields.
           • inCategory—the asset in the left operand is assigned at least one of the asset categories of the right operand.
           • inActiveDirectoryGroup—the Active Directory account in the left operand belongs to one of the Active Directory groups in the right operand.
           • TIDetect—this operator is used to find events using CyberTrace Threat Intelligence (TI) data. This operator can be used only on events that have completed enrichment with data from CyberTrace Threat Intelligence. In other words, it can only be used in collectors at the destination selection stage and in correlators.
           • inContextTable—presence of the entry in the specified context table.
           • intersect—presence in the left operand of the list items specified in the right operand.
        4. If necessary, select the do not match case check box. When this check box is selected, the operator ignores the case of the values.

           The selection of this check box does not apply to the InSubnet, InActiveList, InCategory or InActiveDirectoryGroup operators.

           This check box is cleared by default.

        5. If you want to add a negative condition, select If not from the If drop-down list.
        6. You can add multiple conditions or a group of conditions.
     5. If you have added multiple conditions or groups of conditions, choose a search condition (and, or, not) by clicking the AND button.
     6. If you want to add existing filters that are selected from the Select filter drop-down list, click the Add filter button.

        You can view the nested filter settings by clicking the button.

4. Click Save.

The created destination is displayed on the Installation Wizard tab. A destination resource can be removed from the resource set by selecting it and clicking Delete in the opened window.

Proceed to the next step of the Installation Wizard.

Step 7. Setup validation

This is the required, final step of the Installation Wizard. At this step, KUMA creates a service resource set, and the Services are created automatically based on this set:

• The set of resources for the correlator is displayed under Resources → Correlators. It can be used to create new correlator services. When this set of resources changes, all services that operate based on this set of resources will start using the new parameters after the services restart. To do so, you can click the Save and restart services and Save and update service configurations buttons.

  A set of resources can be modified, copied, moved from one folder to another, deleted, imported, and exported, like other resources.

• Services are displayed in Resources → Active services. The services created using the Installation Wizard perform functions inside the KUMA program. To communicate with external parts of the network infrastructure, you need to install similar external services on the servers and assets intended for them. For example, an external correlator service should be installed on a server intended to process events, external storage services should be installed on servers with a deployed ClickHouse service, and external agent services should be installed on Windows assets that must both receive and forward Windows events.

To finish the Installation Wizard:

1. Click Create and save service.

   The Setup validation tab of the Installation Wizard displays a table of services created based on the set of resources selected in the Installation Wizard. The lower part of the window shows examples of commands that you must use to install external equivalents of these services on their intended servers and assets.

   For example:

   /opt/kaspersky/kuma/kuma correlator --core https://kuma-example:<port used for communication with the KUMA Core> --id <service ID> --api.port <port used for communication with the service> --install

   The "kuma" file can be found inside the installer in the /kuma-ansible-installer/roles/kuma/files/ directory.

   The port for communication with the KUMA Core, the service ID, and the port for communication with the service are added to the command automatically. You should also ensure the network connectivity of the KUMA system and open the ports used by its components if necessary.

2. Close the Wizard by clicking Save.

The correlator service is created in KUMA. Now the equivalent service must be installed on the server intended for processing events.