Threat Intelligence: Teaching Your Platform to Recognise Bad Actors

Most security platforms collect far more than they understand. Firewalls, endpoints, cloud audit logs, and identity providers all emit events, and the detection layer is asked to decide which of millions of them matter. Without outside context, it has to guess. An outbound connection, a downloaded file, or a login from a new country looks the same whether it's routine or the first sign of a breach.

Threat intelligence is the context that makes those guesses informed. It tells your platform which IP addresses, domains, file hashes, and techniques have already been seen in real attacks, so an alert can say "this host just contacted known ransomware infrastructure" instead of "this host made a connection." Done well, it shortens investigations and cuts noise. Done badly, it either floods analysts with false positives or quietly goes stale, leaving the platform blind while looking healthy.

This guide covers what threat intelligence actually is, which feeds are worth importing, how the enrichment flow works event by event, how to manage indicators of compromise at scale, why freshness is the failure mode nobody notices, how to handle noisy signals like TOR exit nodes, how MITRE ATT&CK mapping adds meaning, and what building the module realistically costs.

An IP Address Means Nothing on Its Own

A log line lands in your pipeline: a server accepted an outbound connection to 185.220.101.47. On its own, that number is inert. It's not suspicious, it's not safe — it's just a destination. A human analyst who's seen it before might feel a prickle of recognition. Everyone else shrugs.

Threat intelligence is what closes that gap at machine speed. It's the module that turns an anonymous IP into a known ransomware command-and-control server, a hash into a known malware sample, a domain into a known phishing host. Without it, your platform is technically watching everything and understanding none of it — it can see the connection but has no idea the destination has been burning through victims for the past three weeks.

This is the third layer in an AI-native security platform, sitting between the log processing pipeline that normalises raw events and the detection engine that turns them into alerts. Get it right and every alert arrives pre-loaded with context. Get it wrong and you either drown in false positives or miss the one connection that mattered.

What Threat Intelligence Actually Is

Strip away the marketing and threat intelligence is a set of curated lists of things known to be bad, kept current by people and organisations who track attackers for a living. The industry term for an entry on one of those lists is an indicator of compromise, or IOC — an IP address, a domain, a file hash, a URL, an email sender — that has been observed in malicious activity.

You don't have to build these lists yourself, and you shouldn't try. A mature platform imports them from established feeds:

• CISA — advisories and known-exploited-vulnerability data from the US cyber agency.
• AlienVault OTX — a large community threat-sharing exchange.
• AbuseIPDB — crowd-reported IP addresses associated with abuse and attacks.
• Spamhaus — long-running block lists for spam and malware infrastructure.
• Emerging Threats — network signatures and IP reputation, widely used with intrusion detection.
• CVE feeds — the canonical catalogue of publicly disclosed software vulnerabilities.
• MITRE ATT&CK — a structured knowledge base of attacker tactics and techniques.
• Exploit DB — a repository of public exploit code, useful for knowing what's weaponised.

Some are free, some are paid, some are community-maintained. The engineering work isn't in any single feed — it's in ingesting all of them into one normalised store, keeping them fresh, and making a lookup fast enough to run against every event flowing through the platform.

The Enrichment Flow

Enrichment is the moment threat intelligence earns its place. Here's the shape of it, using the outbound connection from the opening.

A normalised event arrives from the processing layer: source host, destination IP 185.220.101.47, timestamp, port. Before the detection engine ever looks at it, the enrichment step asks a series of fast questions against the IOC store:

1. Is this IP in any reputation feed? A hit in AbuseIPDB or Spamhaus immediately raises its risk weight.
2. Is it associated with a known ransomware group's infrastructure? If threat intel ties it to a named campaign, the event stops being a curiosity.
3. Is it a known botnet node? Command-and-control traffic often lights up here.
4. Is it a known TOR exit node? Worth knowing — but, as we'll get to, not automatically damning.
5. Is it a known phishing or malware-hosting server? If so, an internal host reaching it is a strong signal something is already wrong.

The output isn't a yes/no verdict. It's context attached to the event: "destination flagged by two reputation feeds, associated with a known ransomware campaign, first reported eleven days ago." That enriched record is what moves downstream. The detection engine can now weight the event far more heavily, and when an alert fires, the investigation agent inherits all of that context for free rather than starting cold.

Benefits of Threat Intelligence Enrichment

The enrichment step adds a lookup to every event, which is a real cost. These are the returns that justify it.

Alerts arrive with an explanation attached

An alert that says "host contacted an IP reported by two reputation feeds and tied to a ransomware campaign" can be acted on immediately. One that says "host made an outbound connection" sends an analyst off to look things up by hand. Enrichment does that research once, automatically, for every event, so the first minutes of each investigation go into judgement rather than copy-pasting addresses into lookup sites.

Prioritisation reflects real-world threat activity

Without outside context, detection rules can only score behaviour inside your environment. Reputation and campaign data let the detection engine raise the weight of events that touch infrastructure already seen in attacks elsewhere. The queue analysts work from is then ordered by actual risk, not just by how unusual something looks locally. Low-value anomalies drop down the list, and the handful of events touching known-bad infrastructure rise to the top where they belong.

Investigations start from evidence, not from zero

Because every IP, domain, and hash in an incident already carries its reputation, sources, and ATT&CK context, the investigation agent and human analysts can reason about the sequence of events straight away. That shortens the time from alert to a decision about containment, which is usually the number that matters most during a live incident. It also makes handovers between shifts easier, because the context travels with the alert rather than living in one analyst's notes.

Small teams borrow the visibility of large ones

Feeds such as CISA advisories, community exchanges, and long-running block lists represent the observations of many organisations and researchers. Importing them gives a small security team awareness of attacker infrastructure it could never discover on its own, at little or no licensing cost for the reputable free sources. Commercial feeds can be layered on later, once the team knows where its coverage is thinnest.

Coverage gaps become measurable

When intelligence is held in one store with timestamps and sources, you can see how fresh it is, which feeds contribute most, and which indicator types are thin. That visibility turns "do we have good threat intel?" from a feeling into something you can report on and improve deliberately.

Threat Intelligence Use Cases

Enrichment shows up in several distinct workflows inside a security operation. Each uses the same indicator store in a different way.

Spotting command-and-control traffic

The problem is outbound connections that look routine until you know where they go. Enrichment checks every destination against reputation, botnet, and campaign data before detection runs. When an internal host reaches known C2 infrastructure, the event's score jumps to critical and the alert explains why. The outcome is earlier detection of compromised hosts, often before data leaves the network. Because the reputation context is attached, responders can also see whether the same infrastructure has been contacted by other hosts.

Triaging phishing and suspicious email

Security teams receive a steady stream of reported emails. Extracting sender domains, URLs, and attachment hashes and checking them against phishing and malware feeds separates known-bad messages from the merely odd ones. Analysts can quarantine confirmed threats quickly and spend their attention on the messages no feed recognises, which are often the more targeted attacks. The same enrichment can feed back into mail filtering so similar messages are caught on arrival next time.

Prioritising vulnerability remediation

Patch backlogs are always longer than the time available. Combining CVE feeds with known-exploited vulnerability data and public exploit availability shows which vulnerabilities attackers are actually using. Teams then fix those first, rather than working through a list ordered only by severity scores that ignore real-world exploitation. For teams with limited patching windows, that ordering is often the single most valuable use of vulnerability intelligence.

Hunting back through historical logs

New indicators often describe infrastructure that was active before it was reported. Re-checking recent logs against freshly ingested IOCs reveals whether any host contacted that infrastructure in the past days or weeks. This turns new intelligence into a retrospective check, catching compromises that slipped through when the indicator was still unknown. It is one of the cheapest ways to get extra value from feeds a platform already ingests.

Explaining attack sequences to responders

When several alerts map to consecutive ATT&CK tactics, enrichment lets the investigation layer present them as one campaign moving through stages. Incident responders get a narrative of what the attacker has done and what they are likely to try next, which informs containment decisions far better than a list of unrelated alerts.

Managing Indicators of Compromise at Scale

The volume is what makes this hard. A single feed can carry hundreds of thousands of IOCs; run several dozen feeds and you're maintaining tens of millions of indicators, refreshed constantly, that you need to check against every relevant event in real time.

Three engineering problems follow from that.

The lookup has to be fast. If checking one IP against the IOC store takes 50 milliseconds, and you're processing tens of thousands of events a second, the enrichment step becomes the bottleneck for the entire platform. In practice this means holding hot indicators in an in-memory store (Redis is a common choice) with the full corpus behind it, and structuring lookups so a "not found" answer is as cheap as a "found" one.

Deduplication matters. The same malicious IP appears across a dozen feeds. You don't want a dozen records — you want one indicator with a list of which feeds reported it and when, because how many independent sources agree is itself a signal of confidence.

Every indicator needs metadata, not just a value. When it was first seen, when it was last confirmed, which feed reported it, what it's associated with, and a confidence score. Without that, you can't reason about staleness, and you can't explain to a downstream analyst why an event was flagged — which is the whole point of enrichment.

Freshness, Staleness, and the Quiet Failure

Threat intelligence has a short shelf life, and this is the part teams underestimate.

Attacker infrastructure is disposable. A ransomware group spins up a C2 server, uses it for a fortnight, and abandons it before it gets too hot. A phishing domain might live for 48 hours. This means intel goes stale in two directions, and both are dangerous.

Stale intel causes false negatives — the failure nobody notices. If your feeds haven't updated in a week, a brand-new malicious IP that first appeared yesterday simply isn't in your store. The connection sails through enrichment marked "unknown, no reputation data," the detection engine sees nothing to weight, and no alert fires. The platform looks calm precisely because it's blind. There's no error message for intelligence you never received.

The fix is unglamorous: feeds must be pulled on a schedule appropriate to how fast each one moves, ingestion failures must alert loudly, and the age of your intelligence should itself be a monitored metric. A dashboard tile reading "newest indicator: 9 days old" is a red flag, not a footnote.

The mirror problem is intel that should expire but doesn't. An IP that hosted malware last year may belong to an ordinary cloud tenant today. Indicators need an ageing policy — confidence that decays over time and eventually retires the entry — or you generate false positives against infrastructure that reformed months ago.

The False-Positive Problem: TOR Exit Nodes and Friends

Here's where naive threat intelligence quietly damages trust in the whole platform.

Consider TOR exit nodes. They are absolutely worth knowing about — traffic to or from one is worth a second look. But TOR is not malware. Plenty of entirely legitimate people use it: privacy-conscious researchers, journalists, employees in restrictive jurisdictions. If your platform treats "known TOR exit node" as equivalent to "known ransomware C2," you'll fire high-severity alerts every time someone browses your public site over TOR, and within a week your analysts will be muting the category wholesale — at which point you've trained your own team to ignore a genuine signal.

The same nuance applies broadly. A shared-hosting IP might carry one malicious site among thousands of innocent ones. A CDN address might appear on a block list because of a single abusive customer. Treating every IOC as a binary "malicious" flag is the fastest way to turn a useful platform into noise.

The discipline is to enrich with context and confidence, not verdicts. "This destination is a TOR exit node" is a fact you attach to the event. Whether that rises to an alert is a decision for the detection engine, weighed against everything else it knows — who the internal host is, what it was doing, whether the connection pattern is unusual. Threat intelligence should inform judgement, not replace it.

Mapping to MITRE ATT&CK

Reputation feeds tell you whether something is bad. MITRE ATT&CK helps explain what kind of bad — and that framing is disproportionately useful once an alert reaches a human.

ATT&CK is a structured catalogue of attacker tactics (the goal — say, Command and Control or Exfiltration) and techniques (the specific method within that goal). When enrichment maps an indicator or a detection to an ATT&CK technique, an alert stops reading like an isolated event and starts reading like a step in a recognisable playbook.

The difference in an analyst's experience is stark:

That last row is the real payoff. Once alerts carry ATT&CK context, the investigation agent can recognise a sequence — an attacker moving through stages — rather than treating each detection in isolation. It's the difference between noticing three unlocked doors and realising someone is walking through your building.

How Enrichment Feeds the Rest of the Platform

Threat intelligence is not a destination; it's a service the layers above depend on.

For the detection engine, enrichment is an input to scoring. A behavioural rule might notice an unusual outbound connection and assign it a low base score — until enrichment reveals the destination is a known C2 server, and the score jumps to critical. The same raw event produces a very different alert depending on what threat intelligence knew about it.

For the investigation agent, enrichment is pre-gathered evidence. When the agent assembles the story of an incident, it doesn't have to look up every IP and hash itself — the context is already attached. Its job shifts from collecting facts to reasoning over them, which is exactly where an AI agent adds value and exactly the kind of scoped, well-bounded tool design that keeps agent behaviour predictable and safe.

The through-line: good enrichment makes every layer above it smarter without those layers doing more work.

Common Threat Intelligence Mistakes

Threat intelligence is easy to switch on and easy to get quietly wrong. These are the mistakes that most often undermine it.

Treating every indicator match as an alert

Matching an IOC and firing a high-severity alert feels decisive, but it turns TOR exit nodes, shared hosting ranges, and CDN addresses into a stream of false positives. Analysts respond by muting whole categories, and the genuine signal disappears with the noise. Matches should add context and confidence for the detection engine to weigh, not trigger alerts by themselves. Analyst fatigue is cumulative, and trust in a noisy category is slow to rebuild once it's gone.

Assuming feeds are still updating

Ingestion jobs fail silently: an expired API key, a changed endpoint, a full disk. The platform keeps enriching against an ageing store and reports nothing unusual, because missing intelligence produces no errors. Teams that never monitor feed freshness discover the gap only after an incident that the intelligence should have flagged.

Keeping indicators forever

The opposite failure is never retiring anything. Attacker infrastructure is abandoned and reassigned, so an address that hosted malware last year may now belong to a legitimate tenant. Without confidence decay and expiry, old indicators generate false positives against innocent infrastructure and erode trust in every match. Ageing also keeps the indicator store smaller, which helps lookup performance.

Storing duplicates instead of corroboration

Loading each feed as a separate list means the same IP appears many times, sometimes producing several alerts for one event. Worse, it throws away the most useful signal multiple feeds provide: how many independent sources agree. One record with a list of reporting sources is both cheaper and more informative.

Building enrichment that slows the pipeline

A lookup that is too slow under real event volumes becomes the platform's bottleneck. Teams then sample events or skip enrichment under load, which means the busiest moments, often during an attack, are exactly when context goes missing.

Threat Intelligence Best Practices

A well-built threat intelligence module has a handful of recognisable properties:

• Multiple feeds, deduplicated into one store, with each indicator carrying its sources, timestamps, and a confidence score. Corroboration across independent feeds should raise confidence automatically. Record the feed's own confidence where it provides one, rather than flattening every source to the same weight.
• Fast lookups that run against live traffic without becoming the pipeline's bottleneck. Keep hot indicators in memory and make a "not found" answer as cheap as a "found" one. Load-test enrichment at peak event volumes, not average ones, since attacks often coincide with spikes.
• Freshness as a monitored metric. Know how old your newest and oldest intelligence is, show it on a dashboard, and make ingestion failures page someone rather than log quietly. Treat a feed that hasn't updated within its expected interval as an incident in its own right.
• An ageing policy so stale indicators decay in confidence rather than lingering forever, with different decay rates for fast-moving types like phishing domains and slower ones like vulnerability data.
• Context, not verdicts. Label TOR exit nodes, shared hosts, and CDN ranges as facts attached to the event, and leave the decision to alert with the detection engine. That keeps the noisy categories useful as supporting evidence instead of a reason for analysts to mute alerts.
• ATT&CK mapping so alerts explain themselves in the language of attacker behaviour, and sequences of alerts can be recognised as one campaign.
• Retrospective checks on new intelligence. When fresh indicators arrive, re-run them against recent logs so past contact with newly reported infrastructure is caught.
• Clean hand-off to detection and investigation, so enrichment happens once and benefits everything downstream instead of being repeated by each layer. Document which fields enrichment adds so detection rules and the investigation agent can rely on them consistently.

Questions to Ask Before You Build

"How fresh is our intelligence, and how would we know if a feed stopped updating?" If nobody can answer, you have a false-negative risk you can't see. Freshness must be measured, not assumed.

"How do we avoid alerting on legitimate TOR or shared-hosting traffic?" The answer should be about confidence and context feeding the detection engine — not about matching an IOC and firing an alert.

"What happens when the same indicator appears in five feeds?" You want one deduplicated record with corroboration counted, not five duplicate alerts.

"Do our alerts carry MITRE ATT&CK context?" Without it, analysts see isolated events instead of attack sequences, and investigations take far longer.

What It Costs and How Long It Takes

Honestly, a working threat intelligence module is one of the more tractable pieces of a security platform — the feeds already exist, and the hard problems are engineering ones you can reason about rather than open research questions. A first version that ingests a handful of reputable feeds, deduplicates into a fast IOC store, and enriches live events is typically a four-to-six-week effort for a small team, assuming the log processing pipeline it depends on is already in place.

The cost lives in the long tail, not the build. Some high-quality feeds carry commercial licensing. Keeping intelligence fresh, tuning confidence and ageing so you neither drown in false positives nor go quietly blind, and expanding ATT&CK coverage are ongoing operational work rather than one-off tasks. Budget for the module as something you run, not something you ship and forget — stale threat intelligence is worse than useless, because it looks like coverage while providing none.

Related guides

• Building an AI-native security operations platform: the complete architecture
• The log processing pipeline that feeds threat intelligence
• Building the detection engine
• The AI investigation agent that inherits your enrichment
• AI agent security: what business owners need to know
• Our AI development services

We Build Enrichment That Actually Enriches

Threat intelligence is deceptively easy to do badly — plug in a few feeds, match some IPs, call it done — and the failure mode is silent. We build it the way it needs to be built: multiple feeds deduplicated into a fast store, freshness monitored as a first-class metric, context and confidence rather than blunt verdicts, and ATT&CK mapping so every alert explains itself. And we build it to hand off cleanly to the detection and investigation layers that depend on it.

If you're weighing how to add real threat intelligence to a security product, or wondering why your current alerts arrive with no context, we're happy to walk through the specifics for your platform.

Talk to us about your platform — no commitment, just a conversation.

Frequently Asked Questions

What is an indicator of compromise (IOC)?

An IOC is a specific, observable piece of data associated with malicious activity — an IP address, a domain, a file hash, a URL, or an email sender that has been seen in attacks. Threat intelligence feeds are essentially large, curated lists of IOCs. Your platform imports them into one store and checks incoming events against them, so an otherwise-anonymous connection can be recognised as reaching known-bad infrastructure. The value of an IOC depends heavily on its freshness and the confidence attached to it, not just its presence on a list.

Which threat intelligence feeds should a platform use?

A sensible starting set mixes free and community sources — CISA advisories, AlienVault OTX, AbuseIPDB, Spamhaus, and Emerging Threats for reputation data; CVE feeds and Exploit DB for vulnerability and exploit awareness; and MITRE ATT&CK for behavioural context. There's no single correct list; the engineering challenge isn't picking feeds but ingesting several into one deduplicated, well-scored store and keeping them fresh. Commercial feeds add coverage and speed but come with licensing costs, so most platforms start with reputable free sources and add paid ones as the need becomes clear.

Why does stale threat intelligence cause false negatives?

Attacker infrastructure is disposable — a command-and-control server or phishing domain may only live for days before being abandoned. If your feeds haven't refreshed recently, a brand-new malicious address simply won't be in your store, so enrichment marks the connection "unknown," the detection engine finds nothing to weight, and no alert fires. The platform looks calm because it's blind, and there's no error for intelligence you never received. That's why freshness has to be a monitored metric with loud alerts on ingestion failure, not something assumed to be working.

Are TOR exit nodes always malicious?

No, and treating them as if they were is a common way to flood a platform with false positives. TOR is used by plenty of legitimate people — researchers, journalists, employees in restrictive jurisdictions — as well as by attackers. The right approach is to enrich an event with the fact that a destination or source is a known TOR exit node, then let the detection engine weigh that against everything else it knows before deciding whether to alert. Threat intelligence should supply context and confidence, not deliver binary verdicts that fire alerts on their own.

What does MITRE ATT&CK add to threat intelligence?

Reputation feeds tell you whether something is bad; ATT&CK helps explain what kind of bad. It's a structured catalogue of attacker tactics and techniques, so when enrichment maps an indicator or detection to an ATT&CK technique, an alert reads as a recognisable step in an attack rather than an isolated event. The biggest payoff is sequence recognition — several alerts mapped to consecutive tactics suggest one campaign progressing through stages, which lets the investigation agent connect events that would otherwise look unrelated.

How does threat intelligence connect to the rest of the security platform?

It sits between log processing and detection, enriching every normalised event before an alert can fire. For the detection engine, enrichment is a scoring input — the same raw event becomes low or critical severity depending on what intelligence knew about the destination. For the investigation agent, enrichment is pre-gathered evidence, so the agent reasons over context rather than collecting it from scratch. Done well, threat intelligence makes every layer above it smarter without those layers doing extra work; done badly, it silently starves them of the context they were built to rely on.

Conclusion

A security platform without threat intelligence can see every connection and still understand none of them. Importing reputable feeds, normalising them into one indicator store, and enriching every event with reputation, confidence, and ATT&CK context is what turns raw telemetry into alerts an analyst can act on quickly.

The build itself is one of the more tractable parts of a security platform. The difficulty is operational. Indicators age fast, so freshness has to be monitored with loud failure alerts rather than assumed. Signals like TOR exit nodes or shared hosting ranges need to be treated as context weighed by the detection engine, not as verdicts that fire alerts on their own. Commercial feeds can add coverage but bring licensing costs, and ATT&CK coverage expands over time rather than arriving complete.

If you already run a detection pipeline, a good first step is to check when each of your feeds last updated successfully and what happens, visibly, when one stops. If you're planning or rebuilding the enrichment layer of a security product and want an experienced second opinion, book a call with our engineering team.