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. Then, 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 spaces 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 looking 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.


XPath and blocklist filter together

If you have both an XPath Query and a Predefined Filter in the log source, they are both applied. As XPath is a query in itself, the data is retrieved based on of the XML and returned to WinCollect.

XPath is more powerful than using a Predefined filter as you can create special conditions like suppress EventID 4663, but only when the service is {servicename}. The XPath is smart enough to filter based on these conditions. Whereas the predefined filter looks for exact matches from the retrieve data, such as 4663 and not forward over the matches event for EventID=4663 to QRadar. XPath is more flexible when it comes to special conditions whereas the predefined filter is more of a “if matches, then drop” filter.

Both XPath and Predefined filters can be used in coordination together, but you want to ensure that your XPath special conditions and your predefined filters do not overlap. If both exist in a log source, the order of operations would be:

  1. XPath queries the remote endpoint to retrieve the data. Only the data in the XPath query is returned, meaning that you can use the XPath to add special conditions to your filtering or selectively filter at the endpoint.

  2. WinCollect processes the event and applies the Predefined filter from the log source configuration based on the EventID number or service name.

As an administrator, what query type to use

  • XPath Queries – More flexible and can be conditional, but limited to 10 event logs. You can add special filtering like processname, LoginID, eventID, computername, path, and more to target specific data or use cases. The data is filtered based on the query before it is returned to WinCollect.

  • Predefined filter – Gets all data from the endpoint, then filters are applied by the WinCollect agent to exclude event IDs or a service name. Predefined filters can be used in coordination with XPath, but are not conditional and any matches are not forwarded as events to QRadar.

[{"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:
21 August 2023