Starting the Correlator Installation Wizard

To start the Correlator Installation Wizard:

• In the KUMA web interface, under Resources, click Add correlator.
• In the KUMA web interface, 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 using 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 web interface 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 specify the general settings of the correlator:

1. On the Basic settings tab, fill in the following fields:
   • 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.
   • You can optionally add up to 256 Unicode characters describing the service in the Description field.
2. On the Advanced settings tab, fill in the following fields:
   • If necessary, use the Debug toggle switch to enable logging of service operations.
   • You can use the Create dump periodically toggle switch at the request of Technical Support to generate resource (CPU, RAM, etc.) utilization reports in the form of dumps.
   • In the Dump settings field, you can specify the settings to be used when creating dumps. The specifics of filling in this field must be provided by Technical Support.

General settings of the correlator are specified. 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.

  When entering functions, you can use autocomplete as a list of hints with possible function names, their brief description and usage examples. You can select a function from the list and insert it together with its list of arguments into the input field.

  To display the list of all hints in the field, press Ctrl+Space. Press Enter to select a function from the list. Press Tab to go to the next argument in the list of arguments of the selected 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 resource set 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 resource set 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 resource set.

Use 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. Using 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 resource set 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 resource set for the correlator and will be displayed in the rules table.

To create a new correlation rule in a resource set 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 resource set 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

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 resource set:

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 resource set for the correlator.

To create a new enrichment rule in a resource set:

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. 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 array extended schema 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.

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

       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—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.
     • 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 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,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.
     • When using cybertrace-http enrichment, POST lookup requests do not support the multi-tenancy mode.

     Available settings:

     • 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,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.
   • 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 toggle switch 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

   To create a filter:

   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. Maximum length of the name: 128 Unicode characters.
   4. Under Conditions, 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, fields of additional parameters for identifying the value to be passed to the filter may be displayed. For example, when you select active list, you must specify the name of the active list, the entry key, and the entry key field.
      3. In the operator drop-down list, select an 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 you want the operator to be case-insensitive, select the do not match case check box. 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.

      You can add multiple conditions or a group of conditions.

   5. If you have added multiple conditions or groups of conditions, choose a selection 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 resource set for the correlator.

Proceed to the next step of the Installation Wizard.

Step 5. Response

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 resource set:

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 resource set for the correlator.

To create a new response rule in a resource set:

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 Kaspersky Security Center task that you need to start. Tasks must be created beforehand, and their names must begin with "KUMA ". For example, "KUMA antivirus check".

       Types of Kaspersky Security Center tasks that can be started using KUMA:

       • Update
       • Virus scan
     • Event field (required)—defines the event field of the asset for which the Kaspersky Security Center task should be started. Possible values:
       • SourceAssetID
       • DestinationAssetID
       • DeviceAssetID

     To send requests to Kaspersky Security Center, you must ensure that Kaspersky Security Center is available over the UDP protocol.

   • 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 directory, 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 General Administrator role, the Run program task will be displayed in the Task manager section of the application 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 application 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/KATA—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/KATA 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/KATA 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. Possible 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

   To create a filter:

   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. Maximum length of the name: 128 Unicode characters.
   4. Under Conditions, 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, fields of additional parameters for identifying the value to be passed to the filter may be displayed. For example, when you select active list, you must specify the name of the active list, the entry key, and the entry key field.
      3. In the operator drop-down list, select an 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 you want the operator to be case-insensitive, select the do not match case check box. 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.

      You can add multiple conditions or a group of conditions.

   5. If you have added multiple conditions or groups of conditions, choose a selection 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 resource set 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 resource set 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 application.

   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 using 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 resource set 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 application.

   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.
   • Use 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 using 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 application installation and are stored on the KUMA Core server in /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

     To create a filter:

     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. Maximum length of the name: 128 Unicode characters.
     4. Under Conditions, 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, fields of additional parameters for identifying the value to be passed to the filter may be displayed. For example, when you select active list, you must specify the name of the active list, the entry key, and the entry key field.
        3. In the operator drop-down list, select an 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 you want the operator to be case-insensitive, select the do not match case check box. 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.

        You can add multiple conditions or a group of conditions.

     5. If you have added multiple conditions or groups of conditions, choose a selection 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 resource set for the correlator is displayed under Resources → Correlators. It can be used to create new correlator services. When this resource set changes, all services that operate based on this resource set will start using the new parameters after the services restart. To do so, you can use the Save and restart services and Save and update service configurations buttons.

  A resource set 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 application. 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 resource set 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 service must be installed on the server intended for processing events.