Hi everyone, I'm new to ThreatConnect and still getting my bearings. We're a small shop and the volume of alerts from the default malware analytics is overwhelming. We're definitely experiencing alert fatigue.
I'd love to hear how others have tuned this. What rules or filters did you adjust first? Are there specific low-fidelity indicators you found safe to suppress or set to lower severity? Any guidance on finding the right balance between noise and missing something important would be a huge help. 👋
Hey user701, welcome. This is a common starting point. The default analytics are a great baseline, but they're designed to cast a wide net for diverse environments.
I'd suggest starting by reviewing the alerts you've already marked as false positives or low risk over the last week or two. Look for patterns in the indicator type, source, or targeted system. You'll often find certain hash or URL rules that simply don't align with your specific software stack or user behavior. Adjusting the severity for those whole categories is a good first step, rather than trying to tackle each alert individually.
It's a balance, but you can be pragmatic. If you don't have any Macs in your environment, for instance, Mac-specific malware signatures are pure noise for you. Tuning is about matching the tool to your reality.
Keep it constructive.
user603 has the right approach, but the timeline is too generous. A week or two of data is a luxury you don't have when you're drowning. Pull the last 48-72 hours of alerts flagged as false positives and you'll see your top 3 noise sources immediately. It's almost always faster.
Their point about matching the tool to your reality is critical, but it's more than just OS. Think about your approved application list. Alerts for software that can't even exist in your locked-down environment are free to suppress. Don't just lower severity, kill the rule entirely. Every alert you allow through is a distraction from the one that might matter.
Great starting advice from others. Focus on tuning the source, not just the destination. We found the 'External Intelligence' modules were a huge latency hit, pulling in generic feeds that caused more noise than signal for our specific assets.
If you're a small shop, you probably don't need global malware prevalence data triggering alerts. Go to the analytics management and look for any rules weighted heavily by external, non-curated intel. Dialing those confidence scores down (or off) cut our alert volume by 60% without a single missed incident in six months.
The balance is in the scoring. Adjust the rule confidence thresholds before you touch severities. A low-confidence alert should be a log entry, not a ticket.
ms matters
Exactly. Pivoting from "what's possible" to "what's possible *here*" is the only way to stay sane. Your point about the approved application list is spot on, but I'd push the logic a step further.
If you've blacklisted an app category entirely, don't just kill the rule for that executable. Go after the behavioral analytics that trigger on its *installation patterns* too. Otherwise, you're still getting noise about failed deployment attempts or hash mismatches for something that can't run. You have to prune the entire branch.
Data over dogma.
Pruning the entire branch sounds elegant until you have to update your approved list. That "blacklisted" app you killed rules for today becomes the legacy line-of-business app the CFO needs installed next quarter during an acquisition.
You're not just pruning, you're burning the soil. Now you have no baseline for what a failed, unauthorized installation attempt looks like, which is often a far more valuable signal than a successful one in a locked-down environment. Suppress the executable alert, fine, but killing the behavioral rule means you're blind to the attempt itself.
Your mileage will vary
Welcome. The fatigue is real and you're right to tackle it head-on. Starting with the most generic, feed-driven rules is the fastest path to relief.
I disagree slightly with the advice to just look at your own false positives from the last 48 hours. That's reactive. You'll be chasing yesterday's noise. Instead, start proactively by auditing the rule library itself. Go to the analytics management console and sort all enabled rules by their *update frequency*. Rules that ping every few minutes based on volatile external intel feeds are your primary noise generators. For a small shop, you can safely set any rule with a sub-hourly execution interval to "Log Only" as a starting baseline. This stops the pager from firing while preserving forensic data.
That balance you're asking about is really a function of confidence scoring, not severity. A high-severity alert with a 30% confidence score is just a badly tuned rule. Focus on adjusting the confidence thresholds upward first, especially for behavioral patterns tied to assets you don't have. Severity tuning should come much later, only for the alerts that survive your confidence filter.