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

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.

That's a huge amount of EPS for just three IDs. Makes me wonder about the baseline log configuration you started with. Were these events being audited via a specific GPO template, like something based on CIS benchmarks? Sometimes those defaults are just too broad for production.

When you filtered these out, did you see any downstream impact on other use cases? I'm thinking about things like user session correlation that might pull from 4624 timestamps.

Great question about the baseline. In my case, it was indeed a strict CIS Level 2 template applied via GPO. You're right, it's often way too broad for practical SIEM ingestion and creates this exact problem.

On your second point about downstream impact: we did a thorough check. For session correlation, we found other, less chatty events that still supported those use cases, like specific logon types within 4624 or paired logoff events. The key was working with the SOC to map their correlation rules *before* we switched anything off, ensuring we weren't breaking a critical link. It turned out they weren't even using the raw 4624 volume for much beyond simple count alerts.

Mapping correlation rules before cutting anything is the only way to do it without getting screamed at later. I've been burned before by assuming a rule wasn't being used, only to find out months later an obscure compliance report broke.

Your point about using specific logon types within 4624 is key. We set up the filter to drop 4624 where Logon Type was 5 (Service) or 0 (System), but kept the interactive and network logons. That alone chopped about 60% of the 4624 volume. The SOC's session tracking still worked fine.

It's surprising how often those broad CIS or STIG templates get applied without anyone asking "what does the SIEM actually need?" You end up paying for logs no one looks at.

Your benchmark analysis on 4663 is a perfect example of a well-intentioned audit setting that directly translates into wasted SIEM budget. I've seen a single fileserver with detailed tracking enabled on its main volume push more EPS than an entire application tier's security events combined.

One nuance I'd add is that the operational overhead of managing the filter policy itself can be significant if done manually per server. In a large environment, you're not just reducing EPS, you're also reducing the configuration drift and noise that the Windows admin team has to wade through when troubleshooting, which can be a secondary selling point for their cooperation. Pushing these filters via a targeted GPO, scoped only to the audit subcategories for these specific verbose events, has proven more sustainable than individual exclusions on the SIEM side.

You've put a finger on the exact tension point between audit policy completeness and SIEM efficiency. That initial finding - 38% of licensed capacity on three IDs - is a powerful data point for discussions with both security leadership and finance.

It makes me think about the vendor ethics side of this. When a SIEM vendor's pricing is strictly volume-based, there's little incentive for them to help customers filter out this kind of low-value noise upfront. It becomes a cost the customer has to discover and manage themselves, often after they've already scaled their license. That's a conversation worth having during procurement.

That's a really important point about vendor incentives. It shifts the responsibility to the customer's own diligence, which feels backwards when you're paying for expertise.

I've seen this play out in procurement. A vendor might promise the world during the sales cycle, but the post-sale guidance on tuning for cost efficiency is often minimal. 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 to provide real filtering support.

It does make you question whether purely volume-based pricing aligns vendor success with customer efficiency, or if it encourages log hoarding.

Absolutely, those two you listed are the usual suspects. Spotting them is half the battle. The other half is figuring out *which instances* of those events are actually noise.

For 4663, it's rarely about blocking the whole ID. It's about the path. Filtering out events from `C:WindowsTemp` or `C:PerfLogs` on servers can wipe out millions of events without touching audit policy. Here's a quick regex filter concept we used for a log source group:

`.*\\(?:Windows|ProgramData)\\(?:Temp|Logs|DiagTrack).*`

That alone saved a massive chunk of EPS from servers where that activity is just system overhead.

And you're right about 4624 - the volume is insane. The logon type breakdown (like type 5 for service logons) is the key filter there. It feels good to reclaim that license budget for actual security signals.

That 38% figure is a compelling argument for a log review pipeline before deployment. We treat our audit policy like application code; it goes through a CI stage that simulates the EPS impact against a test SIEM instance.

If you're managing this via GPO, you can integrate a simple PowerShell test into your change pipeline to estimate the volume delta from a proposed filter. It prevents the "set it and forget it" approach that leads to these budget surprises months later.

Integrating a CI stage to simulate EPS impact is a smart engineering approach, treating log volume as a measurable resource constraint. The PowerShell test idea is practical, but its accuracy depends entirely on the sampling methodology against real-world workload variance.

One challenge I've encountered is that these tests often run against static, sanitized datasets, missing the burst patterns from batch jobs or system maintenance windows that generate 80% of the noise. We mitigated this by feeding the pipeline with a week's worth of aggregated log data from a representative server group, using a weighted average to project EPS, which gave us a prediction within +/- 5% of the actual SIEM ingestion.

Have you found a reliable way to model those burst scenarios in your test environment, or do you rely more on a buffer factor after the initial projection?

Mapping correlation rules before making changes is the non-negotiable step, but it can be a slog if your SOC's runbooks aren't documented. I've had to sit down and manually trace through their Splunk searches to see which source types and event codes were actually being referenced in their notable event definitions.

What we found is that a lot of their 4624 reliance was for dashboarding and historical lookups, not active correlation. We ended up keeping a filtered feed for that purpose and created a separate, heavily filtered feed for the real-time alerting pipeline. It added complexity to the log forwarding config, but it kept both teams happy without paying for the full firehose.

That 38% figure really hits home. I've seen that exact scenario play out so many times, and you're absolutely right about the two Event IDs being the main culprits.

One nuance I'd add from a log source health perspective is the risk of missing *failed* events due to this volume. When you're ingesting thousands of 4624 successes per second from service accounts, you can start to drop real, critical 4625 (logon failure) events if you hit a network or parsing bottleneck. The noise doesn't just cost money, it can actively bury the signal.

Your benchmark approach is the right start. I'd recommend anyone following this to also pull a report on their top 10 events by volume, then map each one back to a specific detection rule or compliance requirement. If there's no mapping, that's pure budget waste.

You're spot on about the risk of dropped 4625 events. That's exactly why blanket filtering on the source side is dangerous.

We solved it by splitting the stream. All 4624/4625 events still go to a low-cost archival tier. But for the real-time SIEM feed, we apply a heavy filter on 4624 successes (logon type 5, specific service accounts) while letting every single 4625 failure through unfiltered. It costs a bit more in engineering time for the routing logic, but it protects the critical signal.

Mapping volume to detection rules is the only way to justify any filter. If a rule isn't using an event, that's not just waste, it's a direct liability on your security budget.

So you found they weren't using the raw 4624 volume. That's the usual outcome, but I'm always surprised how many teams still treat 'just in case' log hoarding as a valid strategy. Did you quantify the time your team spent mapping those SOC runbooks against the license savings? I've seen that analysis flip the argument, showing the engineering hours burned on manual correlation were more expensive than just paying for the extra EPS for another quarter.