Most TIP feeds are mostly noise
A blunt assessment of where threat-intel feeds actually add value, where they waste analyst time, and how to tell which is which.
I want to be careful with the framing on this one, because the TIP industry has done real, valuable work and we depend on multiple TIP sources ourselves. But after enough customer conversations and enough volume of TIP-matched events flowing through our collector, a pattern is clear that's worth saying out loud.
Most TIP feeds, used the way most security teams use them, produce more noise than signal.
This is fixable. But it requires being honest about what's happening.
What "mostly noise" looks like in practice
Pick a typical mid-market security team subscribing to three or four TIP feeds. Pipe those feeds into their SIEM. Configure detections that fire when a network event matches an indicator from one of the feeds.
Measure the resulting alert volume. Then ask a senior analyst to grade a random sample of the alerts on a four-point scale: clearly actionable, probably actionable, probably benign, clearly benign.
The consistent finding, across the teams we've talked to that have actually done this measurement: 60-80% of alerts grade as probably benign or clearly benign. Not because the TIP indicators were wrong — they may have been correct at the time they were published — but because the context in which the team is matching them has changed.
The indicators are stale. The IP that was malicious last week is on Cloudflare this week. The domain that was hosting a phishing page got taken down. The JA4 fingerprint matches a known tool, but the tool is also used legitimately by your own red team.
Why this happens
TIP feeds are built to be high recall. The threat researchers publishing them want to make sure nothing slips through. The cost of an indicator being included that turns out to be benign is small, in the publisher's view, because the consumer is supposed to apply context.
The consumer rarely does. They subscribe to the feed, match against the feed, and treat the match as the conclusion. The context — when was this indicator last validated, has the underlying infrastructure changed, does this indicator make sense for this customer environment — gets skipped because applying it is work.
The result is a stream of matches that's technically accurate ("yes, this IP was on the feed") and operationally useless ("no, this isn't worth investigating right now").
What actually helps
A few patterns that move the signal-to-noise ratio.
Use confidence and freshness, not just presence. A TIP match with high confidence from a feed that was updated this morning is meaningfully different from a low-confidence match from a feed that hasn't been touched in two months. Most security stacks discard the metadata and treat all matches equivalently. They shouldn't.
Match across multiple feeds before alerting. A single-source TIP match is weak signal. The same indicator showing up across three independent feeds is stronger. Cross-source corroboration is one of the cheapest signal-quality improvements available.
Combine TIP with behavioral context. A TIP-matched destination receiving normal user traffic at normal volume is much less interesting than a TIP-matched destination receiving sudden, high-volume traffic from a single host. The TIP match is the alert qualifier; the behavior is the alert reason.
Suppress what doesn't matter for your environment. If a TIP feed flags cryptominer-related infrastructure and your environment has no crypto-relevant assets, those matches should not be generating tickets. Per-customer suppression of categories that don't apply is a force multiplier on remaining signal.
How Signal Fabric handles this
We subscribe to multiple TIP sources and match against all of them at the collector. Every match comes out with the full metadata: which sources flagged it (tip_ip_destination_sources), the highest-priority match (tip_best_source_primary), confidence in basis points (tip_best_confidence_bp), severity (tip_best_severity_bp), categories.
The consumer can filter on any of these. A common pattern we see is filtering for tip_hit_count >= 2 (multiple sources agree) and tip_best_confidence_bp >= 7000 (at least 70% confidence). That filter alone removes 60-70% of TIP-matched events with minimal loss of true positives.
We also expose the behavioral context — cumulative bytes, occurrences, flow characteristics — on the same event. A consumer writing a detection can combine "this is a multi-source TIP match" with "this destination has received 50x normal traffic from this source in the last hour" into a single filter that fires only on the events that genuinely warrant investigation.
The TIP enrichment isn't the answer. The TIP enrichment plus the behavioral context plus the confidence metadata is the answer.
The honest part
Some of our customers have, on first measurement, found that 90% of the alerts they were generating from TIP feeds were not worth investigating. That's not a Signal Fabric problem and we don't claim credit for fixing it. We just made the metadata available so they could see what they were doing.
If you have a TIP-based detection pipeline and you've never measured its precision against analyst-graded ground truth, that's the first thing to do — independent of any vendor decision. You'll likely find the precision is much lower than you think. Whatever you do about it after that is a real choice.
The sandbox shows live TIP-matched events with full metadata, if you want to see what the unfiltered firehose looks like.
— Derek