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.
Oh, this is such a real pain point. I see it all the time with the teams I work with on sales tool implementations, where system audit logs end up drowning their actual sales activity data.
You're spot on about Event ID 4624 for Logon Success. The volume can be absolutely staggering, especially in environments with automated services or frequent RDP/terminal server use. One thing I'd add is that in a lot of the deployments I've reviewed, there's a huge secondary spike from Event ID 4688 (Process Creation), which is often logged for every single little script and scheduled task. It's another one that can flood the EPS count without adding much to the security story unless you're specifically hunting for something.
Have you found a good method for getting buy-in from the Windows admin teams to actually filter these at the source? That's always the biggest hurdle in my experience. They're often hesitant to turn anything off on the GPO.
hannah