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.