What is Threat Intelligence?

Back to learning

Threat Intelligence is evidence that helps a security team decide what to do with a request, account event, API call, or incident. It is not useful because it has a large feed attached to it. It is useful when it changes a decision at the right point in the request path: allow the request, challenge it, rate limit it, block it, log it for review, or tune policy after the fact.

For web and API security, threat intelligence is usually decision context. An IP address may have a history of brute forcing. A domain may be tied to phishing infrastructure. A fingerprint may match tooling seen in previous abuse. A route may be under the same pressure as a current campaign. None of those signals should be treated as proof by itself, especially when shared networks, carrier-grade NAT, residential proxies, VPNs, and normal browser drift can all produce misleading evidence.

Threat Intelligence as Decision Context

The practical question is: what should the edge know before the origin spends work on the request?

Raw intelligence starts as logs, incident notes, third-party feeds, open source reports, malware research, vulnerability data, or customer-specific observations. It becomes useful only after it is normalised, deduplicated, given confidence, and tied to the routes or workflows being protected. A feed that is accurate for one industry may be noisy for another. A signal that is useful on a login API may be too aggressive for a public content page.

This is why threat intelligence should be attached to policy with context. IP reputation can support a blocklist, but it can also be used more carefully: deny known brute-force sources on POST routes, rate limit suspicious infrastructure on expensive APIs, or log uncertain traffic until there is enough evidence to act. The same signal can have different outcomes depending on route sensitivity, account state, current attack pressure, and false-positive risk.

Signals, Formats, and Feeds

Most teams will see threat intelligence in a few familiar forms:

• Indicators of compromise (IOCs) such as IP addresses, domains, URLs, file hashes, certificate data, and known malicious infrastructure.
• Threat intelligence feeds from commercial, community, government, open source, and internally managed sources.
• STIX and TAXII for structured threat information and automated exchange between tools.
• MITRE ATT&CK as a shared vocabulary for describing tactics, techniques, and procedures.
• Internal evidence from WAF events, bot decisions, rate-limit events, incident reviews, and log forwarding pipelines.

Structured formats help machines exchange intelligence, but they do not decide what is safe. Human-readable reports and incident notes still matter because they explain why a signal is relevant, where it was observed, and how confident the source is.

From Feed to Edge Action

At the edge, threat intelligence normally enriches an existing request decision. A request to a password reset route from an IP category associated with credential attacks is more important than the same signal on a cached image. A TLS or HTTP fingerprint linked to automation is more useful when it is combined with bot behaviour, residential proxy status, request cadence, and response-code loops. The aim is not to find one perfect signal; it is to build enough evidence to choose a proportionate action.

Good implementations keep the decision record visible. Operators should be able to see which feed or category matched, which route was affected, what action was taken, and whether the result helped or harmed legitimate users. Without that feedback, threat intelligence becomes a black box that either blocks too much or is ignored because nobody trusts it.

Quality and Limits

Threat intelligence needs regular review. Sources age, attackers rotate infrastructure, and legitimate users share networks that may have a bad history. Confidence, freshness, relevance, and coverage matter more than the number of feeds connected.

The safest operating model treats intelligence as one risk input beside application context. Use IP Intelligence to add reputation and category context, use logs to preserve evidence, and keep enough review space for uncertain cases. The goal is not to make every decision automatic. The goal is to make defensive decisions earlier, with clearer evidence and fewer avoidable false positives.