Threat intelligence requirements checklist

How to use this threat intelligence platform requirements checklist

Your security team has decided to run MISP or OpenCTI, but the decision alone does not tell an implementer what the platform must do. This checklist turns that decision into written requirements, and each requirement carries a verification step, so you can tell whether it was met once the platform is running. Work through the sections in order, because later items depend on the answers to earlier ones. For example, the sharing communities you join determine the distribution levels and TLP rules you need, and those rules then shape the data model and the integrations.

Assign each part of the checklist to an owner before any build work starts. The CTI lead owns intelligence requirements, consumers and the list of feeds and sharing communities. The SOC owns the consumers that act on indicators, including firewall, SIEM and SOAR integrations and the false positive process. Legal and data protection review sharing agreements, the handling of personal data inside indicators and any restrictions on where data may be stored. The platform team owns hosting, identity integration, backup and upgrades. Someone must be accountable for who curates indicators, because that role decides how quickly stale data is removed.

Keep the requirements platform-neutral until the comparison section. Many items, such as sharing groups, STIX and TAXII exchange and TLP handling, apply to any platform, and writing them first prevents the product choice from quietly reducing your scope. Record each requirement as a short statement with an owner, an acceptance test and an evidence location, such as a test export or a documented sharing policy. Items you cannot test yet should be marked as open questions for the implementation partner to confirm against the versions you intend to deploy.

Which functional requirements to write down before choosing MISP or OpenCTI

This table lists the functional requirements to define before selecting MISP or OpenCTI, why each one matters and a check to run in a proof of concept. Items the vendor documentation does not clearly confirm are marked as questions to confirm, so the team can close them before committing.

Requirement	Why it matters	How to verify in a proof of concept
Intelligence requirements and named consumers	Without a written list of who reads which intelligence (SOC, fraud, OT, executives), the platform fills with indicators nobody acts on.	Write three to five priority questions with named consumers, then confirm each can be answered from a sample feed within the proof of concept.
Feeds and sharing communities	Default feeds differ in quality and licensing, and community membership sets sharing rules and obligations.	Load the default feeds and one trusted community feed, then check the sources, licenses and refresh schedule for each.
STIX and TAXII import and export	Partners and tools exchange intelligence in STIX and TAXII, so gaps here block sharing and tool integration.	Import a STIX 2 bundle and export the same event, then confirm the TAXII server or client the partner uses can connect. Confirm the TAXII version supported in each platform's documentation.
Distribution levels and TLP rules	Sharing outside the intended audience is the most common handling failure, and sector rules often depend on it.	Create events with each distribution level and a sharing group, then confirm a non-member instance cannot see them. Ask the vendor how TLP labels map to platform settings.
Correlation across events and sources	Correlation links new indicators to past campaigns, which is where most analyst time is saved.	Load overlapping indicators, then test exact matches and pattern matches. Confirm which correlation types, including CIDR and fuzzy hashes, each platform supports.
Taxonomies, galaxies and ATT&CK mapping	Shared tags let different teams and partners describe the same threat in the same terms.	Tag a sample event with a taxonomy and an ATT&CK technique, then search by tag. For OpenCTI, confirm the ATT&CK connector is included in the chosen edition.
Enrichment and export to detection tools	Enrichment turns raw indicators into actionable context, and export feeds firewalls, IDS and SIEM rules.	Export indicators to Suricata or Zeek format and to the SIEM, then confirm a test indicator produces an alert. Confirm which enrichment connectors work offline if air-gapped.
Indicator aging and false positive handling	Stale indicators cause false positives and noisy blocking, so expiry rules must be defined before go-live.	Set an expiry period on a test feed, then confirm expired attributes stop exporting. Ask the vendor how false positive flags are recorded.
Access roles and single sign-on	Curators, analysts and partner users need different rights, and access must be auditable.	Create three roles, log in through the chosen identity provider, and check the audit trail records changes. Confirm the authentication method each platform documents.

How to define intelligence requirements and consumers first

This sequence fixes the decisions, consumers and priority questions before any feed or sharing community is connected, so the platform only collects indicators that someone will act on. The output is a short requirements record that the data model, distribution rules and integrations are built from.

List the decisions intelligence must support
Start by writing down the specific decisions the platform should inform, such as whether to block a domain at the firewall, whether to hunt for a actor's tooling in the last 90 days, or whether to brief leadership on a campaign aimed at the sector. The security lead and the heads of operations for each affected team draw up the list in a workshop. It is done when every decision has an owner and names the action that follows from it, so no entry stays abstract.
Identify and interview the intelligence consumers
Name every team that will receive or act on intelligence, including SOC analysts, incident responders, fraud teams, vulnerability management and leadership. For each consumer, record the format they need (indicator lists, campaign summaries, ATT&CK-mapped behaviors), how fast they must receive it, and which tools they already use. Interviews with each group usually surface requests that a single feed would not meet. The output is a consumer register that lists the requirement and the decision it serves for each group.
Set priority intelligence questions
Turn the decisions and consumer needs into a short set of priority intelligence questions, such as which threat groups target the organization's sector or which vulnerabilities in internet-facing products are being exploited. Keep the list short enough that an analyst can answer each question from sources. Have leadership approve the list, since it sets the scope for collection. The check is that each question maps to at least one consumer and one decision.
Define the indicator and context types needed
For each question, decide which observables and context the platform must hold, such as IP addresses, domains, file hashes, email artifacts, ATT&CK techniques or victim sector data. Note which of these must reach detection tools and which only support analysis. This list determines the data model you will configure later in OpenCTI or MISP, and it shows whether personal data could enter the platform. The output is an attribute list with a stated purpose for each type.
Define the sources and communities to evaluate
Only after the questions are set, shortlist feeds, sharing communities and commercial or open sources that could answer them. For each candidate, record the coverage it offers against the questions, the license terms that govern reuse, and any membership or vetting it requires. Confirm with the community operators which sharing rules apply, because they may restrict redistribution. The output is a source register with a decision to adopt, defer or reject each source.
Set the success measures and review cadence
Agree how the team will judge whether intelligence is used, such as the share of indicators that generate a detection, the number of questions answered in a period or the feedback from responders on relevance. Set a review cadence for the questions and sources, and assign who retires stale feeds. Ask the consumers to confirm the measures in writing. The check is a signed requirements record that names the owner of every question, consumer and source.

Which security requirements a threat intelligence platform must meet

A threat intelligence platform holds indicators that other organizations trust you with, and some of them describe incidents involving personal data or regulated systems. The controls below cover who can see and share what, how the platform is protected, and how every action is recorded. Each one should be decided before deployment, because retrofitting access rules into a shared MISP or OpenCTI instance is harder than designing them in.

Unique user identification and role-based access

Every analyst, feed operator and automation account needs its own identity, with roles that limit who can create events, edit attributes, publish to communities or administer the instance. The HIPAA Security Rule's access control standard in 45 CFR 164.312 expects unique user identification for systems holding ePHI, and the same expectation applies to any system holding sensitive incident data. Check that shared accounts are not used for API keys, that API keys can be scoped and revoked, and that roles map to your curation process rather than to job titles.

SSO and multi-factor authentication

Connect the platform to your workforce identity provider so that accounts are created, disabled and grouped centrally, and enforce multi-factor authentication for every interactive login. The FTC Safeguards Rule in 16 CFR 314.4 requires covered financial institutions to apply MFA to any individual accessing an information system, and sharing platforms are a common phishing target because they hold valuable indicators. Confirm which MISP authentication plugins or OpenCTI authentication options your version supports, and decide how leavers lose access to community sync credentials.

Encryption in transit and at rest

Indicators can reveal your monitoring coverage, investigations and sometimes personal data, so protect them on the wire and on disk. Require TLS for the web interface, API, synchronization between instances and connector traffic, and encrypt the database, search index, object storage and backups. OpenCTI keeps data in Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage, so each of those stores needs its own encryption decision. Ask which components the platform encrypts natively and which depend on the host or storage layer.

Audit logging of views, changes and sharing

Record who viewed, created, edited, published, exported or shared each event and attribute, with timestamps and the sharing group or community involved. The HIPAA audit controls standard in 45 CFR 164.312 expects systems holding ePHI to record and examine activity, and the FTC Safeguards Rule expects monitoring and logging of authorized user activity. Decide where these logs go, how long they are kept, and who reviews them. Confirm which actions MISP or OpenCTI log by default and which need additional configuration or forwarding to your SIEM.

Host hardening and patch cadence

The platform, its database, search engine, message broker and operating system all need a documented hardening baseline and a patch schedule. MISP 2.4 is end of life with security fixes only, and the project recommends MISP 2.5 for new deployments, so confirm the version you deploy is still supported before you commit. OpenCTI has non-LTS releases from daily to weekly and LTS releases every 6 months, so decide which line you will follow and who applies hotfixes. Keep the admin interface off public networks and restrict outbound connections to the feeds and communities you actually use.

Protection against accidental release

The most damaging sharing mistake is publishing an indicator from a sensitive investigation to a wider community than intended. Use distribution levels and custom sharing groups to limit each event, confirm that defaults do not publish to communities automatically, and require review before publication for events marked as restricted. Check whether indicators can be exported to Suricata, Snort, Zeek or STIX without the same distribution restrictions, since exports can leave the platform outside its sharing controls. Test these rules with a restricted sample before live data arrives.

How MISP or OpenCTI connects to the SIEM, firewalls and SOAR

A MISP or OpenCTI instance only reduces risk when its indicators reach the tools that act on them. Each integration below moves data in a different direction, uses a different export format, and depends on versions and credentials in the receiving product that you must confirm before go-live.

SIEM ingestion of indicators

Data flows from the platform into the SIEM so that log searches and correlation rules can match indicators such as IP addresses, domains and file hashes. Decide which event types and distribution levels reach the SIEM, since sharing-group restrictions must still apply after export. Confirm the SIEM connector or ingestion method supported by your SIEM version, the service account used for pulls, and how indicator expiry is applied so stale entries stop matching.

Firewall and blocklist export

Indicators are exported as lists that firewalls, DNS filters and proxies can load, with the RPZ format covering DNS policy use cases. Define which indicator types are blocked automatically and which only go to analysts, because a false positive in a blocklist causes an outage. Confirm the firewall vendor's supported list formats and update intervals, and whether the device pulls from the platform over an authenticated channel.

Network sensor rules for Suricata and Zeek

MISP exports indicators as Suricata, Snort and Zeek formats, so network sensors can alert on known command-and-control domains or addresses. Decide which rule sets are generated automatically and who approves them before they reach production sensors. Confirm the Suricata and Zeek versions in your sensor fleet against the export syntax you generate, and test rule loading on a non-production sensor before each update.

SOAR enrichment and playbook triggers

SOAR playbooks query the platform to enrich alerts with context such as related events, galaxy tags and ATT&CK technique links, and can open a case when a matching indicator appears. Define which enrichment results can trigger automated containment and which require analyst review. Shuffle and similar tools call the platform API, so confirm the API key scope, rate limits in your deployment, and the version of the platform API your playbooks expect.

STIX and TAXII exchange with partners

STIX and TAXII are the formats and transport used to exchange structured intelligence with partners who do not run MISP or OpenCTI. MISP exports STIX 1 and STIX 2, and OpenCTI is built on the STIX 2 model, so decide which version each partner expects before you publish. Confirm the partner's TAXII server or client version, mutual authentication method, and how TLP markings carry through the exchange.

Which sharing communities and TLP rules to set before the first import

Before the first indicator is imported, decide which sharing communities you will join, who may see what, and how each TLP label maps to a distribution setting. Sharing rules are easier to set before data arrives than to correct after it has been synchronized outward. Start with the communities your sector and customers actually depend on, such as an ISAC, a national CERT, a peer group or a supplier community. For each one, record the sharing agreement, the expected direction of exchange (import only, or import and publish), and the handling rules the community requires. Do not assume a community's rules match the defaults in your platform. Write them down in the requirements document so the people who configure synchronization and the people who approve it work from the same source.

In MISP, the distribution level on each event and attribute controls who can receive it. The levels range from this organization only, through the community, to all connected communities, and custom sharing groups let you restrict an event to a named set of partner instances. MISP supports distribution down to individual attributes, so one event can carry a broadly shareable indicator next to a sensitive one. Map TLP to these settings explicitly, for example TLP:CLEAR to a wide distribution and TLP:RED to an organization-only or named sharing group, and confirm that the mapping is enforced at the attribute level for your version. For OpenCTI, the access model (marking definitions, groups, and how markings propagate to related objects) must be confirmed by the buyer and tested with sample data, because the controls for the same purpose work differently and the Enterprise Edition may change what is available. Ask the implementation partner to show a test event that reaches the right recipients and nobody else.

Which operational requirements decide whether curation keeps up

This table compares the operational requirements that determine whether a self-hosted MISP or OpenCTI instance stays current after launch. Each row names what to define and how to verify it, such as a restore test or an upgrade rehearsal in a non-production copy. The main takeaway is that curation capacity, upgrade cadence and backup discipline matter more than the initial install.

Requirement	What to define	How to verify
Curation ownership and cadence	Named curators for each feed and sharing group, with a stated review frequency for new indicators and retired ones	Run a sample week of indicator submissions and confirm each has an owner, a review date and a recorded decision
False positive ageing and expiry	Rules that set how long an indicator stays active, when it is downgraded or expired, and who can override the rule	Check that expired attributes stop exporting to Suricata, Zeek or SIEM feeds, and confirm the decision trail in a test event
MISP upgrade path	Target MISP 2.5, since 2.4 is end of life with security fixes only and the project advises against new 2.4 installs	Rehearse the upgrade on a cloned instance with the provided Ubuntu upgrade script and record the database migration result
OpenCTI release model	Choose between regular releases and the LTS line, and set a patch intake process that matches the chosen model	Confirm the license key requirement for LTS builds, then test a container image swap in staging before production rollout
Backup and restore	Scope of data to protect: database, search index, object storage, configuration and sharing keys, with a recovery time target agreed internally	Perform a full restore into an isolated environment and compare event counts and attribute counts with the source
Elasticsearch or OpenSearch sizing	Index growth from feeds and enrichment, retention period and node count, using the vendor minimum as a floor only	Load a representative feed volume in staging and measure disk, heap and query latency against agreed thresholds
Redis, RabbitMQ and storage	Queue depth expectations for OpenCTI workers, Redis memory limits and S3-compatible storage capacity for files	Simulate a worker outage and confirm queued messages drain after restart without data loss
Monitoring and alerting	Health signals for workers, connector failures, sync errors, feed ingestion lag and disk growth	Trigger a deliberate connector failure in staging and confirm an alert reaches the on-call channel

How MISP and OpenCTI answer the same checklist differently

MISP is organized around sharing. Its checklist answers center on distribution levels, sharing groups and synchronization with trusted communities, and its stack is a conventional PHP application that most platform teams can operate.

Sharing model: Distribution levels and custom sharing groups can be applied down to individual attributes. Map your TLP labels and community membership rules to these settings before go-live, because they are hard to correct after members begin syncing.
Stack: MISP is built on PHP with CakePHP, MySQL or MariaDB, and Redis. Confirm that your database and hosting teams already support these components.
Version and migration: MISP 2.5 is the recommended line for new deployments, and MISP 2.4 is end of life with security fixes only. MISP 2.5.47 introduced a new database migration system with PostgreSQL support, so settle your database standard before choosing the install path.
Exports and API: Native exports include STIX 1 and 2, Suricata, Snort, Zeek and RPZ, and the API is described with OpenAPI and used through PyMISP. List the formats each sensor and firewall needs and test them.
Authentication: The OidcAuth plugin README describes single sign-on for the 2.5 branch. Confirm its fit with your identity provider and who supports it.

Confirm the database choice, the sharing group map and the export formats first, since these are the items most expensive to change once members are connected.

What compliance evidence the requirements should produce

The checklist is only useful to an auditor if each decision it records leaves a document, a configuration state or a log behind. Treat every requirement in this list as an evidence item from day one: the written intelligence requirements, the sharing rules per community, the access review for each analyst and sync account, the audit trail of sharing and configuration changes, and the record of why each indicator was accepted, changed or retired. ISO/IEC 27001:2022 Annex A control 5.7, Threat intelligence, is the control most directly served, because it asks an organization to collect, analyze and act on threat information. Its title is the anchor for the evidence pack, and the wording of the control itself should be read from the standard, not paraphrased into policy.

For MISP, the evidence sits in the distribution level and sharing group fields on each event and attribute, in the sync configuration with each partner instance, and in the audit log of changes made to them. For OpenCTI, it sits in the author, marking definition and confidence fields on each object, and in the platform's activity records. Ask your implementation partner to show, before go-live, how each of these fields is populated, who may change them, and where the change history is retained and for how long. Confirm the retention behavior of both platforms and any log forwarding to your SIEM in your own environment, because the default settings may not meet your own evidence period.

Access reviews should be run on the platform's own user and role lists, with a named owner who signs off each quarter or on the cadence your policy sets, and the same review should cover service accounts used for feed ingestion and sharing. Curation decisions need their own record: who approved an indicator, the source, the reason for any false positive removal, and the date of expiry. The applicable sharing and retention rules depend on your sector, your contracts with sharing communities and the advice of counsel, so have those confirmed before the evidence format is fixed. DeployOpen prepares the systems, controls and evidence for an assessment, but independent auditors and certification bodies issue any assessment or certification.

What buyers ask before hiring help with a threat intelligence platform

What does the requirements work for a threat intelligence platform cost?

The cost is the effort of a written requirements phase, not a software fee, because MISP is free and the OpenCTI Community Edition is licensed under Apache License 2.0. The main cost drivers are the number of feeds to evaluate, the number of integrations to define (SIEM, firewalls, SOAR), the sharing communities you intend to join, the sector rules that set retention and distribution, and whether you need OpenCTI Enterprise Edition features under its separate license. Ask for a quote that lists each of these as a line item, states what is one-time and what recurs, and names who is paid for what. DeployOpen does not publish a price list; a quote follows from the written scope.

How long does threat intelligence requirements work take?

The duration depends on how many consumers, feeds, sharing communities and integrations need decisions, and on how quickly your owners approve them. No duration is set here because DeployOpen agrees timelines in writing as part of a fixed scope. Timing usually moves for three reasons: unclear intelligence consumers, pending sharing agreements that require legal review, and integration targets (SIEM, firewalls, SOAR) whose owners have not confirmed their input formats or change windows. Ask for a schedule with named milestones and the buyer decisions each milestone depends on.

What do we need to provide for threat intelligence requirements?

The work needs three named people from your side before it starts. A CTI lead owns the intelligence requirements, the consumers and the curation rules. A SOC contact confirms which detection tools will consume indicators and how alerts should be handled. A data owner signs off on what indicators may contain, how long they are kept and who may see them, including whether any indicator could carry personal data. Without these sign-offs, distribution levels and TLP rules tend to be set by default and revisited later. Confirm these roles in the scope document before work begins.

Can a small team define requirements and run MISP or OpenCTI alone?

A capable team can deploy and learn MISP and the OpenCTI Community Edition without outside help, and the upstream documentation covers installation options for both. The harder part is the requirements decisions: which sharing communities to join, how distribution levels and sharing groups map to your obligations, and how indicators are aged out and curated. OpenCTI also depends on Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage, so you need operators for those services. If your team lacks these skills, a fixed-scope engagement can cover requirements, deployment and handover, and ongoing support is available as a retainer.

Should we fix threat intelligence requirements before or after a proof of concept?

Fix the core requirements before the proof of concept, and treat the proof of concept as a test of them. The requirements that must be settled first are the consumers, the sharing communities, the distribution and TLP rules, and the data model, because changing them after data is loaded can mean re-tagging events and reworking sharing groups. Use the proof of concept to test feed ingestion, the SIEM and firewall export paths, and sizing against the OpenCTI platform, worker and dependency guidance. Record what changed during the test and update the written requirements before production.

Which OpenCTI features require the Enterprise Edition?

Confirm this with Filigran and the current OpenCTI Enterprise Edition documentation rather than assuming, because the feature split can change between releases. The Community Edition is licensed under Apache License 2.0 and the Enterprise Edition falls under a separate proprietary license. Put each feature your requirements depend on on a checklist, verify its edition status against the vendor documentation, and record the answer in the scope. If a feature is Enterprise only, the licensing cost belongs in the quote alongside the infrastructure and integration work.

Does the requirements work cover sector rules such as sharing obligations?

Requirements work should record which rules apply to your sector, but it does not produce a legal opinion or a compliance certification. For example, US healthcare organizations subject to the HIPAA Security Rule at 45 CFR 164.312 need audit controls and unique user identification for systems that handle ePHI, so indicators and sharing logs must be governed accordingly. Financial institutions under the FTC Safeguards Rule at 16 CFR 314.4 need multi-factor authentication and activity logging for the platform itself. Ask your counsel and compliance lead to confirm which obligations apply, and ask DeployOpen to prepare the controls and evidence those obligations require.

How DeployOpen scopes and delivers the requirements phase

DeployOpen treats the requirements phase as a written, fixed-scope engagement that turns intelligence needs into a platform design before any server is built. The output is the decisions this checklist describes, documented so your team and any implementation partner can build from the same baseline.

How we scope

Interview intelligence consumers and record which decisions each feed of indicators must support.
Agree in writing which sharing communities, feeds and distribution levels are in scope for the first release.
Map the SIEM, firewall and SOAR integrations to named owners, data flows and the TLP rules each one must honor.

How we build

Draft the data model, including whether MISP events or OpenCTI STIX objects will carry each indicator type.
Define the curation workflow, including who approves indicators, how false positives are aged out and how sharing groups are assigned.
Prototype the exchange path with STIX and TAXII on a test instance so the requirements are checked against real behavior.

How we hand over

Deliver a written requirements document covering consumers, feeds, sharing rules, integrations, data model and curation roles.
Provide a decision log that records each open question, the option chosen and the person who approved it.
Hand over the test results and configuration notes that the implementation phase will reuse without rework.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the requirements are signed off.
Review the requirements when MISP or OpenCTI release lines change, such as MISP 2.5 or OpenCTI LTS branches.
Confirm with your team which licensing terms, including any OpenCTI Enterprise Edition features, apply before build starts.

Threat intelligence platform requirements checklist