Filter thresholds enable you to not only take action when a certain event occurs, but also depending on how often the event occurs. Some threshold scenarios:
•Be notified if an event occurs X number of times within a specific time period
•Prevent events from flooding an action
•Detect lateral movements throughout a network (requires collector)
•Detect if users log on with a wrong password more than X times
Thresholds are setup on a per-filter basis, and you can access the threshold settings by editing a filter and clicking on the Threshold tab. Set a threshold to either "Agent-Side" or "Collector-Side" to activate threshold settings for a filter. Filters with thresholds are shown with a little ruler 
in the list.
Threshold Type
Agent-Side
These thresholds are executed on the agent, the only type of threshold supported until v3.3. Agent-side thresholds should always be preferred unless correlation of events occurring on multiple hosts is necessary. Required for filters that are part of a filter-chaining package.
Collector-Side
These thresholds are executed on the collector, and require that:
•a collector is installed and running
•the referenced action of the filter uses a collector
•no agent-side thresholds are processed before the collector-side threshold
•the filter is not part of a filter chaining package
Collector-side thresholds make it possible to correlate and evaluate events from multiple hosts in order to detect threats and patterns that involve more than one host. For example, lateral movements can be detected by analyzing certain logon events.
The "Computer" event and the "Group By" options are only available for collector-side thresholds.
|
When the primary purpose of a collector-side threshold is to detect activity rather then suppress (e.g. all check boxes under "Event Processing" are unchecked), then it's recommended to associate an action that already processes the events in question (e.g. a database action) when possible - rather than assigning a different action (e.g. email).
For events that occur often this can reduce the data volume by ensuring that events are not transmitted twice - once for each action. |
Threshold Interval
Specify the threshold interval, for example 20 events in one hour.
Event Processing
Allows you to configure whether events are forwarded to the configured notification before and/or after the threshold has been met. You can either check all, one or none in this section.
Forward events until threshold is reached
Checking this box means that events matching your filter will be processed (and forwarded to the notification) until the threshold is met.
Forward events after threshold has been met
Checking this box means that events matching your filter will be processed after the threshold has been met.
Forward first event only
You can configure a threshold filter to only forward the first event after a threshold has been met, instead of forwarding all events after the threshold has been met.
This is particularly useful when working with events from the security log. When you configure a threshold for a failed-login type of filter (e.g. notify me when there are more than 5 failed logins in 5 minutes), then you will usually not want to receive the first failed login attempts, since users type in wrong passwords all the time. If the threshold is exceeded however, you probably do want to know which user is trying to log in. If you just configure the filter to forward all events after the threshold, then you will get an email for every wrong password attempted, which is usually also not desired. Instead, you configure the filter to only forward you the first event after the threshold has been exceeded, and then write an event to the event log when the period has expired to indicate how many failed logon attempts there have been for this user account.
Selecting none of the two check boxes is allowed when you check at least one check box in the "Event Logging" section. In this case the filter will never forward any events, but write an event to the event log when the threshold has been met.
Event Logging
This section controls whether events will be generated and logged to the application event log when the threshold is met, and/or when the threshold period is complete.
Log when threshold is met
Checking this box results in an event being written to the Application event log immediately when the filter meets its threshold.
Log when threshold is met/exceeded and interval is elapsed
This option is similar to the first one, except that this feature will log an event only after the threshold has been met and the threshold interval has elapsed. The advantage of this option is that the event logged by the threshold filter will let you know how many events have been processed by this filter, and how many were dropped.
Log as
Specify whether you would like events logged as Error, Warning or Information events. Please see Event Logs for more information as to which events are logged to the event log by this feature.
Threshold Matching
By default the internal counters (that count towards the threshold limits) are increased every time an event matches a filter (Filter setting). While this is desirable in most cases, you can also have threshold counters be applied to event records, which allows for more granular threshold settings but is slightly more resource consuming.
Filter (every event processed by this filter)
Every time an event matches the filter the internal threshold counters are increased. This is the recommended option for threshold filters applied to events that are not from the Security event log.
Event Properties / Insertion Strings (every event sharing properties)
Every event that has the same values for the selected properties will increase the internal threshold counters, this feature is mostly useful for events from the Security event log, for example to analyze failed logins. Instead of every event counting towards the threshold, only events that share certain event properties, including insertion strings if selected, will count towards the total counter.
|
The "Computer" field is only available for Collector-Side thresholds, since the "Computer" property is always the same for Agent-Side thresholds. |
The diagram below illustrates how matching based on event properties and insertion strings works. In this example, a filter processes 4624 events and uses insertion string 5, which represents the "Security ID", as the unique identifier. Consequently, virtual threshold objects for each unique occurrence of an encountered Security ID are created. When the same Security ID is encountered 4 times within 3 minutes, an alert will be immediately generated - UserC in this example. Another alert will be generated when the threshold period, 3 minutes, is elapsed.
Group By (Collector-Side)
By default, thresholds are increased whenever an event matches a filter or the selected event properties. Using the "Group By" feature will compare the number of groups created against the threshold instead of the number of events.
The diagram below illustrates how matching based on event properties and insertion strings in combination with grouping by computer works to detect lateral network movement. In this example, a filter processes 4624 events and uses insertion string 5, which represents the "Security ID", as the unique identifier. Instead of just counting the occurrences of Security IDs however (as shown in the previous example), the threshold object keeps track of all the different computer names encountered instead.
In the example below, UserA logged on to 5 different hosts, resulting in the threshold limit of 4 being exceeded. While the total number of logons for that user is being recorded (8), that number does not count towards the threshold. Only the unique number of computer values (5) is evaluated. UserB on the other hand only logged on to one unique computer, a total of 3 times.
