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 that has not been previously processed will flag the processed event as an anomaly. After the event (and its associated data) has been processed, it will be considered as 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 a review 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 "Values" point to insertion strings which represent dynamic values (e.g. processes, users, IP addresses, ...) that are used for anomaly detection.
If the values point to data (insertion strings) that are considered "global" on the monitored host (e.g. are not linked to any other value of the event), then the key can point to any static insertion string in the event (see example 1). This would be considered a one-dimensional setup.
If the "Values" (insertion strings) are connected to another insertion string of the event, then this would be considered a two-dimensional setup, where the data represented by each key has its own unique data list (see example 2).
