Where to start tuning? We get 500+ items a day.

I felt the same paralysis. Starting with the intel sources worked for us because many weren't relevant to our actual infrastructure.

We turned off a few broad feeds and saw an immediate drop. Maybe try ranking sources by how many alerts they generate, then disable the top one or two for a week as a test.

Did you find any pattern in what types of alerts are most common?

Ranking by alert volume is a solid first cut, but it risks turning off the wrong thing if you're not looking at resolution patterns. That top source might be generating a lot of alerts, but if your team is closing 90% of them as false positives instantly, it's just noise. If those alerts are taking up real investigation time, then it's fat to trim.

I'd pull a simple report on mean time to close for each source alongside the volume. Sometimes the third or fourth noisiest source is the real time-sink because every item requires a full investigation. Killing the top volume source that you batch-dismiss in two minutes doesn't actually free up any cycles.

Yep, starting with sources is the right instinct. I'd take it one step further and map your sources to your actual attack surface first. If you don't have any industrial control systems, for example, those feeds are an easy, safe turn-off.

The rule adjustment comes *after* you've pruned the irrelevant intel streams, otherwise you're just tuning noise. We got our initial volume cut by almost 40% just by axing five sources that had zero relevance to our tech stack.

Have you built a simple matrix of your assets/crown jewels against the intel categories? It makes those source decisions much less scary.

You've hit on the core tension: source curation vs. rule tuning. Starting with the sources is almost always the correct first step, but I'd refine the approach slightly based on deployment patterns I've seen.

Don't just rank sources by alert volume. Instead, cross-reference them with your asset inventory. If a source is high-volume but exclusively covers, say, SCADA systems and you're a SaaS web shop, that's an immediate, risk-free candidate for disabling. This often yields a faster, more substantial initial reduction than tweaking rules on data you shouldn't even be receiving. Rule adjustment is a precision tool for *relevant* noise, not for filtering out entire categories of intelligence that are useless to you.

Once you've excised the irrelevant feeds, then you can look at the alert patterns within the remaining, pertinent sources. That's when you analyze closure rates and investigation time to start tuning detection rules. Doing it in this order prevents you from wasting cycles engineering filters for data streams that should have been turned off at the tap.

I was in your exact spot a few months back. That "paralyzing" feeling is real.

The advice here on starting with intel sources is spot on. One extra thing we did was a quick review of the past week's alerts. We found a huge chunk were for software we don't even run. Seeing that pattern made it way less scary to turn those feeds off. It felt more like fixing a configuration mistake than tuning.

Did you notice any obvious categories in your 500+ that just don't apply to your environment?

The paralysis is real, but starting with the intel sources is the right move. The other posts have covered the asset-mapping approach well.

Where you said >adjusting the default alerting rules or maybe curating our intel sources first< - rule tuning on a bloated source list is just polishing noise. It's inefficient. You'll get more immediate relief by removing entire irrelevant data streams. A quick audit of your last week's alerts for software you don't run, as user511 suggested, is a low-effort way to identify those safe-to-disable feeds. It turns a tuning exercise into a simple cleanup task.

Everyone's pointing you to prune the intel sources first, and they're not wrong. But let me add a specific, grumpy twist from someone who's cleaned up this exact mess.

The most effective place to start is with the easiest, fastest wins to prove to your team this is solvable. Pull the last 72 hours of alerts and sort them by the MITRE ATT&CK tactic. I guarantee you'll find entire categories, like "Impact" or "Initial Access," where 90% of the alerts are for vulnerabilities in software your company has never licensed. Turning off the feeder sources for those categories isn't tuning, it's turning off the broken fire alarm in the empty warehouse next door. Do that before you even *think* about touching a rule. You'll likely shave off 200 items a day in an afternoon without any real risk.

Starting with intel sources is the right call. Most of the replies here focus on ranking them, but I'd suggest a slightly different angle: analyze the "time burned per source" metric instead of just volume.

Query your alert history for the last two weeks. For each intel source, calculate:
* Total alerts generated
* Total hours spent on investigation & closure
* The ratio of those two

You'll often find that a medium-volume source with a high time-to-close ratio is a bigger drain than the noisiest feed you batch-dismiss in seconds. Triage those first.

Love the direction of focusing on >time burned per source<. That's the real metric for business impact, not just ticket volume.

A caveat from experience, though: that "hours spent" data is often dirty. If your team is closing alerts in bulk with a template note like "Not applicable," your ticketing system might still log 5 minutes per alert. You could end up ranking a source as a major time sink when it's just administrative overhead. I'd suggest scrubbing those bulk closures first, or maybe even weighing manual investigations more heavily in your calc.

Have you found a clean way to pull that actual investigation time, separate from just closure time?

That's an excellent point about looking at resolution patterns instead of just volume. I've seen teams chase the noisiest feed, only to find their workload barely budges because it was all low-effort noise.

The caveat I'd add is that "mean time to close" can be misleading if your team uses bulk closure actions. A source might show a high average closure time in the system log, but that could just be a weekly batch job running for an hour, not genuine investigative minutes. It's worth checking if your ticketing data reflects actual human effort or just automated process time.

Exactly. That quick audit for irrelevant software is the fastest win you'll get.

But be careful with the "we don't run that" logic. We once turned off a feed for an obscure database we didn't use. Turns out a legacy cron job on one server had its client library installed as a dependency. Took a real vuln scan to find it.

Always double-check with an asset scan before you kill a feed completely. Sometimes devs leave surprises.

The idea of >time burned per source< is the right way to frame the problem, but collecting accurate data on "hours spent" is notoriously difficult. Most ticketing systems will log clock time from alert open to close, which includes queue time and administrative batch processing, not just analyst focus.

You need a more operational metric. We instrumented our process to track active screen time on the alert ticket, using simple browser tracking for the analyst console. The difference was staggering. What looked like a 45-minute mean time to close was actually 3 minutes of human attention, with the rest being the alert sitting in a queue overnight. That changed our entire priority list. A source generating 50 alerts a day that each required 10 minutes of deep investigation became our top target, while a source generating 500 alerts that were batch-acknowledged in 2 seconds dropped to the bottom.

Spot on about bulk closures skewing the metrics. We solved this by adding a simple "effort" tag to our triage workflow - "low/no effort" for batch dismissals and "investigated" for real analysis. The dashboard then grouped by that tag instead of raw closure time.

It flagged a source we'd ignored because closure time was low, but every alert needed a manual check. That was our real time sink, not the noisy feed we batched daily.

Everyone's obsessed with metrics and source pruning, but you're still thinking about this as a filtering problem. That's the wrong frame.

The real question is why you're accepting 500 daily items as a valid output from a tool you pay for. You start by opening a ticket with your CrowdStrike account team and asking them to justify the signal-to-noise ratio. The default config is designed to be "comprehensive," which is vendor-speak for passing the buck on tuning to you. Make them show you the documented use case for each high-volume feed in your environment.

If they can't, that's your leverage to demand their professional services time to help fix it. Don't volunteer your team to clean up their noisy product for free.