Cyware Intel Exchange or MISP: which fits your sharing model
A vendor-operated hub fits when you want someone else to run the sharing server and accept a subscription with support obligations. MISP fits when your data residency rules, board policy or member agreements require the sharing server to sit inside your own cloud account or data center. MISP is AGPL-3.0 software you install and operate yourself. Before you decide, check your current renewal terms and member agreements for the hosting location, the named operator and who can access raw event data. Those clauses often settle the question before any feature comparison starts.
The formats are not the deciding factor. Intel Exchange supports the MISP format, so a member that already exchanges MISP JSON can often keep doing so on either platform. The real difference is governance. MISP's sharing controls include distribution levels and custom sharing groups that reach down to individual attributes, and events can sync automatically between instances. Ask Cyware how its own sharing groups map to those controls, who administers group membership, and what audit records it keeps. Then confirm the same questions in a test environment with your own sample events before you commit.
The third factor is who must connect and who answers when a connection breaks. In a hub model, members usually join through accounts the vendor manages. In a MISP model, each member either runs its own instance and syncs with yours, or uses a shared instance that you host. The second option makes you the operator for membership, key issuance, patching, backups and sync failures. List your members by how they connect today, then ask each group which connection method they can support. Your answers will show whether the platform choice or the staffing model is the harder constraint.
Which platform fits which sharing scenario
This table matches common sharing scenarios to the platform that usually fits best, with the condition that makes the reason matter. Read each row as a starting point, then check the condition against your own membership, staffing and data rules before deciding.
| Scenario | Better fit | Reason and the condition that matters |
|---|---|---|
| ISAC with many small members | MISP | MISP's sharing groups, distribution levels and server-to-server synchronization suit a hub where many members run their own instances or connect as peers. The fit depends on members being able to operate or accept MISP sync, so confirm that before choosing. |
| National CERT running its own server | MISP | MISP is widely used among CERTs and sharing communities, and it supports STIX, MISP JSON, OpenIOC and NIDS exports for downstream tools. Choose it if the CERT wants to control sharing rules directly and publish feeds to constituents. |
| Team with no in-house platform staff | Depends on operating model | Either platform needs a named owner for upgrades, backups and member onboarding. Without that owner, a fixed-scope implementation with ongoing support may matter more than the choice of platform itself. |
| Analysis-heavy CTI team alongside sharing | OpenCTI for analysis, MISP for exchange | OpenCTI structures data on STIX 2 with a GraphQL API and connectors for MISP, so teams often run both. Running both adds components to maintain, so confirm the team has capacity for two systems. |
| Organization that must keep all data on its own servers | MISP or OpenCTI, self-hosted | Both are open source and run in your infrastructure, so the data stays where you put it. Confirm which vendor-hosted feeds or connectors still send data outward, since those flows sit outside the platform itself. |
| Member community already using Cyware feeds | MISP with a transition plan | Cyware supports the MISP format, which eases moving feeds and events. Plan member reconnection and sharing group rebuilds before cutover so existing integrations do not break. |
How MISP sharing groups and distribution levels control who sees what
Distribution levels decide how far an event or attribute can travel, and sharing groups decide which named organizations receive it. In MISP, each event carries a distribution setting that can limit it to the local instance, to a connected community, or to all instances that synchronize with yours. Sharing groups go further: they define a named set of organizations and the servers that may receive the data, and MISP supports applying distribution down to individual attributes, so one event can contain material for a wide audience alongside fields that only a small group should see. Before you configure anything, export a representative sample of your current Cyware Intel Exchange content and map each sharing rule to a MISP distribution level or sharing group. Confirm with Cyware how its own access and sharing controls behave in your configuration, because the mapping only works if you know exactly what each existing rule permits today.
Automatic synchronization carries these controls between servers. When one MISP instance pulls or pushes events to another, the receiving side applies the sharing rules attached to each event and attribute, and an instance will not forward material beyond the scope the originator allowed. This is what makes a federated community workable, but it also means a single misconfigured sync partner can expose data widely. Plan for testing with a non-production pair of instances, and verify that a restricted attribute does not appear on a partner server that is outside its group. Confirm the exact sync and filtering options in the MISP documentation for your version, and do not rely on memory or on a pilot that used only public data.
A community governance team has to settle several questions before onboarding members. It should decide who may create sharing groups and who approves them, which distribution level is the default for new events, how attributes that mention personal data or victim information are handled, and what happens when a member asks to be removed from a group that already received its material. It also needs a written rule for which sync partners are trusted, who signs off on adding a server, and how revocation works when a partner is compromised. Settle these rules first, then encode them in MISP, because changing sharing behavior after members have already exchanged data is much harder to explain to them.
Where the data lives and who controls the server
Cyware Intel Exchange is a hub that many organizations reach through a vendor-operated service or a vendor-supported deployment. With MISP, the server, the data and the access rules sit in your own infrastructure, which changes who answers for each control. The cards below set out where the data lives, how each option is hosted, how users sign in, what the license allows and what evidence you must produce yourself.
Where the intelligence is stored
With Cyware Intel Exchange, indicators, events and sharing metadata are held in the hub and in any connected member instances, and the exact storage location depends on your contract and deployment model. With MISP, every event, attribute and sharing group lives in the database on servers you choose. Ask Cyware in writing where hub data is stored, which regions and subprocessors handle it, and how member data is separated from other tenants. Then map the same questions to your MISP host.
Hosting models on each side
Cyware is offered as a vendor-operated hub, and the exact models available to you should be confirmed in your agreement. MISP runs on Ubuntu 24.04 through the project installer, or as Docker images, RPM packages, an Ansible role or a Puppet module. Choosing among these is a platform decision: your team, or a partner such as DeployOpen under a written scope, takes on patching, backups, high availability and monitoring of the server.
Identity integration with OIDC
Shared intelligence platforms are only as safe as the accounts that reach them. MISP supports single sign-on through the OidcAuth plugin, so logins can come from your existing OpenID Connect identity provider instead of local passwords. Confirm how Cyware handles SSO for your members, including MFA enforcement and deprovisioning when a person leaves a partner organization. For MISP, check the plugin configuration against your identity provider's group and role mapping before go-live.
Licensing under AGPL-3.0
MISP is licensed under the GNU AGPL version 3, so you can run, study and modify it without a per-seat license fee. The AGPL also requires that users who interact with a modified version over a network can receive its source, which matters if you customize the platform for a community. Taxonomies and galaxies are licensed separately under CC0 1.0 or the 2-clause BSD license. Have legal review how these terms apply to any custom code and to the content you share with partners.
Evidence you must produce yourself
A vendor hub can supply reports and certifications, but those cover the vendor's environment, not yours. With MISP, the logs, access reviews, sharing-group records, backup tests and change history that show how intelligence is handled are your responsibility. DeployOpen prepares the controls and collects the evidence for a compliance assessment, but it does not issue audit reports or attestations. Independent auditors and certification bodies make those determinations.
Who runs the platform under each model
In a vendor-operated model, the commercial provider runs the hub and its member connections, and the sharing community consumes the service under a subscription. The provider generally carries the platform lifecycle, but the contract defines exactly which duties move to the provider and which stay with your team. Read the agreement before assuming any duty is covered.
- Upgrades: Ask who schedules platform releases, how much notice members receive and whether your organization can test against a staging environment first.
- Backups and recovery: Confirm backup frequency, retention, where copies are stored and the documented restore process, including whether you can export your own intelligence independently.
- Member support: Clarify the support hours, escalation path and whether onboarding help for new member organizations is included or billed separately.
- Sync health: Ask how connection failures between the hub and member instances are detected and reported to you.
- Data custody: Establish where the data is hosted and who can access it at the provider.
Before signing, request the written support and service terms and confirm each duty above against them.
When your organization runs MISP on its own servers, your team owns every operational duty. MISP 2.5 is the version the project recommends for new deployments, and MISP 2.4 is end of life with security fixes only, so a new installation should start on 2.5. The project's download page recommends Ubuntu 24.04 with its installer, and also lists Docker images, RPM packages, an Ansible role and a Puppet module.
- Upgrades: Plan upgrades on a schedule you control. The download page provides an upgrade script for Ubuntu, and existing 2.4 instances should be moved off that branch.
- Backups: Back up the database and the file store, and test restores on a separate host. Record which instance is authoritative for each sharing group.
- Member support: Your team answers questions from connected organizations, so define who is on call and which channels members use.
- Sync health: Monitor synchronization jobs between your instance and partners, and alert when a pull or push fails or stalls.
- Hardening: Patch the operating system, PHP and database components as well as MISP itself.
Confirm that your staffing covers these duties before selecting this model, and check the MISP support page for the channels available to you.
A community hub is run by a national CERT, an ISAC or a sector body on behalf of its members. Members connect to a shared server with rules set by the community, and the operator carries most of the upgrade, backup and sync duties while members keep responsibility for their own instances. This model suits communities that need shared governance more than individual control of the platform.
- Governance: Agree in writing who may join, which distribution levels are permitted and how sharing groups are created and retired.
- Upgrades: Define how the hub operator announces upgrades and whether member instances must move to the same release within a set window.
- Backups: Clarify whether the operator backs up member-contributed data and how members retrieve their own copies.
- Member support: Establish a help desk, documentation and an onboarding path for new members, and state the response expectations in writing.
- Sync health: Publish a process for members to report broken connections and for the operator to review synchronization status.
Before committing, ask the community operator for its runbook and its current list of member duties.
Cost components on each side and what drives them
Cyware Intel Exchange costs split between what the hub vendor charges and what your own team carries. MISP removes the software license fee, but infrastructure, implementation, migration, onboarding and staff time remain, and each one has its own drivers. The cards below separate one-time from recurring items so you can compare quotes on the same basis.
Vendor subscriptions for the hub
Cyware charges for the hub and, depending on the agreement, for any connected member instances. These fees recur for the life of the contract, so they are usually the largest recurring line on the Cyware side. Ask the vendor to itemize the hub, each connected instance, feed or connector entitlements, and any usage tiers, and confirm how renewal pricing is calculated. Your renewal date is the point where the cost comparison becomes concrete.
MISP software licensing
MISP carries no license fee. The software is licensed under AGPL-3.0, so the recurring cost is the time and infrastructure needed to run it, not a per-seat or per-instance charge. Confirm with your legal team how the AGPL applies if you modify MISP and offer it to external users, since that obligation is separate from the cost of running it. MISP taxonomies and galaxies carry their own licenses (CC0 1.0 or 2-clause BSD), which should also be reviewed.
Infrastructure and hosting
Infrastructure is a recurring cost on the MISP side: compute, storage, backups, a database (MySQL or MariaDB, with PostgreSQL support in recent releases), Redis, TLS certificates and monitoring. Costs rise with the number of events and attributes you store, the number of sync partners, and your availability target. Ask your infrastructure team to size a production server and a standby or backup instance, and to state whether the cost is charged to your own cloud account or your data center.
Installation method and effort
The install method changes the one-time effort. The MISP download page recommends Ubuntu 24.04 with the provided installer for MISP 2.5, and also lists Docker images, RPM packages, an Ansible role and a Puppet module. The installer is the shortest path for a single server, while Ansible or Puppet suit teams that already manage configuration as code. Choose the method that matches your existing tooling, because a mismatch adds hardening and maintenance work to the project.
Implementation and migration
Implementation and migration are one-time costs on both sides. On the MISP side they cover standing up the instance, rebuilding sharing groups and distribution levels, re-creating feeds, importing exported Cyware data in STIX or MISP format, and testing sync with each member. Quotes should list the number of member organizations, integrations to be re-pointed, and whether data validation and cutover testing are included. Fixed-scope work agreed in writing before it starts makes these costs easier to compare.
Member onboarding and ongoing staff
Onboarding members and running the platform are the costs most often underestimated. Each member organization needs accounts, sync credentials, a sharing policy and a support path, and the MISP team needs people who maintain upgrades, monitor sync health and handle sharing governance. Staff time is recurring and can be a larger share of total cost than software. Ask any implementation partner to separate one-time onboarding from retained support, and ask your own team to estimate the on-call and upgrade hours it can absorb.
What a move from Cyware Intel Exchange to MISP involves
The sequence moves your indicators, sharing rules and member connections into a MISP instance you run, so intelligence keeps flowing to the community without a gap in service. The detailed steps sit on the migration page linked below.
Inventory feeds, sharing groups and member connections
Your team lists every intelligence feed, sharing group, distribution rule, automation playbook and member organization connected to the Cyware hub, noting which members push data in, which pull data out and which integrations depend on the hub's API. Confirm with each member how they consume intelligence, since some may read STIX over TAXII while others use MISP sync. The step is done when you hold a written inventory that each sharing group owner has reviewed.
Export intelligence in STIX or MISP format
Export historical intelligence from Cyware Intel Exchange in STIX or the MISP format it supports, keeping the original sharing markings and source attribution with each record. Check the export against a sample set by confirming that indicator counts, timestamps, tags and distribution settings survive the transfer. The step closes when an exported set has been reviewed and stored in a location your team controls.
Stand up MISP on your infrastructure
Your platform team deploys MISP on infrastructure you control, choosing an installation method that matches your operating model. The MISP download page recommends MISP 2.5 with the provided installer on Ubuntu 24.04, and also lists Docker images, RPM packages, an Ansible role and a Puppet module. Configure authentication, backups and network access before any data arrives, and confirm the version against the MISP releases page. The step is complete when a hardened instance passes your internal review.
Import events and map attributes
Load the exported data into MISP as events and attributes, then check how Cyware's fields map to MISP's event structure, tags, galaxies and taxonomies. Where a field has no direct equivalent, decide whether to carry it as a tag, an attribute or a note, and record that decision. Your analysts should spot-check a sample of imported events against the originals. The step closes when mapping rules are documented and the spot checks show no lost context.
Rebuild sharing groups and synchronization
Recreate sharing groups and distribution levels in MISP to match the access rules you recorded at inventory, then configure synchronization with the trusted partners and communities you intend to keep. MISP supports sharing controls down to individual attributes, so test that each group sees only what it should. Run test synchronizations with a small pilot group before opening the change to the wider community. The step is done when the pilot members confirm they receive and send the expected events.
Move member organizations without breaking integrations
Coordinate with each member organization to point its tooling, whether a SIEM, SOAR or TAXII client, at the new MISP instance, using the API and PyMISP where automation depends on them. Run both platforms in parallel for a period you agree with the community, so no member loses intelligence during the switch. Confirm each member's integration with a test event before retiring its Cyware connection. The step is complete when every member has a verified connection to MISP.
Retire the Cyware connections and archive records
After every member has verified its connection, disconnect the Cyware hub from live sharing, retain the exported archive under your records policy, and close the Cyware subscriptions in line with your contract terms. Keep the mapping documentation and inventory with the archive so future audits can trace where intelligence came from. The step closes when the archive is verified and no live flows still depend on Cyware.
Questions buyers ask before choosing MISP over Cyware
How much effort does moving from Cyware Intel Exchange to MISP take?
The effort depends mostly on how many member organizations connect to your hub, how much custom automation sits on top of Cyware, and how much historical intelligence you need to carry over. A small sharing group with a handful of feeds and a few playbooks is a far smaller project than a national sharing community with dozens of member integrations. The main work streams are rebuilding sharing groups and distribution levels in MISP, mapping Cyware feed sources to MISP feeds, re-creating playbook logic as MISP automation or external scripts, and testing synchronization with each member. Ask any implementation partner to break the scope into those streams, since each one scales differently.
Can our team migrate to MISP without outside help?
A team with Linux administration skills, some database experience and a working knowledge of the MISP data model can often handle a pilot in-house. The MISP download page recommends Ubuntu 24.04 with the provided installer for MISP 2.5, which lowers the initial setup burden. Production cutover is harder: it involves sharing group design, trust decisions with other organizations and testing sync against each peer. Many teams keep the core build in-house and bring in outside help for the sharing governance design, the migration of member integrations or hardening. DeployOpen plans, implements and documents self-hosted platforms in your own infrastructure under a written, fixed scope, so you can decide which parts to keep internal.
What skills and staff time does a self-hosted MISP server need?
Plan for three kinds of skill: systems administration to run the Linux host, database and cache services, and backups; application knowledge of MISP, including its sharing model, taxonomies, galaxies and PyMISP scripting; and CTI analyst time to curate intelligence, review feeds and manage community requests. MISP is built on PHP with CakePHP, MySQL or MariaDB and Redis, and the project has added PostgreSQL support through a new migration system in MISP 2.5.47, so your database choice affects which skills you need. Staff time for a sharing community grows with the number of members, because each onboarding and sync problem lands on someone. Confirm these allocations against your own environment before you commit.
How long does migration depend on member coordination?
In a sharing community, the slowest part of the move is usually agreeing with member organizations on when they switch their connections, not the technical import. Each member needs to confirm its sync configuration, its sharing group membership and its own automation before cutover. Members that rely on Cyware-specific integrations need extra time, because those integrations must be rebuilt or replaced in MISP. There is no fixed duration that fits every community, so ask for a schedule that lists each member as a separate dependency and that sets out how you will run both platforms in parallel during the transition.
Can MISP import and export the MISP format that Cyware supports?
Yes, MISP uses its own MISP JSON format natively, so events created in MISP can be shared and synchronized without conversion. The MISP features page also lists STIX 1 and 2, OpenIOC, CSV, text, Suricata, Snort, Zeek and RPZ exports. Confirm with your Cyware administrator which MISP format version and object templates your Cyware instance produces, and test a sample export through a MISP import before you plan the full migration. Attributes that Cyware stores in custom fields may need mapping to MISP attributes or objects, so check that during the pilot rather than assuming a one-to-one match.
What does ongoing support for a self-hosted MISP server look like?
Ongoing support covers three recurring tasks: applying MISP releases, operating the server and responding to sharing issues. The MISP download page says MISP 2.4 is end of life with security fixes only and recommends MISP 2.5 for new deployments, so plan upgrades on a regular schedule. The MISP support page is the entry point for community help. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and provides backups and documentation as part of implementation under a written scope. Ask any provider which upgrades, backup tests and member onboarding tasks are included in a retainer and which are billed separately.
Which costs change when we replace Cyware with self-hosted MISP?
The software licence cost moves to zero for MISP, which is licensed under AGPL-3.0, but you still pay for infrastructure, implementation, migration, staff time and support. Cyware subscription fees for the hub and member instances stop, while your own compute, storage, backups and monitoring become recurring costs in your environment. One-time costs include the migration project and the pilot. Ask any quote to separate those items and to state what drives each one up or down, such as the number of members and the volume of intelligence you retain.
How DeployOpen helps evaluate, implement or migrate MISP
DeployOpen starts from your sharing obligations, member organizations and integrations, then plans a MISP deployment inside your own infrastructure. Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work begins.
How we scope
- Inventory which sharing groups, distribution levels and member communities must be preserved or rebuilt.
- List every Cyware feed, playbook and integration that produces or consumes intelligence today.
- Agree in writing whether the scope covers evaluation, implementation, migration or a combination of these.
How we build
- Plan the MISP installation path for your target platform, such as the provided installer, Docker, Ansible or RPM packages.
- Configure sharing groups, sync connections and authentication, including OIDC or other SSO integration where required.
- Test feed ingestion, STIX and MISP format exports, and API-driven automation against your own sample data.
How we hand over
- Document the deployed architecture, sharing policy, sync topology and the administrative procedures your team will run.
- Provide a member onboarding guide covering how new organizations connect, receive access and verify their sync.
- Walk your operators through backup, upgrade and incident procedures so the platform stays with your team after delivery.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope work closes.
- Plan MISP version upgrades against the project's current release guidance and your change control process.
- Confirm with your own team which support tier, if any, members and partner communities will expect from you.
