Cyware alternative for ISACs and sharing communities

ISACs, ISAOs and national CERTs can run a self-hosted sharing hub on MISP with OpenCTI for analysis, keeping member data and governance under their own control.

Book a callTalk to us
On this page

Why an ISAC or CERT is replacing Cyware with a self-hosted sharing hub

An ISAC, ISAO or national CERT replacing a hosted sharing platform has to answer three questions before any technology choice: who runs the hub server, who decides which organizations may join, and in which country and under whose control member data is stored. A self-hosted hub gives the community direct answers to all three. The usual self-hosted sharing core is MISP, which handles event storage, sharing groups, distribution levels and synchronization between servers, while OpenCTI is more often added for analysts who need relationship graphs and structured analysis on top. MISP is licensed under the GNU AGPL version 3, and the project is associated with CIRCL, the Computer Incident Response Center Luxembourg, and co-funded by the European Union. Those facts describe the project's origin and licensing. They do not, by themselves, guarantee how the project will be governed in the future, so ask counsel to review the license terms against your community's obligations.

The gaps are the part to verify before committing. MISP has no commercial support contract by default, so the community needs a named operator, an on-call rota and a documented upgrade path, and the project's MISP support page is a starting point for understanding community versus paid options. Membership onboarding, trust decisions and sharing-group design are governance tasks that software will not perform for you. Confirm with your candidate implementer which Cyware features your members rely on, such as specific feed formats or workflow automation, and map each one to a MISP or OpenCTI equivalent or an integration. Check that your hosting location, backup location and admin access model meet the data residency rules that apply to your members.

Plan for the people and the exit as well as the software. Ask for a written scope that covers hosting, hardening, backup, upgrades, member documentation and the first-line support members expect, and ask for the recurring cost of each. Test a restore and a sync between two servers before members depend on the hub. For regulated members, document where sharing data is held, who can read it and how it leaves the community if a member withdraws, since those answers feed the third-party and exit planning that frameworks such as DORA expect from financial entities.

What members need before they connect to a sharing hub

Before a member organization connects to an ISAC or sharing hub, the community needs decisions on identity, sharing rules, synchronization, formats, API access and audit. MISP covers each of these natively, but the policy choices behind them belong to the community's governance and must be confirmed in writing.

Member onboarding and identity

Each member organization needs a named account, a sponsoring contact and a defined role before it can see or publish anything. MISP supports OpenID Connect through the OidcAuth plugin, so confirm whether your community's identity provider can issue the group claims that map to MISP roles. Ask who approves a new organization, how quickly access is removed when a member leaves, and whether accounts for smaller members are managed by the hub or by the member's own administrator.

Distribution levels and sharing groups

Every event and attribute carries a distribution level that sets how far it travels, and MISP sharing groups let a community define custom audiences down to individual attributes. Before onboarding, the community should agree on the default distribution for new events and who may create sharing groups. Confirm that the agreed rules match your members' legal and contractual limits on sharing, because the platform enforces the settings but does not decide them.

Inter-server synchronization

Members that run their own MISP instance can exchange events and attributes with the hub through synchronization, which respects the sharing controls set on each item. A member that only consumes intelligence can use the hub as a source instead. Check which sync direction each member needs, how connections are authenticated, and what happens to events a member has already received if a sharing group is later narrowed.

Export formats for detection tools

Members rarely consume MISP's native format directly. They need output that their SIEM, firewall or network sensors can ingest, such as NIDS rules for Suricata, Snort and Zeek, or STIX 1 and 2 bundles for partner tools. List the detection platforms each member uses and test every export format against them before go-live, since format support and parsing behavior differ between products.

API access for members

Members that automate sharing or enrichment need API keys tied to their own accounts, with their own permissions. MISP exposes a REST API described in OpenAPI, and PyMISP is the bundled client library. Agree on who issues keys, how long they remain valid, and how a key is revoked after a staff change. Ask the hub operator to document the rate and volume expectations for automated pulls, so one busy integration does not degrade the service for everyone.

Audit of who shared what

A sharing community needs a record of which organization published or changed each event and who approved it, both for trust and for any later incident review. MISP keeps event history and organization attribution, but retention periods and log export are settings the operator chooses. Confirm the retention period the community requires, where logs are stored, and who may read them. Note that these records may contain personal data about individual analysts, which brings GDPR obligations into scope where they apply.

MISP, OpenCTI or both: how each option fits a sharing community

MISP is built around distribution and sharing, which is why it is the common starting point for ISACs, ISAOs and national CERT communities. Every event and attribute can carry a distribution level, and sharing groups can be defined down to individual attributes, so a hub can decide exactly which members see which indicators. Synchronization between MISP instances carries those controls across servers, so each member can run its own node while still exchanging intelligence with the hub.

  • Distribution and sharing groups: Set visibility per event or attribute and build custom groups for subsets of members.
  • Synchronization: Pull and push events between trusted instances, so members keep a local copy under their own control.
  • Broad export set: Feeds can be published as MISP JSON, STIX 1 and 2, OpenIOC, CSV, Suricata, Snort, Zeek and RPZ, which covers most member tooling.
  • Automation surface: The REST API is described in OpenAPI and the PyMISP library supports scripted onboarding and feed handling.
  • Operating model: The installer targets Ubuntu 24.04 for MISP 2.5, with Docker, RPM, Ansible and Puppet as other options.

Confirm with the community which sharing rules, trust relationships and sync topology it needs before you design the groups. Check the current release and upgrade path on the MISP download page before you deploy.

How MISP sharing groups, distribution levels and sync work between servers

Distribution levels and sharing groups decide who sees each piece of intelligence, so they are the first design decision a sharing community makes. MISP's features page describes distribution levels together with custom sharing groups, and it states that sharing can be controlled down to individual attributes, not only whole events. Before go-live, the community should map its member types (full members, affiliates, partner CERTs, vendors) to sharing groups and decide which attributes are restricted by default. Test each rule with a pilot account from every member type, because an event that looks shared on the hub can still be filtered at the attribute level on a receiving instance.

Synchronization moves events and attributes between MISP instances and trusted communities, and the features page lists automatic sync as a core capability. What the reader must confirm in a pilot is the exact behavior for their topology: which sharing groups are pushed to which peers, how a sync connection is paused, and what a receiving node does with an event whose distribution it does not accept. Run a test event through a two- or three-node chain before onboarding members, and record the results as part of the governance pack. The MISP project support page is the natural starting point for community questions on these settings.

Governance has to be settled in writing before any sync link is live. Assign a named owner to each sharing group, with the authority to approve or remove the organizations in it. Define who approves a new member node, what evidence of trust is required, and who holds the sync credentials. Also write the removal procedure: who disables a hub node, how its outbound and inbound connections are cut, and whether events it already received must be purged or retained. These are community decisions, not software settings, and a sharing platform without them tends to drift as membership grows.

Deploying a self-hosted sharing hub in your own infrastructure

This sequence takes a sharing community from an undecided hosting choice to a running MISP hub, with members onboarded through SSO, a tested sync with trusted partners and an operating routine for upgrades. OpenCTI is added only when the team needs structured analysis on top.

  1. Choose the hosting environment and database

    The sponsoring organization or ISAC operator decides where the hub runs: its own cloud account, a data center or an air-gapped network for restricted sharing. Confirm the database choice before installing, because MISP 2.5.47 introduced a new database migration system with PostgreSQL support, and you should verify that migration path against the database you plan to use. Ask the vendor or project which database engine each installation method supports. The step is done when a written architecture note names the host, the database, the backup location and who holds administrator access.

  2. Install MISP 2.5 on the recommended path

    Deploy MISP 2.5 on Ubuntu 24.04 using the project's provided installer, which the MISP download page recommends for this version. Docker images, RPM packages, an Ansible role and a Puppet module are alternatives if your configuration management already standardizes on them. Do not install MISP 2.4 for a new hub: the project lists 2.4 as end of life with security fixes only and advises against new 2.4 instances. The step is done when the hub answers on its administrative interface, reports version 2.5 and passes a basic login and API check.

  3. Connect identity and SSO for members

    Integrate the hub with your identity provider so members and administrators sign in with managed accounts rather than local passwords. MISP's OidcAuth plugin documentation describes OpenID Connect configuration for the 2.5 branch, so confirm your provider's support and claim mapping against that README. Define which roles map to organization administrators, sharing-group managers and read-only members. The step is done when a test member from each role can sign in, and an account removed in the identity provider loses access to the hub.

  4. Define sharing groups and distribution policy

    Agree the community's rules before any member data arrives. MISP supports distribution levels and custom sharing groups down to individual attributes, so write down which events go to the whole community, which go to a trusted subset and which stay within one organization. Record who may create sharing groups and who approves a new member organization. The step is done when a signed governance document lists each distribution level, its audience and the named approvers, and the MISP configuration matches that document.

  5. Pilot synchronization with one or two trusted members

    Set up synchronization with one or two members who have agreed to test, using MISP's sync between instances with its granular sharing controls. Send a small set of test events at each distribution level, then confirm that restricted events do not reach partners outside their sharing group. Check that attributes and tags arrive intact and that both sides can see the same correlations. The step is done when both pilot partners confirm the events they received match what was published, and a documented test log shows that restricted content stayed restricted.

  6. Add OpenCTI when analysis needs structure

    Deploy OpenCTI only if analysts need a knowledge graph, STIX 2 based relationships or enrichment on top of the sharing feed. Plan its dependencies first: 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. Connect it to MISP with the MISP connector, and review the sizing guidance in the deployment overview before choosing hardware. Choose the Community Edition or the Enterprise Edition after confirming which features, such as audit logs and SSO options, your governance needs. The step is done when a test import from the pilot MISP instance produces linked objects in OpenCTI.

  7. Operate the hub with a routine for upgrades

    Assign an owner for patching, backup testing, certificate renewal and member onboarding, and write a runbook that covers each one. Track MISP releases and move to newer 2.5 builds through the project's upgrade path, testing on a staging copy first. If you run OpenCTI, choose between regular releases and an LTS line, noting that LTS releases require a specific license key and receive only critical bug and security fixes after stabilization. The step is done when a restore from backup has been rehearsed, the upgrade runbook has been executed once on staging, and the support contacts for each member organization are current.

Evidence governance boards and members will ask for

Boards, members and regulators tend to ask the same questions about a sharing hub: who may see what, where the data sits, and whether the platform can be restored. The six artifacts below answer those questions, and the operator prepares them for review. Independent auditors or regulators decide what is sufficient for a given obligation.

Sharing agreement and distribution policy

This is the written rule set that maps each distribution level and sharing group to the members allowed to receive it. It should state who may create events, who may upgrade a shared event's distribution, and how a member leaves the community. In MISP, check that the policy matches the sharing groups configured on the server, because the platform enforces what is configured, not what the agreement says. Ask legal counsel to review the agreement before onboarding the first member.

Sharing group and member register

Keep a current list of every sharing group, the organizations inside it, the contact for each member, and the date each membership began or ended. Reconcile the register against the user accounts and sync peers on the server each quarter. A mismatch here is the most common reason a former member keeps receiving events after leaving. Record who approved each change and when.

Sync configuration records

Document each peer connection: the remote instance, the direction of sync, the sharing groups and distribution levels that flow across it, and any filters applied. Export the configuration after every change and store the copies under version control. Reviewers will ask how an event that should have stayed inside one group reached another, and this record is the only way to answer quickly.

Access and audit logs of shared events

Retain authentication events, administrative changes and the publish, edit and export actions on shared events. Decide the retention period with your counsel and any regulator involved, then confirm the logs are stored outside the server they describe so an intruder cannot alter them. If you add single sign-on, log the identity provider's records alongside the platform's own.

Upgrade and backup records

Record each MISP upgrade with the version before and after, the date, the person who ran it and the result of the post-upgrade checks. Keep backup logs that show when the database and file store were captured and that a restore was tested on a separate host. MISP 2.4 is end of life with security fixes only, so the upgrade log is also the proof that the hub runs a supported line.

Architecture document and data location

Describe every component the hub uses, where each one runs, which jurisdiction holds the data, and which members' systems connect to it. Include the database, cache, file storage and any OpenCTI deployment with its own queue and search index. Several regulations, including DORA's requirement to state where data is processed, rely on this kind of record, so keep it current after every change. Confirm the description with your legal and data protection teams.

Questions ISAC and CERT operators ask before choosing a self-hosted hub

What does a self-hosted sharing hub cost, and which components drive it?

The cost splits into one-time work and recurring work. One-time work covers planning, installation, configuration of sharing groups and distribution levels, member onboarding, integration with your existing tools and migration of any data from the current platform. Recurring work covers the servers and storage, upgrades, backups, monitoring, member support and the staff who run the platform. The software licenses are not the main variable: MISP is licensed under AGPL-3.0 and OpenCTI Community Edition under Apache 2.0, so the cost lies in infrastructure and people. Costs rise with the number of member organizations, feed volume, retention periods and the number of connectors. Ask any partner for a quote that lists each of these items separately, with the hosting assumptions written down.

How long does a pilot take, and what does it depend on?

The length of a pilot depends mainly on how many member organizations must connect, how much existing intelligence must be migrated and how quickly governance decisions are made. Technical installation of MISP is the smallest part of the work, since the project recommends Ubuntu 24.04 with its provided installer for MISP 2.5 and also lists Docker images, RPM packages, an Ansible role and a Puppet module. Sharing rules, identity integration and member testing usually take longer. Ask for a written scope with a timeline that separates a pilot with a few trusted members from a full rollout, and confirm which member tests you need to sign off before work begins.

What must the community provide before a hub can go live?

A self-hosted hub needs decisions from people, not only servers. The community must agree on a governance charter that defines who may join, which distribution levels members use, how sharing groups are created and who may sign off on new feeds. It must also decide how member identity is verified and how accounts are provisioned and removed. On the staff side, the community needs named administrators, an on-call route for outages and a person who owns the content rules. Identity options should be checked against the MISP OidcAuth plugin documentation and your own directory service. Put these responsibilities in writing before the platform is built, because they shape the configuration.

Can an in-house team run MISP alone?

A team can run MISP alone if it has Linux administration skills, database and cache operations experience, and a clear plan for upgrades. Maintenance includes applying security fixes, moving between MISP versions, managing the database and handling sync failures between instances. The project's download page recommends MISP 2.5 for new deployments and states that MISP 2.4 is end of life with security fixes only, so any installation should start on 2.5. Be honest about coverage: a small team may struggle to provide out-of-hours response. Ask a partner to assess your skills gap, and consider a retainer for upgrades, monitoring and testing if internal capacity is thin.

How do OpenCTI's LTS license key and release cadence affect operations?

OpenCTI has two release tracks that affect planning. Non-LTS releases ship when ready, from daily to weekly, and use date-based version numbers. LTS releases arrive every 6 months and are supported for 1 year, giving a 6-month overlap between consecutive LTS versions. According to OpenCTI's product life cycle documentation, LTS releases are distributed as container images but require a specific LTS license key to use, and after a one-month stabilization they receive only critical bug and security fixes. Plan upgrades on the LTS track for a stable hub, budget time for regular patching and confirm with Filigran how license keys are issued and renewed before you commit.

What does a quote for a self-hosted hub need to include?

A useful quote lists the scope in writing before work starts. It should name the platforms in scope, such as MISP alone or MISP with OpenCTI, the number of member organizations to onboard, the sharing rules and distribution levels to configure, the integrations with your SIEM or ticketing tools, and the data migration assumptions. It should separate one-time implementation from recurring support, state the hosting environment and the backup and upgrade approach, and say what the client must provide, such as servers, identity sources and named staff. Ask for the acceptance criteria, the handover documents and the exit or data return terms. DeployOpen does not publish a price list, so a quote follows from the agreed scope.

Does a self-hosted hub meet our compliance obligations on its own?

No platform meets a compliance obligation by itself. A hub can support the evidence you need for regulators, auditors or sector frameworks, such as access records, change logs and documented exit plans, but the organization still owns its controls. Requirements differ by sector and by the rules that apply to your members, so confirm which obligations apply with your legal and compliance team. Where a regulation requires a register of ICT services or a tested exit strategy, the hub should appear in that documentation. DeployOpen prepares systems, controls and evidence for assessments but does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those roles.

What support should members expect from a self-hosted sharing hub?

Members usually expect a clear route for onboarding, a documented way to request access changes, a status page or notice channel, and a response path for sync failures or suspected data quality issues. Define the support hours, escalation steps and the difference between platform support and content support before launch. Ask whoever runs the hub to document these routes in a member guide. Where support is needed beyond business hours, decide in advance who covers it. Support can be delivered in house or through a retainer covering upgrades, monitoring and testing, and the scope of that retainer should be written down.

Moving members without breaking their integrations

Moving a sharing community to a new hub is a coordinated change for its members, not a server swap. Member organizations have usually wired the hub into their own tooling: feeds they pull on a schedule, API keys stored in SIEM or SOAR connectors, and exports that their firewalls, IDS sensors or DNS resolvers consume in a specific format. Before the cutover date is set, the platform team should inventory every member integration and record, for each one, the endpoint, the authentication method, the feed or export format and the owner on the member side. That inventory becomes the migration checklist, and it is the document that determines whether a member can be moved in one step or needs a longer overlap.

Plan for the old and new hubs to run in parallel while members onboard. The practical pattern is to stand up the self-hosted MISP instance, connect it to the existing community through synchronization, and move members in groups, starting with those whose integrations are simplest. Credentials should be re-issued per member on the new hub rather than copied across, so that revoking access on the old hub later is a clean, auditable step. Confirm with each member which API fields and export formats their tools read, and check the MISP features page and the PyMISP library documentation for the exact export options available in the version you deploy. Do not assume that a field name or a sharing group label from the old platform maps one to one into MISP.

Verify before each member is cut over. Run a sample of exports from the new hub, such as Suricata, Snort, Zeek or CSV outputs, and compare them with what the member's detection tools received during the last test window. Check that distribution levels and sharing groups restrict data the same way they did before, because a mismatch there can expose intelligence to the wrong audience. Keep the old hub read-only until every member has confirmed a working integration. The migration and cost sibling pages on this site cover the export and import steps and the total cost of running both hubs in parallel, and they are the right next read for planning the timeline and budget.

Deciding whether your team or a partner runs the hub

This sequence settles who owns the sharing hub before any software is chosen, so the community knows who answers for uptime, membership, upgrades and recovery. It ends with a written scope that either your own staff or an outside partner can be held to.

  1. Map staffing and on-call coverage

    List the people who can operate a MISP server and, if you plan OpenCTI, its supporting services, and record how many hours each can cover, including nights, weekends and public holidays. Compare that list with the hours members expect the hub to answer. The output is a one-page coverage table that shows every gap, so you know whether the hub needs cover from outside your organization before you commit.

  2. Confirm the governance owner

    Name one accountable owner for the hub's membership rules, sharing groups, distribution levels and acceptance of new organizations. This person decides who can connect and what each group may see, and signs off changes. Write the role down in the community's charter or operating agreement. The step is done when the owner can answer a membership request without escalating it to the technical team.

  3. Decide who handles upgrades and backups

    Assign separate owners for platform upgrades, database and file backups, and restore testing. Check the MISP download page for the currently recommended version and the upgrade path your installer or deployment method supports, and confirm with the MISP project which end-of-life dates apply to the version you plan to run. If OpenCTI is in scope, check its product life cycle documentation for release cadence and license requirements for LTS builds. The output is a named owner for each task and a restore test date agreed in writing.

  4. Define the support members expect

    Agree the support commitments you will make to member organizations: how requests arrive, which hours are covered, how incidents are triaged, and how members are told about maintenance. Write these as a service description that members can read. Confirm each commitment against the staffing map from the first step. The output is a signed-off service description that states what is not covered.

  5. Compare internal and partner operating models

    Using the coverage gaps, governance owner and task list, decide which tasks stay in-house and which go to an implementation partner. DeployOpen plans, implements, hardens, backs up, upgrades and supports self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. Ask any partner, including DeployOpen, which tasks it will take and which remain yours.

  6. Request a quote from a written scope

    Turn the decisions from the previous steps into a written scope covering systems, member count and integrations, deliverables, responsibilities on each side, and the support model. DeployOpen does not publish a price list. A quote follows from that written scope, so the more precise the scope, the more comparable the quotes. Ask every bidder to price the same scope and to state which costs recur, such as retainers and infrastructure, and which are one-time. The output is a scope document that you can compare across bidders.

  7. Record the decision and review it

    Document the chosen operating model, the owners for each task, the support commitments and the retainer or internal staffing plan in the community's governance records. Set a review point to revisit the decision when membership, staffing or the platform release cycle changes. The output is a signed governance record that a new board member could read and act on.

How DeployOpen deploys a sharing hub under your governance

DeployOpen plans, implements, customizes, hardens and documents self-hosted MISP and OpenCTI inside your own infrastructure, so the sharing hub follows the governance rules your members already trust. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

  • Map which member organizations connect, and which sharing groups and distribution levels each community needs
  • Agree in writing where the hub, its database and its backups will run, and who holds administrator rights
  • Define which feeds, formats and sync partners are in scope, and which member integrations must keep working

How we build

  • Install MISP 2.5 on your chosen platform and configure sharing groups, roles and authentication to your governance model
  • Set up synchronization between hub and member instances, then test sharing controls with sample events before go-live
  • Where analysis is needed, deploy OpenCTI with its dependencies and connectors, and document each integration point

How we hand over

  • Deliver architecture, runbooks, backup and restore procedures, and a record of sharing and access decisions
  • Train your operators and member onboarding staff on creating events, managing groups and checking sync health
  • Provide a written register of the components, versions and licenses in use, so governance reviews have a current reference

How we support

  • Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped in writing
  • Plan MISP and OpenCTI upgrades against their release and life cycle channels, with testing before each change
  • Prepare control evidence and documentation for your own assessors, while audit reports remain the work of independent auditors

Related

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.
Book a callhello@deployopen.com