That's a really good, practical question. My team ran into something similar with our primary cloud platform feed. We couldn't turn it off, but the group-by showed a specific rule category, "credential access," was causing most of the noise. It was tuned for a much stricter baseline than we needed.
So yes, the approach shifts slightly. You use that same group-by, but you drill down into that single source. Look for the specific rule *names* or *types* within it that are generating the volume, not just the feed itself. It becomes about internal tuning rather than feed elimination.
Have you been able to run that more granular query against your main EDR source yet? Sometimes the top offender is just one overly broad detection looking for, say, any PowerShell execution, and you can adjust that without touching the feed itself.
It's a bold move, but turning off top rules without looking at what they are first is like disconnecting random smoke detectors. Sure, the noise stops, but your chance of missing something that *actually* matters for your specific environment goes way up.
That "maximally paranoid" default setting is often tied to a legit, high-fidelity detection for a common TTP. Disabling it wholesale might give you breathing room, but it also might be the one rule that would have caught a real credential dump while you were busy celebrating the quiet. The paralysis doesn't come from the volume itself, it comes from not knowing which signals in that volume are garbage. I'd at least pull the rule description and the last 10 alerts it generated before flipping the switch. If they're all for a software stack you don't run, then by all means, kill it with fire. But you have to look.
Trust but verify.
Been there, and that feeling of being buried is real. You've already got good advice on both sides, but let me frame the trade-off I think you're facing.
Starting with feeds gives you a big, fast reduction, but it's a blunt instrument. You might accidentally filter out something valuable that's just mislabeled. Starting with rules is more precise, but it's a slog - you're tuning each sprinkler head individually while you're still getting soaked.
Given your volume, I'd actually split the difference. Use that export everyone's talking about, but sort it by *source AND rule name together*. Look for the combination that's generating the most noise. Often, it's one specific rule within one overly-generic feed. You can then make an informed choice: do you turn off the whole irrelevant feed, or just tune that single, hyper-noisy rule? That first decision becomes a concrete example you can use to build your team's tuning policy.
Also, don't just look at counts. Sample a few of the actual alerts from your top offenders. If you're seeing ten alerts a day for "Apache Struts vulnerability" and you're a .NET shop, that's a clear feed problem. If you're seeing fifty alerts for "unusual process spawn" that are all just your CI/CD tool, that's a rule tuning problem. The content of the noise tells you which lever to pull first.
Prod is the only environment that matters.
Totally get that buried feeling. I'm in a similar spot with our own alerts.
Everyone's saying start with feeds or rules, but how do you even get that export? I'm still finding my way around the CrowdStrike console. Is there a specific report or log view you used to pull the data for sorting by source? That feels like the first practical step I'm missing.
The "start with feeds vs. rules" debate here misses a crucial prerequisite: you need an accurate asset inventory first. Filtering feeds for software you don't have is useless if your inventory is wrong.
Map your actual stack against the top five noisy sources. You'll probably find two feeds flagging vulnerabilities for products your team decommissioned years ago. Disabling those gives an immediate, safe reduction.
Then look at rule tuning. But without that inventory baseline, you're just guessing what's relevant.
Your cloud bill is 30% too high
That feeling of being buried is the product working as designed. Vendors sell on detection breadth, not operational sanity. They know a quiet console looks like you aren't getting value, so they flood it.
Everyone's suggesting you start with feeds or rules, but you're missing the real first step: defining what a win looks like. Is it raw alert count reduction, or is it making sure your team looks at *actionable* alerts? Cutting 300 irrelevant Adobe Flash alerts is a win, but it doesn't help if the 200 left are still all junk.
Do the export, sure. But before you start disabling anything, pick a random sample of 20 alerts from your top source and ask a simple question: "Could we have done anything about this, even if it was real?" If the answer is "no" for most, you've found your blunt instrument. Start there.
cg
Spot on about vendors flooding the console to prove value. But that "define a win" step is often just theoretical hand-wringing that prolongs the pain.
You sample 20 alerts, and most are non-actionable. Great. Now what? That just confirms the system is broken. The real question is whether you have the political capital to actually turn the broken thing off. Management often hears "fewer alerts" and thinks "less security," regardless of your sample study.
So you do the export, you show the data, and you still get told to "just tune it" instead of killing the irrelevant feed. The win is defined for you: make the noise stop without appearing to reduce coverage. That's when you start the miserable, precise rule-by-rule tuning dance.
null