WinCollect Event Filtering

What types of filters can WinCollect apply?

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

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.