|
Stop Processing Checking this box will prevent any filters below this filter in the same package or filters in packages below the current package from being processed.
Require Acknowledgment When consolidating events to a database, one can require select events to require a manual acknowledgment. This is usually useful for critical events that need to be reviewed and manually "cleared" or "acknowledged".
For example, you can create a filter for events that pertain to a failed backup event. If a backup fails, then this event will show up in the web reports as "pending acknowledgment", requiring an administrator to document what action was taken to resolve the issue.
Process Events with Anomaly Filters events based on their anomaly property, requires that at least one anomaly filter is setup. Filters can either process any event regardless of their anomaly property, or events that either are or are not considered an anomaly.
Most commonly one would setup a filter to only process events which are considered anomalies (e.g. to set the "require acknowledgment"). |
|
If one filter matching the event has "Require Acknowledgment" set, then the acknowledgment flag will stick, even if other matching filters do not have this setting enabled. |
Email / Network Action Overrides
By default, all events are forwarded as-is, which can be overwhelming for some users. The "Override" feature allows the user to define the subject/title as well as content of an email or network message. The subject/title or message can either be a static text or may contain any variables from the event itself (e.g. insertion strings or event properties). The screenshot above shows two insertion strings from a 4625 security event being used.
|
If an email contains more than one event then the email message body will not be overwritten and instead revert back to the "default" where the content of every event is listed. |
Insertion String Override
Even though most events utilize message DLLs supporting the ability to create filter rules based on insertion strings, some events either do not use message templates or include long dynamic content where insertion strings do not help.
For example, when EventSentry logs the content of a log file or an incoming Syslog message, that content is simply injected into the respective EventSentry event. If the (log file) content follows a known pattern, EventSentry can redefine the insertion strings of the event based on a regular expression pattern. The original insertion strings are always lost since they are replaced.
Template |
Actual Event |
Event after insertion string override |
|
Event |
Text matching one or more filter rules has been found in file %1:
%2 |
Text matching one or more filter rules has been found in file C:\INETPUB\LOGS\LOGFILES\W3SVC1\u_ex161022.log: |
Text matching one or more filter rules has been found in file C:\INETPUB\LOGS\LOGFILES\W3SVC1\u_ex161022.log: |
Insertion Strings |
$STR1 = C:\INETPUB\LOGS\LOGFILES\W3SVC1\u_ex161022.log $STR2 = 2016-10-22 07:20:04 12.31.29.171 GET /index.php - 443 - 12.31.29.80 Mozilla/5.0+[en]+(X11,+U;+OpenVAS+8.0.7) 404 0 2 0 |
$STR1 = 2016-10-22 $STR2 = 07:20:04 $STR3 = 12.31.29.171 $STR4 = GET $STR5 = /index.php $STR6 = - $STR7 = 443 $STR8 = - $STR9 = 12.31.29.80 $STR10 = Mozilla/5.0+[en]+(X11,+U;+OpenVAS+8.0.7) $STR11 = 404 $STR12 = 0 $STR13 = 2 $STR14 = 0 |
