General information

The Analytics section provides the functionality of a SIEM system, or security information and event management system. With UserGate SIEM, you can analyze security event logs received from the configured sensors such as UserGate NGFWs, UserGate Client endpoints, third-party network devices that support SNMP communication, and WMI sensors. All data is stored in a single database, making it possible to perform complex searches, correlate repetitive events, aggregate them into security incidents, and simplify the process of incident investigation.

The basic unit of incoming information for UserGate SIEM is an event. An Event is a single log record, e.g., a single instance of an IDPS rule triggered on a UserGate NGFW, blocked access to a prohibited resource (triggering of a blocking content filtering rule), successful or failed attempt to access the management console, or other similar occurrences recorded on devices connected to UserGate SIEM. While an individual event may not provide sufficient information about a security threat, multiple events of the same type (e.g., failed attempts to access the management console) or dissimilar events recorded in a specific sequence and coming from different sources can be useful for identifying a threat. This process is called event correlation. A group of events combined under an analytics (correlation) rule is called a Triggered alert. A security engineer analyzes the triggered alert, examines the events that caused the alert and can, if necessary, create a security Incident based on one or multiple triggered alerts.

Using analytics rules, the security engineer can automate the process of event correlation and triggered alert generation as well as assign certain Response actions to the generated triggered alerts. All of this makes it easier to investigate logged events and contributes to reducing the time between problem detection and resolution.

The analytics settings are located in the Analytics tab where you can configure analytics rules, create response actions, and view the rule log and triggered alert details.

These features will be discussed in the next sections, Response Actions, Triggered Alerts, and Triggered Alert Details.

The Analytics rules tab allows you to create log event processing rules. By configuring analytics rules, you can perform complex searches on cybersecurity events. The rule is triggered when events from different sources are found to be correlated. Rules can function in two modes: historical (analyze events for the selected time period) and real-time.

To create a rule, click Add. Then go to the General tab, and specify the rule's properties.

Name

Description

Enabled

Enables or disables applying the analytics rule in real time.

Name

The name of the analytics rule.

Description

A description of the analytics rule. This field is optional.

Threat level

The threat level that will be displayed when the rule is triggered.

The following threat levels are defined:

  • Very low: the events present a very low threat level, and the administrator may choose not to take any action.

  • Low: the events present a low threat level, and the administrator may choose not to take any action.

  • Medium: the events require attention.

  • High: the events require investigation and response.

  • Very high: the events require investigation and urgent response.

Priority

The priority assigned to triggered alerts for this analytics rule:

  • Low: low response priority.

  • Normal: needs attention and may need response.

  • Important: needs attention and response.

  • Critical: requires urgent response.

When the analytics rule is triggered, the priority will indicate the severity of the triggered alert.

Category

The category to which the triggered alert belongs.

The following predefined categories are available:

  • Security: incidents that degrade the security of information systems.

  • Availability: incidents that degrade the availability of information systems.

  • Performance: incidents that degrade the performance of information systems.

Additional triggered alert categories can be created in the Libraries ➜ Triggered alert categories section of the General settings tab.

Timezone

The timezone that analytics rules will use (because the server can collect data from sources located in different timezones).

In the Conditions tab, specify one or multiple conditions that will trigger the rule. If there are multiple conditions, they are combined using a Boolean AND and evaluated top to bottom. Thus, a rule will be triggered only if all its conditions are matched. To create a condition, click Add. and provide the following parameters:

Name

Description

Name

The name of the analytics rule condition.

Description

A description of the analytics rule condition. This field is optional.

Limit condition time

Enable or disable the time limit for evaluating this condition.

If the time limit is enabled, the analytics rule will be triggered only if the condition is matched the specified number of times within that time period.

Condition time, sec

The time period within which the condition must be matched the specified number of times for the analytics rule to be triggered. The time is set in seconds.

This setting can be configured if the Limit condition time checkbox is set.

Use stop query

Enable/disable the use of a stop query in an analytics rule.

Stop query

An SQL-like stop search query is executed along with the condition query. To formulate a query, use field names, field values, keywords, and operators (set similarly to a filter query).

If, when performing an analysis, at least one record is found that matches the specified stop query, before the specified number of events that match the condition of the analytics rule are found, then the analytics rule will not work, and the counter for the number of records found before the stop query is executed will be reset.

Filter query

An SQL-like condition search query against the log database. To formulate a query, use field names, field values, keywords, and operators.

For the query syntax, refer to the section Data Search and Filtering.

The query can also be written using the Google/RE2 syntax in a MATCH operator.

Example. Search query:

source = 'wmi log' and logFile = 'Microsoft-Windows-Sysmon/Operational' and logEventId = 1 and data MATCH 'ParentCommandLine:(.*)cmd.exe' and data ~ 'CertReq -Post -config'.

This query will perform a search in the endpoint event log that gets data from the Microsoft-Windows-Sysmon/Operational log. When an event is found indicating the creation of a new process, a search is run for the parent process (i.e. the process that caused the new process to be created) and a certreq command invocation with parameters. The MATCH part of the query allows detection of the fact that certreq was invoked from cmd.exe (the command line). This identifies cmd.exe as the parent for the current process.

More details on the use of Google/RE2 syntax with the MATCH operator can be found here: https://github.com/google/re2/wiki/Syntax.

Group by

The list of parameters by which rules can be grouped as a result of a triggered alert. The fields will be displayed when triggered alert details are viewed.

The parameters that can be used for grouping are described in the Analytics Search section.

When grouping categories are specified, the analytics rule will be triggered only if the condition is matched for this specific category the number of times specified in the Pattern repeats field.

Pattern repeats

How many times the condition must be matched for the rule to be triggered. This can be used with or without the Limit condition time setting.

Run now

Runs event analysis for a certain time range (historical mode).

This option needs a time range to be specified. If the Use time range checkbox is not set, the analysis is run using the created analytics rule over the entire time span covered by the whole event database. When the analysis is completed, you can click Show triggered alerts in the Analytics rule execution window to open the alert log and view the triggered alert details for the rule.

You can also run the rule without writing to the alert log --- e.g., to check if the rule works correctly or just view the number of triggered alerts. To do that, set the Test run checkbox.

In the Response actions tab, you can add actions to be performed automatically when the analytics rule is triggered. Response actions can be created by clicking Create and add new object or added from the list of existing actions. For more details on response actions and how to configure them, see the section Response Actions.

To run the rule in real time, click Enable. To stop the execution of the selected analytics rule, click Disable.

The created rules can be edited, deleted, and copied. By clicking Show triggered alerts, you can view a log showing quick details about all triggered alerts for this rule. You can also configure the rule list to display all rules or only enabled/disabled rules.

Export and import are also available for analytics rules. Rules are imported in binary or YAML format. Rules can only be exported in binary format; the selected rules or all created ones are exported if no rules were selected.

When configuring conditions for analytics rules, you can group events by parameters used in SIEM, NGFW, and endpoint log records. For a list of parameters that can be used for event grouping, see the table in the Analytics Search section.