What good is a threat feed nobody reads? That question underlies almost every failed threat intelligence program. Teams buy a subscription, plug in a feed, watch alerts pile up, and quietly stop looking. Six months later the renewal comes up and nobody can explain what the program delivered.
Setting up threat intelligence properly is less about buying data and more about building a loop: decide what you need to know, collect it, turn it into something a human can act on, and feed it back into decisions. This guide walks through that loop step by step, with the practical mistakes that trip up most teams and the standards worth building on.
Start With Decisions, Not Feeds
The most common setup mistake is starting with tools. Vendors make this easy, because buying a feed feels like progress. But intelligence only has value when it changes a decision: patching a system sooner, blocking a domain, briefing executives, or accepting a risk with eyes open.
Before touching a tool, write down the decisions the program must support. A typical list looks like this:
- Prioritization decisions. Which vulnerabilities get patched first this week?
- Detection decisions. Which new behaviors should trigger an alert in the SOC?
- Blocking decisions. Which indicators go into the firewall or proxy?
- Risk decisions. Which threat actors are most likely to target this organization, and why?
- Communication decisions. What does the board need to hear each quarter?
Each decision implies a requirement: a specific question with an owner and a deadline. “Which ransomware families are actively exploiting internet-facing VPN appliances right now?” is a requirement. “Get threat intel” is not.
This discipline traces back to the classic intelligence cycle of planning, collection, processing, analysis, and dissemination, which predates cyber threat intelligence by decades. Borrowing it keeps a program honest, because every stage has a deliverable. (Cyber Threats and Advisories)
Map Your Assets and Attack Surface First
Intelligence about threats means little without context about what is being threatened. A feed item about a credential-stealing malware family matters enormously to a company with thousands of remote workers and hardly at all to an air-gapped industrial site.
Build a simple asset inventory before buying anything. Note which systems face the internet, which hold regulated data, which support revenue, and which would hurt most if unavailable for a week. Then note the crown jewels and the paths an attacker would take to reach them.
This is where frameworks earn their keep. MITRE ATT&CK gives a shared vocabulary of adversary tactics and techniques, so a detection engineer and a threat analyst can describe the same behavior the same way. Mapping existing detections to ATT&CK techniques exposes gaps quickly, and it gives collection a target list. If nobody is watching for a technique that appears constantly in incident reports for your sector, that is a requirement worth writing down.
Choose the Right Intelligence Sources and Levels
Threat intelligence comes in layers, and a healthy program uses several. The layers differ in cost, freshness, and how much human judgment they need.
| Level | What it gives you | Typical sources | Main risk |
|---|---|---|---|
| Strategic | Actor motivations, sector trends, geopolitical context | Vendor reports, government advisories, industry sharing groups | Too vague to act on |
| Operational | Campaign details, actor infrastructure, tooling | Commercial feeds, ISACs, vendor research | Requires skilled analysis |
| Tactical | Attacker tactics and techniques | ATT&CK mappings, incident write-ups | Ages quickly |
| Technical | Indicators such as IPs, domains, file hashes | Open source feeds, commercial feeds, sensor data | High volume, short shelf life |
Technical indicators are the easiest to collect and the easiest to overvalue. Most malicious IP addresses go stale within days or weeks, and blocking them after the fact rarely stops a determined adversary. Treat indicators as one input among several, not the whole program.
Free sources matter too. Government advisories, sector Information Sharing and Analysis Centers, and open research from reputable vendors cover a surprising amount of ground. For teams building out a broader data picture, guides on what a cyber threat intelligence map actually shows can help frame how sources get combined into a view of the threat landscape.
A practical rule: start with two or three sources you can genuinely process, and add more only when the team has spare capacity. Ten feeds nobody reads are worse than two feeds that feed a workflow.
Build the Collection and Processing Pipeline
Collection is plumbing, and it needs to be boring. The goal is to get data from sources into a normalized store without manual copy-paste.
Standards make this possible. STIX 2.1 (Structured Threat Information Expression) provides a machine-readable format for indicators, threat actors, and relationships between them, and TAXII 2.1 handles transport. Both are maintained by OASIS, and most serious platforms and feeds support at least one version. A frequent integration headache is version mismatch, since tools sometimes support STIX 2.0 but not 2.1 or the reverse. Confirm support before committing.
Processing steps to plan for:
- Deduplication. The same indicator arrives from five feeds. Store it once.
- Normalization. Convert formats, time zones, and indicator types into one schema.
- Enrichment. Add context such as geolocation, WHOIS age, passive DNS history, and whether the indicator has been seen in your own telemetry.
- Scoring. Apply confidence and relevance scores so analysts see the best material first.
- Aging. Set expiry rules so dead indicators do not linger in blocklists forever.
Enrichment is where many homegrown pipelines stall. It is also where the difference between a list and intelligence shows up. An IP address alone is trivia; an IP address linked to a named actor, first seen three days ago, communicating with a domain that resembles your brand, is intelligence.
Apply Sharing Rules Before You Share Anything
Intelligence programs live on sharing, and sharing without rules is how trust gets destroyed. The Traffic Light Protocol, maintained by FIRST, sets the expectations. TLP 2.0, published in 2022, replaced the older four-color scheme with five labels: CLEAR, GREEN, AMBER, AMBER+STRICT, and RED. Older documents still say TLP:WHITE, which maps to CLEAR, so expect to translate occasionally.
Practical rules that prevent embarrassment:
- Label every artifact at creation, not at sharing time.
- Never forward AMBER material to a mailing list without checking the source’s terms.
- Keep a log of what was shared with whom and under which label.
- Sanitize internal details before sharing externally, since indicators often reveal victim infrastructure.
For public-sector or critical-infrastructure teams, CISA’s Automated Indicator Sharing service and the guidance in NIST SP 800-150, Guide to Cyber Threat Information Sharing, are worth reading before drafting internal sharing policy. Both emphasize handling requirements and trust relationships over formats.
Turn Intelligence Into Detection and Response
This is the step where programs succeed or fail. Intelligence that never reaches a detection rule, a blocklist, or a briefing is a cost center.
Build explicit handoffs. A detection engineering workflow takes finished intelligence, extracts observable behaviors, and writes or tunes rules. A vulnerability management workflow takes exploitation reports and reorders the patch queue. An incident response workflow uses actor profiles to anticipate next moves during an active case.
Metrics keep these handoffs visible. Track how many intelligence reports produced a detection change, how many blocklist entries were actually hit, and how many incidents were informed by intelligence. If the numbers stay at zero, the program is producing reading material, not intelligence.
Tooling choices matter less than the workflow, but a few categories are worth knowing:
- Threat intelligence platforms (TIPs) aggregate, deduplicate, and enrich feeds. The term has no formal standard definition, so vendor capabilities vary widely.
- SIEM and detection platforms consume indicators and behavior rules. Integration quality matters more than feature lists.
- SOAR tools automate enrichment and response, which is how small teams handle volume.
Teams comparing commercial data options often find that contact and company data quality determines whether enrichment is useful at all; a look at best sales intelligence tools b2b contact data shows how similar data-quality trade-offs play out in a different market.
Staff the Program Realistically
A threat intelligence program needs three skills: collection and engineering, analysis, and consumer liaison. One person can cover all three in a small organization, but only if scope stays narrow.
Common staffing mistakes:
- Hiring analysts before building the pipeline. Analysts end up doing data janitor work.
- Skipping the liaison role. Nobody talks to the SOC or the business, so products go unread.
- Expecting 24/7 coverage from one person. Set service hours and be explicit about them.
Training helps more than most teams expect. Analysts who understand structured analytic techniques, such as competing hypotheses and key assumptions checks, produce better judgments than analysts who only know tools. The same reasoning discipline applies outside security; background on what artificial intelligence is and how does it work is useful for teams evaluating AI-assisted triage tools that claim to do analysis for them.
Measure, Report, and Iterate
Set a review cadence from day one. Monthly, review which requirements were met and which products were read. Quarterly, review source value against cost and drop anything unused. Annually, revisit the requirement list, because the business changes and so do the threats.
Useful measures include:
- Percentage of intelligence requirements answered on time
- Number of detection rules created or tuned from intelligence
- Analyst hours spent per finished product
- Consumer satisfaction, gathered by asking directly
The last one is uncomfortable and essential. If the SOC lead cannot name a single intelligence product that helped last quarter, the program needs redesign, not more feeds.
Avoid the Classic Setup Mistakes
A short list of traps that appear again and again:
- Buying feeds before defining requirements. Volume substitutes for direction.
- Treating indicators as the whole product. Context is the value.
- Ignoring internal telemetry. Your own logs are the best relevance filter you have.
- Sharing without labels. One leak ends a sharing relationship.
- No expiry on indicators. Stale blocks cause outages and erode trust.
- No feedback loop. Products nobody reads keep getting produced.
Each of these is fixable with process discipline rather than budget. That is encouraging news for small teams.
Conclusion
Setting up threat intelligence is a design problem before it is a purchasing problem. Define the decisions the program must support, inventory what you are defending, pick a small number of sources you can actually process, and build handoffs into detection, response, and risk management. Layer in sharing discipline through TLP 2.0 and the NIST guidance, staff for analysis rather than collection, and measure whether anyone’s behavior changed.
Do that, and the renewal conversation becomes easy: the program can point to detections written, incidents informed, and risks retired. Skip it, and the feeds keep arriving whether or not anyone reads them.
Frequently Asked Questions
What is threat intelligence in simple terms?
Threat intelligence is information about attackers and their methods, processed so that it supports a specific decision. That decision might be patching a system sooner, blocking a domain, or briefing leadership on risk. Raw data becomes intelligence only when it is contextualized, evaluated for relevance, and delivered to someone who can act on it.
How much does a threat intelligence program cost to start?
A minimal program can start close to free using government advisories, open research, and sector sharing groups, plus staff time. Costs rise with commercial feeds, a threat intelligence platform, and dedicated analysts. The bigger constraint is usually analyst hours rather than licensing, which is why scoping requirements tightly matters more than budget size.
Do small teams really need threat intelligence?
Yes, but narrowly scoped. A five-person security team cannot process ten feeds, and should not try. Two or three sources tied to a short requirement list, such as “which vulnerabilities in our stack are being exploited right now,” deliver real value. The goal is relevance, not coverage.
What is the difference between threat intelligence and threat hunting?
Threat intelligence is information about adversaries, processed for decision support. Threat hunting is a proactive search through your own environment for signs of compromise. Intelligence informs hunts by suggesting where to look, but hunting produces its own findings, which then feed back into the intelligence picture.
Which standards should a new program adopt first?
Start with MITRE ATT&CK for a shared vocabulary of adversary behavior and the Traffic Light Protocol 2.0 for sharing labels, since both are lightweight and widely understood. Add STIX 2.1 and TAXII 2.1 when automating exchange, and consult NIST SP 800-150 before drafting sharing policy. Confirm version support in any tool before relying on it.
How do you know if a threat intelligence program is working?
Look for changed behavior, not volume. Signs of health include detection rules created or tuned from intelligence, incidents where intelligence shaped the response, blocklist entries that actually matched traffic, and consumers who can name products they used. If nobody can point to a decision that changed, the program needs redesign rather than more sources.
