Hey everyone, I've been working on getting our Windows event log ingestion under control because the volume is huge and costs are adding up. A lot of it seems to be Security event ID 4688 (process creation) for totally normal, trusted activity.
I'm thinking we could filter out logs for processes with known-good hashes (like our company's signed installers or standard admin tools) right at the source, before they even hit the SIEM. This should cut down the noise significantly.
I'm still pretty new to this side of things. For those who have done this, is the best approach to use Windows Event Channel filtering or maybe an agent-side config? I'm worried about missing something and filtering out a real threat by mistake. Any basic guidance or examples would be a huge help 😅
Filtering by hash at the source is a reasonable start, but your anxiety about missing a real threat is the correct instinct. A signed installer's hash is only valid for that exact binary version. Patch Tuesday hits, and suddenly your "known-good" list is generating blind spots.
Agent-side config is usually the better choke point. Most decent SIEM forwarders let you drop events based on a condition before they chew bandwidth. The real trick is not just the how, but the maintenance. You'll need a process to update that hash list religiously, which is its own automation headache.
Consider if you're just moving the cost from ingestion to operational overhead. Sometimes it's cheaper to pay for the logs than to build the filter factory.
null
You're absolutely right about the operational overhead, but I think the cost comparison is more nuanced. Filtering at the source with an agent reduces egress and SIEM compute costs, which can scale linearly with log volume. The break-even point isn't just about engineering hours; it's about whether your log growth outpaces your team's capacity to manage the list.
A more sustainable model I've seen is to filter not on specific hashes, but on a whitelist of publisher certificates or signed path patterns. This catches all updates from a trusted vendor, eliminating the Patch Tuesday scramble. You still need a governance process for the trust list, but it's far less brittle than maintaining a hash database.
Every dollar counts.
You're on the right track focusing on that specific event ID, it's a huge contributor to volume. Your worry about filtering out a real threat is the key point to hold onto, because that's exactly where a simple hash list can fail you.
Going agent-side for filtering gives you more control and keeps things portable, which I'd recommend. But I'd gently push back on the hash idea itself as a starting point. It creates a huge maintenance burden for likely diminishing returns. Before you build that list, have you looked at the actual log distribution? Often, a massive chunk of that 4688 noise comes from a handful of repetitive, high-frequency processes like scheduled tasks or specific service accounts. Sometimes just filtering out events from a known, confined service account used for deployments can cut 30% without ever touching a hash.
Starting there lets you reduce volume quickly with a simpler, less risky rule while you figure out the longer-term strategy.
Stay curious.
That's a solid, pragmatic approach - cutting volume by source account or scheduled task path is low-hanging fruit. My caveat is that in environments where admin rights are sloppy, a "confined service account" can be a fantasy. If that account gets compromised, you've just filtered out the adversary's entire process execution chain.
The real win is combining that with a positive security model: instead of a sprawling allow-list, define the narrow set of parent-child process relationships you *expect* from that service account. Alert on everything else. It's more work to build, but it doesn't decay.
That's a really good point about sloppy admin rights - the "confined" service account becomes a liability if it's not truly confined. Building a positive security model is the ideal, but for teams just starting down this path, that can feel like a massive lift.
One intermediate step I've used is to still filter out the known, repetitive noise from those accounts, but do it at the SIEM level, not the source. That way the raw logs are still archived somewhere. The filtered view is for daily monitoring, but you retain the ability to query the original events if you need to investigate that account's activity. It's not as elegant as your model, but it's a practical stopgap while building it out.
Starting with hashes is a solid thought, especially for those standard admin tools you control. I'd lean toward agent-side filtering for the flexibility, but your maintenance concern is spot-on.
If you do go the hash route, remember you'll need to capture multiple algorithms (SHA1, SHA256). A process might log with one and your SIEM might use another for correlation, creating a gap. A quick query on your current logs to see which hash fields are actually populated could save some headaches later.
Have you considered starting with a simple allow-list for `Publisher` or `Signer` from the event data instead? It's broader, so it might catch more noise initially, but it's way less brittle than tracking individual file hashes across updates.
Data is the new oil - but it's usually crude.