Threat Intelligence Guide: CTI Lifecycle, Feeds and Sharing

Most threat intelligence programmes collect far more data than they ever turn into a decision, a detection or a blocked attack. Buying feeds is easy; deciding what you need to know, judging how far to trust a source, and getting the answer to the person who can act on it is the actual work. This guide covers the cyber threat intelligence (CTI) lifecycle, intelligence requirements, feeds and sources, the analytical models practitioners use (Pyramid of Pain, Cyber Kill Chain, Diamond Model, MITRE ATT&CK), source grading, sharing with TLP, STIX and TAXII, and how to measure whether intelligence changes outcomes. It is written for security operations, detection engineering and CTI teams, and for security leaders deciding how much intelligence capability to build or buy.

Key takeaways

• Requirements come first. Without written priority intelligence requirements, collection follows whatever feeds are available and analysts answer questions nobody asked.
• Indicators expire; behaviours last. On David Bianco's Pyramid of Pain, hash values and IP addresses are trivial or easy for an adversary to change, while detections built on tactics, techniques and procedures (TTPs) force them to learn new behaviour.
• Grade every source and every claim. The Admiralty system rates source reliability (A to F) and information credibility (1 to 6) separately, so a trusted source's surprising claim still gets checked.
• Share with labels and standards. TLP 2.0 sets who may see what, STIX 2.1 describes it, and TAXII 2.1 moves it over HTTPS. Without labels, partners stop sharing.
• Measure action, not volume. Count detections, hunts, patch decisions and blocked access that intelligence produced, not the number of indicators ingested.

What threat intelligence is, and the four levels

NIST SP 800-150 describes cyber threat information as any information that can help an organisation identify, assess, monitor and respond to cyber threats: indicators, adversary TTPs, suggested actions and the results of analysis. Intelligence is that information after it has been evaluated, put in context and related to a decision. A list of 50,000 IP addresses is data; "this access broker is selling VPN credentials for firms in our sector, and our VPN still accepts password-only logins for contractors" is intelligence.

Many organisations fold technical into tactical. The distinction that matters is between products that change a machine's behaviour (technical) and products that change a person's decision (the other three). Strategic reports differ from tactical ones less in subject than in audience: the same campaign becomes a budget question for the board and a detection backlog for engineers.

The CTI lifecycle and intelligence requirements

The lifecycle

CTI teams use the intelligence cycle inherited from government practice. Each phase has a concrete output; if a phase has no output, it is not happening.

1. Planning and direction: agree intelligence requirements with stakeholders and record them. Output: a requirements register.
2. Collection: gather data against those requirements from internal telemetry and external sources. Output: a collection plan showing which source answers which requirement.
3. Processing: normalise, de-duplicate, translate and enrich (WHOIS, passive DNS, sandbox results). Output: structured data, usually STIX objects in a threat intelligence platform (TIP).
4. Analysis and production: test hypotheses, assess confidence, relate findings to your environment. Output: finished intelligence, from a one-paragraph flash alert to a strategic assessment.
5. Dissemination: deliver to the right consumer in a usable form: detection content to the SIEM, a briefing to executives, a TLP-marked report to partners.
6. Feedback: ask consumers whether the product was timely, relevant and actionable, and revise requirements. This is the phase most often skipped.

Intelligence requirements and the collection plan

Priority intelligence requirements (PIRs) are the few questions leadership most needs answered. They should be specific to your business, revisited at least annually and after major changes such as an acquisition or a new market.

• Weak: "What are the latest threats?"
• Strong: "Which ransomware groups are gaining initial access to manufacturers through edge devices or stolen VPN credentials, and which of their techniques can we not yet detect?"
• Strong: "Are credentials, session tokens or API keys belonging to our staff, suppliers or workloads being sold or published?"
• Indications and warnings: for each PIR, list observable signs that the threat is materialising (for example exploitation of a vulnerability in a product you run appearing in a government advisory) so analysts know what should trigger an alert to leadership.

Sources and feeds

ISACs grew out of US Presidential Decision Directive 63 of May 1998, which asked each critical infrastructure sector to set up a sharing organisation; most operate 24/7 threat warning for members. Joining your sector's ISAC is usually the best-value first external source. CISA's own product types distinguish a Cybersecurity Advisory (in-depth, with TTPs, IOCs and mitigations) from an Alert (short summaries) and an Analysis Report (in-depth analysis of a new threat).

Feed aggregation: a TIP de-duplicates indicators across feeds, records which source supplied each one, scores them and pushes curated sets to controls. MISP, an open source platform for collecting, storing, distributing and sharing indicators, adds correlation, taxonomies, galaxies (including ATT&CK) and STIX export. OpenCTI, also open source, structures knowledge on a STIX2-based schema and integrates with MISP and ATT&CK. Before adding a feed, sample a week of its indicators against your own logs: if almost nothing matches and the rest is already in another feed, it adds cost, not coverage.

Analytical models: Pyramid of Pain, Kill Chain, Diamond and ATT&CK

The Pyramid of Pain

David J. Bianco's Pyramid of Pain (2013) ranks indicator types by how much pain denying them causes the adversary. The labels below are from his diagram.

Bianco notes that hashes are so easy to change that in many cases "it may not even be worth tracking them". The practical lesson is to spend analyst time on the top three levels and automate the bottom three.

Comparing the models

The Kill Chain paper's central argument still holds: "just one mitigation disrupts the chain and the adversary." The models are complementary: the Diamond Model organises what you know about an event, ATT&CK names the behaviour, and the Kill Chain shows where in the intrusion you can intervene.

Grading sources and expressing confidence

The Admiralty (NATO) system grades source and information separately. A rating of B2 means a usually reliable source reporting something probably true.

• Do not change the scale: define what each grade means for your sources, but keep the standard criteria so partners read "B2" the same way.
• Grade by topic: a vendor that is excellent on ransomware may be weak on state actors. Promote and demote sources as evidence accumulates.
• Use consistent probability language: the UK Professional Head of Intelligence Assessment (PHIA) Probability Yardstick maps terms to ranges, for example "highly likely" to roughly 80% to 90% and "remote chance" to 5% or less. Pair it with a separate analytical confidence rating (high, moderate, low) that reflects the quality of evidence.
• Carry grades into tooling: store ratings as tags in the TIP so automated scoring and decay can use them.

Sharing: TLP, STIX, TAXII and formats

FIRST's TLP 2.0 has been authoritative since August 2022; it replaced TLP:WHITE with TLP:CLEAR and added AMBER+STRICT. Update templates, TIP marking definitions and email footers that still use version 1.0 labels.

• STIX 2.1: the OASIS CTI Technical Committee's JSON language for CTI. It defines 18 domain objects (including Indicator, Malware, Threat Actor, Intrusion Set, Campaign, Attack Pattern, Vulnerability, Report and Course of Action), cyber-observable objects (such as Domain-Name, IPv4-Addr and File, which took over the role of the separate Cyber Observable eXpression, CybOX, used with STIX 1.x) and two relationship objects, Relationship and Sighting. Version 2.1 added a confidence property.
• TAXII 2.1: a RESTful protocol over HTTPS for exchanging STIX. Servers expose API Roots containing Collections (request and response); Channels for publish and subscribe are only reserved in 2.1. Clients discover servers through a taxii2 DNS SRV record or the /taxii2/ endpoint. Authenticate TAXII clients and scope each credential to the collections it needs.
• IODEF (RFC 7970): an XML format, still used by some CSIRTs, for exchanging incident reports and indicators. Most new tooling uses STIX.
• Sharing policy: SP 800-150 recommends defining sharing goals, scoping what can be shared, setting handling rules and joining existing communities. Have legal and privacy teams pre-approve categories (indicators, sanitised TTPs) so analysts can share in hours, not weeks, and strip customer and employee personal data from anything outbound.

Turning intelligence into action

The indicator lifecycle

1. Ingest into the TIP with source, TLP marking and Admiralty grade.
2. Enrich and score: add context (first seen, related campaigns) and drop known-benign values (cloud provider ranges, popular domains) using warning lists.
3. Deploy in detect-only mode first: alert, do not block, until the indicator set has run for an agreed period without disrupting legitimate traffic. Keep the ability to withdraw a set in one action.
4. Record sightings: a hit in your environment is intelligence in itself; feed it back to the TIP and, where TLP allows, to the source.
5. Expire: give each indicator type a lifetime. MISP's decaying model (since version 2.4.116) lowers each indicator's score over time from a base score derived from its tags, and resets the score when a new sighting arrives.

From TTPs to detections

For each actor relevant to your PIRs, map reported techniques to ATT&CK, compare them with your detection coverage, and turn gaps into a detection engineering backlog or hunt hypotheses. A joint advisory that lists techniques and mitigations is a ready-made hunt plan: search back over the retention period for each behaviour before writing new rules.

Strategic action

Feed strategic assessments into risk scenarios, budget cases and tabletop exercises. Intelligence that an actor routinely abuses help desk resets should change the help desk procedure, not only the SIEM.

Where identity fits

Credentials are the most directly actionable intelligence an organisation can receive. Valid Accounts (T1078, including T1078.004 Cloud Accounts) and Unsecured Credentials (T1552, including T1552.001 Credentials In Files and T1552.004 Private Keys) recur across actor reporting, and the response is an identity action: revoke, rotate, reset, require stronger authentication. The Snowflake breach showed infostealer-harvested credentials unlocking customer accounts that lacked MFA. Monitoring infostealer and breach data for your domains, and for your API keys and tokens in public code, belongs in the collection plan. See the Leaked Credential Response Playbook and the ITDR Guide.

Building the programme: decisions and rollout

• Small organisations (no dedicated analyst): consume rather than produce. Join an ISAC, subscribe to government advisories, use the managed intelligence in your EDR or MDR service, and write three PIRs. A TIP is rarely worth it at this size.
• Mid-sized organisations: one or two analysts, an open-source or commercial TIP, a written collection plan and a monthly briefing. Prioritise tactical intelligence that feeds detection engineering.
• Large or high-threat organisations: a CTI team covering strategic, operational and tactical products, commercial services for underground and actor collection, active two-way sharing and producing intelligence for peers.
• Build or buy: buy collection that you cannot do yourself (underground forums, large-scale infrastructure scanning); build analysis, because only your team knows your environment.

1. Write PIRs with stakeholders and get them signed off by the CISO.
2. Inventory existing sources and map them to PIRs; cancel feeds that answer none.
3. Stand up the TIP or sharing platform and integrate it with the SIEM and EDR in detect-only mode.
4. Pilot automated blocking on one high-confidence, curated indicator set with a named owner and a documented rollback (remove the set from the enforcement list).
5. Start regular products: a weekly tactical note, a monthly operational brief, an annual strategic assessment.
6. Join a sharing community and agree internal approval for outbound sharing.
7. Review requirements and source grades every quarter using consumer feedback.

Measurement and framework mapping

What to log and measure

Log the TIP's ingestion, scoring and export activity, each indicator's matches in SIEM and EDR, and the analyst decisions taken. Useful metrics:

• Requirement coverage: percentage of PIRs with at least one active source and a product delivered in the last period.
• Actioned intelligence: number of detections, hunts, patch priority changes and access revocations attributed to intelligence each month.
• Indicator precision: share of indicator matches confirmed as malicious, by source. Use it to grade and prune feeds.
• Time to action: median time from receiving a relevant advisory or credential exposure to completed response.
• ATT&CK coverage for priority actors: share of their documented techniques with a tested detection.
• Consumer feedback: share of products rated timely and actionable by recipients.

Framework mapping

Common failure patterns

• Feeds without requirements: millions of indicators ingested, no question answered, and analysts drowning in low-value matches.
• Blocking on raw feeds: pushing unvetted IP lists to firewalls blocks shared cloud and CDN addresses and erodes trust in the programme.
• Intelligence that stops at the report: knowing about a supplier compromise is not the same as acting on it. In the Cloudflare Thanksgiving breach, four credentials left unrotated after the Okta breach let a nation-state attacker in.
• Indicators that never expire: stale IPs and domains generate false positives for years and hide real matches.
• Ignoring TLP or sharing nothing: breaching handling rules gets you dropped from trust groups; only consuming means peers stop prioritising you.
• Missing identity collection: no monitoring for exposed credentials, tokens and keys, so the warning arrives from the attacker. In the Salt Typhoon telecom intrusions, stolen credentials and network device secrets kept attackers inside for years.

Practitioner checklist

• Write three to ten priority intelligence requirements with named stakeholders and review them annually.
• Map every source to the requirements it answers and cancel feeds that answer none.
• Grade sources and information with the Admiralty system and use consistent probability language.
• Mark everything with TLP 2.0 labels and remove TLP 1.0 labels from templates and tooling.
• Exchange machine-readable intelligence as STIX 2.1 over TAXII 2.1 with scoped client credentials.
• Deploy new indicator sets in detect-only mode, with expiry and a one-step rollback.
• Map priority actors' TTPs to ATT&CK and track detection coverage gaps.
• Monitor for exposed credentials, tokens and API keys and route hits to identity response.
• Measure actioned intelligence and consumer feedback, not indicator volume.

Standards and references

• NIST: SP 800-150, Guide to Cyber Threat Information Sharing
• FIRST: Traffic Light Protocol (TLP) Version 2.0
• OASIS CTI TC: Introduction to STIX
• OASIS CTI TC: Introduction to TAXII
• MITRE: ATT&CK Resources
• Lockheed Martin: Intelligence-Driven Computer Network Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains
• Caltagirone, Pendergast and Betz: The Diamond Model of Intrusion Analysis
• David J. Bianco: The Pyramid of Pain

Related NHI Mgmt Group resources: ITDR Guide · Leaked Credential Response Playbook · Windows Event Log Guide · Patch Management Guide · Ransomware Prevention Guide