IBM Support

WinCollect Event Filtering

Question & Answer


How does WinCollect filter events and where does event filtering occur in the network?


Why use exclusion filters or XPath Queries?

The most common reason for administrators to use filtering is to reduce the volume of incoming events with no security value to ensure low-value events do not consume license on the QRadar appliance. Filtering events allow administrators to tune collection of their Windows events that they do not want to forward to the QRadar appliance. Filtering reduces event noise and the overall event volume from hosts that generate repetitive or low value security events.

What types of filters can WinCollect apply?

WinCollect agents provide two methods to filter events: Exclusion filters or XPath Queries. These two methods cannot be used together in a log source as they are mutually exclusive and both of these methods filter events in different locations.
  1. Exclusion Filters

    This type of filtering is done at the WinCollect agent and applies to both local and remote event collection. Exclusion filtering is done by the agent after events are polled, but before the data is forwarded to the QRadar appliance.

    For exclusion filters, WinCollect agents (both local or remote) collect events by using the Microsoft Event Collection API. Each time the value specified in the Polling Interval field expires, the agent requests all available events from the Event Collection API. When an exclusion filter is enabled for a log source, the agent sorts through all of the events retrieved from the Event Collection API and filters out events that match the exclusions defined by the administrator (either by Windows Event ID or by source). The agent then takes the remaining events and assembles the name=value pairs and forwards the events to either the Console or Event Collector appliance. The events are filtered before they enter the event pipeline at the Console or Event Collector appliance.

    Figure 1: An example of where an exclusion filter is applied.

    Note: When WinCollect is retrieving local events, the API request is made against the local system and the events are retrieved. The exclusion filter is then applied and events are forwarded to the Console or Event Collector appliance.

    WinCollect log sources can apply exclusion filters against both Microsoft event IDs or by service name. Any white space that appears next to the commas are removed; however, white space between names are not removed.

    Restrictions: The maximum size of an exclusion filter value is 4096 characters and service names must be separated by semi-colons. Event ID codes can be separated either by commas or hyphens to note a range of values.
    1. Example 1: The first example shows an exclusion filter applied to Security events by Microsoft Event ID codes. The filter applied in the log source excludes event IDs that match 4616, and events 4673, 4674, 4675, 4676, and 4677.
    2. Example 2: The second example lists an exclusion filter applied to Application events by service name and event ID. The filter CertEnroll(64-68) excludes events that match the source CertEnroll and events where the EventIDCode matches any of the following events 64, 65, 66, 67, and 68. When administrators filter by service, they can determine the name of the service either by reviewing the event from the Console or they can look at the application event log on the Windows system that generated the event.

      Figure 2: An example of a Windows application event with the Source and EventID underlined.
    3. Example 3 (not pictured in screen capture): A third example an administrator might want to apply would be to combine filters to allow the WinCollect agent to exclude multiple services and event ID codes. For example, SceCli(1202);Symantec AntiVirus(200-456, 49, 4904, 400-670);CertEnroll(65);1003,1066-1202

      Figure 3: An example in the log source user interface with two filters applied.

  2. XPath Queries

    This type of filtering is done on the Windows operating system and applies to both local and remote event collection. XPath queries are only supported on Windows operating systems that have Windows 2008 Server or later installed.

    For XPath queries, the Log Type and Event Type check boxes in the log source interface are ignored. The types of events that are retrieved are defined in the XPath Query field of the log source. Since XPath queries are filtered on the operating system side, they are not transferred on the wire to the agent. An XPath query can be used for both local system log source or by log sources that remotely poll for events. The WinCollect agent requests the XPath query during each polling interval defined in the log source. The WinCollect agent is responsible for assembling the query results in to name=value pairs, then forwarding the Syslog events from the query to the Console or Event Collector appliance.

    Figure 4: An example of where XPath Query filtering occurs for Windows event data.


[{"Type":"MASTER","Line of Business":{"code":"LOB24","label":"Security Software"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSBQAC","label":"IBM Security QRadar SIEM"},"ARM Category":[{"code":"a8m0z000000cwtwAAA","label":"WinCollect"}],"ARM Case Number":"","Platform":[{"code":"PF016","label":"Linux"}],"Version":"All Versions"}]

Document Information

Modified date:
16 August 2021