Contents
- Working with events
- Filtering and searching events
- Selecting Storage
- Generating an SQL query using a builder
- Manually creating an SQL query
- Filtering events by period
- Displaying names instead of IDs
- Presets
- Limiting the complexity of queries in alert investigation mode
- Saving and selecting events filter configuration
- Deleting event filter configurations
- Supported ClickHouse functions
- Viewing event detail areas
- Exporting events
- Configuring the table of events
- Refreshing events table
- Getting events table statistics
- Viewing correlation event details
- Filtering and searching events
Working with events
In the Events section of the KUMA web interface, you can inspect events received by the program to investigate security threats or create correlation rules. The events table displays the data received after the SQL query is executed.
Events can be sent to the correlator for a retroscan.
The event date format depends on the localization language selected in the application settings. Possible date format options:
- English localization: YYYY-MM-DD.
- Russian localization: DD.MM.YYYY.
Filtering and searching events
The Events section of the KUMA web interface does not show any data by default. To view events, you need to define an SQL query in the search field and click the button. The SQL query can be entered manually or it can be generated using a query builder.
Data aggregation and grouping is supported in SQL queries.
You can add filter conditions to an already generated SQL query in the window for viewing statistics, the events table, and the event details area:
- Changing a query from the Statistics window
- Changing a query from the events table
- Changing a query from the Event details area
After modifying a query, all query parameters, including the added filter conditions, are transferred to the query builder and the search field.
When you switch to the query builder, the parameters of a query entered manually in the search field are not transferred to the builder, so you will need to create your query again. Also, the query created in the builder does not overwrite the query that was entered into the search string until you click the Apply button in the builder window.
In the SQL query input field, you can enable the display of control characters.
You can also filter events by time period. Search results can be automatically updated.
The filter configuration can be saved. Existing filter configurations can be deleted.
Filter functions are available for users regardless of their roles.
When accessing certain event fields with IDs, KUMA returns the corresponding names.
For more details on SQL, refer to the ClickHouse documentation. See also KUMA operator usage and supported functions.
Selecting Storage
Events that are displayed in the Events section of the KUMA web interface are retrieved from storage (from the ClickHouse cluster). Depending on the demands of your company, you may have more than one Storage. However, you can only receive events from one Storage at a time, so you must specify which one you want to use.
To select the Storage you want to receive events from,
In the Events section of the KUMA web interface, open the drop-down list and select the relevant storage cluster.
Now events from the selected storage are displayed in the events table. The name of the selected storage is displayed in the drop-down list.
The drop-down list displays only the clusters of tenants available to the user, and the cluster of the main tenant.
Generating an SQL query using a builder
In KUMA, you can use a query builder to generate an SQL query for filtering events.
To generate an SQL query using a builder:
- In the Events section of the KUMA web interface, click the
button.
The filter constructor window opens.
- Generate a search query by providing data in the following parameter blocks:
SELECT—event fields that should be returned. The * value is selected by default, which means that all available event fields must be returned. To make viewing the search results easier, select the necessary fields in the drop-down list. In this case, the data only for the selected fields is displayed in the table. Note that Select * increases the duration of the request execution, but eliminates the need to manually indicate the fields in the request.
When selecting an event field, you can use the field on the right of the drop-down list to specify an alias for the column of displayed data, and you can use the right-most drop-down list to select the operation to perform on the data: count, max, min, avg, sum.
If you are using aggregation functions in a query, you cannot customize the events table display, sort events in ascending or descending order, or receive statistics.
When filtering by alert-related events in alert investigation mode, you cannot perform operations on the data of event fields or assign names to the columns of displayed data.
- FROM—data source. Select the events value.
- WHERE—conditions for filtering events.
Conditions and groups of conditions can be added by using the Add condition and Add group buttons. The AND operator value is selected by default in a group of conditions, but the operator can be changed by clicking on this value. Available values: AND, OR, NOT. The structure of conditions and condition groups can be changed by using the
icon to drag and drop expressions.
Adding filter conditions:
- In the drop-down list on the left, select the event field that you want to use for filtering.
- Select the necessary operator from the middle drop-down list. The available operators depend on the type of value of the selected event field.
- Enter the value of the condition. Depending on the selected type of field, you may have to manually enter the value, select it from the drop-down list, or select it on the calendar.
Filter conditions can be deleted by using the
button. Group conditions are deleted using the Delete group button.
- GROUP BY—event fields or aliases to be used for grouping the returned data.
If you are using data grouping in a query, you cannot customize the events table display, sort events in ascending or descending order, receive statistics, or perform a retroscan.
When filtering by alert-related events in alert investigation mode, you cannot group the returned data.
- ORDER BY—columns used as the basis for sorting the returned data. In the drop-down list on the right, you can select the necessary order: DESC—descending, ASC—ascending.
- LIMIT—number of strings displayed in the table.
The default value is 250.
If you are filtering events by user-defined period and the number of strings in the search results exceeds the defined value, you can click the Show next records button to display additional strings in the table. This button is not displayed when filtering events by the standard period.
- Click Apply.
The current SQL query will be overwritten. The generated SQL query is displayed in the search field.
If you want to reset the builder settings, click the Default query button.
If you want to close the builder without overwriting the existing query, click the
button.
- Click the
button to display the data in the table.
The table will display the search results based on the generated SQL query.
When switching to another section of the web interface, the query generated in the builder is not preserved. If you return to the Events section from another section, the builder will display the default query.
For more details on SQL, refer to the ClickHouse documentation. See also KUMA operator usage and supported functions.
Manually creating an SQL query
You can use the search string to manually create SQL queries of any complexity for filtering events.
To manually generate an SQL query:
- Go to the Events section of the KUMA web interface.
An input form opens.
- Enter your SQL query into the input field.
- Click the
button.
You will see a table of events that satisfy the criteria of your query. If necessary, you can filter events by period.
Supported functions and operators
SELECT
—event fields that should be returned.For
SELECT
fields, the program supports the following functions and operators:- Aggregation functions:
count, avg, max, min, sum
. - Arithmetic operators:
+, -, *, /, <, >, =, !=, >=, <=
.You can combine these functions and operators.
If you are using aggregation functions in a query, you cannot customize the events table display, sort events in ascending or descending order, or receive statistics.
- Aggregation functions:
DISTINCT
–removes duplicates from the result of a SELECT statement. You must use the following notation: SELECT DISTINCT SourceAddress as Addresses FROM <rest of the query
>.FROM
—data source.When creating a query, you need to specify the events value as the data source.
WHERE
—conditions for filtering events.AND, OR, NOT, =, !=, >, >=, <, <=
IN
BETWEEN
LIKE
ILIKE
inSubnet
match
(the re2 syntax of regular expressions is used in queries, special characters must be shielded with "\")
GROUP BY
—event fields or aliases to be used for grouping the returned data.If you are using data grouping in a query, you cannot customize the events table display, sort events in ascending or descending order, receive statistics, or perform a retroscan.
ORDER BY
—columns used as the basis for sorting the returned data.Possible values:
DESC
—descending order.ASC
—ascending order.
OFFSET
—skip the indicated number of lines before printing the query results output.LIMIT
—number of strings displayed in the table.The default value is 250.
If you are filtering events by user-defined period and the number of strings in the search results exceeds the defined value, you can click the Show next records button to display additional strings in the table. This button is not displayed when filtering events by the standard period.
Example queries:
SELECT * FROM `events` WHERE Type IN ('Base', 'Audit') ORDER BY Timestamp DESC LIMIT 250
In the events table, all events with the Base and Audit type are sorted by the Timestamp column in descending order. The number of strings that can be displayed in the table is 250.
SELECT * FROM `events` WHERE BytesIn BETWEEN 1000 AND 2000 ORDER BY Timestamp ASC LIMIT 250
All events of the events table for which the BytesIn field contains a value of received traffic in the range from 1,000 to 2,000 bytes are sorted by the Timestamp column in ascending order. The number of strings that can be displayed in the table is 250.
SELECT * FROM `events` WHERE Message LIKE '%ssh:%' ORDER BY Timestamp DESC LIMIT 250
In the events table, all events whose Message field contains data corresponding to the defined
%ssh:%
template in lowercase are sorted by the Timestamp column in descending order. The number of strings that can be displayed in the table is 250.SELECT * FROM `events` WHERE inSubnet(DeviceAddress, '00.0.0.0/00') ORDER BY Timestamp DESC LIMIT 250
In the events table, all events for the hosts that are in the 00.0.0.0/00 subnet are sorted by the Timestamp column in descending order. The number of strings that can be displayed in the table is 250.
SELECT * FROM `events` WHERE match(Message, 'ssh.*') ORDER BY Timestamp DESC LIMIT 250
In the events table, all events whose Message field contains text corresponding to the
ssh.*
template are sorted by the Timestamp column in descending order. The number of strings that can be displayed in the table is 250.SELECT max(BytesOut) / 1024 FROM `events`
Maximum amount of outbound traffic (KB) for the selected time period.
SELECT count(ID) AS "Count", SourcePort AS "Port" FROM `events` GROUP BY SourcePort ORDER BY Port ASC LIMIT 250
Number of events and port number. Events are grouped by port number and sorted by the Port column in ascending order. The number of strings that can be displayed in the table is 250.
The ID column in the events table is named Count, and the SourcePort column is named Port.
If you want to use a special character in a query, you need to escape this character by placing a backslash (\) character in front of it.
Example:
In the events table, all events whose Message field contains text corresponding to the |
When creating a normalizer for events, you can choose whether to retain the field values of the raw event. The data is stored in the Extra event field. This field is searched for events by using the LIKE operator.
Example:
In the events table, all events for hosts with the IP address 00.00.00.000 where the example process is running are sorted by the Timestamp column in descending order. The number of strings that can be displayed in the table is 250. |
When switching to the query builder, the query parameters that were manually entered into the search string are not transferred to the builder so you will need to create your query again. Also, the query created in the builder does not overwrite the query that was entered into the search string until you click the Apply button in the builder window.
Aliases must not contain spaces.
For more details on SQL, refer to the ClickHouse documentation. See also the supported ClickHouse functions.
Filtering events by period
In KUMA, you can specify the time period to display events from.
To filter events by period:
- In the Events section of the KUMA web interface, open the Period drop-down list in the upper part of the window.
- If you want to filter events based on a standard period, select one of the following:
- 5 minutes
- 15 minutes
- 1 hour
- 24 hours
- In period
If you select this option, use the opened calendar to select the start and end dates of the period and click Apply Filter. The date and time format depends on your operating system's settings. You can also manually change the date values if necessary.
- Click the
button.
When the period filter is set, only events registered during the specified time interval will be displayed. The period will be displayed in the upper part of the window.
You can also configure the display of events by using the events histogram that is displayed when you click the button in the upper part of the Events section. Events are displayed if you click the relevant data series or select the relevant time period and click the Show events button.
Displaying names instead of IDs
When accessing certain event fields with IDs, KUMA returns the corresponding names rather than IDs. This helps make the information more readable. For example, if you access the TenantID
event field (which stores the tenant ID), you get the value of the TenantName
event field (which stores the tenant name).
When exporting events, values of both fields are written to the file, the ID as well as the name.
The table below lists the fields that are substituted when accessed:
Requested field |
Returned field |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Substitution does not occur if an alias is assigned to the field in the SQL query. Examples:
SELECT TenantID FROM `events` LIMIT 250
— in the search result, the name of the tenant is displayed in the TenantID field.SELECT TenantID AS Tenant_name FROM `events` LIMIT 250
— in the search result, the tenant ID will be displayed in the Tenant_name field.
Presets
You can use
to simplify work with queries if you regularly view data for a specific set of event fields. In the line with the SQL query, you can typeSelect *
and select a saved preset; in that case, the output is limited only to the fields specified in the preset. This method slows down performance but eliminates the need to write a query manually every time. Presets are saved on the KUMA Core server and are available to all KUMA users of the specified tenant.
To create a preset:
- In the Events section, click the
icon.
- In the window that opens, on the Event field columns tab, select the required fields.
To simplify your search, you can start typing the field name in the Search area.
- To save the selected fields, click Save current preset.
The New preset window opens.
- In the window that opens, specify the Name of the preset, and in the drop-down list, select the Tenant.
- Click Save.
The preset is created and saved.
To apply a preset:
- In the query entry field, enter Select *.
- In the Events section of the KUMA web interface, click the
icon.
- In the opened window, use the Presets tab to select the relevant preset and click the
button.
The fields from the selected preset are added to the SQL query field, and the columns are added to the table. No changes are made in Builder.
- Click
to execute the query.
After the query execution completes, the columns are filled in.
Limiting the complexity of queries in alert investigation mode
When investigating an alert, the complexity of SQL queries for event filtering is limited if the Related to alert option is selected in the drop-down list. If this is the case, only the functions and operators listed below are available for event filtering.
If the All events option is selected from the drop-down list, these limitations are not applied.
SELECT
- The
*
character is used as a wildcard to represent any number of characters.
- The
WHERE
AND
,OR
,NOT
,=
,!=
,>
,>=
,<
,<=
IN
BETWEEN
LIKE
inSubnet
Examples:
WHERE Type IN ('Base', 'Correlated')
WHERE BytesIn BETWEEN 1000 AND 2000
WHERE Message LIKE '%ssh:%'
WHERE inSubnet(DeviceAddress, '10.0.0.1/24')
ORDER BY
Sorting can be done by column.
OFFSET
Skip the indicated number of lines before printing the query results output.
LIMIT
The default value is 250.
If you are filtering events by user-defined period and the number of strings in the search results exceeds the defined value, you can click the Show next records button to display additional strings in the table. This button is not displayed when filtering events by the standard period.
When filtering by alert-related events in alert investigation mode, you cannot group the returned data. When filtering by alert-related events in alert investigation mode, you cannot perform operations on the data of event fields or assign names to the columns of displayed data.
Page topSaving and selecting events filter configuration
In KUMA, you can save a filter configuration and use it in the future. Other users can also use the saved filters if they have the appropriate access rights. When saving a filter, you are saving the configured settings of all the active filters at the same time, including the time-based filter, query builder, and the events table settings. Search queries are saved on the KUMA Core server and are available to all KUMA users of the selected tenant.
To save the current settings of the filter, query, and period:
- In the Events section of the KUMA web interface, click the
icon next to the filter expression and select Save current filter.
- In the window that opens, enter the name of the filter configuration in the Name field. The name can contain up to 128 Unicode characters.
- In the Tenant drop-down list, select the tenant that will own the created filter.
- Click Save.
The filter configuration is now saved.
To select a previously saved filter configuration:
In the Events section of the KUMA web interface, click the icon next to the filter expression and select the relevant filter.
The selected configuration is active, which means that the search field is displaying the search query, and the upper part of the window is showing the configured settings for the period and frequency of updating the search results. Click the button to submit the search query.
You can click the icon near the filter configuration name to make it a default filter.
Deleting event filter configurations
To delete a previously saved filter configuration:
- In the Events section of the KUMA web interface, click the
icon next to the filter search query and click the
icon next to the configuration that you need to delete.
- Click OK.
The filter configuration is now deleted for all KUMA users.
Page topSupported ClickHouse functions
The following ClickHouse functions are supported in KUMA:
- Arithmetic functions.
- Arrays—all functions except:
- has
- range
- functions in which higher-order functions must be used (lambda expressions (->))
- Comparison functions: all operators except == and less.
- Logical functions: "not" function only.
- Type conversion functions.
- Date/time functions: all except date_add and date_sub.
- String functions.
- String search functions—all functions except:
- position
- multiSearchAllPositions, multiSearchAllPositionsUTF8, multiSearchFirstPosition, multiSearchFirstIndex, multiSearchAny
- like and ilike
- Conditional functions: simple if operator only (ternary if and miltif operators are not supported).
- Mathematical functions.
- Rounding functions.
- Functions for splitting and merging strings and arrays.
- Bit functions.
- Functions for working with UUIDs.
- Functions for working with URLs.
- Functions for working with IP addresses.
- Functions for working with Nullable arguments.
- Functions for working with geographic coordinates.
In KUMA 2.1.3, errors with the operation of the DISTINCT operator have been fixed. In this case, you must use the following notation: SELECT DISTINCT SourceAddress as Addresses FROM <rest of the query
>.
In KUMA 2.1.1, the SELECT DISTINCT SourceAddress / SELECT DISTINCT(SourceAddress) / SELECT DISTINCT ON (SourceAddress) operators work incorrectly.
Search and replace functions in strings, and functions from other sections are not supported.
For more details on SQL, refer to the ClickHouse documentation.
Page topViewing event detail areas
To view information about an event:
- In the program web interface window, select the Events section.
- Search for events by using the query builder or by entering a query in the search field.
The event table is displayed.
- Select the event whose information you want to view.
The event details window opens.
The Event details area appears in the right part of the web interface window and contains a list of the event's parameters with values. In this area you can:
- Include the selected field in the search or exclude it from the search by clicking
or
next to the setting value.
- Clicking a file hash in the FileHash field opens a list in which you can select one of the following actions:
- Show info from Threat Lookup.
This is available when integrated with Kaspersky Threat Intelligence Portal.
- Add to Internal TI of CyberTrace.
- This is available when integrated with Kaspersky CyberTrace.
- Show info from Threat Lookup.
- Open a window containing information about the asset if it is mentioned in the event fields and registered in the program.
- You can click the link containing the collector name in the Service field to view the settings of the service that registered the event.
You can also link an event to an alert if the program is in alert investigation mode and open the Correlation event details window if the selected event is a correlation event.
In the Event details area, the name of the described object is shown instead of its ID in the values of the following settings. At the same time, if you change the filtering of events by this setting (for example, by clicking ) to exclude events with a certain setting-value combination from search results), the object's ID, and not its name, is added to the SQL query:
- TenantID
- SeriviceID
- DeviceAssetID
- SourceAssetID
- DestinationAssetID
- SourceAccountID
- DestinationAccountID
Exporting events
In KUMA, you can export information about events to a TSV file. The selection of events that will be exported to a TSV file depends on filter settings. The information is exported from the columns that are currently displayed in the events table. The columns in the exported file are populated with the available data even if they did not display in the events table in the KUMA web interface due to the special features of the SQL query.
To export information about events:
- In the Events section of the KUMA web interface, open the
drop-down list and choose Export TSV.
The new export TSV file task is created in the Task manager section.
- Find the task you created in the Task manager section.
When the file is ready to download, the
icon will appear in the Status column of the task.
- Click the task type name and select Upload from the drop-down list.
The TSV file will be downloaded using your browser's settings. By default, the file name is event-export-<date>_<time>.tsv.
The file is saved based on your web browser's settings.
Page topConfiguring the table of events
Responses to user SQL queries are presented as a table in the Events section. The fields selected in the custom query appear at the end of the table, after the default columns. This table can be updated.
The following columns are displayed in the events table by default:
- Tenant.
- Timestamp.
- Name.
- DeviceProduct.
- DeviceVendor.
- DestinationAddress.
- DestinationUserName.
In KUMA, you can customize the displayed set of event fields and their display order. The selected configuration can be saved.
When using SQL queries with data grouping and aggregation for filtering events, statistics are not available and the order of displayed columns depends on the specific SQL query.
In the events table, in the event details area, in the alert window, and in the widgets, the names of assets, accounts, and services are displayed instead of the IDs as the values of the SourceAssetID, DestinationAssetID, DeviceAssetID, SourceAccountID, DestinationAccountID, and ServiceID fields. When exporting events to a file, the IDs are saved, but columns with names are added to the file. The IDs are also displayed when you point the mouse over the names of assets, accounts, or services.
Searching for fields with IDs is only possible using IDs.
To configure the fields displayed in the events table:
- Click the
icon in the top right corner of the events table.
You will see a window for selecting the event fields that should be displayed in the events table.
- Select the check boxes opposite the fields that you want to view in the table. You can search for relevant fields by using the Search field.
You can configure the table to display any event field from the KUMA event data model. The Timestamp and Name parameters are always displayed in the table. Click the Default button to display only default event parameters in the events table.
When you select a check box, the events table is updated and a new column is added. When a check box is cleared, the column disappears.
You can also remove columns from the events table by clicking the column title and selecting Hide column from the drop-down list.
- If necessary, change the display order of the columns by dragging the column headers in the event tables.
- If you want to sort the events by a specific column, click its title and in the drop-down list select one of the available options: Ascending or Descending.
The selected event fields will be displayed as columns in the table of the Events section in the order you specified.
Page topRefreshing events table
You can update the displayed event selection with the most recent entries by refreshing the web browser page. You can also refresh the events table automatically and set the frequency of updates. Automatic refresh is disabled by default.
To enable automatic refresh,
select the update frequency in the drop-down list:
- 5 seconds
- 15 seconds
- 30 seconds
- 1 minute
- 5 minutes
- 15 minutes
The events table now refreshes automatically.
To disable automatic refresh:
Select No refresh in the drop-down list:
Getting events table statistics
You can get statistics for the current events selection displayed in the events table. The selected events depend on the filter settings.
To obtain statistics:
Select Statistics from the drop-down list in the upper-right corner of the events table, or click on any value in the events table and select Statistics from the opened context menu.
The Statistics details area appears with the list of parameters from the current event selection. The numbers near each parameter indicate the number of events with that parameter in the selection. If a parameter is expanded, you can also see its five most frequently occurring values. Relevant parameters can be found by using the Search field.
In a fault-tolerant configuration, for all event fields that contain the FQDN of the Core, the Statistics section displays "core" instead of the FQDN.
The Statistics window allows you to modify the events filter.
When using SQL queries with data grouping and aggregation for filtering events, statistics are not available.
Page topViewing correlation event details
You can view the details of a correlation event in the Correlation event details window.
To view information about a correlation event:
- In the Events section of the KUMA web interface, click a correlation event.
You can use filters to find correlation events by assigning the
correlated
value to theType
parameter.The details area of the selected event will open. If the selected event is a correlation event, the Detailed view button will be displayed at the bottom of the details area.
- Click the Detailed view button.
The correlation event window will open. The event name is displayed in the upper left corner of the window.
The Correlation event details section of the correlation event window contains the following data:
- Correlation event severity—the importance of the correlation event.
- Correlation rule—the name of the correlation rule that triggered the creation of this correlation event. The rule name is represented as a link that can be used to open the settings of this correlation rule.
- Correlation rule severity—the importance of the correlation rule that triggered the correlation event.
- Correlation rule ID—the identifier of the correlation rule that triggered the creation of this correlation event.
- Tenant—the name of the tenant that owns the correlation event.
The Related events section of the correlation event window contains the table of events related to the correlation event. These are base events that actually triggered the creation of the correlation event. When an event is selected, the details area opens in the right part of the web interface window.
The Find in events link to the right of the section header is used for alert investigation.
The Related endpoints section of the correlation event window contains the table of hosts related to the correlation event. This information comes from the base events related to the correlation event. Clicking the name of the asset opens the Asset details window.
The Related users section of the correlation event window contains the table of users related to the correlation event. This information comes from the base events related to the correlation event.