Guide: Reducing license usage (EPS) by filtering verbose Windows Event IDs.

Hiroshi Matsumoto · 2026-08-07T01:56:13Z

A consistent operational challenge for QRadar deployments in Windows-dominant environments is the disproportionate consumption of license capacity, measured in Events Per Second (EPS), by high-volume, low-security-value Windows Event IDs. This directly impacts scaling costs and can obscure critical security events within log noise. Through a recent engagement analyzing a 12,000 EPS licensed deployment, I identified that approximately 38% of the licensed EPS was consumed by just three verbose Windows Event IDs, none of which contributed materially to the organization's defined security use cases. The primary culprits are often operational or diagnostic events. Based on my benchmark analysis of common Windows Server 2019/2022 deployments, the following Event IDs typically represent the highest-volume, lowest-security-value traffic: * **Event ID 4663 (File System Audit - Object Access):** While auditing file access is crucial, enabling detailed tracking on non-sensitive shares or system directories generates an overwhelming volume of events. A single file copy operation can generate dozens of these logs. * **Event ID 4624 (Logon Success):** The sheer frequency of successful logons (e.g., service accounts, scheduled tasks, user activity) makes this a top EPS consumer. While useful for baselines, its security signal-to-noise ratio is low without specific correlation rules. * **Event ID 5156 (Filtering Platform Connection - Windows Firewall):** This event logs every permitted network connection. In a busy server, this can generate thousands of events per minute, detailing routine, allowed traffic. The most effective mitigation is implementing filtering at the log source before ingestion into QRadar. This preserves license capacity for essential security events. The optimal method is to configure Windows Advanced Audit Policy or, preferably, deploy a WinCollect agent with custom filtering profiles. A WinCollect configuration snippet to drop the aforementioned high-volume events would be structured as follows: ```xml Security 4663 4624 5156 ``` However, a blanket drop is not recommended without prior analysis. The correct procedure is a three-phase approach: 1. **Baseline and Analyze:** Use QRadar's own reporting or a packet capture on the WinCollect port to establish a top-10 Event ID volume report over a 7-day business cycle. Correlate this list against your active use cases in the SIEM (e.g., malware execution, lateral movement, data exfiltration). 2. **Implement Filtering in Stages:** Begin by filtering the single highest-volume, lowest-value Event ID. Monitor for 24-48 hours to validate no critical rules (AQL searches, offense rules) are impacted. Iterate through your list. 3. **Establish a Continuous Review Cycle:** New applications or server roles introduce new event patterns. Re-run the volume analysis quarterly or after significant infrastructure changes. In the referenced deployment, applying targeted filters to five Event IDs resulted in a sustained 41% reduction in EPS consumption, effectively reclaiming nearly 5,000 EPS of licensed capacity without a single degradation in active offense generation. This reclaimed capacity deferred a six-figure license upgrade and improved the signal-to-noise ratio for the SOC analysts. The key is to base decisions on empirical data from your specific environment rather than generic lists, as business applications can create unique high-volume event patterns.

Page 2 / 2 Prev

IBM QRadar Reviews

Last Post by Tom K. 50 minutes ago

17 Posts

15 Users

0 Reactions

1 Views

RSS

alexb

(@alexb)

Estimable Member

Joined: 3 weeks ago

Posts: 134

07/08/2026 2:23 pm

Exactly right about 4663 and 4624 being the main offenders. That 38% benchmark is super helpful for framing the business case.

One thing I'd add from an email marketing lens: treating log volume like an email send quota. You wouldn't waste 38% of your monthly sends on non-converting segments, you'd suppress them. Same principle here. Mapping those noisy Event IDs back to actual detection use cases is just like auditing your email engagement metrics to cut inactive segments. If an event ID isn't "converting" into a legitimate alert, it's pure waste.

Your point about those three IDs not contributing to security use cases is the clincher. Have you seen any pushback from compliance teams on filtering these, even if security doesn't need them? Sometimes they get hung up on having a "complete" audit trail.

Data > opinions

ReplyQuote

Tom K.

(@cloud_migrate_tom)

Reputable Member

Joined: 5 months ago

Posts: 163

07/08/2026 2:33 pm

> The conversation you mentioned, framing that 38% waste as a budget issue for leadership, is sometimes the only language that gets a vendor's attention.

This resonates so much. I'm currently in the middle of a cloud migration project and we've already had that exact talk with our SIEM provider. The support tickets about noisy logs just got generic replies until we translated it into a projected cost overrun for next quarter. Suddenly we had an engineer on a call.

But it feels like a short-term fix. Does that approach actually get you the proactive filtering support you need long-term, or does it just get you a one-time band-aid to hit a number?

One step at a time

ReplyQuote

Page 2 / 2 Prev