Most threat intelligence budgets are decided by habit, either "free feeds are good enough" or "buy the big subscription", rather than by asking which intelligence requirements each source actually answers. Open-source and community intelligence (public feeds, government sharing services, ISACs, open platforms) costs little in licence fees but a lot in engineering and analyst time. Commercial intelligence costs money up front and can still go unused if nobody consumes it. This guide treats the choice as a sourcing and budget decision: what each model gives you, the hidden costs of each, how to blend them by programme maturity, and how to prove the spend is working. It is written for CTI leads, SOC managers and security leaders who own the intelligence budget. Feed quality scoring is covered in the Threat Intelligence Feed Evaluation Guide, and the indicator versus analysis question in Threat Feeds vs Finished Intelligence; this page does not repeat them.
Key takeaways
- Free is a licence price, not a total cost. Open sources shift spend from subscriptions to platform engineering, deduplication, false positive handling and analyst hours.
- Licence terms decide what "open" means for you. Several community datasets are free for non-commercial use but need a paid subscription for commercial or high-volume use, so read the terms before you build a pipeline on them.
- Commercial value sits in coverage you cannot build. Closed-source telemetry, underground and actor reporting, analyst access and takedown or enrichment services are what you pay for, not the indicator count.
- Maturity sets the mix. A programme without written intelligence requirements or a platform to consume data gains little from an expensive subscription; a mature programme usually needs both models.
- Measure consumption, not volume. Track what each source contributed to detections, blocks, hunts and decisions, and renew or cancel on that evidence.
Short answer
Start with open and community sources plus a platform to handle them, write intelligence requirements, and buy commercial intelligence only to close specific gaps those requirements expose. Small teams with no dedicated analyst usually get more from a managed or commercial service that arrives curated than from a pile of raw open feeds they cannot triage. Large or regulated organisations nearly always run a blend: open and sector sharing for breadth and peer context, commercial sources for actor depth, early warning on targeted threats and services such as brand or credential exposure monitoring.
Side-by-side comparison
| Dimension | Open-source and community | Commercial |
|---|---|---|
| Typical sources | Public blocklists and IOC feeds, government services such as CISA Automated Indicator Sharing, sector ISACs, MISP communities, open research and vendor blogs | Subscription feeds, finished reporting portals, threat intelligence platform bundles, digital risk and exposure monitoring, analyst request services |
| Licence cost | Often nil; some datasets charge commercial users; ISAC membership may carry a fee | Annual subscription, often tiered by modules, users or API volume |
| Hidden cost | Integration, normalisation, deduplication, whitelisting, analyst triage, platform hosting | Integration and tuning still needed; renewal uplift; risk of shelfware |
| Coverage | Strong on commodity malware, phishing and scanning infrastructure; weaker on targeted actors and closed sources | Can add proprietary telemetry, underground sources and actor tracking; varies widely by provider |
| Context | Frequently bare indicators with little attribution or confidence data | Usually richer context, confidence and linkage to reports; quality still varies |
| Accountability | Best effort; providers usually accept no liability for false positives | Contractual service levels and a support channel |
| Sharing back | Reciprocity is often expected and builds trust | Usually one-way; check whether your submissions are reused |
| Exit | Low lock-in if you keep data in open formats | Portal and API lock-in unless data is exported in STIX or similar |
Open-source and community intelligence in depth
What it is
Open intelligence covers anything you can obtain without a commercial subscription: public feeds, government and sector sharing, open-source platforms and published research. Three groups matter in practice.
- Public datasets: abuse.ch runs URLhaus (malware distribution URLs), ThreatFox (malware IOCs), MalwareBazaar (samples), Feodo Tracker (botnet C2), SSL Blacklist (malicious certificates and JA3 fingerprints) and YARAify (YARA rules). The MISP project publishes a default feed catalogue that, when checked in November 2026, listed 108 feeds from 52 providers in MISP, CSV and free-text formats.
- Government and sector sharing: CISA describes Automated Indicator Sharing as a free service for machine-readable indicator exchange using a TAXII 2.1 client, open to private sector, government, ISAC and international partners after signing its terms and an interconnection agreement. ISACs are typically non-profit, sector-based bodies that analyse and share threat information with members.
- Open platforms: MISP and OpenCTI let you collect, correlate and share intelligence without a licence fee. See the MISP Threat Sharing Guide and the OpenCTI Guide.
Threat model it serves
Open data is strongest against high-volume, opportunistic activity: commodity malware delivery, phishing kits, botnet C2, mass scanning and widely reported vulnerabilities. If your threat model is dominated by these, a well-run open pipeline covers a large share of your indicator needs.
Architecture in words
Feeds are pulled into a platform (MISP, OpenCTI or a SIEM's intelligence module), normalised to a common model, deduplicated, checked against allowlists such as MISP warninglists, scored, aged out and then pushed to enforcement points: SIEM correlation, DNS or proxy blocklists, EDR custom indicators and firewall dynamic lists. Analysts read the open research and government advisories and turn them into hunts and detection rules.
Failure modes
- Licence surprise: abuse.ch's terms state that MalwareBazaar, URLhaus and ThreatFox are free for not-for-profit use, while commercial or for-profit use may require a paid subscription managed by Spamhaus; Feodo Tracker, SSL Blacklist and YARAify are released under CC0. A managed service provider or a vendor reselling enriched data can breach terms without realising.
- Feed overload: enabling every catalogue feed floods the platform with overlapping, stale indicators. The MISP catalogue itself labels the IPsum aggregation levels by false positive rate, with the lowest levels marked as having many false positives.
- Availability drift: the MISP catalogue notes that it does not check feed availability. Feeds go quiet (abuse.ch notes the Feodo Tracker dataset has been empty since Operation Endgame) and nobody notices because nothing alerts on silence.
- Shared infrastructure blocking: blocking Tor exit nodes, public DNS resolvers or cloud ranges from a raw feed causes outages; warninglists exist precisely to flag such values.
Commercial intelligence in depth
What you are paying for
- Proprietary collection: telemetry from the provider's own products or sensors, malware sandboxes at scale and access to closed forums or marketplaces that you cannot or should not access yourself.
- Analysis and context: actor tracking, campaign linkage, confidence ratings and mapping to ATT&CK, which save analyst time when it matches your requirements.
- Services: analyst requests for information, credential and brand exposure monitoring, takedown handling and vulnerability prioritisation feeds.
- Accountability: a contract, support, service levels and someone to escalate to when a bad indicator blocks a business partner.
Threat model it serves
Commercial sources add most when you face targeted actors, sector-specific campaigns, fraud and extortion groups, or when you need early warning of your own credentials, domains or data appearing for sale. They add least when the subscription mostly duplicates public commodity indicators you already ingest.
Architecture in words
The provider's API or TAXII collection feeds the same platform as open data. Finished reports land in a portal and, ideally, are also pulled as STIX objects so they link to indicators and ATT&CK techniques. Exposure alerts route to the incident or fraud queue, not the CTI inbox. See the STIX and TAXII Guide.
Failure modes
- Shelfware: the portal is bought for one champion who leaves; usage drops to zero and the renewal goes through unchallenged.
- Overlap with free data: some subscription indicators also appear in public feeds. Without an overlap test you pay twice for the same data.
- Volume-tiered pricing traps: API caps force teams to throttle enrichment exactly when an incident needs it.
- Lock-in: intelligence kept only in a provider portal is lost at exit; insist on bulk export in an open format.
The real cost model
Compare total cost of ownership over a three-year term, not the licence line. The table shows the cost elements to estimate for each model; the figures are yours to fill in.
| Cost element | Open-source and community | Commercial |
|---|---|---|
| Licence or membership | Low; check commercial-use and ISAC fees | Main visible cost |
| Platform | Self-hosted MISP or OpenCTI: servers, storage, upgrades, backup | Sometimes bundled; otherwise same platform cost |
| Integration engineering | Higher: many formats and endpoints to maintain | Lower per source, but still needed |
| Curation and false positives | Higher: allowlisting, scoring, ageing, triage | Lower but not zero |
| Analyst time | Reading and synthesising open research | Reading finished reports, managing the vendor |
| Legal and compliance | Terms of use review, sharing agreements, TLP handling | Contract, data processing and export terms |
| Exit cost | Low with open formats | Data migration and re-integration |
Rule of thumb: if you cannot name the person who will consume a source each week, its effective cost per useful outcome is infinite, whether it is free or not.
Choosing by maturity and use case
| Programme stage | Typical state | Sourcing emphasis |
|---|---|---|
| Starting | No dedicated analyst, no platform, intelligence read ad hoc | Government advisories, one sector ISAC, a small set of high-confidence open feeds through existing SIEM or EDR integrations; consider a managed service instead of raw feeds |
| Developing | Written requirements, a platform, one or two analysts | Curated open feeds with scoring and warninglists; first commercial purchase targeted at the top unmet requirement |
| Established | Requirements reviewed with stakeholders, metrics in place | Blend: open and sector sharing for breadth, commercial for actor depth and exposure monitoring; annual overlap test |
| Advanced | Contributes intelligence, runs hunts and red team input | Multiple commercial sources chosen per requirement, active sharing back to communities, own collection |
Decision criteria
- Use case first: blocking commodity infrastructure, detection engineering, threat hunting, vulnerability prioritisation, fraud, executive risk briefings and third-party monitoring each favour different sources. Map each requirement to at least one source and note who consumes it.
- False positive tolerance: sources feeding automated blocking need the highest precision; sources feeding hunts can be noisier. A noisy free feed may be fine for enrichment and unacceptable for blocking.
- Staff capacity: open sources need curation skill. If you lack it, buy curation (commercial or managed) before buying more data.
- Sector and geography: sector ISACs and national CERT feeds often carry context no global provider has; check what your sector already shares.
- Legal position: commercial use clauses, resale restrictions, TLP obligations and restrictions on reuse for AI training. abuse.ch, for example, requires Spamhaus's prior written consent to use its data for AI training.
- Reciprocity: community sources work best when you share back; budget analyst time for contributions.
Controls that make either model pay off
- Write intelligence requirements: priority questions from SOC, incident response, vulnerability management, fraud and leadership. Every source must map to at least one. The Threat Intelligence Guide covers the lifecycle.
- Use one platform as the system of record: ingest every source, open and commercial, into one platform so you can measure overlap and contribution. Tag each object with its source.
- Score and age indicators: use source reliability, confidence and age. STIX 2.1 defines a confidence property on a 0 to 100 scale and validity windows on indicators; use them rather than keeping indicators forever.
- Filter known-benign values: enable MISP warninglists or equivalents for private ranges, public resolvers, top domains and major cloud and SaaS ranges before anything reaches a blocklist.
- Separate block from detect: only high-confidence, recent indicators from proven sources go to automated blocking; the rest go to alerting or enrichment.
- Respect handling labels: apply TLP 2.0 (RED, AMBER, GREEN, CLEAR, as defined by FIRST) on ingest and enforce it on export, especially when mixing community and commercial data.
- Test overlap before buying: run a trial feed into the platform for 30 to 60 days and measure unique indicators, unique detections and analyst time saved against what you already have.
- Review on a cycle: quarterly source review, annual renewal decision based on contribution metrics.
Worked scenario: one budget, two routes
A mid-sized insurer has two security analysts, a SIEM and EDR, and a budget roughly equal to one commercial subscription. Its top requirements are phishing and commodity malware blocking, early warning of stolen employee credentials, and sector campaign awareness for board reporting.
- Route A, all commercial: buy a broad subscription. Indicators arrive with context, but the SIEM integration is never tuned, half the indicators overlap with EDR vendor protections already in place, and nobody reads the reports. After a year the team cannot show what the spend changed.
- Route B, blended: join the sector ISAC, deploy MISP with a short list of high-confidence open feeds, warninglists and a 30-day indicator expiry, and buy a narrower commercial service focused on credential and brand exposure, the requirement open sources cover worst. Commodity blocking runs on open data, exposure alerts flow into the identity team's queue, and the ISAC supplies peer context for the board.
Route B wins here because each source maps to a requirement and an owner. The same insurer, two years later with a dedicated CTI analyst and active hunting, might add actor-focused commercial reporting, chosen after an overlap test.
Where identity fits
Credential exposure is one of the clearest cases for paid sourcing, because leaked passwords, session cookies and API keys circulate in closed markets that open feeds rarely cover. Whatever the source, route exposure findings to identity owners with a playbook: force reset, revoke sessions and tokens, rotate keys and check for use. Machine credentials matter as much as human ones; leaked cloud keys and CI tokens should go straight to secrets rotation. See the NHI Threat Intelligence Guide.
Implementation roadmap
- Weeks 1 to 4: inventory current sources (including those embedded in EDR, email and firewall products), owners and costs; write or refresh intelligence requirements.
- Weeks 5 to 8: stand up or clean up the platform; tag every source; enable warninglists; set default expiry per indicator type.
- Weeks 9 to 12: enable a short list of open and community sources in detect-only mode; measure noise and unique hits; join the relevant ISAC or government sharing service.
- Months 4 to 6: identify the unmet requirements; run time-boxed commercial trials into the same platform; compare contribution against cost.
- Months 6 onwards: promote proven sources to blocking; set the quarterly source review. Rollback: keep a per-source kill switch on every enforcement integration so a bad feed can be disabled in minutes, and keep the previous blocklist version for restore.
Detection and measurement
- Unique contribution per source: indicators and detections no other source supplied, per quarter.
- Actioned rate: share of a source's indicators or reports that led to a detection, block, hunt, patch decision or briefing.
- False positive rate in blocking: blocked legitimate connections traced to each source.
- Cost per actioned item: total cost of ownership divided by actioned items, for both open and commercial sources.
- Requirement coverage: share of priority intelligence requirements with at least one source and a named consumer.
- Feed health: alerts when a source delivers nothing for a set period, so silent feeds are caught.
The Threat Intelligence Feed Evaluation Guide gives the scorecard for per-feed accuracy and freshness.
Common failure patterns
- Ingesting everything: turning on every free feed creates alert fatigue that hides real signals. See the Alert Fatigue Reduction Guide.
- Buying before requirements exist: a commercial subscription chosen from a demo rather than mapped to requirements rarely survives its first renewal review.
- Ignoring licence terms: using non-commercial community data inside a paid service or product.
- Never retiring indicators: years-old IP addresses, now reassigned to legitimate hosts, stay on blocklists.
- Treating government sharing as complete: government services add authoritative context but are not a full replacement for sector and commercial sources where targeted threats matter.
- No sharing back: taking from communities without contributing erodes the trust that makes them useful.
Framework mapping
| Framework | Reference | Relevance to sourcing |
|---|---|---|
| NIST CSF 2.0 | ID.RA-02 | Cyber threat intelligence is received from information sharing forums and sources |
| NIST CSF 2.0 | ID.RA-03 | Internal and external threats are identified and recorded |
| NIST SP 800-53 Rev 5 | PM-16 Threat Awareness Program | Cross-organisation threat information sharing capability |
| NIST SP 800-53 Rev 5 | SI-5 Security Alerts, Advisories, and Directives | Receiving and acting on external advisories |
| NIST SP 800-53 Rev 5 | RA-3(3) Dynamic Threat Awareness | Using threat information to keep risk assessment current |
| ISO/IEC 27001:2022 | Annex A 5.7 Threat intelligence | Collect and analyse threat information to produce intelligence |
| MITRE ATT&CK | M1019 Threat Intelligence Program | Mitigation describing a programme that informs defences |
| NIST SP 800-150 | Guide to Cyber Threat Information Sharing | Sharing goals, sources, rules and community participation |
Practitioner checklist
- Write or refresh priority intelligence requirements and map every current source to one.
- Name a weekly consumer for every source, open or commercial.
- Read the terms of use for each community dataset and confirm your use (commercial, MSSP, AI training) is permitted.
- Ingest all sources into one platform and tag each object with its origin.
- Enable warninglists and default expiry before any indicator reaches automated blocking.
- Join the sector ISAC or national sharing service relevant to you and budget time to share back.
- Trial any commercial source for 30 to 60 days and measure unique contribution before signing.
- Require bulk export in STIX 2.1 or another open format in every commercial contract.
- Review source contribution quarterly and base renewals on cost per actioned item.
Standards and references
- NIST: SP 800-150 Guide to Cyber Threat Information Sharing
- CISA: Automated Indicator Sharing
- FIRST: Traffic Light Protocol 2.0
- OASIS: STIX Version 2.1
- National Council of ISACs: About ISACs
- MISP Project: Default feeds
- MISP Project: misp-warninglists
- abuse.ch: Terms of Use
Related NHI Mgmt Group resources: Threat Intelligence Guide · Threat Intelligence Feed Evaluation Guide · Threat Feeds vs Finished Intelligence · MISP Threat Sharing Guide · OpenCTI Guide