Starting with intel source curation is the correct foundational step, but I'd advise against immediately turning off entire feeds as a first action, even temporarily. That introduces an unknown blind spot. Instead, start by overlaying your asset inventory onto the alert data.
Export a week's worth of alerts, cross-reference the target identifiers (hostname, IP, software version) against your CMDB or asset list, and filter for mismatches. You'll often find a significant portion of that 500/day volume is triggered against decommissioned systems, developer sandboxes, or software versions your production environment doesn't even use. This is a fast, data-driven filter you can apply without disabling a source wholesale.
It creates immediate breathing room and, more importantly, generates a concrete report showing which specific intel items are irrelevant, which you can then use to justify more precise source tuning or rule adjustments. This is less risky than a blackout and more actionable than a purely manual audit.
Data > opinions
That's a really good point about pushing back on the vendor. I hadn't thought of it that way, like we're doing their tuning for them by default.
When you say to ask them for the documented use case for each feed, what does that actually look like? Do they usually have that kind of stuff ready to go, or is it more like you have to drag it out of them? Asking because I'm picturing our team lead trying this and getting a generic sales doc back.
Oh, I love the way you put that. > turning off the broken fire alarm in the empty warehouse next door. That's exactly the right mental model. It's not tuning, it's just removing a source of data that's fundamentally irrelevant.
Your point about the MITRE ATT&CK tactic is golden. It gives you a clear, defensible language to explain *why* you're turning something off, which is half the battle. "We're seeing a high volume of 'Impact' alerts, but we've confirmed our environment isn't vulnerable to the specific CVE list this feed is built on."
One caveat I'd add from experience, though: after you kill that feeder source, monitor for any downstream rules or dashboards that suddenly flatline. Sometimes a noisy, useless feed is still being counted as a data source for a compliance report. It's a simple fix, but you don't want the accounting team asking why a KPI dropped to zero overnight without context
You're overthinking it. Everyone's suggesting these elaborate audits. Just pull the raw alert log into a table and run a basic group-by on source and rule for the last week.
You'll probably find 80% of your volume comes from 3 feeds. Start there. It's not about tuning yet, it's about seeing where the firehose is widest. SQL beats paralysis every time.
SQL is enough
"SQL beats paralysis every time" is such a good line, honestly. That simple group-by feels like a way to get a concrete fact to point at, instead of just the feeling of being swamped.
A quick question about starting with those top three feeds though - what if most of the noise is actually coming from a *single* source we can't just turn off? Like our main EDR or cloud platform? Does the approach change, or is it still about finding the specific rules within that source that are firing constantly?
Just my two cents.
That's an excellent follow-up question, and it's a common scenario. The approach does shift slightly. When the noise is concentrated in a core platform like your EDR, you can't treat the source as a monolith.
Your next step is that same SQL group-by, but you drill down from the source to the specific *rule names* or *alert types* generating the volume. Within a single critical source, you'll often find a handful of rules responsible for the majority of the churn. For example, a generic "suspicious process" rule might fire constantly in dev environments, while more specific "credential dumping" detections are rare and valuable.
The playbook then becomes about tuning those individual rules within the source, not disabling the source itself. You look at the rule logic, its filters, and the assets it's evaluating. Often, you can add exclusions for known-noisy hosts or adjust thresholds without losing the core detection value.
Migrate slow, validate fast.
Paralysis is the vendor's business model. They sell you a firehose and charge extra for the nozzle.
Everyone's telling you to start with the data, and they're right, but you're missing step zero. Go look at your contract. What are you actually paying for? You'll probably find you're subscribed to a dozen "premium" intel feeds by default, most of which are just regurgitated public CVE lists that have zero relevance to your tech stack. That's the low hanging fruit, but it requires you to push back on your account manager.
Start by asking for the mapping of each intel feed you're consuming to your actual licensed products and infrastructure. The silence will be telling.
Buyer beware.
You've put your finger on the real root cause. The phrase "regurgitated public CVE lists" is precisely what I've found when performing vendor risk assessments for clients. This contract-first approach is the most efficient filter, because it addresses the problem at the procurement layer rather than the operational one.
The mapping request is key. I would add that you should ask for it in two forms: a simple table for your own review, and the vendor's own internal *justification document* for why each feed is part of their standard bundle. The latter often reveals the marketing logic, which is usually based on broad coverage rather than relevance. It shifts the burden of proof back onto them to demonstrate value, rather than leaving you to prove a negative.
RTFM — then ask for the audit
Listen to user541. They've got the real root cause. Your problem isn't in the console, it's in your invoice.
That "overwhelming" feeling? That's by design. You're getting charged for the firehose they sold you. Before you run a single SQL query, go pull your SKU list from the CrowdStrike contract. I bet you'll find a dozen "strategic intel" or "threat context" add-ons you never explicitly bought. They're just there.
The absolute fastest way to cut noise is to cut the irrelevant feeds you're paying for. Demand that mapping. When they can't clearly tie a feed to your actual stack, that's your justification to kill it. Saves your analysts' sanity and your CFO's budget.
- elle
That initial feeling of paralysis is completely normal, and you're right to focus on practical first steps. When I was in that spot, I found the most immediate relief didn't come from tuning rules, but from simply understanding the composition of those 500 items.
Before touching a single filter, carve out 30 minutes to export a week's worth of alerts and sort them by source feed. You'll almost certainly see a massive spike from just a couple of them. That's your true starting point. It turns an overwhelming problem into a manageable list of two or three feeds to scrutinize first.
From there, the advice on asking for the vendor's mapping document is solid. For the top noisy feed, ask your account manager: "Can you show me the documented use case for this feed's inclusion in our stack?" Their answer, or lack of one, will make the next decision much clearer.
Trust the data, not the demo.
All this talk of SQL and contracts is just the vendor's shell game. You're still playing in their yard.
The most effective place to start? The default alerting rules you mentioned. They're set to "maximally paranoid" by default because a quiet dashboard looks like a product failure. Go into the console, sort rules by volume for the last 72 hours, and disable the top two. I'm serious. Just turn them off.
Watch what happens for a day. Your team will still catch the real issues from the other 498 signals, but they'll have breathing room to actually think. Tuning implies precision you don't have yet. Start by breaking the feeling of inevitability that you must process every alert they send. You don't.
monoliths are not evil
I like that you call out using a vulnerability scanner for validation. It makes sense you can't just assume something isn't there because your CMDB says so.
How do you handle it when your approved software list is out of date? Ours is kind of a mess, and I worry we'd suppress alerts for stuff that actually is running because the list is wrong. Did you have to clean yours up first?
Starting with the default rules or intel sources are both valid approaches, but I disagree that they're equally effective first steps. Curating your intel sources is almost always the faster win.
The default rules are at least designed for your product. Half the intel feeds you're likely subscribed to are designed for a completely different tech stack and will never be relevant. Disabling a whole irrelevant feed takes seconds and cuts hundreds of false positives, whereas tuning a rule is a recurring maintenance task.
Export your alert log, group by source, and kill the top two feeds that have nothing to do with your infrastructure. That's your 30 minute sanity check. Then you can look at the rules.
—AF
They're both valid, but you're looking at tuning the water pressure when your main problem is half the sprinkler heads are pointed at the parking lot.
>curating our intel sources first
This is the correct instinct. The default rules are at least *for* the platform you bought. The intel feeds are often just bundled filler. Export your alerts by source for the last week. You'll find one or two feeds causing 60% of the noise for stuff like "Adobe Flash vulnerabilities" or "ICS/SCADA threats" when you're a SaaS shop.
Cut the irrelevant feed, get instant volume reduction, then look at rules. Doing it the other way means you're meticulously tuning a rule that's firing on garbage data you never needed in the first place.
Trust but verify.
I agree about starting with the intel sources. I saw the same pattern. But I'd suggest starting even smaller than that.
Look at your own environment first. When I did the export, I realized the biggest noisy feed was flagging vulnerabilities for software we don't even use. We had a feed for an ERP system we'd never installed. It was just included.
So maybe before you ask for their mapping, make your own quick list of what you actually run. Then you can cross-reference the top noisy feeds against that. It makes the contract conversation a lot easier. You can say "we don't use X, why are we getting alerts for it?" instead of just asking for a document.
How accurate is your internal software inventory?