Migrate from Cyware Intel Exchange to MISP

Member integrations usually break because they were built against Cyware's API paths, authentication method, or feed format, and nobody inventoried them before the switch. Members often run scripts, SIEM connectors, or firewall feeds that poll the old hub on a schedule, and those jobs fail silently once the endpoint changes. Prevent this by listing every connected member and every consumer of the feed before cutover, recording the exact endpoint, key type, and format each one uses, and keeping the old hub reachable in read-only mode until each member confirms a successful pull from the new MISP instance. Give members a written cutover date and a named contact, and ask them to report a successful test pull, not just a completed setup.

Distribution levels get set too broadly when imported events inherit a default such as community-wide sharing, or when staff pick the widest option to avoid sharing gaps. Intelligence that was restricted in Cyware can then reach partners who should never see it. Prevent this by mapping each source classification to a MISP distribution level before importing anything, defaulting new events to the most restrictive level, and reviewing a sample of events from each sharing group before enabling synchronization. Keep a short written rule that a higher distribution level needs a named approver. Confirm the exact field mapping with the MISP documentation for your version, because the labels you used in Cyware may not carry over one to one.

Sharing group membership is often lost or recreated incorrectly because the group definitions live in Cyware's configuration, not in the intelligence itself. After import, a group may exist with no members, or members may hold roles that let them see more or less than before. Prevent this by exporting the current membership list for every group, rebuilding each group in MISP, and checking that each organization's role and sync permissions match the original. Then run a test event through each group and confirm which organizations receive it and which do not. Record the approved membership in a governance document so future changes go through the same review.

Formats that carry fields MISP does not model directly, such as custom enrichment tags, proprietary scoring, or nested relationships, will lose detail or need manual mapping. Some indicators will import as attributes with different types than they had before, which changes how detection exports render them. Prevent this by exporting a representative sample from Cyware in every format you use, importing it into a test MISP instance, and comparing the results field by field. Decide in advance what happens to unmapped fields: store them as tags, as comments, or drop them with sign-off from the people who consume them. MISP supports STIX 1 and 2, MISP JSON, CSV, and NIDS exports, so check which of those your downstream tools actually read.

Sync problems hide during a parallel run because both systems look healthy while data quietly diverges. Events may fail to push to a peer, attributes may be dropped by filters, or a peer may reject events that exceed its distribution rules. Prevent this by choosing a fixed set of test events, publishing them from MISP to each peer, and confirming receipt by UUID on the other side. Compare event counts, attribute counts, and sync timestamps daily during the overlap period. Review the synchronization logs for rejected or failed pushes, and do not end the parallel run until every member has confirmed matching data for the agreed window.

Weak admin ownership causes trouble when no one is clearly responsible for sync health, user access, and sharing rules once the project team leaves. Shared administrator accounts, unclear escalation paths, and unpatched servers are common results. Prevent this by naming at least two accountable administrators, assigning each user to an individual account with the least role needed, and documenting who approves new sharing groups and new member organizations. Set up a regular review of administrator access and a patch schedule for the MISP server. The MISP support page lists the project's community channels, so decide in advance which internal team handles first-line problems and when to escalate.

Archiving history matters because incident responders, auditors, and member organizations often need to trace an indicator back to the report that introduced it, and that trail may disappear when the old hub is decommissioned. Prevent this by exporting all events, attributes, sharing group records, user access logs, and audit trails from Cyware in open formats before shutdown. Store the archive in a location with its own access controls and retention schedule, and confirm with your legal or compliance team how long it must be kept. Test that you can open and search a sample of the archive before deleting the Cyware tenant, and record the archive location in your runbook.

Your team can run this migration if it has time, MISP administration experience, and clear ownership of sharing rules, but the biggest risks lie in member coordination and verification rather than installation. Costs come from internal staff time, server infrastructure in your own environment, and any external help on the scope you agree. DeployOpen plans, implements, and hardens self-hosted open-source platforms inside a client's own infrastructure, and most engagements are fixed-scope with deliverables and timelines agreed in writing before work starts. To compare options, ask for a written scope covering member inventory, format mapping, parallel run verification, and archive handover, and check whether each item is in your plan or in the quote.

The cost is driven by components, not a single number. MISP's software is open source under the AGPL-3.0 license, so the license line disappears, but you still pay for the server and storage you run it on, the people who operate it, the migration work, and the time your members spend reconnecting. Recurring costs include infrastructure, patching, backups, and staff time for user and sync administration. One-time costs include export, import, testing, and sharing group design. Ask Cyware in writing what it charges for the hub, any connected member instances, data export, and whether any contract terms restrict extraction of your feeds. A written scope from DeployOpen is the basis for a quote, and it should list each component separately so you can compare it with your current Cyware spend.

Duration depends on how many sharing groups, feeds, automations and member organizations you have, and on how much history you keep. Build time for a clean MISP 2.5 server is the smaller part. Most of the calendar goes to deciding sharing groups and distribution levels, validating imported events, and coordinating member cutover. Run the old and new platforms in parallel for a defined period so members can test sync before you switch. Because MISP 2.5 is the recommended version for new deployments and MISP 2.4 is end of life with security fixes only, do not plan a new 2.4 installation. Agree timelines in the written scope and confirm your member calendar, since their change windows often set the pace.

Your team owns the decisions that the platform cannot make for you. You need a named sharing owner who approves which events go where, a list of sharing groups and the organizations in each, and a clear view of distribution levels your community already uses. Infrastructure staff must provide a Linux host or virtual machine, network access for member sync, DNS, TLS certificates, and identity integration if you want single sign-on through the OidcAuth plugin. Someone must also own backups, patching and monitoring after go-live. Ask whether your team will also handle member onboarding, since MISP sync depends on each member's trust and configuration.

Yes, a technically strong team can install MISP and import data, because MISP offers an installer for Ubuntu 24.04, Docker images, RPM packages, an Ansible role and a Puppet module. The harder parts are the ones that depend on your community: mapping Cyware's sharing model to MISP sharing groups, re-creating enrichment and feed ingestion, testing sync with each member, and running the cutover without losing alerts. If you have no in-house MISP experience, or your sharing community is large or regulated, a fixed-scope engagement with DeployOpen can plan, implement, document and test the work. DeployOpen does not issue audit reports or certifications, so any compliance evidence still comes from your independent assessors.

Probably yes, and the change should be agreed before cutover. Members who receive intelligence through Cyware's connectors or member instances will need a new connection, new credentials and, in most cases, a sync configuration that points to your MISP server. If they consume feeds in a format Cyware supports, confirm that the same format is available from MISP, which supports MISP JSON, STIX 1 and 2, OpenIOC, CSV, and NIDS exports for Suricata, Snort and Zeek. Members with automated detection pipelines must also confirm that their parsers accept the new output. Ask Cyware which of your member integrations depend on Cyware-specific APIs or formats, and send each member a written change plan.

Historical intelligence can be exported and imported, but completeness depends on what Cyware allows you to extract and on how the data was originally shared. Ask Cyware in writing for export in STIX or a MISP-compatible format, including attributes, relationships, sightings, and original sharing or distribution metadata. Then test imports in a staging MISP instance. Expect some fields to map imperfectly, and decide in advance which history you keep as active events, which you archive, and which you leave behind. Keep a read-only archive of the Cyware export so you can answer audit or dispute questions later. Confirm retention obligations with your legal and compliance owners before deleting anything.

Sharing stays safe when access is designed before data moves. MISP supports distribution levels and custom sharing groups down to individual attributes, which lets you keep sensitive intelligence within a restricted group. Build the sharing model first, then import events with their distribution set, and test that a member outside a group cannot see restricted items. Enforce authentication on the MISP server, including single sign-on where your policy requires it, and restrict administrative access. Plan monitoring for sync failures, since a silent sync error can leave members with stale intelligence.