Open source threat intelligence for NIST CSF 2.0

Open source threat intelligence for NIST CSF 2.0: what the framework asks

A security leader who has to show that threat intelligence from sharing forums reaches detection and analysis needs to map that claim to two specific outcomes in the NIST Cybersecurity Framework 2.0. ID.RA-02 and DE.AE-07 are the outcomes a threat intelligence platform serves, and MISP or OpenCTI can be self-hosted to do the work inside your own environment. ID.RA-02 asks that cyber threat intelligence be received from information sharing forums and other sources. DE.AE-07 asks that threat intelligence and other contextual information be built into adverse event analysis. The framework is the reference point, not the test: NIST describes CSF 2.0 as voluntary for most organizations, although some customers and suppliers require it, and U.S. federal agencies have been required to use it since a 2017 executive order.

Before you map anything, be clear about what NIST does not do. NIST states that it does not certify or endorse CSF-related products, implementations or services, and it has no plans for a conformity assessment program. A platform that is "CSF 2.0 compliant" is a vendor claim, and so is a self-hosted deployment described as CSF-aligned. What you can show is evidence that the outcomes operate: feeds and sharing memberships configured, intelligence reaching detection tools, and analysts recording how intelligence changed an analysis. The Core is organized into six Functions (Govern, Identify, Protect, Detect, Respond and Recover), 22 Categories and 106 Subcategories, according to the CSF 2.0 dataset NIST publishes. Govern is the newest Function, so ask who owns the intelligence program as a governance decision, not only as a technical one.

How ID.RA-02 and DE.AE-07 map to platform functions and configuration

This table compares the two NIST CSF 2.0 subcategories this page covers, the implementation examples NIST publishes for each, and how MISP or OpenCTI can serve them. Read each row as a requirement, then check the configuration column against your own sharing rules, and the last column against what your sharing community has agreed. The main takeaway is that the platform only satisfies these outcomes once intake is governed and intelligence reaches detection tools in a controlled way.

Requirement	What the function must do	How to configure MISP or OpenCTI	What to confirm with the sharing community
ID.RA-02: receive cyber threat intelligence from sharing forums and other sources	Collect intelligence from forums, peers, vendors and government sources on a defined schedule, and record where each item came from	Create one MISP event per source feed or community with a named owner. Set the source organization and tags on import. In OpenCTI, map each feed to a connector and a labeled identity for the source	Which forums the organization is a member of, what each forum permits you to ingest, and whether membership must be reported to a regulator
ID.RA-02 implementation example: configure detection and response tools to ingest feeds securely	Limit which feeds reach detection tools, and confirm feed integrity and access before ingestion	Use MISP sharing groups and distribution levels to decide which attributes leave the instance. Export only selected attributes to Suricata, Zeek and the SIEM, and restrict API keys to the roles that need them	Feed authentication methods, whether the sharing agreement limits downstream systems, and the approved list of tools that may receive indicators
ID.RA-02 implementation example: review advisories on threat actors and their TTPs	Track threat actors, malware and attack techniques that target the organization's sector and technology	Enable MISP galaxies for threat actors, malware and MITRE ATT&CK. In OpenCTI, use the MITRE ATT&CK connector and link reports to intrusion sets and techniques	Which sector advisories are shared with the organization, and whether they carry a TLP marking that limits internal circulation
ID.RA-02 implementation example: track vulnerabilities of emerging technologies	Record advisories on new products and platforms in use, and link them to owners and assets	Create tags or custom taxonomies for technologies in the estate. Keep vulnerability objects in OpenCTI or MISP separate from confirmed indicators so that analysts can tell them apart	Whether vendor advisories shared through the forum can be stored with the organization's asset names, and who approves those records
DE.AE-07: feed threat intelligence to detection technologies, processes and people	Route curated indicators and context to the tools and teams that act on them, with a record of who received what	Use MISP exports (Suricata, Zeek, RPZ, STIX, CSV) on a scheduled job, or the MISP API through PyMISP. In OpenCTI, use stream connectors or export connectors. Send a summary to incident responders through the agreed channel	Which teams may receive shared intelligence, the handling rules for TLP:AMBER and TLP:RED material, and whether analysts must not paste shared content into tickets
DE.AE-07 implementation example: provide asset inventory information to detection	Give analysts asset and owner context so that an indicator match can be linked to a system and its criticality	Import the asset inventory as MISP or OpenCTI objects or as enrichment data, keeping asset identifiers internal. Do not publish internal asset names to the sharing community	Which asset fields may be used in shared events, and whether the community accepts sanitized indicators only
DE.AE-07 implementation example: rapidly analyze vulnerability disclosures from suppliers, vendors and advisories	Triage new supplier and vendor disclosures against the asset inventory and decide which need action	Create a MISP event or OpenCTI report per disclosure with a standard set of tags and an owner. Use correlation in MISP and relationship graphs in OpenCTI to match products and versions to the estate	Whether supplier advisories received under confidentiality terms may be stored in the platform, and which retention period applies
DE.AE-07: keep the platform's own sharing and data handling defensible	Show which data was shared, with whom and under which rules, so the organization can answer questions from members and regulators	Set distribution levels and sharing groups on every event, enable audit logging for the MISP or OpenCTI instance, and record connector and feed configuration in version control	Retention and deletion rules for shared indicators, and any personal data within indicators that would bring data protection rules into scope

How a sharing forum feed becomes a detection input under CSF 2.0

ID.RA-02 asks an organization to receive threat intelligence from sharing forums, and DE.AE-07 asks that this intelligence be built into adverse event analysis. The working path runs from a community feed into a self-hosted MISP or OpenCTI instance, then out to the tools that act on it. In MISP, the controls that decide what reaches your analysts are the distribution level on each event and attribute, the sharing group that defines who may receive it, and the synchronization settings that pull events from your community partners. Before you enable a feed, confirm which distribution levels your community uses, which sharing groups you have been added to, and whether the community expects you to push data back. MISP's correlation engine then links new attributes to existing events, which is how a single IP address from a forum becomes a case with related hashes and domains.

In OpenCTI, the equivalent work happens through the STIX2-based knowledge schema and connectors. Import connectors bring in feeds and sharing content, the MITRE ATT&CK connector maps reported behavior to techniques, and enrichment connectors add context. Here the decision is which connectors run in your environment and who owns their configuration, since each one is an additional component to patch and monitor. Downstream, Suricata and Zeek consume indicators exported in formats such as Suricata and Zeek rules, and Wazuh can ingest intelligence for alert context. Each of these export paths should be tested against a known sample before production use, and the owner of each rule set should be named.

DE.AE-07 is broader than feeds. NIST's own implementation examples also cover asset inventory information fed to detection, and rapid analysis of vulnerability disclosures from vendors and third-party advisories. An indicator is only useful if you know which of your systems run the affected product, so the asset inventory and vendor advisory feeds are part of the same flow. Intelligence must also be curated before it is trusted. Assign an owner for reviewing new indicators, set expiry or aging rules so stale indicators stop generating alerts, and record which sharing source each indicator came from. Confirm these rules with your analysts and your sharing community before the first indicator reaches a blocking control.

MISP or OpenCTI: which platform fits which team

Choose MISP when the main job is exchanging indicators with peers, sector groups or a national CERT, and when the team needs fine-grained control over who sees what. MISP is an open source platform for collecting, storing, distributing and sharing cyber security indicators, licensed under AGPL-3.0. The project is associated with CIRCL, the Computer Incident Response Center Luxembourg, and its repository notes that interlocked copyright among contributors prevents any single entity from changing the license model. That matters to a procurement team weighing long-term licensing risk.

Sharing controls: Distribution levels and custom sharing groups can be set down to individual attributes, and events and attributes can synchronize automatically among MISP instances and trusted communities.
Export and automation: MISP exports MISP JSON, STIX 1 and 2, OpenIOC, CSV, text, Suricata, Snort, Zeek and RPZ formats, so indicators can reach detection tools without manual conversion.
Scripting access: An OpenAPI-described API with restSearch and the bundled PyMISP library lets engineers automate ingestion and enrichment from their own code.
Version choice: MISP 2.5 is the recommended line for new deployments. MISP 2.4 is end of life with security fixes only, and the project strongly advises against installing new 2.4 instances. MISP 2.5.50 was released on 9 October 2026.
Data licensing: Taxonomies and galaxies are licensed under CC0 1.0 Universal or the 2-clause BSD license, separate from the AGPL software license, so confirm how any shared content is reused.

Before committing, confirm with your sharing partners which MISP version and sync method they accept, and what sharing group rules their community requires.

Which open-source platforms fit this function

ID.RA-02 and DE.AE-07 depend on a chain: intelligence arrives from sharing forums and feeds, is stored and shared by a threat intelligence platform, and is then pushed into the sensors and consumers that detect and triage events. The cards below cover the platform, the sensors that receive indicators, the monitoring tools that correlate them, and the automation layer that acts on them.

MISP as the intelligence hub

MISP is the platform that collects, stores and distributes indicators, and it is the most direct fit for ID.RA-02 because it receives intelligence from sharing communities. Its license is AGPL-3.0, so the software is free to run, but you must confirm whether your sharing partners expect a particular version and whether you will modify the code and need to publish those changes. Check which distribution levels and sharing groups your community uses, and who curates indicators before they reach detection.

OpenCTI as the knowledge graph

OpenCTI models intelligence as a STIX2-based knowledge graph, which suits teams that need relationships between threat actors, TTPs and campaigns for DE.AE-07 analysis. The Community Edition is licensed under Apache License 2.0, but some features sit in the Enterprise Edition under a separate proprietary license. Confirm which connectors and capabilities you need, and whether the platform's dependencies (Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage) fit your hosting standards.

Suricata for intrusion detection

Suricata is an intrusion detection and prevention engine that can use indicators exported from MISP as rules, which is how shared intelligence reaches network detection under DE.AE-07. Its GPL-2.0 license covers the engine itself. Confirm which sensors see the traffic that matters, how rule updates are approved and deployed, and how false positives from shared indicators are retired before they reach analysts.

Zeek for network sensor exports

Zeek produces structured network logs that analysts can match against indicators from the threat intelligence platform, which supports both the intake and analysis outcomes. Zeek is distributed under a BSD-style license from the Regents of the University of California. Confirm the sensor placement, the log formats your SIEM expects, and how intelligence files are loaded and refreshed on each sensor.

Wazuh and Security Onion as consumers

Wazuh and Security Onion are the SIEM and network security monitoring layers where intelligence is correlated with logs and alerts, so they carry DE.AE-07 into day-to-day adverse event analysis. Wazuh's core is licensed under GPL version 2, while Security Onion uses the Elastic License 2.0, which restricts some hosted uses. Check the license terms against your service model, and confirm which fields from the platform map to your detection rules.

Shuffle for enrichment and response

Shuffle is a security automation platform that can enrich alerts with indicators from the threat intelligence platform and trigger response steps, which turns received intelligence into action. Its AGPL-3.0 license applies to the software you modify and host. Confirm which enrichment lookups run automatically, which require analyst approval, and what audit trail each action leaves for later review.

What auditors ask for as evidence of threat intelligence use

What evidence shows we received threat intelligence from sharing forums?

Feed and sharing agreement records are the starting point: signed membership terms, feed licenses, and the list of sharing communities your instance subscribes to. Auditors also look for records showing which organization administers each feed and how often it is reviewed. In MISP, the feed configuration and sync partner list show which sources are live. In OpenCTI, connector configuration and import history serve the same purpose. The auditor decides whether these records are sufficient for ID.RA-02. DeployOpen can help you organize and keep these records, but it does not judge whether they meet the outcome.

Which sharing group and distribution settings do auditors expect to see?

Auditors expect exported or screenshotted configuration showing which distribution levels and sharing groups apply to each event and attribute, plus the rules that set them. In MISP, distribution levels and custom sharing groups are configured per event and can be applied down to individual attributes, so the export of those settings and the change history matter. Documented handling rules for restricted or TLP-marked material should match the configuration. The auditor decides whether this demonstrates controlled handling. DeployOpen can configure and document these settings in your environment, but sufficiency is the auditor's call.

What synchronization logs prove intelligence arrived from trusted communities?

Sync logs record when events and attributes were pulled from or pushed to partner instances, which partner sent them, and whether the transfers succeeded. For MISP, keep the server sync job logs and the audit trail for each synchronization partner, and retain them under your log retention policy. For OpenCTI, keep connector and worker logs that show import activity from each source. Auditors use these logs to test that the intelligence flow described in your procedures actually operates. Confirm with your platform team how long logs are retained in your own environment, because that retention period is set by your policy and infrastructure.

How do correlation and export logs support threat intelligence evidence?

Correlation and export logs show that intelligence was analyzed and passed to detection tools. In MISP, the correlation engine links attributes across events, and the export history shows indicators sent in formats such as Suricata, Snort, Zeek and RPZ, or through the API. In OpenCTI, enrichment and export connector logs provide the same trail. Keep records of which consumers received each export and when. The auditor decides whether this trail demonstrates that intelligence was built into analysis for DE.AE-07. Your team should confirm which export formats and connectors are enabled in its own environment before the assessment.

Can detection rules built from threat intelligence count as audit evidence?

Detection rules generated or tuned from intelligence are strong evidence, provided you can trace each rule to its source. Keep the rule files, the version history in your repository, and the intelligence event or indicator each rule came from. Suricata and Zeek rules exported from MISP, and rules written in your SIEM from OpenCTI indicators, should carry references to the originating event identifiers. Show deployment records from the sensor or SIEM that confirm the rules were active. The auditor decides how much weight these records carry. Ask your implementation partner to confirm how rule provenance is recorded for your chosen tools.

What analyst curation and aging records do auditors review?

Auditors look for records showing who reviewed indicators, when they were checked, and when stale or false positive indicators were retired. In MISP, this includes the to-IDS flags, the last-seen fields, the decay or expiry settings, and the event history showing edits. In OpenCTI, review the indicator validity periods, status changes and analyst notes. Keep a documented curation procedure and a schedule for periodic review, with the reviewer named on each cycle. The auditor decides whether this demonstrates adequate analysis. Confirm the review cadence your organization sets, since it is a governance decision rather than a platform default.

Which incident tickets should cite threat intelligence to show it was used?

Incident tickets that reference a MISP event identifier or OpenCTI report, indicator or observable show intelligence was applied during adverse event analysis. Each ticket should record the intelligence source, the matched indicator, the analyst's conclusion and the action taken. Connect your ticketing system to the platform through its API or through your SOAR workflow, so the reference is captured automatically. Sample several closed incidents during internal review to confirm the references are present. The auditor decides whether these tickets are sufficient evidence. Confirm with your ticketing and SOAR vendors which fields can carry the intelligence reference in your environment.

Who decides whether our threat intelligence evidence is sufficient?

The auditor or assessing body decides whether your evidence is sufficient for each NIST CSF 2.0 outcome. NIST does not certify products or implementations, and it has no plans for a conformity assessment program, so no certificate will be issued for this work. DeployOpen configures the platform, documents the records above, and prepares them for review, but it does not issue audit reports, attestations or certifications. Ask your assessor early which artifacts they expect and in what format, so the platform can be set up to produce them. Your organization owns the final evidence package.

What tooling alone does not satisfy

A running MISP or OpenCTI instance receives and distributes intelligence, but it does not decide what the organization needs, who it trusts, or whether the intelligence changed a decision. The gaps below are the work that policy, people and documented process must cover before the platform's output counts as evidence against NIST CSF 2.0.

Intelligence requirements and consumers

The platform stores whatever is loaded into it, but it cannot say which threats matter to the business or which teams should receive each product. Someone must write intelligence requirements, name the consumers in security operations, risk and leadership, and review those requirements on a set cycle. Check that each requirement traces to a business risk and that every feed or sharing group maps to a requirement.

Choosing sharing communities

MISP and OpenCTI can connect to many sharing communities, but the platform does not decide which ones are worth joining or what the organization is allowed to share. That decision depends on sector, contractual obligations, legal review and trust in each community's handling of data. Record the membership decision, the sharing rules agreed with each community, and who approves changes to them.

Analyst judgment and false-positive aging

Feeds contain stale, wrong and overly broad indicators, and the correlation engine will match them without knowing their age or quality. Analysts must review indicators, set expiry or aging rules and retire noise before it reaches detection. Ask who owns the aging policy, how often it runs and how overrides are logged.

Proof of use in detection

Importing an indicator does not show that it influenced an alert, a hunt or a response. Without a documented link from intelligence to detection rule, alert or case, DE.AE-07 is hard to evidence. Keep a traceable record that connects each feed or event to the detection content it informed and to the case where it was used.

Govern Function ownership

The Govern Function was added in CSF 2.0 and sets the organization's risk strategy, roles and oversight, so it is the outcome set that assigns who owns threat intelligence. The platform cannot assign that ownership or approve the policy behind it. Name an accountable owner, document the roles for curation and sharing, and confirm that leadership reviews the program.

No CSF certification

NIST does not certify CSF implementations, products or services, and it has no conformity assessment program planned. A vendor or implementation partner cannot grant CSF conformance for a MISP or OpenCTI deployment. Use the platform as evidence for specific outcomes, and ask any assessor to test the documented policies, records and results against the Subcategories you claim.

How to roll out threat intelligence against CSF 2.0 in phases

The sequence moves from defining what intelligence the organization needs to proving, against the CSF 2.0 Profile, that intelligence from sharing forums reaches detection and analysis. Each phase produces a record that the next phase depends on.

Define intelligence requirements and consumers
Leadership, the security operations lead and the incident response team agree which threats matter to the business, which systems and teams will use the intelligence, and what decisions it should inform. The output is a short written requirements list naming each consumer, such as the SOC, vulnerability management or the risk function. This step is done when every requirement maps to a named consumer and a named owner, and the list is recorded in the CSF Organizational Profile work so it can be reviewed later.
Select and join sharing forums
The team identifies which sharing forums, feeds and trusted communities serve the requirements in the previous step, and confirms membership terms, eligibility and the information each forum expects members to share. Legal and compliance review the terms before anything is exchanged. The output is a register of joined forums with the contact, the agreed sharing rules and the data the organization is permitted to send out. This register is the primary evidence for ID.RA-02, which concerns receiving threat intelligence from information sharing forums.
Deploy and harden the platform
Platform engineers deploy MISP or OpenCTI inside the organization's own infrastructure, following the vendor's current installation guidance and the chosen version line, then apply hardening for access, logging, backups and patching. For OpenCTI, the team also confirms the required supporting services, such as the search index, cache, message queue and object storage, are sized and secured. The step is complete when the platform passes an access and restore test and a documented baseline configuration exists. Ask the implementation partner to show that baseline before accepting this phase.
Configure sharing groups and TLP rules
The team sets up organizations, sharing groups and distribution levels so each indicator reaches only the audience it is meant for, and defines Traffic Light Protocol handling rules that analysts apply at intake. Synchronization with forum partners is enabled only for the groups the register approves. The output is a written sharing policy and a tested configuration in which a test event is visible to the intended group and hidden from others. Confirm this test before any production feed is connected.
Connect exports to detection
Engineers connect the platform's exports to the tools that act on indicators, such as network sensors, the SIEM and the SOAR platform, using formats the detection tools accept. Each connection is limited to the indicator types and confidence levels set in the requirements. The output is a mapping that lists each consumer, the export format, the update method and the owner. This mapping supports DE.AE-07, which expects threat intelligence to be fed securely to detection technologies, processes and people. Validate by confirming that a known test indicator produces an alert in the target tool.
Set curation and aging rules
Analysts agree who curates indicators, how each source is scored, and when stale or unconfirmed indicators are removed or downgraded so they stop generating alerts. The rules also cover how false positives are reported and corrected. The output is a curation procedure with named roles and a review cadence written into the team's operating model. The step is complete when a sample of indicators has been reviewed under the procedure and the outcome is recorded, which gives evidence that intelligence is analyzed before it is acted on.
Collect evidence and review against the CSF Profile
The team gathers the records produced in each phase, including the forum register, sharing policy, export mapping, curation logs and alert tests, and maps them to the relevant CSF 2.0 Subcategories, including ID.RA-02 and DE.AE-07. Gaps are logged against the Current Profile and assigned to owners. DeployOpen prepares this evidence for internal reviews and assessments, but independent auditors decide whether the controls meet any requirement. The phase closes when the Profile review is signed off by the accountable executive and the open gaps have dated owners.

How much does open source threat intelligence for NIST CSF 2.0 cost and who does the work?

What does it cost to run MISP or OpenCTI for NIST CSF 2.0?

The software licenses are not the main cost. MISP is licensed under AGPL-3.0 and OpenCTI ships a Community Edition under Apache License 2.0, so the recurring spend sits in infrastructure, connector and integration work, paid feeds, analyst time and any OpenCTI Enterprise subscription. Ask for a quote that separates one-time implementation from recurring hosting, feed subscriptions and support, and that names each cost driver so you can see what moves the total up or down.

What infrastructure does an OpenCTI deployment need?

OpenCTI depends on Elasticsearch 8.0 or OpenSearch 2.9 or later, Redis 7.1 or later, RabbitMQ 3.11 or later, and S3-compatible storage such as MinIO. Its documented sizing starts with 2 cores and at least 8 GB RAM for the platform, 2 cores, 8 GB RAM and 16 GB SSD for Elasticsearch or OpenSearch, and at least one platform node for every 3 workers. Those are starting points. Your feed volume, retention period and number of connectors determine the final sizing, so confirm it against your own intelligence load before budgeting.

Does OpenCTI Enterprise Edition cost more than the Community Edition?

Yes, the Enterprise Edition is licensed under the proprietary OpenCTI Enterprise Edition License, which is separate from the Apache License 2.0 that covers the Community Edition. Whether you need it depends on which features your intelligence workflow requires, so confirm with Filigran which capabilities are in each edition before you commit. Also check the LTS terms: OpenCTI LTS releases require a specific LTS license key to use, which is a licensing point to raise in procurement.

What must our team supply before a partner can start?

Expect to supply the intelligence requirements, the list of consumers who will use the outputs, the feeds and sharing communities you intend to join, and the systems the platform must connect to, such as your SIEM, firewalls and SOAR. You also need to name who curates indicators and who approves sharing under your TLP and distribution rules. Provide hosting access in your own cloud account, data center or air-gapped network, along with identity and secrets integration points. A written scope depends on these inputs, so prepare them before the scoping call.

Can our internal team deploy MISP or OpenCTI without a partner?

A capable platform or security engineering team can deploy either platform, since MISP offers an Ubuntu 24.04 installer, Docker images, Ansible roles and other packages, and OpenCTI publishes its deployment architecture. The harder work is ongoing: connector configuration, sharing group governance, STIX and TAXII exchange, mapping outputs to ID.RA-02 and DE.AE-07 evidence, and upgrades. Assess whether your team has time for those tasks on a sustained basis, and whether you want an outside partner for the initial build, the upgrade cycle or both.

How long until we share our first event with a community?

The technical deployment is usually not the constraint. The timing depends mostly on community onboarding: the sharing community or ISAC must approve your membership, agree on distribution levels and TLP rules, and exchange trust material with your instance before any event is shared. Those steps run on the community's schedule, not yours. Ask a partner to separate the technical build from onboarding in the written timeline, and confirm with the community which steps it requires before the first event.

Does NIST certify threat intelligence platforms or implementations for CSF 2.0?

No. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans for a conformity assessment program. A platform vendor or implementation partner cannot provide a NIST certification for your deployment. The CSF is a voluntary framework, so the evidence you produce is a mapping of your systems and outputs to the ID.RA-02 and DE.AE-07 outcomes, which your own assessors or customers review.

What does DeployOpen do and what does it not do in this engagement?

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, and it prepares systems, controls and evidence for compliance assessments. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer. DeployOpen does not issue audit reports, attestations or certifications, and it does not publish a price list, so a quote follows from the written scope.

Build, partner or SaaS for CSF-aligned threat intelligence

The first decision is who runs the platform after go-live. MISP and OpenCTI Community Edition carry no license fee, so the sourcing question is really about who is paid for engineering, hosting, feed curation and evidence. In-house build gives full control of sharing groups, feeds and the link to detection tools, but it puts the work of keeping the platform patched, the connectors current and the IDENTIFY and DETECT evidence in your own staff. A fixed-scope engagement with an implementation partner moves the one-time work (architecture, installation, feed and sharing setup, SIEM and SOAR integration, and documentation mapped to ID.RA-02 and DE.AE-07) into a written deliverable with agreed timelines. A commercial threat intelligence platform replaces much of that build with a subscription, but you pay recurring fees and still need staff to decide what intelligence matters to your organization.

Separate one-time costs from recurring ones. One-time costs include design, deployment, initial connector and sharing configuration, integration testing and the first evidence pack. Recurring costs include hosting, storage and the backing services OpenCTI requires (Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage), paid feeds, analyst time for curation and false-positive review, upgrades, and any OpenCTI Enterprise Edition subscription. MISP 2.4 is end of life, so budget for upgrades to the 2.5 line as a recurring item. A written quote should state which edition and license terms apply, which feeds and connectors are included, who owns the sharing group configuration, and what the evidence pack contains. Confirm whether the quote covers the Enterprise Edition features you need and whether those features are priced separately.

For an ongoing support retainer, ask for the scope of platform patching, MISP or OpenCTI version upgrades, connector maintenance, and monitoring of sharing synchronization. Ask how often the partner reviews feed quality and how it reports ageing of indicators. Ask who answers when a sharing community changes its distribution rules, and what response the retainer commits to. Confirm in writing whether the partner prepares evidence for your assessor or only supplies it, because DeployOpen prepares systems, controls and evidence but does not issue audit reports or certifications. Use the NIST CSF FAQs as the reference for what the framework does and does not certify, since NIST offers no conformity assessment program.

What to ask an implementation partner before signing

Use these questions to test whether a partner can tie ID.RA-02 and DE.AE-07 to working feeds, sharing rules and detection outputs, not just a installed platform. Each answer should produce a written artifact you can keep as evidence and hold the partner to in the statement of work.

Ask how feeds map to ID.RA-02
Ask the partner to list every intelligence feed and sharing forum they will configure in MISP or OpenCTI, and to name the ID.RA-02 Implementation Examples each source supports, such as ingesting feeds securely, reviewing threat actor and TTP advisories, and tracking vulnerabilities in emerging technologies. Ask who selects each source and who approves it. The check is a feed register with source, owner, licence terms, ingestion method and the ID.RA-02 example it serves.
Confirm sharing groups and distribution levels
Ask how sharing groups, distribution levels and TLP markings will be set for each community and for each attribute, and who may change them. Ask the partner to show how an indicator received under one sharing agreement is kept from reaching a community it was not meant for. MISP supports distribution down to individual attributes, so the partner should demonstrate that configuration on a test event. The output is a written sharing policy the partner has tested.
Verify the path from indicators to detection
Ask the partner to describe each export and connector that moves indicators into detection tools, such as Suricata, Zeek, the SIEM or firewalls, and which formats carry them. Ask how DE.AE-07 is met, meaning how threat intelligence and contextual data reach detection technologies, processes and people. Request a test showing one indicator travelling from the platform to a detection tool and producing an alert, with the log entry kept as evidence.
Define how false positives are aged out
Ask how indicators get an expiry or decay rule, who reviews stale or disputed indicators, and how a false positive is removed from downstream sensors and from communities it was shared with. Ask whether MISP correlation and warning list settings will be tuned for your environment before go-live. The partner should give you the written rule set and a sample review record that shows an indicator being retired.
Identify which OpenCTI features need Enterprise
If OpenCTI is in scope, ask the partner to list each feature the design depends on and state whether it is in the Community Edition under Apache License 2.0 or needs the OpenCTI Enterprise Edition License. Ask them to confirm which licence key and which LTS line they will deploy, since LTS releases need a specific licence key. Ask for the answer in writing, checked against the OpenCTI Enterprise Edition documentation at the time of contract. The output is a feature-by-licence table signed off by you.
Assign connector and upgrade ownership
Ask who maintains each connector, who applies MISP and OpenCTI upgrades, and how security patches are tested before they reach production. Ask which version line will be deployed, and whether the partner will move you off any line that has reached end of life. Ask what is handled under a support retainer and what is a separate fixed-scope change. The check is a responsibility matrix naming a person or team for every connector, upgrade and patch step.

How DeployOpen scopes, delivers and supports threat intelligence for CSF 2.0

DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For threat intelligence aligned to NIST CSF 2.0, we start from written outcomes for ID.RA-02 and DE.AE-07, then build a MISP or OpenCTI deployment that fits your sharing rules, data handling limits and detection stack.

How we scope

Engagements are fixed-scope, with the sharing communities, feeds and detection tools agreed in writing before work starts.
The written scope names which CSF 2.0 outcomes the platform supports and which Subcategories stay with your existing processes.
We confirm distribution levels, TLP handling and sharing group rules with your legal and compliance owners during scoping.

How we build

We deploy MISP or OpenCTI in your cloud account, data center or air-gapped network, with dependencies sized to your environment.
We configure feed ingestion, correlation and export to the detection tools that will consume indicators, then test each path.
We document data flows, sharing group settings and integration points so your team can audit how intelligence reaches detection.

How we hand over

Handover includes configuration records, runbooks for feed onboarding and indicator review, and a map to the relevant CSF 2.0 Subcategories.
We provide evidence packs that show how intelligence was received and used, prepared for your internal reviewers or independent auditors.
Your team receives training on curation, aging out false positives and running upgrades, so operation does not depend on us.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the initial engagement.
Retainers can cover platform upgrades, connector maintenance and periodic review of feeds and sharing group settings.
Confirm with us in the quote which upgrade paths, including MISP 2.5 or OpenCTI LTS line changes, are covered by the retainer.