Many threat intelligence platforms end up as expensive indicator warehouses: millions of ageing IP addresses and hashes pushed to the SIEM, more false positives, and no analyst able to say which intelligence changed a decision. A threat intelligence platform (TIP) should aggregate and normalise intelligence from feeds, sharing communities and your own incidents, score and age it, enrich it, and push the right subset to detection and blocking tools. Some products are standalone TIPs, some are modules inside SIEM, SOAR or extended detection suites, and some are open source. This vendor-neutral guide is for CTI leads, SOC managers and security architects writing requirements or running an RFP. Our Threat Intelligence Guide covers the CTI discipline itself; this page is about choosing the platform.
Key takeaways
- Write intelligence requirements before you buy. Priority intelligence requirements (PIRs) decide which feeds, scoring and integrations you need; a TIP bought without them collects data nobody uses.
- Insist on open standards. Native STIX 2.1 and TAXII 2.1, MISP interoperability and correct TLP 2.0 handling keep your intelligence portable and shareable.
- Scoring and ageing matter more than volume. Indicators must carry confidence, source reliability and an expiry, and stop reaching blocking tools when they decay.
- The TIP holds keys to your security stack. API credentials for the SIEM, SOAR, EDR and firewalls make it a high-value non-human identity hub; score its security as hard as its features.
- Prove value with your own incidents. A proof of value should show intelligence that would have detected, blocked or prioritised something real, not a demo tenant full of feeds.
Define requirements
- Intelligence requirements: write five to ten PIRs with stakeholders, for example "Which ransomware groups target our sector, and what initial access do they use?" or "Are our domains, executives or credentials being sold or impersonated?" Map each to a consumer (SOC, incident response, vulnerability management, fraud, leadership). NIST CSF 2.0 expects both receiving and using intelligence: ID.RA-02 "Cyber threat intelligence is received from information sharing forums and sources" and DE.AE-07 "Cyber threat intelligence and other contextual information are integrated into the analysis". See the Threat Actor Groups Guide and the Ransomware Groups Guide for adversary context.
- Sources: list open source feeds, commercial feeds you already pay for, government and CERT advisories, ISAC membership, vendor reports and internal sources (incident findings, phishing submissions, sandbox output). The volume and formats drive storage, licensing and normalisation needs.
- Sharing obligations: whether you must share back with an ISAC, a sector community or a national scheme, and under which handling rules. NIST SP 800-150 gives "guidelines for establishing and participating in cyber threat information sharing relationships".
- Consumers and tools: SIEM, SOAR, EDR, firewalls and secure web gateways, DNS filtering, email security, vulnerability management and ticketing, each with its own API and indicator limits.
- Team capacity: how many analysts will curate intelligence. A team of one needs automation and curated sources; a mature CTI team needs a knowledge graph, collaboration and reporting.
Size changes the answer. Many small and mid-sized organisations are better served by curated intelligence inside their SIEM, EDR or managed detection service, plus ISAC membership, than by a standalone TIP. Larger organisations with a CTI function, several detection tools and sharing obligations usually justify a TIP. Open source platforms such as MISP suit teams with engineering capacity; commercial TIPs trade licence cost for supported connectors and less maintenance.
| Standard | What it does | Check during evaluation |
|---|---|---|
| STIX 2.1 (OASIS Standard, June 2021) | JSON model for indicators, threat actors, malware, attack patterns, relationships and sightings; confidence "MUST be a number in the range of 0-100"; revocation is permanent | Round-trip import and export without losing relationships, confidence, valid_until or revoked status |
| TAXII 2.1 | HTTPS REST API with API Roots and Collections; discovery at /taxii2/; STIX 2.1 mandatory to implement | Acts as both TAXII client and server; per-collection access control; pagination for large pulls |
| FIRST TLP 2.0 | TLP:RED, TLP:AMBER, TLP:AMBER+STRICT, TLP:GREEN, TLP:CLEAR; authoritative since August 2022 | All five labels supported and enforced on export; legacy TLP:WHITE mapped to TLP:CLEAR |
| MISP | Open source sharing platform with taxonomies, galaxies, STIX export and a REST API (PyMISP) | Bidirectional sync with MISP communities, preserving tags, sightings and distribution settings |
| MITRE ATT&CK | Enterprise, Mobile and ICS published as STIX 2.1 collection bundles per release | Version-aware ATT&CK import, so mappings survive technique changes between releases |
Evaluation criteria
Weight criteria to your PIRs. An illustrative split for a mid-sized CTI team is 25% integrations and dissemination, 20% scoring and ageing, 20% standards and sharing, 15% analyst workflow, 20% platform security, data and cost.
| Criterion | What good looks like | Weak signs |
|---|---|---|
| Aggregation and normalisation | Ingests STIX, TAXII, MISP, CSV, JSON, email and PDF reports; deduplicates across sources; keeps provenance for every object | Sources merged with no record of where an indicator came from |
| Feed management and quality | Per-feed statistics: volume, unique contribution, overlap, false positive rate, hits in your telemetry; easy to retire a feed | No way to tell which paid feeds produced detections |
| Scoring and confidence | Separate source reliability and information credibility (for example Admiralty-style grading), STIX confidence, and customer-editable scoring rules | One opaque vendor score you cannot explain to an analyst |
| Ageing and expiry | Indicator lifetimes by type, decay that sightings can refresh, automatic withdrawal from blocking tools; MISP's model, for example, resets the score to its base value when a sighting is added (MISP decaying of indicators) | Indicators stay on firewall blocklists forever |
| Enrichment | Passive DNS, WHOIS, certificate, sandbox and internal asset context on demand, with costs and API quotas visible | Enrichment that silently burns third-party quota |
| Integrations and dissemination | Bidirectional connectors for SIEM, SOAR, EDR, firewalls, DNS and email security; filtered pushes by score, type and TLP; sightings returned from tools | One-way pushes of everything; no feedback of hits |
| Sharing and TLP | Sharing groups per community or ISAC, TLP enforced on every export path, redaction before sharing | TLP stored as a tag that export ignores |
| Analyst workflow | Knowledge graph of actors, campaigns, malware and techniques; ATT&CK mapping; tasks, notes and finished reports tied to PIRs | Indicator search with no actor or campaign context |
| AI summarisation | Summaries of long reports with citations back to source text, extracted indicators reviewed before publishing, clarity on whether your data trains models | Unsourced summaries; extracted indicators sent straight to blocking |
| Platform security and data | SSO and enforced MFA, role-based access per sharing group, audit log, regional hosting, full export via API at contract end | Shared admin accounts; no tenant audit log |
A TIP is not a SIEM. The SIEM stores and correlates your telemetry; the TIP curates external and internal intelligence and decides which subset the SIEM and other tools should act on. See the SIEM Guide and the SOAR and Security Automation Guide.
Where identity fits
To push indicators and pull sightings, a TIP holds API keys, OAuth clients and service accounts for the SIEM, SOAR, EDR, firewalls, email gateway and cloud tenants, and often write access to blocklists. A compromised TIP could disable blocking or poison it with your own infrastructure. This maps to the OWASP Non-Human Identities Top 10: NHI5:2025 Overprivileged NHI, NHI7:2025 Long-Lived Secrets, NHI2:2025 Secret Leakage and NHI3:2025 Vulnerable Third-Party NHI. Require one credential per connector with the narrowest scope, write access only where blocking is intended, rotation, a named owner, and an exportable connector inventory. The Sisense breach showed the risk of a platform that stores many customers' tokens. Leaked credentials also make good intelligence: ask whether the platform can match exposed keys and passwords to your accounts. See the Leaked Credential Response Playbook and the Secrets Management Guide.
Questions to ask vendors
- Export a threat actor with its indicators, relationships and sightings as a STIX 2.1 bundle, import it into a clean instance, and show nothing was lost.
- How do you handle TLP:AMBER+STRICT and TLP:CLEAR, given that the STIX 2.1 built-in TLP markings predate TLP 2.0? Which export paths enforce TLP, and how is it audited?
- How are confidence and source reliability calculated, can we change the rules, and how does an indicator expire and leave our firewalls?
- For each feed in our trial, what share of its indicators were unique and how many matched our telemetry?
- Which permissions does each connector need, can it run read-only, and does it support short-lived or federated credentials instead of static API keys?
- How do AI summaries cite sources, and is our intelligence or reporting used to train models or shared with other customers?
- Can we share with our ISAC and with MISP communities in both directions, and how is attribution of our submissions controlled?
- What does the price count (users, feeds, indicators, connectors, API calls or enrichment lookups), and what do bundled premium feeds cost at renewal?
- At contract end, what do we receive, in which formats, and when is our data deleted?
Red flags
- Value measured in indicator counts or feed numbers rather than detections, blocks or decisions supported.
- Proprietary formats with STIX or TAXII export "on the roadmap", or STIX export that drops relationships.
- No indicator expiry, so blocklists grow until they cause outages or are ignored.
- TLP shown in the interface but not enforced on export, API or connector paths.
- Connectors that need administrator rights in the SIEM, EDR or firewall, or one shared API key for all of them.
- AI summaries without citations, or unclear terms on reuse of your intelligence.
Proof of concept
- Start from PIRs: pick three PIRs and agree what success looks like, for example earlier detection of a named ransomware group's infrastructure, or prioritising exploited vulnerabilities.
- Load real sources: connect your existing feeds, one ISAC or MISP community and three months of internal incident data. Measure deduplication and overlap.
- Connect with least privilege: create dedicated integration identities for the SIEM, one EDR and one firewall, read-only first, with named owners and expiry. Record every permission requested.
- Retro-hunt: run intelligence against historical telemetry and count true matches, false positives and missed incidents.
- Test ageing and rollback: push a scored, time-limited indicator set to a test blocklist, confirm expiry removes entries, then roll back the whole set in one action.
- Share and check TLP: share a TLP:AMBER+STRICT and a TLP:CLEAR item and confirm each export path honours the label.
- Exit test: export all objects as STIX 2.1, revoke every connector credential and confirm the integrations stop.
Keep measuring after go-live: share of PIRs with current reporting, detections or blocks attributable to TIP intelligence, false positive rate of pushed indicators, unique contribution per feed, median indicator age on blocklists, and time from advisory to deployed detection.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: Threat Intelligence Guide · Threat Actor Groups Guide · Ransomware Groups Guide · SIEM Guide · NHI Security Platform Buyer's Guide