Filters are a set of conditions (by using Boolean operators) that focus on particular event attributes, reducing the number of events that are processed by the ESM Server.
Filters are applied at 2 different levels: ESM Server and Connectors. Within the ESM Server, the same filter resource can be used by different resources such as rules, queries, reports, query viewers, trends, data monitors, and active channels.
This practical guide is intended to provide an overall overview and hands-on on how to create this valuable resource within ESM, providing some hints and tips along the way.
In this 2nd part we will review how filters can use and be implemented within other ESM Resources:
- ArcSight Zones
- ArcSight Asset and Network Model
- Empty filters
- Rule filters
- Connector filters
- Debugging filters
What this guide is…
- A document to be used as a reference to help you effectively build your ESM content
- A quick start guide to help you get up to speed in ESM filters authoring
What this guide is not…
- A written-in-stone guide. As every environment is different, different conditions or assumptions apply to them
- A replacement for ArcSight ESM Training
- A replacement for the ESM Console User guide or any other ArcSight official guide
You can also look for events based on the location of either the source or destination host, leveraging the ArcSight Network Model adding Zone conditions to your filters, here a few examples:
a) You can add a condition that validates if the Zone of the intended host(either source or destination) belongs to a specific Zone Group, using the InGroup operator
b) You can also check if the source or destination Zone has an Asset Category (by leveraging the Asset Model)
c) You can check if the source or destination Zone event field is NOT NULL
d) You can match the destination or source zone to a specific ArcSight Zone in the Network model
This would be the resulting filter:
You can take advantage of the ArcSight Asset Model by matching Asset Categories:
1) In this example we are going to look for Destinations Assets who are either Revenue Generation Assets or whose Criticality is very High. Assets should already be defined within the ESM environment.
2) This will be the resulting condition. Again, within the OR operator we choose the least restrictive condition to be the first one
When filters are created and no conditions are added to them they look like this.
After the filter is saved and opened once again it looks like this.
This True condition means that it matches any event, so if this filter is used in a rule (or any other resource) it will match every single event flowing into the ESM. This is NOT a desirable condition.
If the filter is kept and left empty for any compelling reason, it should be opened and then double-click on the True condition and set to False.
This will exclude any event. Later on, conditions can be safely added to the filter.
Filters in rules behave in the same way as they do as single resources with one important exception: In Join rules you can look for more than 1 type of event, adding another alias (referenced by blue curly brackets) as we see in the image, each node contains a different set of conditions matching different events.
Please refer to the ArcSight Console User guide for more information on Join Rules.
Filters can also be applied at the connector level, but they have different intent as when used at the ESM level:
a) Filter Out: If you add a filter in this option, within the connector properties, the connector excludes all matching events and they will not be sent to the destination (ESM, Logger). In this example all events whose Device Severity is Low will be excluded.
b) If you select any of the Very-High/High/Medium/Low/Unknown Severity options and then add a filter to it, all events that match the filter will be associated with that specific severity.
In this example all events (coming from this connector) whose DecID = 611 will be associated with the Very High Severity. This will impact the final Arcsight Criticality event field value.
Tip: Derived fields, which are derived from data in other fields, cannot be used at the connector level.
One easy way to find out what event fields are derived fields is to create a Field Set and in the Fields Tab, derived fields are in italics.
Filter debugging validates if the filter matches the intended events, identifying conditions that are not matched by the event fields.
1) Create/open an active channel containing with the events the intended filter has to match with.
2) Right-click the corresponding event and from the sub-menu select Debug Filter.
3) Select the appropriate filter from the Filter selector window.
Tip: Filters containing InActiveList conditions cannot be debugged this way, unless using a variable.
4) In the Debug Filter window the results for the debugging will appear, showing whether the conditions were met or not.
This type of validation does not show possible events that might also be inadvertently matched by the filter.
An Active channel with the intended filter can be created for this purpose.