Open source threat intelligence platform

Start with a small set of feeds you can review and explain, then add more only when analysts can show what each one contributes. Recurring analyst time grows with every feed because each one adds indicators to triage, overlaps with others and changes format over time. Good first candidates are feeds tied to your sector, your technology stack and any sharing communities you already belong to. Track, per feed, how many indicators it adds, how many reach a detection, and how many analysts close as false positives. A feed that produces volume but no confirmed detections costs more than it returns. Ask your implementation partner to document the onboarding criteria so the list can be reviewed on a schedule rather than debated in each incident.

Ownership usually sits with a named threat intelligence or detection engineer, with SOC analysts reporting false positives through a defined channel. The time spent depends on how often indicators are matched against benign traffic, such as shared CDNs, cloud provider ranges or widely used software update hosts. Each false positive should trigger a short record: the indicator, the feed, the matched asset and the reason it was benign. Those records drive allowlists, feed suppression rules and rescoring. Without that loop, the same false positives return every week. Confirm in writing who owns the review queue, how fast analysts expect a response and who can approve a change to a shared allowlist.

Expiry and decay are policy decisions that you set per indicator type and source, not defaults to accept unchanged. An IP address observed in a botnet may be useful for days, while a file hash or a certificate fingerprint may remain relevant longer. Define a validity window for each indicator type, then decide whether expired indicators are disabled, removed from detection exports or only down-scored. Revisit those windows after you review detection outcomes, since a window that is too long floods the SIEM and one that is too short misses recurring infrastructure. Confirm which decay and revocation functions your chosen version of MISP or OpenCTI supports before you write the policy.

Every indicator should carry a handling marking, typically a Traffic Light Protocol label, and a sharing scope that tells the platform where it may leave your organization. Set defaults at import so that feeds and analysts do not rely on memory. Review markings when you share with partners, because an indicator derived from a restricted report may need a stricter label than the feed it came from. In MISP, sharing groups and distribution levels control this; in OpenCTI, marking definitions and access rules play a similar role. Analyst time here comes from exceptions, such as indicators that arrive unmarked or mixed-source records. Ask your partner to document the marking standard and test that exports respect it before any external sharing starts.

Retire indicators through scheduled expiry, deduplication jobs and a periodic review of what the SIEM actually matched. Duplicates arise when several feeds report the same value with different context, so merge them into one object that keeps all sources and sightings. Stale records should leave detection exports even if they remain in the archive for investigation history. Measure how many indicators are removed each cycle and how many were matched after expiry, since that number shows whether your windows are right. Keep an audit trail of deletions and disablements so that analysts can explain why an indicator stopped firing during an investigation. Confirm the exact deduplication and archival behavior in the release you deploy.

The recurring work falls into four areas: reviewing new or changed feeds, triaging false positives, tuning expiry and sharing rules, and checking that exports still reach the SIEM. The main cost drivers are the number of active feeds, the volume of indicators per feed, how many detections depend on intelligence, and how often sharing partners change their requirements. Staffing estimates should come from your own alert volumes and sample reviews, not from a generic ratio. Ask any implementation partner to separate one-time configuration from ongoing curation, to name the roles that do each task and to explain what a quote includes after go-live, such as support, upgrades and content maintenance under a retainer.

Often yes, if one or two people own the platform and the review routines are written down. Most of the ongoing effort is judgment on false positives and sharing rules, which benefits from analysts who know your environment. Teams struggle when no one owns the schedule, when upgrades are deferred, or when the platform is run by people who did not build the feed logic. Before deciding, document the feed list, expiry policy, marking standard and review cadence, then test whether a new analyst can follow them. A partner can build the runbooks, train the owners and offer a retainer for upgrades and periodic reviews, with the split agreed in a written scope.

The software licence is usually the smallest part of the cost, because MISP and OpenCTI Community Edition are open source. The larger costs are the infrastructure to host the platform, the people who install, integrate and maintain it, and the time spent curating feeds. Infrastructure cost depends on the number of feeds, indicator volume, retention period, and whether you run a single instance or a high availability pair. Labor cost depends on how many integrations you build (SIEM, EDR, ticketing, sharing partners) and how much analyst time goes into reviewing indicators. Ask any partner to split the quote into one-time items (design, installation, integration, initial feed setup, documentation and training) and recurring items (hosting, patching, upgrades, feed review and support). Ask for the assumptions behind each line, such as indicator volume and number of users.

A team with Linux, container and database experience can install MISP or OpenCTI, but the harder work is operational: keeping the platform patched, connecting it to the SIEM, deciding which feeds to trust, and writing sharing rules that match your legal and contractual obligations. Before you decide, check whether your team has an owner for the platform, time for feed curation each week, and someone who can answer for sharing decisions. If those roles are already stretched, a fixed-scope implementation with a partner can cover the build and handover while your staff keep ownership. DeployOpen implements and documents self-hosted open-source platforms inside the client's own infrastructure, and it supports them through retainers when the client wants ongoing help.

The rollout length is set in the written scope, not by a fixed rule, so ask each partner for phase-by-phase durations tied to deliverables. A typical sequence covers requirements and sharing policy, infrastructure build, platform installation and hardening, feed onboarding, SIEM connection, analyst training and handover. Timelines grow with the number of integrations, the number of sharing communities, any air-gapped or data residency constraints, and how quickly your change approvals run. Feed onboarding often takes longer than the technical install, because each source needs validation before it reaches detection. Confirm the start conditions in the scope, including access to cloud accounts, network paths, identity provider configuration and named reviewers.

Expect to supply a named technical owner, an analyst who understands your detection workflow, and a platform or infrastructure contact who can approve hosting, network rules and backup targets. Security staff must define which indicator types matter, which sources are trusted, how long indicators should live, and what can be shared externally. Platform staff provide virtual machines or Kubernetes capacity, storage, DNS, certificates, and a path to the SIEM. Ask for a RACI (responsible, accountable, consulted, informed) table in the scope so each deliverable has one owner on each side. Plan for these people to be available in review sessions, not only at kickoff, because most rework comes from unclear sharing and retention decisions.

MISP is a mature open source threat intelligence and sharing platform licensed under AGPL-3.0, and it fits teams that focus on indicator sharing, event exchange and communities. OpenCTI, maintained by Filigran, is built around a knowledge graph of threat actors, campaigns, malware and relationships, and its Community Edition is licensed under Apache License 2.0. Choose MISP when sharing with peers and sector communities is the main goal. Choose OpenCTI when analysts need to model relationships and track adversary activity over time. Many organizations evaluate both against a few real use cases from their own alerts before committing. Check the current versions on the project repositories, since both move quickly.

Yes, they can. OpenCTI ships an Enterprise Edition under a separate OpenCTI Enterprise Edition License, so confirm which features your requirements depend on and whether they are in the Community Edition. Commercial threat feeds, premium sharing communities and vendor connectors are separate contracts with their own fees and terms, and they often recur every year. Some open source components include enterprise directories with separate licences, so check the license file for any component you plan to use. Ask each partner and vendor to list every licence, subscription and feed that the design needs, with the term, renewal date and who holds the contract. Also confirm whether the design depends on any feed that restricts redistribution, because that affects what you can share.

Feed curation is the recurring work that keeps indicators useful. Analysts review new sources, retire feeds that create noise, tune expiry and scoring, and check that enrichment and false positive rules still match your environment. The effort rises with the number of feeds, the rate of indicator churn, and how many alerts reach your SIEM from intelligence matches. Agree on a review cadence, owner and metrics in the scope, such as how many indicators reach analysts and how many are closed as false positives. Ask the partner whether curation is included in support, or whether it is a separate retainer, and what happens when a feed changes its format or licence.