The anomaly feature of event log filters helps detect unusual events by examining event data (insertion strings) after a learning period established a baseline of known data.
In detail, anomaly detection determines whether a combination of insertion strings of an event (which are configurable in a filter) have not been encountered before and thus considered an anomaly. While anomaly detection can be used with any event that utilizes insertion strings (or where a RegEx pattern can create dynamic insertion strings), it integrates well with security events from the Windows security event log.
Anomaly detection can be used to detect a variety of unusual activity including:
•A user logs on via RDP from a new remote IP address
•A user starts a new process
•A logon by user that has never logged on before via the same logon type (e.g. console vs RDP)
Anomaly detection works by creating key/value pairs from insertion strings, where the key usually represents a static key value (e.g. user, computer) with which dynamic values are then associated with. Both keys and values are composed of at least one insertion string, with a combination of insertion strings also being possible.
Learning Period
After an anomaly filter first processes a matching event, a learning period starts and establishes a baseline of known key/value pairs (e.g. 2 weeks). For example, a filter may learn which processes users on the monitored system start by examining event id 4688 (which is logged when a new process starts). After the learning period is complete, any event data (=process) that has not been previously seen will flag the event as an anomaly. After the event (and its associated data) has been processed, it will be considered to be part of the baseline and will not be considered an anomaly when processed again in the future.
Separate Learning Period for new keys
Enabling this option is almost always recommended, since it ensures that values associated with a key have their own learning period, independent of that of other keys (see example 2 for details).
|
Anomalies are determined by each individual agent, and each agent / monitored host has its own learning period & cache. |
Acting on Anomalies
It's important to understand that anomaly filters themselves will not forward events to an action. Instead, matching events will be flagged internally as being an anomaly. Another, subsequent, event log filter can then evaluate this flag and process the event accordingly, for example:
•Send the event to a different action
•Require an acknowledgment of this event in the DB
An event log filter can be configured to only process events which are considered an anomaly through the "Process Events with Anomaly" option, which is available in the advanced properties.
|
Events that are considered an anomaly are however marked as such in all applicable compliance tracking features, where this condition can be evaluated through the isanomaly search property. This makes it easy to search for processes or logons that are considered an anomaly for example. |
Enabling Anomalies
To analyze anomalies, simple select the "Anomaly" option of an event log filter. Click the "Anomaly" button to configure the anomaly rules.
Keys and Values
Every anomaly filters requires at least one key and one value, where keys and values point to insertion strings which represent dynamic values (e.g. processes, users, IP addresses, ...).
In general anomaly detection will differentiate between one-dimensional and two-dimensional configurations.
One-Dimensional
The "key" will point to an insertion string which never changes, for example the local host name. Instead, the encountered values (=insertion strings) will be used to determine whether the event is an anomaly or not. Detecting new users logging on to a computer, or new IP addresses connecting to a RDP session would be an example of a one-dimensional setup (see example 1).
Two-Dimensional
Here, an insertion string defined as the "key" is intrinsically connected to one or more insertion strings defined as "values". For example, a user name can be connected to a process name, so that each user has its own anomaly settings. For example, "User A" running "ipconfig.exe" in March wouldn't automatically consider "ipconfig.exe" executed by "User B" in August safe - it would be flagged as an anomaly (see example 2).
