MISP vs OpenCTI data model compared

Which MISP vs OpenCTI data model fits your analysts and sharing workflow

A threat intelligence team that has to decide how its data should be structured should settle one question before choosing a platform: is the data mainly meant to be pushed to other organizations quickly, or is it meant to be analyzed and linked into a long-lived knowledge graph? MISP fits sharing-first workloads, and OpenCTI fits analysis-first workloads. The answer depends on which of those two workloads dominates, and most teams should measure their own weekly mix of incoming feeds, outgoing sharing and analyst investigation before deciding. MISP models intelligence as *events* that contain *attributes* (single indicators such as a hash, domain or IP address) and *objects* (grouped attributes describing one thing, such as a file or a network flow). *Taxonomies* and *galaxies* add shared tags and threat actor, malware and ATT&CK context. Every element carries distribution levels and sharing groups, and the model is designed so events synchronize between instances. Exports to MISP JSON and STIX 1 and 2 let analysts move that content to other tools. This model suits a team that publishes indicators to a community, needs per-attribute control over who sees what, and wants detection content such as Suricata or Zeek rules generated from the same records.

OpenCTI instead stores intelligence as STIX 2.1 entities and relationships in a graph, so a threat actor, campaign, malware and indicator can be connected and queried as one structure. Connectors import data from sources such as MISP, MITRE and CVE, and the platform's GraphQL API and workers write it asynchronously. This model suits a team that needs to answer questions such as which intrusion sets use a technique across several campaigns, and that accepts the operational cost of running Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage. Before committing, confirm which STIX objects your sharing partners accept, check how each import connector maps fields, and test a sample export round trip, since converting between the two models loses some structure in both directions.

How the two data models compare part by part

This table sets MISP's data model against OpenCTI's one component at a time, from the core container to licensing of the data layer. Read each row as a question you would ask your analysts, then check the marked items against your own environment before deciding which model fits your sharing and analysis workflow.

Model part	MISP	OpenCTI
Core container	An event groups attributes and objects under one title, date, threat level and distribution setting	A STIX-based entity (such as a report, indicator or threat actor) connected to other entities through relationships in a knowledge graph
Atomic indicators	Attributes hold single values such as IP addresses, hashes or domains, each with its own category, type and sharing flag	Observables and indicators follow the STIX 2.1 model; confirm how your connectors map imported values to observables
Grouped structures	Objects bundle related attributes into a template-based set, such as a file with its hashes and filenames	Relationships link entities to each other as first-class records, so grouping is expressed through the graph rather than a container
Classification	Taxonomies provide tags and galaxies supply shared clusters for actors, malware and ATT&CK techniques	Labels and MITRE ATT&CK data come through the dedicated connector; confirm which MITRE objects your connector version imports
Sharing controls	Distribution levels and sharing groups apply down to individual attributes and drive synchronization between instances	Platform roles and segregation control access; organization segregation and SSO configuration require the Enterprise Edition
Export formats	MISP JSON, STIX 1 and 2, OpenIOC, CSV, Suricata, Snort, Zeek and RPZ through the REST API	STIX 2.1 export from the platform; confirm which other formats are available in your release before relying on them
Data layer licensing	Software under AGPL-3.0; taxonomies and galaxy data under CC0 1.0 or 2-clause BSD	Community Edition under Apache-2.0; Enterprise Edition files under a paid proprietary license

How MISP events, attributes and galaxies shape what analysts see

In MISP, the event is the unit of work. Analysts group related indicators into an event, then attach individual attributes such as IP addresses, file hashes, domains and email addresses. Objects bundle attributes that belong together, such as a file with its hashes and filename, and taxonomy tags and galaxy clusters add context like threat actor, malware family or MITRE ATT&CK technique. What an analyst sees in the event view, and what a search returns, depends on how these pieces are tagged and linked. Before migrating or running both platforms, map which of your existing records are events with attributes and which are context objects, because OpenCTI expresses the same knowledge as STIX entities and relationships rather than as events.

Distribution settings decide what leaves the instance. Each event and attribute carries a distribution level, and sharing groups can restrict an event to named organizations. Setting distribution at the attribute level lets you share a single indicator while keeping the surrounding event internal. Synchronization and exports, including MISP JSON, STIX 1 and 2 and CSV, follow these controls, so a STIX export is only as complete as what the sharing settings allow. Ask your MISP administrators to document the distribution defaults for each sync partner and confirm them in a test export before any data moves to OpenCTI.

Correlation and licensing are separate questions. MISP's correlation engine links attributes across events through exact matches and advanced patterns, including fuzzy hashes and CIDR overlaps, with granular controls over what is compared. This is useful for analysts who need to see that a new indicator already appears in an older event. The taxonomies and galaxy data are licensed under CC0 1.0 Universal or the 2-clause BSD license, separate from the AGPL-3.0 license of the MISP software. Legal and procurement teams should review both licenses when they plan to redistribute MISP content, and confirm the terms of any third-party feed they import.

What changes the data model fit in practice

The two platforms store intelligence in different shapes, so the right fit depends on how your team uses the data day to day. The factors below cover the sharing versus knowledge graph choice, how deeply analysts model relationships, distribution, the STIX version your partners expect, connector dependence, and where OpenCTI's Enterprise Edition begins.

Sharing indicators or building a graph

MISP is organized around events and attributes that are pushed to sharing partners through distribution levels and sync. OpenCTI is organized around STIX entities and relationships that analysts browse and enrich as a knowledge graph. If your main output is indicators sent to peers, MISP's event model fits more directly. If your main output is reports, campaigns and linked actors, OpenCTI's graph is the closer match. Check which output your team will produce most often in the first quarter.

How much relationship modeling analysts need

MISP links data through objects, correlation and galaxies, which covers many analyst questions without a full graph. OpenCTI stores relationships between entities as first-class records, so analysts can traverse from a threat actor to campaigns, malware and indicators. Ask a sample of analysts to write three real investigative questions and check whether the answers require multi-hop traversal. If they do, test that query path in OpenCTI before committing.

Whether your community uses MISP distribution

MISP distribution levels and sharing groups control which attributes reach which instances, down to individual attributes. OpenCTI has its own access and segregation model, and its organization segregation controls require the Enterprise Edition. If your partners depend on MISP sync and trusted communities, moving the sharing function to OpenCTI means rebuilding those trust relationships. Confirm with your partners whether they connect over MISP sync before you design the flow.

The STIX version partners expect

MISP exports both STIX 1 and STIX 2, while OpenCTI's knowledge schema is based on STIX 2 standards. Partners still on STIX 1 tooling will need MISP's export path rather than OpenCTI's. Ask each partner which STIX version and which bundle structure their ingestion accepts, and test a round trip with a sample event before relying on either platform for exchange.

Connector dependence in OpenCTI

OpenCTI imports most external data through connectors, and its deployment depends on Python workers consuming RabbitMQ messages for writes. Each feed you rely on, including the MISP connector, is another component to deploy, patch and monitor. Teams that pull from MISP into OpenCTI should list every connector, its owner and its update path before go-live, because a stalled connector silently stops data from arriving in the graph.

The Enterprise Edition boundary

OpenCTI's audit logs, playbooks and automation, organization segregation and SSO through OpenID, LDAP or SAML require the Enterprise Edition. MISP's OidcAuth plugin is available within the AGPL-licensed project, so SSO and audit needs are judged differently on each side. Before choosing OpenCTI for workflows that need auditability or automation, confirm which of those features your compliance and access policies require and get the Enterprise Edition scope in writing.

How OpenCTI's STIX 2.1 knowledge graph and connectors store data

OpenCTI stores intelligence as STIX-based entities and relationships, not as MISP-style events with attributes and objects. Its knowledge schema is built on the STIX2 standards, and the web application sits on a GraphQL API. For an analyst, this means a threat actor, an indicator, a malware family and a campaign are separate typed objects linked by relationships that the platform can traverse, rather than attributes grouped under one event. When you map MISP content into OpenCTI, plan for each MISP object to be reshaped into STIX objects and relationships, and test that reshaping on a sample of real events before you commit a migration.

Data arrives through connectors. The MISP connector, along with MITRE and CVE connectors, pulls content into the platform, and the deployment overview describes import, enrichment, file extraction, export and stream connectors as separate roles. Writes are asynchronous: Python workers consume RabbitMQ messages, so a burst of imports builds a queue instead of blocking the UI. The stack is also a cost driver. OpenCTI depends on Elasticsearch 8.0 or later or OpenSearch 2.9 or later, Redis 7.1 or later, RabbitMQ 3.11 or later and S3-compatible storage such as MinIO. Confirm with your platform team who operates each of these services, how they are backed up and how they are sized against the documented minimums in the OpenCTI deployment overview.

The storage model shapes sharing as well as querying. MISP distributes events between instances according to distribution levels and sharing groups, while OpenCTI's graph is a single knowledge base that your team queries and enriches. Before you choose a data model, confirm whether your partners need to receive your intelligence in MISP form, in STIX form, or both, and whether your OpenCTI edition supports the access controls you need for segregating data. Identity and access features such as SSO through OpenID, LDAP or SAML are part of the Enterprise Edition, so check those requirements against your licensing decision.

Moving data between MISP and OpenCTI without losing meaning

In this setup MISP stays the system where events are created, shared and distributed, and OpenCTI imports them through its MISP connector so analysts can work with the material as STIX-based entities and relationships. Indicators, their types and their contextual tags generally have a natural place in the STIX model, so they are the first thing to check. Distribution and sharing rules are the part most likely to be lost, because OpenCTI does not apply MISP's distribution levels or sharing groups in the same way, so the imported copy must not be treated as carrying the same release restrictions.

Indicators and observables: Confirm that attribute types, values and timestamps arrive intact for the object types your team relies on.
Taxonomies and galaxies: Check how MISP tags and galaxy clusters appear after import, since they may become labels or linked objects rather than identical structures.
Distribution and sharing groups: Test whether restrictions survive the import, and document who can see imported data in OpenCTI.
Correlation results: Do not assume MISP's correlations are reproduced. Compare results on a sample event set.
Update and deletion behavior: Test how edits and removals in MISP propagate on later connector runs.

Before going live, run a sample of events with known attributes through the connector and compare the records on both sides, and confirm the connector version against the OpenCTI release you run.

How to test the data model fit in your own environment

This sequence shows, with your own data, what survives a round trip from MISP into OpenCTI and what does not. The output is a written gap record that your analysts, sharing owners and platform team can review before choosing a model.

Select a representative event sample
Pick a set of MISP events that reflects your real workload. Include events with attributes, at least one object template such as a file or network object, and events tagged with galaxy clusters and taxonomies. Include a few events with restrictive distribution levels or sharing groups, since these control what can leave MISP. Record the event IDs, their tags and their distribution settings in a sheet so you can trace every item later. The step is done when the sample covers each data shape your analysts use and the sheet lists every event ID.
Export the sample as MISP JSON and STIX
Using the REST API or the export tooling in your MISP instance, export the same sample in MISP JSON and in STIX 2. Keep the two files side by side and label them with the MISP version you ran. Compare object counts, tag names and galaxy references between the two exports, noting anything the STIX output drops or renames. The step is done when you have both exports for every sampled event and a short list of fields that differ between them.
Import the sample through the MISP connector
In your OpenCTI test environment, configure the MISP connector against your test MISP instance, limiting it to the sample events where possible. Confirm the connector version and its settings in your own environment, because import behavior depends on both. Run the import and let the workers finish processing. The step is done when the connector logs show each sampled event as imported, skipped or failed, and every failure has a recorded reason.
Compare what survives in OpenCTI
For each sampled event, open the matching objects in OpenCTI and check attributes, observables, object relationships, labels, marking definitions and galaxy-derived entities against your original MISP record. Mark each item as preserved, transformed, merged or missing. Pay particular attention to MISP objects that have no direct STIX equivalent and to galaxy clusters that map to different entity types. The step is done when every sampled event has a row for each checked field and the counts of missing or changed items are written down.
Check sharing controls against your distribution rules
Confirm how each sampled event's distribution level and sharing group were handled on the OpenCTI side. Ask your sharing owner which rules must hold after the import, then test them by logging in as users with different access levels in OpenCTI and checking what they can see. Verify with the platform documentation and your own configuration which access controls depend on the Enterprise Edition, since these vary by edition. The step is done when your sharing owner has signed off on a table showing each rule, the expected result and the observed result.
Record gaps and decide on remediation
Consolidate the findings from the previous steps into one gap register. For each gap, state the data affected, whether it blocks sharing, analysis or both, and whether it can be fixed by mapping, configuration or a change in how analysts record data. Ask your platform team and the DeployOpen or vendor contacts you engage to confirm which gaps are connector behavior and which are product limits, and confirm versions with the vendors before relying on any result. The step is done when the register is reviewed by analysts, sharing owners and platform engineers, and each gap has an owner and a recorded decision.

Questions teams ask before choosing a threat intelligence data model

Can MISP and OpenCTI hold the same threat intelligence data?

Partly, and the overlap depends on what you store. MISP organizes data as events, attributes and objects, with taxonomies and galaxies for tagging, and exports MISP JSON and STIX 1 and 2. OpenCTI organizes data as STIX 2.1 style entities and relationships in a knowledge graph. Indicators, malware, threat actors and reports map reasonably well, but MISP's sharing controls, distribution levels and sharing groups have no direct one-to-one equivalent in OpenCTI's model. Ask both vendors and your integrator to walk through a sample of your own events and confirm in writing which fields survive a round trip.

What does a data model migration effort depend on?

The effort depends mainly on how much of your history must move, how clean your existing MISP tagging is, and how closely your analysts rely on sharing semantics. Teams with consistent taxonomies and galaxies usually have an easier mapping than teams with free-text tags. Relationships that exist only in analyst notes will need manual rework. Decide early which data is migrated, which is archived and which is re-created from source feeds, because that choice drives most of the scope.

Can our own team build the mapping between the two models?

A capable engineering team can build a basic mapping, especially for indicators, if it has time to test against real records and owns the result afterward. The harder parts are edge cases: attribute types with no STIX equivalent, sharing rules that must be preserved, and relationships that need validation by an analyst. Before deciding, confirm internal skills in STIX 2.1, MISP's API and PyMISP, and the OpenCTI connector model. If those skills are thin, a fixed-scope engagement with written deliverables is one option to compare with an internal build.

What does the work need from our team before it starts?

Expect to supply representative sample data, a written list of sharing rules and distribution levels, and clear expectations for STIX output. Samples should include events with object relationships, galaxy-tagged records and any sightings or feeds that must be retained. Sharing rules need owners who can approve decisions about which communities receive which data. STIX expectations should state the STIX version, the object types analysts depend on and how strictly validation must pass. Ask any integrator to confirm these inputs in the written scope.

What drives the cost and time of a migration?

Cost is driven by the number of data types to map, the volume of history, the number of custom taxonomies or objects, the testing needed to show analysts that results match, and the number of integrations that read from either platform. Recurring costs include running and patching both platforms, sizing OpenCTI's dependencies, and any retainer for upgrades. Compare quotes against the same written scope, and ask each vendor or partner to itemize one-time mapping work separately from ongoing operations. No public figures for this work are supplied here, so request them in writing.

Which OpenCTI Enterprise Edition features gate parts of the workflow?

According to the OpenCTI documentation, audit logs, playbooks and automation, organization segregation and SSO through OpenID, LDAP or SAML require the Enterprise Edition. If your mapped workflow depends on any of these, the Community Edition will not cover that part, and the Enterprise Edition is licensed under a separate proprietary license with a paid subscription. Confirm current feature availability and subscription terms with Filigran or your reseller before finalizing the design, since product editions change over time.

Do the MISP and OpenCTI data models affect licensing for shared data?

They can. MISP is licensed under AGPL-3.0, and its taxonomies and galaxy data carry CC0 1.0 Universal or 2-clause BSD terms separate from the software license. OpenCTI Community Edition is Apache-2.0, while Enterprise Edition files use a proprietary license. Data you export or import keeps its own terms, so have legal counsel review how shared intelligence, feeds and galaxy content may be reused in each platform before moving data between them.

How DeployOpen helps teams evaluate and implement the data model

DeployOpen plans, implements, customizes, integrates, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including MISP and OpenCTI. For data model decisions, we start with a written scope that maps your events, indicators and sharing rules to the structures each platform actually uses.

How we scope

Written scope lists which MISP events, attributes and objects, and which OpenCTI entities, your teams need to keep.
Scope records the sharing communities, distribution levels and sharing groups your organization must honor.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.

How we build

We configure MISP taxonomies, galaxies and export formats, and map them against the STIX 2.1 model used by OpenCTI.
Connector setup and import tests show how MISP data appears as OpenCTI entities and relationships in your environment.
Testing covers round trips of sample indicators, so analysts can confirm that fields and sharing controls survive each move.

How we hand over

Handover documents the mapping rules, connector settings, field decisions and known gaps between the two data models.
Runbooks explain how to deploy, upgrade and back up each platform inside your own cloud, data center or air-gapped network.
Training and written records let your analysts and platform team operate the setup without depending on DeployOpen.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover re-testing of data mappings when MISP or OpenCTI releases change export or import behavior.
Confirm release-specific details, including OpenCTI LTS license requirements, directly with the vendors before scoping.

MISP vs OpenCTI data model