KUMA resources

Expand all | Collapse all

Resources are KUMA components that contain parameters for implementing various functions: for example, establishing a connection with a given web address or converting data according to certain rules. Like parts of an erector set, these components are assembled into resource sets for services that are then used as the basis for creating KUMA services.

Resources are contained in the Resources section, Resources block of KUMA Console. The following resource types are available:

• Correlation rules—resources of this type contain rules for identifying event patterns that indicate threats. If the conditions specified in these resources are met, a correlation event is generated.
• Normalizers—resources of this type contain rules for converting incoming events into the format used by KUMA. After processing in the normalizer, the raw event becomes normalized and can be processed by other KUMA resources and services.
• Connectors—resources of this type contain settings for establishing network connections.
• Aggregation rules—resources of this type contain rules for combining several basic events of the same type into one aggregation event.
• Enrichment rules—resources of this type contain rules for supplementing events with information from third-party sources.
• Destinations—resources of this type contain settings for forwarding events to a destination for further processing or storage.
• Filters—resources of this type contain criteria for selecting individual events from the event stream to be sent to processing.
• Response rules—resources of this type are used in correlators to, for example, execute scripts or launch Open Single Management Platform tasks when certain conditions are met.
• Data collection and analysis rules—resources of this type contain rules that allow scheduling SQL queries with aggregation functions to the storage. Data received from SQL queries is then used for correlation.
• Notification templates—resources of this type are used when sending notifications about new alerts.
• Active lists—resources of this type are used by correlators for dynamic data processing when analyzing events according to correlation rules.
• Dictionaries—resources of this type are used to store keys and their values, which may be required by other KUMA resources and services.
• Proxies—resources of this type contain settings for using proxy servers.
• Secrets—resources of this type are used to securely store confidential information (such as credentials) that KUMA needs to interact with external services.

When you click on a resource type, a window opens displaying a table with the available resources of this type. The table contains the following columns:

• Name—the name of the resource. Can be used to search for resources and sort them.
• Updated—the date and time of the last update of a resource. Can be used to sort resources.
• Created by—the name of the user who created a resource.
• Description—the description of a resource.
• Type—the type of the resource. Displayed for all types of resources, except Aggregation rules, Enrichment rules, Data collection and analysis rules, Filters, Active lists, Proxies.
• Resource path—address in the resource tree. Displayed in the tree of folders, starting from the tenant in which the resource was created.
• Tags—tags assigned to the resource. A resource can have more than one tag.

  Tags are part of the resource and are imported with the resource.

• Package name—the name of the package in which the resource was imported from the repository.
• Correlator—the list of correlators to which the correlation rule is linked. Displayed only for resources of the Correlation rule type.

  For a rule that is not linked to any correlator, the column is blank. If the list contains multiple values, these values are sorted alphabetically. You can filter the values in the Correlator column by clicking the heading of the column and selecting the correlation rules that you want displayed in the table: Without correlator or With correlator.

  For rules of the Shared tenant, the correlators of tenants to which you have access and which you selected in the tenant list are displayed.

  Values in the Correlator column are not editable. If you want to perform actions on correlators, you need to click the rule in the table to open the properties of the rule, and go to the Correlators tab.

• MITRE techniques—the MITRE matrix techniques that this correlation rule covers. Displayed only for resources of the Correlation rule type. When you hover over a value, the name of the rule is displayed.

The maximum table size is not limited. If you want to select all resources, scroll to the end of the table and select the Select all check box, which selects all available resources in the table.

The table of resources in the lower part displays the number of resources from tenants that are available to you in the table:

• Total is the total amount or the amount with the filter or search applied.
• Selected is the number of selected resources.

When filters are applied, the resource selection and the Selected value are reset. If the amount of resources changes due to the actions (for example, deletion) undertake by another user, the displayed number of resources changes after you refresh the page, perform an action with the resource, or apply a filter.

Resources can be organized into folders. The folder structure is displayed in the left part of the window: root folders correspond to tenants and contain a list of all resources of the tenant. All other folders nested within the root folder display the resources of an individual folder. When a folder is selected, the resources it contains are displayed as a table in the right pane of the window.

Resources can be created, edited, copied, moved from one folder to another, and deleted. Resources can also be exported and imported.

KUMA comes with a set of predefined resources, which can be identified by the "[OOTB]<resource_name>" name. OOTB resources are protected from editing.

If you want to adapt a predefined OOTB resource to your organization's infrastructure:

1. In the Resources-<resource type> section, select the OOTB resource that you want to edit.
2. In the upper part of the KUMA Console, click Duplicate, then click Save.
3. A new resource named "[OOTB]<resource_name> - copy" is displayed in the web interface.
4. Edit the copy of the predefined resource as necessary and save your changes.

The adapted resource is available for use.

Operations with resources

To manage Kaspersky Unified Monitoring and Analysis Platform resources, you can create, move, copy, edit, delete, import, and export them. These operations are available for all resources, regardless of the resource type.

The table of resources in the lower part displays the number of resources from tenants that are available to you in the table:

• Total is the total amount or the amount with the filter or search applied.
• Selected is the number of selected resources.

When filters are applied, the resource selection and the Selected value are reset. If the amount of resources changes due to the actions (for example, deletion) undertake by another user, the displayed number of resources changes after you refresh the page, perform an action with the resource, or apply a filter.

Kaspersky Unified Monitoring and Analysis Platform resources are arranged in folders. You can add, rename, move, or delete resource folders.

Creating, renaming, moving, and deleting resource folders

Resources can be organized into folders. The folder structure is displayed in the left part of the window: root folders correspond to tenants and contain a list of all resources of the tenant. All other folders nested within the root folder display the resources of an individual folder. When a folder is selected, the resources it contains are displayed as a table in the right pane of the window.

You can create, rename, move and delete folders.

To create a folder:

1. Select the folder in the tree where the new folder is required.
2. Click the Add folder button.

The folder will be created.

To rename a folder:

1. Locate required folder in the folder structure.
2. Hover over the name of the folder.

   The icon will appear near the name of the folder.

3. Open the drop-down list and select Rename.

   The folder name will become active for editing.

4. Enter the new folder name and press ENTER.

   The folder name cannot be empty.

The folder will be renamed.

To move a folder,

Drag and drop the folder to a required place in folder structure by clicking its name.

Folders cannot be dragged from one tenant to another.

To delete a folder:

1. Select the relevant folder in the folder structure.
2. Right-click to bring up the context menu and select Delete.

   The conformation window appears.

3. Click OK.

The folder will be deleted.

The program does not delete folders that contain files or subfolders.

Creating, duplicating, moving, editing, and deleting resources

You can create, move, copy, edit, and delete resources.

To create the resource:

1. In the Resources → <resource type> section, select or create a folder where you want to add the new resource.

   Root folders correspond to tenants. For a resource to be available to a specific tenant, it must be created in the folder of that tenant.

2. Click the Add <resource type> button.

   The window for configuring the selected resource type opens. The available configuration parameters depend on the resource type.

3. Enter a unique resource name in the Name field.
4. Specify the required parameters (marked with a red asterisk).
5. If necessary, specify the optional parameters (not required).
6. Click Save.

The resource will be created and available for use in services and other resources.

To move the resource to a new folder:

1. In the Resources → <resource type> section, find the required resource in the folder structure.
2. Select the check box near the resource you want to move. You can select multiple resources.

   The icon appears near the selected resources. The number of selected resources is displayed in the lower part of the table.

3. Use the icon to drag and drop resources to the required folder.

The resources will be moved to the new folders.

You can only move resources to folders of the tenant in which the resources were created. Resources cannot be moved to another tenant's folders.

To copy the resource:

1. In the Resources → <resource type> section, find the required resource in the folder structure.
2. Select the check box next to the resource that you want to copy and click Duplicate.

   The number of selected resources is displayed in the lower part of the table.

   A window opens with the settings of the resource that you have selected for copying. The available configuration parameters depend on the resource type.

   The <selected resource name> - copy value is displayed in the Name field.

3. Make the necessary changes to the parameters.
4. Enter a unique name in the Name field.
5. Click Save.

The copy of the resource will be created.

To edit the resource:

1. In the Resources → <resource type> section, find the required resource in the folder structure.
2. Select the resource.

   A window with the settings of the selected resource opens. The available configuration parameters depend on the resource type.

3. Make the necessary changes to the parameters.
4. Do one of the following:
   • Click Save to save your changes.
   • Click Save with a comment, and in the displayed window, add a comment that describes your changes. The changes are saved and the comment is added to the created version of the resource.

The resource is updated and a new version is created for it. If this resource is used in a service, restart the service to apply the new version of the resource.

If the current resource is not editable (for example, you cannot edit a correlation rule), you can go to the card of another resource by clicking the View button. This button becomes available in batch resources when you click another resource linked to your current resource.

If, when saving changes to a resource, it turns out that the current version of the resource has been modified by another user, you are prompted to select one of the following actions:

• Save your changes as a new version of the resource on top of the changes made by the other user.
• Save your changes as a new resource.

  In this case, a duplicate of the original resource is created with the changed settings. The "- copy" string is added to the name of the new resource, and the name and version of the resource that was duplicated is specified in the version comments of the new resource.

• Discard your changes.

  Discarded changes cannot be restored.

To delete the resource:

1. In the Resources → <resource type> section, find the required resource in the folder structure.
2. Select the check box next to the resource that you want to delete and click Delete.

   The number of selected resources is displayed in the lower part of the table. A confirmation window opens.

3. Click OK.

The resource and all its saved versions are deleted.

Bulk deletion of resources

In the KUMA Console, you can select multiple resources and delete them.

You must have the right to delete resources.

To delete resources:

1. In the Resources → <resource type> section, find the required resource in the folder structure.
2. Select the check boxes next to the resources that you want to delete.

   In the lower part of the table, you can see the total number of resources and the number of resources selected.

3. Click Delete.

   This opens a window that tells you whether it is safe to delete resources, depending on whether the resources selected for deletion are linked to other resources.

   For all resources that cannot be deleted, the application displays a table of links in a modal window.

4. Click Delete.

   Only resources without links are deleted.

Deleting folders with resources

You can select the delete operation for any folder at any level, except the tenant.

To delete a folder with resources:

1. In the Resources section, select a folder.
2. Click the button and select the Delete option.

   This opens a window prompting you to confirm deletion. The window displays a field in which you can enter the generated value. Also, if dependent resources exist in the folder, a list of dependencies is displayed.

3. Enter the generated value.
4. Confirm the deletion.

You can delete a folder if:

• The folder does not contain any subfolders or resources.
• The folder does not contain any subfolders, but does contain unlinked resources.
• None of the resources in the folder are dependencies of anything (services, resources, integrations).

Link correlators to a correlation rule

The Link correlators option is available for the created correlation rules.

To link correlators:

1. In the KUMA web interface → Resources → Correlation rules section, select the created correlation rule and go to the Correlators tab.
2. This opens the Correlators window; in that window, select one or more correlators by selecting the check box next to them.
3. Click OK.

Correlators are linked to a correlation rule.

The rule is added to the end of the execution queue in each selected correlator. If you want to move the rule up in the execution queue, go to Resources → Correlators → <selected correlator> → Edit correlator → Correlation, select the check box next to the relevant rule and use the Move up or Move down buttons to reorder the rules as necessary.

Updating resources

Kaspersky regularly releases packages with resources that can be imported from the repository. You can specify an email address in the settings of the Repository update task. After the first execution of the task, KUMA starts sending notifications about the packages available for update to the specified address. You can update the repository, analyze the contents of each update, and decide if to import and deploy the new resources in the operating infrastructure. KUMA supports updates from Kaspersky servers and from custom sources, including offline update using the update mirror mechanism. If you have other Kaspersky products in the infrastructure, you can connect KUMA to existing update mirrors. The update subsystem expands KUMA capabilities to respond to the changes in the threat landscape and the infrastructure. The capability to use it without direct Internet access ensures the privacy of the data processed by the system.

To update resources, perform the following steps:

1. Update the repository to deliver the resource packages to the repository. The repository update is available in two modes:
   • Automatic update
   • Manual update
2. Import the resource packages from the updated repository into the tenant.

For the service to start using the resources, make sure that the updated resources are mapped after performing the import. If necessary, link the resources to collectors, correlators, or agents, and update the settings.

To enable automatic update:

1. In the Settings → Repository update section, configure the Data refresh interval in hours. The default value is 24 hours.
2. Specify the Update source. The following options are available:
   • Kaspersky update servers

     

     The servers are located in many countries around the world, which ensures the high reliability of the update. If the update cannot be performed from one server, KUMA switches to another server.

     .

     You can view the list of update servers in the Knowledge Base.

   • Custom source:
     • The URL to the shared folder on the HTTP server.
     • The full path to the local folder on the host where the KUMA Core is installed.

       If a local folder is used, the kuma system user must have read access to this folder and its contents.

3. If necessary, in the Proxy server list, select an existing proxy server to be used when running the Repository update task.

   You can also create a new proxy server by clicking on the button.

4. Specify the Emails for notification by clicking the Add button. The notifications that new packages or new versions of the packages imported into the tenant are available in the repository are sent to the specified email addresses.

   If you specify the email address of a KUMA user, the Receive email notifications check box must be selected in the user profile. For emails that do not belong to any KUMA user, the messages are received without additional settings. The settings for connecting to the SMTP server must be specified in all cases.

5. Click Save. The update task starts shortly. Then the task restarts according to the schedule.

To manually start the repository update:

1. To disable automatic updates, in the Settings → Repository update section, select the Disable automatic update check box. This check box is cleared by default. You can also start a manual repository update without disabling automatic update. Starting an update manually does not affect the automatic update schedule.
2. Specify the Update source. The following options are available:
   • Kaspersky update servers.
   • Custom source:
     • The URL to the shared folder on the HTTP server.
     • The full path to the local folder on the host where the KUMA Core is installed.

       If a local folder is used, the kuma user must have access to this folder and its contents.

3. If necessary, in the Proxy server list, select an existing proxy server to be used when running the Repository update task.

   You can also create a new proxy server by clicking on the button.

4. Specify the Emails for notification by clicking the Add button. The notifications that new packages or new versions of the packages imported into the tenant are available in the repository are sent to the specified email addresses.

   If you specify the email address of a KUMA user, the Receive email notifications check box must be selected in the user profile. For emails that do not belong to any KUMA user, the messages are received without additional settings. The settings for connecting to the SMTP server must be specified in all cases.

5. Click Run update. Thus, you simultaneously save the settings and manually start the Repository update task.

Configuring a custom source using Kaspersky Update Utility

You can update resources without Internet access by using a custom update source via the Kaspersky Update Utility.

Configuration consists of the following steps:

1. Configuring a custom source using Kaspersky Update Utility:
   1. Installing and configuring Kaspersky Update Utility on one of the computers in the corporate LAN.
   2. Configuring copying of updates to a shared folder in Kaspersky Update Utility settings.
2. Configuring update of the KUMA repository from a custom source.

Configuring a custom source using Kaspersky Update Utility:

You can download the Kaspersky Update Utility distribution kit from the Kaspersky Technical Support website.

1. In Kaspersky Update Utility, enable the download of updates for KUMA 2.1:
   • Under Applications – Perimeter control, select the check box next to KUMA 2.1 to enable the update capability.
   • If you work with Kaspersky Update Utility using the command line, add the following line to the [ComponentSettings] section of the updater.ini configuration file or specify the true value for an existing line:

     KasperskyUnifiedMonitoringAndAnalysisPlatform_3_4=true

2. In the Downloads section, specify the update source. By default, Kaspersky update servers are used as the update source.
3. In the Downloads section, in the Update folders group of settings, specify the shared folder for Kaspersky Update Utility to download updates to. The following options are available:
   • Specify the local folder on the host where Kaspersky Update Utility is installed. Deploy the HTTP server for distributing updates and publish the local folder on it. In KUMA, in the Settings → Repository update → Custom source section, specify the URL of the local folder published on the HTTP server.
   • Specify the local folder on the host where the Kaspersky Update Utility is installed. Make this local folder available over the network. Mount the network-accessible local folder on the host where KUMA is installed. In KUMA, in the Settings → Repository update → Custom source section, specify the full path to the local folder.

For detailed information about working with Kaspersky Update Utility, refer to the Kaspersky Knowledge Base.

Exporting resources

If shared resources are hidden for a user, the user cannot export shared resources or resources that use shared resources.

To export resources:

1. In the Resources section, click Export resources.

   The Export resources window opens with the tree of all available resources.

2. In the Password field enter the password that must be used to protect exported data.
3. In the Tenant drop-down list, select the tenant whose resources you want to export.
4. Check boxes near the resources you want to export.

   If selected resources are linked to other resources, linked resources will be exported, too. The number of selected resources is displayed in the lower part of the table.

5. Click the Export button.

Current versions of resources in a password-protected file are saved on your computer in accordance with your browser settings. Previous versions of the resources are saved in the file. The Secret resources are exported blank.

To export a previous version of a resource:

1. In the KUMA Console, in the Resources section, select the type of resources that you need.

   This opens a window opens with a table of available resources of this type.

   If you want to view all resources, in the Resources section, go to the List tab.

2. Select the check box for the resource whose change history you want to view, and click the Show version history button in the upper part of the table.

   This opens the window with the version history of the resource.

3. Click the row of the version that you want to export and click the Export button in the lower part of the displayed window.

   You can only export a previous version of a resource. The Export button is not displayed when the current version of the resource is selected.

The resource version is saved in a JSON file on your computer in accordance with your browser settings.

Importing resources

In KUMA 3.4, we recommended using resources from the "[OOTB] KUMA 3.4 resources" package and resources published in the repository after the release of this package.

To import resources:

1. In the Resources section, click Import resources.

   The Resource import window opens.

2. In the Tenant drop-down list, select the tenant to assign the imported resources to.
3. In the Import source drop-down list, select one of the following options:
   • File

     If you select this option, enter the password and click the Import button.

   • Repository

     If you select this option, a list of packages available for import is displayed. We recommend you to ensure that the repository update date is relatively recent and configure automatic updates if necessary.

     You can select one or more packages to import and click the Import button. The dependent resources of the Shared tenant are imported into the Shared tenant, the rest of the resources are imported into the selected tenant. You do not need special rights for the Shared tenant; you must only have the right to import in the selected tenant.

     Imported resources marked as "This resource is a part of the package. You can delete it, but it is impossible to edit." can only be deleted. To rename, edit or move an imported resource, make a copy of the resource using the Duplicate button and perform the desired actions with the resource copy. When importing future versions of the package, the duplicate is not updated because it is a separate object.

     Imported resources in the "Integration" directory can be edited; such resources are marked as "This resource is a part of the package". A Dictionary of the "Table" type can be added to the batch resource located in the "Integration" directory; adding other resources is not allowed. When importing future versions of the package, the edited resource will not be replaced with the corresponding resource from the package, which allows you to keep the changes you made.

4. Resolve the conflicts between the resources imported from the file and the existing resources if they occur. Read more about resource conflicts below.
   1. If the name, type, and guid of an imported resource fully match the name, type, and guid of an existing resource, the Conflicts window opens with the table displaying the type and the name of the conflicting resources. Resolve displayed conflicts:
      • To replace the existing resource with a new one, click Replace.

        To replace all conflicting resources, click Replace all.

      • To leave the existing resource, click Skip.

        For dependent resources, that is, resources that are associated with other resources, the Skip option is not available; you can only Replace dependent resources.

        To keep all existing resources, click Skip all.

   2. Click the Resolve button.

   The resources are imported to KUMA. The Secret resources are imported blank.

Importing resources that use the extended event schema

If you import a normalizer that uses one or more fields of the extended event schema, KUMA automatically creates an extended schema field that is used in the normalizer.

If you import other types of resources that use fields of the extended event schema in their logic, the resources are imported successfully. To make sure the imported resources work as intended, you need to create the corresponding extended schema fields in the Settings → Extended event schema fields section or import a normalizer that uses the required fields.

If a normalizer that uses an extended event schema field is imported into KUMA and the same field already exists in KUMA, the previously created field is used.

If a normalizer is imported into KUMA that uses an extended event schema field that does not meet the KUMA requirements, the import is completed, but the extended event schema field is created with the Disabled status and you cannot use this field in other normalizers and resources. An extended event schema field runs afoul of requirements if, for example, its name contains special characters or spaces. If you want to use such a field that does not meet the requirements, you need to fix its problems (for example, by renaming it) and then enable the field.

About conflict resolving

When resources are imported into KUMA from a file, they are compared with existing resources; the following parameters are compared:

• Name and kind. If an imported resource's name and kind parameters match those of the existing one, the imported resource's name is automatically changed.
• ID. If identifiers of two resources match, a conflict appears that must be resolved by the user. This could happen when you import resources to the same KUMA server from which they were exported.

When resolving a conflict you can choose either to replace existing resource with the imported one or to keep exiting resource, skipping the imported one.

In this case, if a conflict occurs, the imported resource is added as a new version of the existing resource. An "imported resource" comment is added to this version.

Some resources are linked: for example, in some types of connectors, the connector secret must be specified. The secrets are also imported if they are linked to a connector. Such linked resources are exported and imported together.

Special considerations of import:

1. Resources are imported to the selected tenant.
2. If a linked resource was in the Shared tenant, it ends up in the Shared tenant when imported.
3. In the Conflicts window, the Parent column always displays the top-most parent resource among those that were selected during import.
4. If a conflict occurs during import and you choose to replace existing resource with a new one, it would mean that all the other resources linked to the one being replaced are automatically replaced with the imported resources.

Known errors:

1. The linked resource ends up in the tenant specified during the import, and not in the Shared tenant, as indicated in the Conflicts window, under the following conditions:
   1. The linked resource is initially in the Shared tenant.
   2. In the Conflicts window, you select Skip for all parent objects of the linked resource from the Shared tenant.
   3. You leave the linked resource from the Shared tenant for replacement.
2. After importing, the categories do not have a tenant specified in the filter under the following conditions:
   1. The filter contains linked asset categories from different tenants.
   2. Asset category names are the same.
   3. You are importing this filter with linked asset categories to a new server.
3. In Tenant 1, the name of the asset category is duplicated under the following conditions:
   1. in Tenant 1, you have a filter with linked asset categories from Tenant 1 and the Shared tenant.
   2. The names of the linked asset categories are the same.
   3. You are importing such a filter from Tenant 1 to the Shared tenant.
4. You cannot import conflicting resources into the same tenant.

   The error "Unable to import conflicting resources into the same tenant" means that the imported package contains conflicting resources from different tenants and cannot be imported into the Shared tenant.

   Solution: Select a tenant other than Shared to import the package. In this case, during the import, resources originally located in the Shared tenant are imported into the Shared tenant, and resources from the other tenant are imported into the tenant selected during import.

5. Only the general administrator can import categories into the Shared tenant.

   The error "Only the general administrator can import categories into the Shared tenant" means that the imported package contains resources with linked shared asset categories. You can see the categories or resources with linked shared asset categories in the KUMA Core log. Path to the Core log:

   /opt/kaspersky/kuma/core/log/core

   Solution. Choose one of the following options:

   • Do not import resources to which shared categories are linked: clear the check boxes next to the relevant resources.
   • Perform the import under a General administrator account.
6. Only the general administrator can import resources into the Shared tenant.

   The error "Only the general administrator can import resources into the Shared tenant" means that the imported package contains resources with linked shared resources. You can see the resources with linked shared resources in the KUMA Core log. Path to the Core log:

   /opt/kaspersky/kuma/core/log/core

   Solution. Choose one of the following options:

   • Do not import resources that have linked resources from the Shared tenant, and the shared resources themselves: clear the check boxes next to the relevant resources.
   • Perform the import under a General administrator account.

Tag management

To help manage resources, the KUMA Console lets you add tags to resources. You can use tags to search for a component, as well as manage tags, link or unlink tags.

You cannot add tags to resources that are created from the interface of other resources. Tags can be added only from the resource's own card. You also cannot add tags to a resource that is not editable.

Tag management

The list of tags is displayed in the Settings → Tags section and is displayed as a table with the following columns: Name, Tenant, Used in resources.

In the Tags table, you can:

• Sort tags by Name, Used in resources fields.
• Filter by values of the Tenant field.
• Find a tag by the Name field.
• Go to the list of resources that have the selected tag.

Adding a tag

To add a tag:

1. Go to the Resources section and select a resource.
2. In the panel above the table, click Add.
3. In the Tags field of the selected resource, add a new tag, or select a tag from the list.
4. Click Create.

The new tag is added.

You can also add tags from existing ones.

When adding a tag, keep in mind the following special considerations:

• You can add multiple tags.
• A tag can contain characters of various alphabets (for example, Cyrillic, Latin, or Greek characters), numerals, underscores, and spaces.
• A tag may not contain any special characters other than the underscore and the space.
• You can enter the tag in uppercase or lowercase, but after saving, the tag is always displayed in lowercase.
• The tag inherits the tenant of the resource in which it is used.
• A tag is part of a resource and exists as long as the resource exists in which the tag was created or is used.
• Tags are unique within a tenant.
• Tags are imported or exported together with the resource as part of the resource.

Searching by tags

In the Resources section, you can search for resources:

• By tags
• By resource name

The search is performed across all resource types and services.

The search results display a list of resources and services.

To find resources by tags:

1. Go to the Resources section and select a resource.
2. In the table of the resource, select the Tags column.
3. In the Search field that is displayed, enter or select a tag name.

Displays a list of resources if the specified tag is used in those resources.

In the list of resources, you can:

• Sort the list by name and type of resource or service.
• Filter resources or services by resource or service type, or by tag.
• Link or unlink tags.

Linking and unlinking tags

To link tags to a resource or unlink tags from a resource:

1. Go to the Resources section.
2. Select the List tab.
3. In the Name column, select the check boxes next to the relevant resources.
4. In the panel above the list, select the Tags tab.
5. Click the Link or Unlink button and select the tags that you want to link or unlink.

The selected tags are linked to or unlinked from the resources.

Resource usage tracing

For stable operation of KUMA, it is important to understand how some resources affect the performance of other resources, what connections exist between resources and other KUMA objects. You can visualize these interdependencies on an interactive graph in the KUMA Console.

Displaying the links of a resource on a graph

To display the relations of the selected resource:

1. In the KUMA Console, in the Resources section, select a resource type.

   A list of resources of the selected type is displayed.

2. Select the resource that you need.

   The Show dependencies button in the panel above the list of resources becomes active. On a narrow display, the button may be hidden under the icon.

3. Click the Show dependencies button.

   This opens the a window with the dependency graph of the selected resource. If you do not have rights to view the resource, it is marked in the graph with the (inaccessible resource) icon. If necessary, you can close the graph window to go back to the list of resources.

Resource dependency graph

The graph displays all relations that are formed based on the universal unique identifier (UUID) of resources used in the configuration of the resource selected for display, as well as relations of resources that have the UUID of the selected resource in their configuration. Downward links, that is, resources referenced (used) by the selected resource, are displayed down to the last level, while for upward links, that is, resources that reference the selected resource, only one level is displayed.

On the graph, you can view the dependencies of the following resources:

• Correlation rules
• Aggregation rules
• Enrichment rules
• Response rules
• Data mining rules
• Normalizers
• Connectors
• Destinations
• Filters
• Notification templates
• Active lists
• Dictionaries
• Proxy servers
• Secrets
• Context tables
• Collectors

  Note that if a collector was initially selected for displaying links, "upward" links are not displayed.

• Correlators
• Storages
• Agents (autoagents)

  Note that if an agent is selected for displaying links, the collector is displayed with the linked relation type only if the collector is running as a service and in the collector is correctly (fqdn+port) specified as the destination of the agent.

• Event routers

  Note that if an event router was initially selected for displaying links, "upward" links are not displayed.

• Integrations

  The name of the integration corresponds to the name of the tab in the Integrations section.

• Resource group

  The number before the parentheses indicates the number of resources from the group displayed in the graph; the number in parentheses indicates the total number of resources in the group.

• Inaccessible resource (if you do not have the rights to view it).

Clicking a resource node lets you view the following information about the resource:

• Name

  Contains a link to the resource; clicking the link opens the resource in a separate tab; this does not close the graph window.

• Type
• Path

  Resource path without a link.

• Tags
• Tenant
• Package name

You can open the context menu of the resource and perform the following actions:

• Show relations of resource

  The dependencies of the selected resource are displayed.

• Hide resource on graph

  The selected resource is hidden. Resources at the lower level that the selected resource references are marked with "*" as having hidden links. Resources that refer to a hidden resource are marked with the icon as having hidden links. In this case, the graph becomes broken.

• Hide "downward" relations of resource on graph

  The selected resource remains. Only those lower-level resources that do not have any links remaining on the first higher level on the graph are hidden. Resources referenced by resources of the first (hidden) level are marked with "*" as having hidden links.

• Hide all resources of this type on graph

  All resources of the selected type are hidden. This operation is applied to each resource of the selected type.

• Update resource relations

  You can update the resource state if the resource was edited by another user while you were managing the graph. Only changes of visible links are displayed.

• Group

  If there is no group node on the screen: the group node appears on the screen, resources of the same type as the selected resource and resources that refer to the same resource are hidden. The edges are redrawn from the group. The Group button is available only when more than 10 links to resource of the same type exist.

  If there is a group node on the screen: the resource is hidden and added to the group, the edges are redrawn from the group.

Several types of relations are displayed on the graph:

• Solid line without a caption.

  Represents a direct link by UUID, including the use of secrets and proxies in integrations.

  

• Line captioned <function_name>.

  Represents using an active list in a correlation rule.

  

• Dotted line captioned linked.

  Represents a link by URL, for example, of a destination with a collector, or of a destination with a storage.

  

Resources created inline are shown on the graph as a dotted line with the linked type.

We do not recommend building large dependency graphs. We recommend limiting the number of nodes to 100 nodes.

When you open the graph, the resource selected for display is highlighted with a blinking circle for some time to set it apart graphically from other resources and draw attention to it.

You can look at the map of the graph to get an idea of where you are on the graph. You can use the selector and move it to display the necessary part of the graph.

By clicking the Arrange button, you can improve the display of resources on the graph.

If you select Show links, the focus on the graph does not change, and the resources are displayed so that you do not have to return to where you started.

When you select a group node in the graph, a sidebar is displayed, in which you can hide or show the resources that are part of the group. To do so, select the check box next to the relevant resource and click the Show on graph or Hide on graph button.

The graph retains its state if you displayed something on the graph, then switched to editing a resource, and then reopened the graph tab.

The previously displayed resources on the graph remain in their places when new resources are added to the graph.

When you close the graph, all changes are discarded.

After the resource links are drawn on the graph, you can search for a node:

• By name
• By tag
• By path
• By package

Nodes, including groups that match the selection criterion, are highlighted with a yellow circle.

You can filter the graph by resource type:

• Hide or show resources of a certain type.
• Hide resources of multiple types. Display all types of resources.

With the filter window closed, you can tell the selected filters by the indicator, a red dot in the toolbar.

Your actions when managing the graph (the last 50 actions) are saved in memory; you can undo changes by pressing Ctrl/Command+Z.

You can save the displayed graph can be saved to an SVG file. The visible part of the graph is saved in the file.

Resource versioning

KUMA stores the change history of resources in the form of versions. A resource version is created automatically when you create a new resource or save changes made to the settings of an existing resource.

The change history is not available for the Dictionaries resource. To save the history of dictionaries, you can export data.

Resource versions are retained for the duration specified in the Settings section. When the age of a resource version reaches the specified value, the version is automatically deleted.

You can view the change history of KUMA resources, compare versions, and restore a previous version of a resource, for example, if it fails and you need to recover it.

To view the change history of a resource:

1. In the KUMA Console, in the Resources section, select the type of resources that you need.

   This opens a window opens with a table of available resources of this type.

   If you want to view all resources, in the Resources section, go to the List tab.

2. Select the check box for the resource whose change history you want to view, and click the Show version history button in the upper part of the table.

This opens a window with a table of saved versions of the selected resource. New resources have only one version, the current version.

For each version, the table displays the following information:

• Version is the serial number of the resource version. When you save changes to the resource and create a new version, the serial number is increased by 1.

  The version with the highest number and the most recent publication date reflects the current state of the resource. Version 1 reflects the state of the resource at the moment when it was created.

• Published is the date and time when the resource version was created.
• Author is the login of the user that saved the changes to the resource.

  If the changes were made by the system or by the migration script, the displayed value is system.

• Comment is a text comment added by the author when saving changes, or a system comment describing the changes made.
• Retention period is the number of days and the date after which the resource version will be deleted.

  If necessary, you can configure the retention period for resource versions.

• Actions is the button that restores the resource version.

You can sort the table of resource versions by the Version, Published, and Author columns by clicking the heading and selecting Ascending or Descending. You can also display only changes made by a specific author or authors in the table by clicking the heading of the Author column and selecting the authors as needed.

If you want to view the status of a resource in a specific version, click that version in the table. This opens a window with the resource of the selected version, in which you can:

• View the settings specified in that version of the resource.
• Restore this version of the resource by clicking the Restore button.
• Export this version of the resource to a JSON file by clicking the Export button.

Comparing resource versions

You can compare any two versions of a resource, for example, if you need to track changes.

To compare versions of a resource:

1. In the KUMA Console, in the Resources section, select the type of resources that you need.

   This opens a window opens with a table of available resources of this type.

   If you want to view all resources, in the Resources section, go to the List tab.

2. Select the check box next to a resource and click the Show version history button in the upper part of the table.

   This opens the window with the version history of the resource.

3. Select the check boxes next to the two versions of the resource that you want to compare and click the Compare button in the upper part of the table.

This opens the resource version comparison window. Resource fields are displayed as a list or in JSON format. Differences between the two versions are highlighted. You can select other versions to compare using the drop-down lists above the resource fields.

Restoring a resource version

You can restore a previous version of a resource, for example, if you need to recover the resource in case of mistakes made when making changes.

Versions of automatically generated agents cannot be restored separately because they are created when the parent collector is modified. If you want to restore a version of an automatically generated agent, you need to restore the corresponding version of the parent collector.

To restore a previous version of a resource:

1. In the KUMA Console, in the Resources section, select the type of resources that you need.

   This opens a window opens with a table of available resources of this type.

   If you want to view all resources, in the Resources section, go to the List tab.

2. Select the check box next to a resource and click the Show version history button in the upper part of the table.

   This opens the window with the version history of the resource.

3. In the row of the relevant version, in the Action column, click the Restore button.

   You can also restore a version by clicking the row of this version and clicking the Restore button in the lower part of the window.

   You can restore only previous versions of a resource; for the current version, the Restore button is not available.

   If the structure of the resource has changed after a KUMA update, restoring its saved versions may not be possible.

4. Confirm the action and, if necessary, add a comment. If you do not add a comment, the "Restored from v.<number of the restored version>" comment is automatically added to the version.

The resource version is restored as a new version and become the current version.

If the resource for which you restored the version is added to the active service, this also changes the state of the service. You must restart the service to apply the resource change.

Configuring the retention period for resource versions

You can change the retention period of resource versions in the KUMA Console in the Settings → General section by changing the Resource history retention period, days setting.

The default setting is 30 days. If you want to keep all versions of resources without time limits, specify 0 (store indefinitely).

Only a user with the General administrator role can view and manage the retention period of resource versions.

The retention period of resource versions is checked daily, and versions of resources that have been stored in KUMA for longer than the specified period are automatically deleted. In the task manager, the Clear resource change history task is created to check the storage duration of resource versions and delete old versions. This task also runs after a restart of the Core component.

You can check the time remaining until a resource version is deleted in the table of versions, in the Retention period column.

Destinations

Destinations define network settings for sending normalized events. Collectors and correlators use destinations to describe where to send processed events. Typically, correlators and storages act as destinations.

You can specify destination point settings on the Basic settings and Advanced settings tabs. The available settings depend on the selected type of destination.

Destinations can have the following types:

• internal – Used for receiving data from KUMA services using the 'internal' protocol.
• nats-jetstream – Used for communication through NATS.
• tcp – Used for communication over TCP.
• http – Used for communication over the HTTP protocol.
• diode – Used to transmit events using a data diode.
• kafka – Used for kafka communications.
• file – Used for writing to a file.
• storage – Used for sending data to storage.
• correlator – Used for sending data to a correlator.
• eventRouter – Used for sending events to an event router.

Destination, internal type

Destinations of the internal typeUsed for receiving data from KUMA services using the 'internal' protocol. You can send the following data over the 'internal' protocol:

• Internal data, such as event routes.
• File attributes. If while creating the collector at the Transport step of the installation wizard, you specified a connector of the file, 1c-xml, or 1c-log type, at the Event parsing step, in the Mapping table, you can pass the name of the file being processed by the collector or the path to the file in the KUMA event field. To do this, in the Source column, specify one of the following values:
  • $kuma_fileSourceName to pass the name of the file being processed by the collector in the KUMA event field.
  • $kuma_fileSourcePath to pass the path to the file being processed by the collector in the KUMA event field.

  When you use a file, 1c-xml, or 1c-log connector, the new variables in the normalizer will only work with destinations of the internal type.

• Events to the event router. The event router can only receive events over the 'internal' protocol, therefore you can only use internal destinations when sending events to the event router.

Settings for a destination of the internal type are described in the following tables.

Basic settings tab

Advanced settings tab

Destination, type nats-jetstream

Expand all | Collapse all

Destinations of the nats-jetstream typeUsed for communication through NATS. Settings for a destination of the nats-jetstream type are described in the following tables.

Basic settings tab

Advanced settings tab

Destination, tcp type

Destinations of the tcp typeUsed for communication over TCP. Settings for a destination of the tcp type are described in the following tables.

Basic settings tab

Advanced settings tab

Destination, http type

Expand all | Collapse all

Destinations of the http typeUsed for communication over the HTTP protocol. Settings for a destination of the http type are described in the following tables.

Basic settings tab

Advanced settings tab

Destination, diode type

Expand all | Collapse all

Destinations of the diode typeUsed to transmit events using a data diode. Settings for a destination of the diode type are described in the following tables.

Basic settings tab

Advanced settings tab

Destination, kafka type

Expand all | Collapse all

Destinations of the kafka typeUsed for kafka communications. Settings for a destination of the kafka type are described in the following tables.

Basic settings tab

Advanced settings tab

Destination, file type

Destinations of the file typeUsed for writing to a file. Settings for a destination of the file type are described in the following tables.

When deleting a destination of the file type that is being used in a service, you must restart the service.

Basic settings tab

Advanced settings tab

Destination, storage type

Destinations of the storage typeUsed for sending data to storage. Settings for a destination of the storage type are described in the following tables.

Basic settings tab

Advanced settings tab

Destination, correlator type

Destinations of the correlator typeUsed for sending data to a correlator. Settings for a destination of the correlator type are described in the following tables.

Basic settings tab

Advanced settings tab

Destination, eventRouter type

Destinations of the eventRouter typeUsed for sending events to an event router. Settings for a destination of the eventRouter type are described in the following tables.

Basic settings tab

Advanced settings tab

Predefined destinations

Destinations listed in the table below are included in the KUMA distribution kit.

Predefined destinations

Normalizers

Normalizers are used for converting raw events that come from various sources in different formats to the KUMA event data model. Normalized events become available for processing by other KUMA resources and services.

A normalizer consists of the main event parsing rule and optional additional event parsing rules. By creating a main parsing rule and a set of additional parsing rules, you can implement complex event processing logic. Data is passed along the tree of parsing rules depending on the conditions specified in the Extra normalization conditions setting. The sequence in which parsing rules are created is significant: the event is processed sequentially and the processing sequence is indicated by arrows.

The following event normalization options are now available:

• 1 collector — 1 normalizer

  We recommend using this method if you have many events of the same type or many IP addresses from which events of the same type may originate. You can configure one collector with only one normalizer, which is optimal in terms of performance.

• 1 collector — multiple normalizers linked to IP

  This method is available for collectors with a connector of UDP, TCP, or HTTP type. If a UDP, TCP, or HTTP connector is specified in the collector at the 'Transport' step, then at the 'Event parsing' step, you can specify multiple IP addresses on the 'Parsing settings' tab and choose the normalizer that you want to use for events coming from the specified addresses. The following types of normalizers are available: json, cef, regexp, syslog, csv, kv, xml. For normalizers of the Syslog and regexp types, you can specify extra normalization conditions depending on the value of the DeviceProcessName field.

A normalizer is created in several steps:

1. Preparing to create a normalizer

   A normalizer can be created in the KUMA Console:

   • In the Resources → Normalizers section.
   • When creating a collector, at the Event parsing step.

   Then parsing rules must be created in the normalizer.

2. Creating the main parsing rule for an event

   The main parsing rule is created using the Add event parsing button. This opens the Event parsing window, where you can specify the settings of the main parsing rule:

   • Specify event parsing settings.
   • Specify event enrichment settings.

   The main parsing rule for an event is displayed in the normalizer as a dark circle. You can view or modify the settings of the main parsing rule by clicking this circle. When you hover the mouse over the circle, a plus sign is displayed. Click it to add the parsing rules.

   The name of the main parsing rule is used in KUMA as the normalizer name.

3. Creating additional event parsing rules

   Clicking the plus icon that is displayed when you hover the mouse over the circle or the block corresponding to the normalizer opens the Additional event parsing window where you can specify the settings of the additional parsing rule:

   • Specify the conditions for sending data to the new normalizer.
   • Specify event parsing settings.
   • Specify event enrichment settings.

   The additional event parsing rule is displayed in the normalizer as a dark block. The block displays the triggering conditions for the additional parsing rule, the name of the additional parsing rule, and the event field. When this event field is available, the data is passed to the normalizer. Click the block of the additional parsing rule to view or modify its settings.

   If you hover the mouse over the additional normalizer, a plus button appears. You can use this button to create a new additional event parsing rule. To delete a normalizer, use the button with the trash icon.

4. Completing the creation of the normalizer

   To finish the creation of the normalizer, click Save.

In the upper right corner, in the search field, you can search for additional parsing rules by name.

For normalizer resources, you can enable the display of control characters in all input fields except the Description field.

If, when changing the settings of a collector resource set, you change or delete conversions in a normalizer connected to it, the edits will not be saved, and the normalizer itself may be corrupted. If you need to modify conversions in a normalizer that is already part of a service, the changes must be made directly to the normalizer under Resources → Normalizers in the web interface.

Event parsing settings

Expand all | Collapse all

You can configure the rules for converting incoming events to the KUMA format when creating event parsing rules in the normalizer settings window, on the Normalization scheme tab. Available event parsing settings are listed in the table below.

When normalizing events, you can use extended event schema fields in addition to standard KUMA event schema fields.

Available event parsing settings

Extended event schema

You can use the extended event schema fields in normalizers for normalizing events and in other KUMA resources, for example, as widget fields or to filter and search for events. You can view the list of all extended event schema fields that exist in KUMA in the Settings → Extended event schema fields section. The list of extended event schema fields is the same for all tenants.

Only users with the General administrator, Tenant administrator, Tier 2 analyst, Tier 1 analyst, Junior analyst, Read shared resources, and Manage shared resources roles can view the table of extended event schema fields.

The Extended event schema fields table contains the following information:

• Type—Data type of the extended event schema field.

  Possible data types:

  Type	Data type
  S	String.
  N	Number.
  F	Floating point number.
  SA	Array of strings. The order of the array elements is the same as the order of the elements of the raw event.
  NA	Array of integers. The order of the array elements is the same as the order of the elements of the raw event.
  FA	Array of floats. The order of the array elements is the same as the order of the elements of the raw event.

• Field name—Name of the extended event schema field, without a type.

  You can click the name to edit the settings of the extended event schema field.

• Status—Whether the extended event schema field can be used in resources.

  You can Enable or Disable the toggle switch to allow or forbid using this extended event schema field in new resources. However, a disabled field is still used in resource configurations that are already operational, until you manually remove the field from the configuration; the field also remains available in the list of table columns in the Events section for managing old events.

  Only a user with the General administrator role can disable an extended event schema field.

• Update date—Date and time of the last modification of the extended event schema field.
• Created by—Name of the user that created the extended event schema field.
• Dependencies—Number of KUMA resources, dashboard layouts, reports, presets, and field sets for searching event sources that use the extended event schema field.

  You can click the number to open a pane with a table of all resources and other KUMA entities that are using this field. For each dependency, the table displays the name, tenant (only for resources), and type. Dependencies in the table are sorted by name. Clicking the name of a dependency takes you to its page (except for dashboard layouts, presets, and saved user queries).

  You can view the dependencies of an extended event schema field only for resources and entities to whose tenants you have access. If you do not have access to the tenant, its resources are not displayed in the table, but still count towards the number of dependencies.

• Description—Text description of the field.

By default, the table of extended event schema fields is sorted by update date in descending order. If necessary, you can sort the table by clicking a column heading and selecting Ascending or Descending; you can also use context search by field name.

By default, the following service extended event schema fields are automatically added to KUMA:

• KL_EventRoute, type S for storing information about the route of the event.

  You can use this field in normalizers, as a key or value in active lists, in enrichment rules, as a query field in data collection and analysis rules, in correlation rules. You cannot use this field to detect event sources.

• The following fields are added to a correlation event:
  • KL_CorrelationRulePriority, type N
  • KL_SourceAssetDisplayName, type S
  • KL_DestinationAssetDisplayName, type S
  • KL_DeviceAssetDisplayName, type S
  • KL_SourceAccountDisplayName, type S
  • KL_DestinationAccountDisplayName, type S

  You cannot use this service fields to search for events.

You cannot edit, delete, export, or disable service fields. All extended event schema fields with the KL_ prefix are service fields and can be managed only from Kaspersky servers. We do not recommend using the KL_ prefix when adding new extended event schema fields.

Adding extended event schema fields

Users with the General administrator, Tenant administrator, Tier 2 analyst, Tier 1 analyst, Junior analyst, Manage shared resources roles can add new extended event schema fields.

To add an extended event schema field:

1. In the KUMA Console, in the Settings → Extended event schema fields section, click the Add button in the upper part of the table.

   This opens the Create extended schema pane.

2. Enable or disable the Status toggle switch to enable or disable this extended event schema field for resources.

   The toggle switch is turned on by default. A disabled field remains available in the list of table columns in the Events section for managing old events.

3. In the Type field, select the data type of the extended event schema field.

   Possible data types

   Type	Data type
   S	String.
   N	Number.
   F	Floating point number.
   SA	Array of strings. The order of the array elements is the same as the order of the elements of the raw event.
   NA	Array of integers. The order of the array elements is the same as the order of the elements of the raw event.
   FA	Array of floats. The order of the array elements is the same as the order of the elements of the raw event.

4. In the Name field, specify the name of the extended event schema field.

   Consider the following when naming extended event schema fields:

   • The name must be unique within the KUMA instance.
   • Names are case-sensitive. For example, Field_name and field_name are different names.
   • You can use Latin, Cyrillic characters and numerals. Spaces or " ~ ` @ # $ % ^ & * ( ) + - [ ] { } | \ | / . " < > ; ! , : ? = characters are not allowed.
   • If you want to use the extended event schema fields to search for event sources, you can only use Latin characters and numerals.
   • The maximum length is 128 characters.
5. If necessary, in the Description field, enter a description for the extended event schema field.

   We recommend describing the purpose of the extended event schema field. Only Unicode characters are allowed in the description. The maximum length is 256 characters.

6. Click the Save button.

A new extended event schema field is added and displayed at the top of the table. An audit event is generated for the creation of the extended event schema field. If you have enabled the field, you can use it in normalizers and when configuring resources.

Editing extended event schema fields

Users with the General administrator, Tenant administrator, Tier 2 analyst, Tier 1 analyst, Junior analyst, Manage shared resources roles can edit existing extended event schema fields.

To edit an extended event schema field:

1. In the KUMA Console, in the Settings → Extended event schema fields section, click the name of the field that you want to edit.

   This opens the Edit extended schema pane. This pane displays the settings of the selected field, as well as the Dependencies table with a list of resources, dashboard layouts, reports, presets, and sets of fields for finding event sources that use this field. Only resources to whose tenants you have access are displayed. If the field is used by resources to whose tenant you do not have access, such resources are not displayed in the table. Resources in the table are sorted by name.

   Clicking the name of a resource or entity takes you to its page (except for dashboard resources, presets, and saved user queries).

2. Make the changes you need in the available settings.

   You can edit the Type and Field name settings only if the extended event schema field does not have dependencies. You can edit the Status and Description settings for any extended event scheme field. However, a field with the Disabled status is still used in resource configurations that are already operational, until you manually remove the field from the configuration; the field also remains available in the list of table columns in the Events section for managing old events.

   Disabling an extended event schema field using the Status field requires the General administrator role.

3. Click the Save button.

The extended event schema field is updated. An audit event is generated about the modification of the field.

Importing and exporting extended event schema fields

You can add multiple new extended event schema fields at once by importing them from a JSON file. You can also export all extended event schema fields with information about them to a file, for example, to propagate the list of fields to other KUMA instances to maintain resources.

Users with the General administrator, Tenant administrator, Tier 2 analyst, Tier 1 analyst, Junior analyst, and Manage shared resources roles can import an export extended event schema fields. Users with the Read shared resources role can only export extended event schema fields.

To import extended event schema fields into KUMA from a file:

1. In the KUMA Console, in the Settings → Extended event schema fields section, click the Import button.
2. This opens a window; in that window, select a JSON file with a list of extended event schema field objects.

   Example JSON file:

   [ {"kind": "SA", "name": "<fieldName1>", "description": "<description1>", "disabled": false}, {"kind": "N", "name": "<fieldName2>", "description": "<description2>", "disabled": false}, .... {"kind": "FA", "name": "<fieldNameX>", "description": "<descriptionX>", "disabled": false} ]

   When importing fields from a file, their names are checked for possible conflicts with fields of the same type. If a field with the same name and type already exists in KUMA, such fields are not imported from the file.

Extended event schema fields are imported from the file to KUMA. An audit event about the import of fields is generated, and a separate audit event is generated for each added field.

To export extended event schema fields to a file:

1. In the KUMA Console, go to the Settings → Extended event schema fields section.
2. If you want to export specific extended event schema fields:
   1. Select the check boxes in the first column of the table for the required fields.

      You cannot select service fields.

   2. Click the Export selected button in the upper part of the table.
3. If you want to export all extended event schema fields, click the Export all button in the upper part of the table.

A JSON file with a list of extended event schema field objects and information about them is downloaded.

Deleting extended event schema fields

Only a user with the General administrator role can delete extended event schema fields.

You can delete only those extended event schema fields that are not service fields, that have the Disabled status, and that are not used in KUMA resources and other entities (do not have dependencies). We recommend deleting extended event schema fields after enough time has passed to make sure that all events in which the field was used have been deleted from KUMA. When you delete a field, it is no longer displayed in event tips.

To delete extended event schema fields:

1. In the KUMA Console, go to the Settings → Extended event schema fields section.
2. Select the check boxes in the first column of the table next to one or more fields that you want to delete.

   To select all fields, you can select the check box in the heading of the first column.

3. Click the Delete button in the upper part of the table.

   The Delete button is active only if all selected fields are disabled and have no dependencies. If at least one field is enabled or has a dependency, the button is inactive.

   If you want to delete a field that is used in at least one KUMA resource (has a dependency), but you do not have access to its tenant, the Delete button is active when this field is selected, but an error is displayed when you try to delete it.

The selected fields are deleted. An audit event is generated about the deletion of the fields.

Using extended event schema fields in normalizers

When using extended event schema fields, the general limit for the maximum size of an event that can be processed by the collector is the same, 4 MB. Information about the types of extended event schema fields is shown in the table below (step 6 of the instructions).

Using many unique fields of the extended event schema can reduce the performance of the system, increase the amount of disk space required for storing events, and make the information difficult to understand.

We recommend consciously choosing a minimal set of additional fields of the extended event schema that you want to use in normalizers and correlation.

To use the fields of the extended event schema:

1. Open an existing normalizer or create a new normalizer.
2. Specify the basic settings of the normalizer.
3. Click Add row.
4. For the Source setting, enter the name of the source field in the raw event.
5. For the KUMA field setting, start typing the name of the extended event schema field and select the field from the drop-down list.

   The extended event schema fields in the drop-down list have names in the <type>.<field name> format.

6. Click the Save button to save the event normalizer.

The normalizer is saved with the selected extended event schema field.

If the data in the fields of the raw event does not match the type of the KUMA field, the value is not saved during the normalization of events if type conversion cannot be performed. For example, the string test cannot be written to the DeviceCustomNumber1 KUMA field of the Number type.

If you want to minimize the load on the storage server when searching events, preparing reports, and performing other operations on events in storage, use KUMA event schema fields as your first preference, extended event schema fields as your second preference, and the Extra fields as your last resort.

Enrichment in the normalizer

Expand all | Collapse all

When creating event parsing rules in the normalizer settings window, on the Enrichment tab, you can configure the rules for adding extra data to the fields of the normalized event using enrichment rules. Enrichment rules are stored in the settings of the normalizer where they were created.

You can create enrichment rules by clicking the Add enrichment button. To delete an enrichment rule, click next to it. Extended event schema fields can be used for event enrichment. Available enrichment rule settings are listed in the table below.

Available enrichment rule settings

Conditions for forwarding data to an extra normalizer

When creating additional event parsing rules, you can specify the conditions. When these conditions are met, the events are sent to the created parsing rule for processing. Conditions can be specified in the Additional event parsing window, on the Extra normalization conditions tab. This tab is not available for the basic parsing rules.

Available settings:

• Use raw event — If you want to send a raw event for extra normalization, select Yes in the Keep raw event drop-down list. The default value is No. We recommend passing a raw event to normalizers of json and xml types. If you want to send a raw event for extra normalization to the second, third, etc nesting levels, at each nesting level, select Yes in the Keep raw event drop-down list.
• Field to pass into normalizer—indicates the event field if you want only events with fields configured in normalizer settings to be sent for additional parsing.

  If this field is blank, the full event is sent to the extra normalizer for processing.

• Set of filters—used to define complex conditions that must be met by the events received by the normalizer.

  You can use the Add condition button to add a string containing fields for identifying the condition (see below).

  You can use the Add group button to add a group of filters. Group operators can be switched between AND, OR, and NOT. You can add other condition groups and individual conditions to filter groups.

  You can swap conditions and condition groups by dragging them by the icon; you can also delete them using the icon.

Filter condition settings:

• Left operand and Right operand—used to specify the values to be processed by the operator.

  In the left operand, you must specify the source field of events coming into the normalizer. For example, if the eventType - DeviceEventClass mapping is configured in the Basic event parsing window, then in the Additional event parsing window on the Extra normalization conditions tab, you must specify eventType in the left operand field of the filter. Data is processed only as text strings.

• Operators:
  • = – full match of the left and right operands.
  • startsWith – the left operand starts with the characters specified in the right operand.
  • endsWith – the left operand ends with the characters specified in the right operand.
  • match – the left operand matches the regular expression (RE2) specified in the right operand.
  • in – the left operand matches one of the values specified in the right operand.

The incoming data can be converted by clicking the button. The Conversion window opens, where you can use the Add conversion button to create the rules for converting the source data before any actions are performed on them. In the Conversion window, you can swap the added rules by dragging them by the icon; you can also delete them using the icon.

Available conversions

Supported event sources

KUMA supports the normalization of events coming from systems listed in the "Supported event sources" table. Normalizers for these systems are included in the distribution kit.

Supported event sources