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.