Most threat intelligence platform rollouts connect every available feed in week one, push the result to the SIEM and firewalls in week two, and spend the next year cleaning up false positives, expired indicators and a block that took down a payment provider. A threat intelligence platform (TIP) aggregates, normalises, scores and distributes intelligence, so the order in which it is switched on decides whether it becomes a trusted source or an indicator warehouse. This playbook sets out a vendor-neutral, phased rollout: the decisions to make before the first feed, how to onboard sources against intelligence requirements, how to consume intelligence in detect-only mode before blocking, how to share safely, and how to show it is working. It is for CTI leads, SOC managers and security platform owners who have already chosen a platform. Choosing one is covered in the Threat Intelligence Platform Buyer's Guide; this page is the delivery plan.
Key takeaways
- Requirements before feeds. Every source onboarded should answer at least one priority intelligence requirement (PIR); a feed that answers none is cost and noise.
- Decide the marking and data model on day one. TLP 2.0 labels, STIX 2.1 objects and the confidence scale are hard to retrofit across millions of objects.
- Every indicator needs an expiry. Decay and safelisting are configured before anything reaches a detection or blocking tool, not after the first false positive.
- Detect first, block later. Push intelligence as watchlists and collect sightings for an agreed period before any automated blocking, and then only for curated, capped sets.
- The TIP is a privileged non-human identity hub. It holds feed keys, sharing credentials and write access to enforcement tools; each integration gets its own scoped identity and an owner before go-live.
Before you start: decisions that are hard to change later
Write a short design record and get it approved by the CTI lead, the SOC manager, the platform owner and the owners of every tool the TIP will write to. NIST SP 800-150, the Guide to Cyber Threat Information Sharing, recommends setting sharing goals, identifying sources, defining the scope of sharing and establishing rules that control the publication and distribution of threat information; those choices belong in this record.
| Decision | Options | What to consider |
|---|---|---|
| Deployment model | SaaS; self-hosted; TIP module inside a SIEM, SOAR or XDR | SaaS removes patching and storage work but places restricted intelligence with a provider. Self-hosted gives control of data residency and handling at the cost of running the database, search and queue tiers. A built-in module reduces integration work but may limit sharing and export. |
| Data model | Native STIX 2.1; proprietary model with STIX import and export | STIX 2.1 (OASIS Standard, Errata 01 dated 2 April 2025) defines objects such as Indicator, Malware, Threat Actor, Intrusion Set, Attack Pattern and Vulnerability, plus Relationship and Sighting objects. A native model keeps relationships intact when you share or migrate. |
| Marking scheme | TLP 2.0 only; TLP plus internal handling labels | TLP 2.0 has been authoritative since August 2022 and has five labels: TLP:RED, TLP:AMBER, TLP:AMBER+STRICT, TLP:GREEN and TLP:CLEAR. Decide how each label maps to platform groups and whether object-level or granular markings are enforced. |
| Confidence and scoring | STIX confidence (0 to 100); platform score; both | Agree one scale and what it means for action, for example the minimum confidence for a watchlist and for a block list. Changing the meaning later invalidates every historical decision. |
| Trust groups and tenancy | One instance; separate instances or API roots per trust group | TAXII 2.1 groups collections under API roots, often one per trust group. Separate roots or instances keep sector-sharing intelligence apart from internal case material. |
| Where intelligence goes | SIEM only; SIEM plus EDR, firewall, DNS and email controls; via SOAR | Routing enforcement through a SOAR gives one approval and rollback point; direct pushes are simpler but multiply write credentials. Each destination has its own list size limits. |
| Credential storage | Platform credential store; external secrets manager | An external secrets manager gives one rotation and audit point for feed keys, TAXII credentials and enforcement API tokens. |
Small versus large organisations: a small team with one analyst, or none, usually gets more from curated intelligence inside its SIEM or EDR, a sharing community membership and three PIRs; a standalone TIP is rarely worth running at that size. A mid-sized team benefits from a TIP fed by a short list of graded sources and pushing watchlists to the SIEM. A large CTI function needs trust-group separation, two-way sharing, analyst collaboration and reporting, and a formal change process for anything that writes to enforcement tools.
The rollout at a glance
| Phase | Main outputs | Exit criteria |
|---|---|---|
| 0. Requirements and design | Signed PIRs, source inventory mapped to PIRs, design record, baseline metrics | Every planned source maps to a PIR and a consumer; marking and confidence scale approved |
| 1. Platform foundations | Hardened platform, SSO and marking-based roles, integration identities, audit log export, backups | Platform audit log reaches the SIEM; no shared or personal credentials in integrations |
| 2. Ingestion and curation | Feeds onboarded in priority order, normalisation, deduplication, scoring, decay and safelists | Each feed has an owner, a grade and a decay rule; safelist blocks known-good infrastructure |
| 3. Detect-only consumption | Watchlists in the SIEM and EDR, sightings returned to the TIP, enrichment for analysts | Indicator precision per source measured for the agreed period |
| 4. Gated enforcement | Curated, capped block lists with expiry and a tested rollback | No unplanned business impact; rollback rehearsed for each destination |
| 5. Share and operate | Outbound sharing with approval, quarterly source review, regular intelligence products | Sharing approvals recorded; low-value feeds cancelled |
Phases 0 and 1: requirements and foundations
- Write PIRs with consumers: five to ten questions agreed with the SOC, incident response, vulnerability management, fraud and leadership, each with a named consumer. The Threat Intelligence Guide covers how to write them; this rollout uses them as the admission test for every source and integration.
- Inventory sources: government and CERT advisories, sharing communities, commercial feeds already licensed, open source feeds and internal sources such as incident findings, phishing reports and sandbox output. Record format, volume, licence terms (especially redistribution limits) and default marking for each.
- Baseline: record current false positive rates for intelligence-driven alerts, time from advisory to action, and analyst hours spent on manual indicator handling. Without a baseline the rollout cannot show value.
- Harden the platform before loading data: single sign-on with phishing-resistant MFA for administrators, roles mapped to markings so TLP:RED and TLP:AMBER+STRICT material is visible only to named groups, audit log export to the SIEM, encrypted backups, and network access limited to the integrations that need it. The detail is in Securing the threat intelligence platform (TIP) itself.
- Create integration identities: one identity per feed, per sharing partner and per destination tool, read-only wherever possible, credentials in the vault, an owner and a review date, before the integration is enabled.
Phase 2: ingestion and curation
Onboard sources in waves, not all at once, so each one can be graded before the next arrives.
| Wave | Sources | Why this order |
|---|---|---|
| 1 | Internal intelligence: incident indicators, phishing submissions, sandbox output | Highest relevance and known provenance; proves the pipeline end to end |
| 2 | Government and CERT advisories, sector sharing community | Curated, contextual, usually well marked |
| 3 | Commercial feeds mapped to PIRs | Higher volume; grade against waves 1 and 2 |
| 4 | Open source feeds, one at a time | Most variable quality and overlap; keep only those that add unique, accurate matches |
- Normalise and deduplicate: map every source to the agreed data model and merge duplicate observables while keeping each source reference, so precision can be measured per source later.
- Score and grade: assign a source reliability grade and a confidence value on the agreed scale. Record the default marking a source's content inherits; never downgrade a marking during import.
- Decay: set an expiry or decay rule by indicator type before any export. Network indicators such as IP addresses usually need far shorter lifetimes than file hashes; the exact values are a local decision, documented in the design record.
- Safelist: load known-good infrastructure before the first export: your own domains and address ranges, cloud provider and content delivery ranges you rely on, payment and identity providers, popular resolvers and update services. A safelist match should stop an indicator reaching any blocking destination.
- Feed health: alert when a feed stops updating, changes format or spikes in volume. A silent feed and a feed that suddenly delivers a million indicators are both faults.
Phases 3 and 4: from detect-only to gated enforcement
In phase 3, push intelligence to the SIEM and EDR as watchlists or match lists that raise alerts but take no action. Return each confirmed or dismissed match to the TIP as a sighting (STIX 2.1 defines a Sighting object for this), so precision can be measured by source and indicator type. Run detect-only for an agreed period, typically several weeks, and long enough to cover monthly business cycles.
In phase 4, move only curated sets to blocking. Use tiers so the blast radius is explicit:
| Tier | Example use | Gate | Rollback |
|---|---|---|---|
| Enrich | Context in alerts and cases; no matching | None | Not needed |
| Watch | SIEM and EDR match lists that raise alerts | Confidence above the watch threshold, safelist passed | Remove the list entry |
| Block, automatic | High-confidence internal and government indicators to DNS or proxy block lists, with expiry and a per-push cap | Curated set with a named owner; cap on additions per run | Restore the previous list version from history |
| Block, approved | Firewall, email gateway or EDR prevention entries | Analyst approval, or two-person approval for network-wide entries | Revert from list history; notify affected service owners |
Test and roll back: before each destination goes live, push a test indicator that resolves to a harmless internal address, confirm it appears and blocks, then confirm removal works within the agreed time. Keep a versioned copy of every list pushed, so a bad push can be reverted in one change. Routing blocks through the SOAR, where one is in place, gives a single approval and undo point; see the SOAR platform rollout playbook.
Phase 5: sharing out and operating
- Outbound sharing: agree who may publish, to which trust groups and under which TLP label, and record an approver for every publication. TAXII 2.1 (OASIS Standard, 10 June 2021) runs over HTTPS with HTTP authentication, uses the
application/taxii+jsonmedia type and organises sharing into collections under API roots; channels are reserved in 2.1 and not yet specified. The STIX and TAXII Guide explains the formats. - Sanitise before sharing: strip internal hostnames, user names, victim details and customer data from incident-derived intelligence, and respect redistribution limits in feed licences.
- Operate: quarterly source review against PIRs and precision, cancelling feeds that answer no requirement; monthly review of safelists and block list expiry; regular intelligence products for consumers. The Threat Intelligence Feed Evaluation Guide gives the grading method.
Where identity fits
A TIP connects to many systems at once: it pulls with feed API keys, exchanges with partners using TAXII credentials, and writes to SIEM, EDR, firewall, DNS and email controls with tokens that can change what those controls block. Treat each as a non-human identity with an owner, least privilege, vault storage and rotation, and alert on any of them being used from outside the platform. Intelligence about your own identities matters too: leaked credentials, exposed API keys and impersonation of your domains are high-value PIRs for most organisations. See the Threat Intelligence for Identity and NHI Guide and the Service Account Security Guide.
Detection and measurement
Log ingestion, scoring, marking changes, exports, publications, role changes and integration credential use, and send the TIP's own audit log to the SIEM. These rollout metrics show the platform is being implemented well; the programme outcome metrics live in the Threat Intelligence Guide.
| Metric | Definition | What good looks like |
|---|---|---|
| Source admission | Active sources mapped to at least one PIR and a named owner ÷ active sources | 100% before phase 3 exits |
| Expiry coverage | Exported indicators carrying an expiry or decay rule ÷ exported indicators | 100% |
| Sighting feedback rate | Indicator matches with a sighting or analyst verdict returned to the TIP ÷ indicator matches | Rising to most matches by the end of phase 3 |
| Safelist catch rate | Indicators stopped by the safelist before export, reviewed for source quality | Tracked per source; a high rate marks a feed to regrade |
| Business-impacting blocks | Blocks caused by TIP pushes that affected a legitimate service, with time to roll back | Zero in phase 4, rollback inside the agreed time when one occurs |
| Integration identity hygiene | Integration credentials that are per integration, vaulted, owned and within rotation ÷ all integration credentials | 100% |
Common failure patterns
- Feeds first, requirements later: dozens of overlapping sources inflate volume and licence cost and make it impossible to say which source added value.
- No expiry: years-old IP addresses that now belong to cloud tenants or shared hosting stay on watchlists and block lists, generating false positives and blocks.
- Blocking before measuring: automated blocking switched on without a detect-only period, a safelist or a cap, so the first bad indicator from a feed blocks a supplier or a content delivery network.
- Markings lost in transit: intelligence received as TLP:AMBER+STRICT exported to a wider group, or published to a sharing community, because the import did not carry markings or roles were not mapped to them.
- Shared write credentials: one administrator token used for every enforcement destination, so a TIP compromise or a leaked key can change every block list at once.
- No feedback loop: sightings never return to the TIP, so source grades never change and poor feeds are renewed by default.
Framework mapping
| Rollout area | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | CIS Controls v8.1 |
|---|---|---|---|
| Requirements and source onboarding | ID.RA-02, ID.RA-03 | PM-16, SI-5, RA-3 | Control 17 |
| Detect-only consumption and enrichment | DE.AE-07, DE.AE-02 | SI-4, RA-10 | Control 8, Control 13 |
| Gated enforcement and rollback | RS.MI-01, PR.PS-01 | CM-3, IR-4 | Control 13 |
| Platform access, markings and integration identities | PR.AA-05, PR.DS-01 | AC-2, AC-6, IA-5 | Control 5, Control 6 |
| Platform audit log and backups | PR.PS-04 | AU-9, CP-9 | Control 8, Control 11 |
| Feed suppliers and sharing partners | GV.SC-07 | SR-3 | Control 15 |
Practitioner checklist
- PIRs signed off and every planned source and destination mapped to one.
- Design record approved: deployment model, data model, TLP 2.0 mapping, confidence scale, trust groups and enforcement routing.
- Platform hardened, roles mapped to markings and audit log flowing to the SIEM before the first feed loads.
- One scoped identity per feed, partner and destination, vaulted, owned and dated.
- Sources onboarded in waves with a grade, a default marking and feed health alerts.
- Decay rules and a safelist in place before any export.
- Detect-only period completed with sightings returned and precision measured per source.
- Blocking limited to curated, capped sets with versioned lists and a rehearsed rollback per destination.
- Outbound sharing approvals recorded and incident-derived intelligence sanitised.
- Quarterly source review scheduled, with authority to cancel feeds.
Standards and references
- NIST: SP 800-150, Guide to Cyber Threat Information Sharing
- OASIS: STIX Version 2.1
- OASIS: TAXII Version 2.1
- FIRST: Traffic Light Protocol (TLP) 2.0
- NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- ASD's ACSC with CISA and partners: Implementing SIEM and SOAR Platforms, Practitioner Guidance
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls
Related NHI Mgmt Group resources: Threat Intelligence Platform Buyer's Guide, Securing the threat intelligence platform (TIP) itself, Threat Intelligence Guide, STIX and TAXII Guide, Threat Intelligence Maturity Model.