Why a sharing hub for ISACs and sector communities needs governance before software
If you run an ISAC, a CSIRT or a sector group that must operate a sharing hub for members, the usual community instance is MISP, and the hard work is not the software. It is the governance: who may join, what each member may see, how indicators are classified and attributed, and how a new member is vetted and onboarded before anything is shared. Those rules need to be agreed in writing before the first event is published, because a hub that shares the wrong indicator to the wrong group is difficult to unwind once synchronization has copied it to other instances.
A single-organization threat intelligence platform answers to one internal owner. A community hub answers to many organizations with different legal duties, different tolerance for risk and different views on who is trusted. The platform choice is the smaller decision. MISP already provides distribution levels, custom sharing groups down to individual attributes and automatic synchronization with trusted communities, so the controls exist. What the community has to decide is how it uses them: which sharing groups exist, who administers them, what an organization must demonstrate to be admitted, and what happens when a member breaks the rules.
DeployOpen plans, implements and hardens the hub inside your infrastructure, including the synchronization configuration and the access controls around it. DeployOpen does not set membership rules, trust criteria or sharing policy for your community. Those belong to the board, the steering group or the sector body that owns the hub, and they should be settled before a technical design is frozen. Confirm with your governance owners who signs off on membership, how revocation works and who can change distribution rules, because the answers determine the architecture.
What a sharing hub must enforce from day one
This table maps the access, logging, transport and sharing rules that a community MISP hub needs before the first event is exchanged, and what each one means for the build. Read each row as a question to settle with your members: which regulations apply to the groups you serve, and how your hub will prove it enforces them. The main takeaway is that identity, logs, TLS and sharing group design must be decided together, because each one limits what the others can safely do.
| Requirement | What it asks for | What it means for hub build |
|---|---|---|
| Unique user identification | HIPAA Security Rule at 45 CFR 164.312 expects each user of systems holding ePHI to have a unique identifier (applies only if members handle health data). | Require named accounts for every member analyst, no shared logins, and federate sign-on through your identity provider so each MISP user maps to one person. |
| Audit controls | 45 CFR 164.312 expects mechanisms that record and examine activity in systems containing ePHI (confirm with counsel whether indicators or event content count). | Log who pulled, created, edited or synchronized each event and attribute, and retain those logs in a store the hub operators cannot quietly alter. |
| Multi-factor authentication | FTC Safeguards Rule at 16 CFR 314.4(c) expects MFA for any individual accessing an information system (applies where members are covered financial institutions). | Enforce MFA for hub administrators and member accounts at the identity provider, and document which accounts are exempt, if any, and why. |
| Person or entity authentication | Confirm the authentication standard each member community requires for administrators, analysts and automated sync partners. | Issue separate credentials for machine-to-machine synchronization and rotate them, rather than reusing analyst accounts for sync jobs. |
| Encryption in transit | The FTC Safeguards Rule at 16 CFR 314.4(c) expects customer information to be encrypted in transit and at rest where it applies to members. | Use TLS on every synchronization link and on the web interface, verify peer certificates, and restrict sync endpoints to known member addresses. |
| Encryption at rest | Confirm with members whether event content, attachments or personal data in indicators must be encrypted on disk and in backups. | Encrypt the database, Redis caches, file storage and backup targets, and keep the encryption keys outside the hub's own data volumes. |
| Distribution levels | Each event and attribute carries a rule for who may receive it, set by the contributing member (confirm the sharing terms in your community agreement). | Default new events to the narrowest distribution the member chose, and block any attribute that a member has not cleared for wider sharing. |
| Sharing group design | Sharing groups define which member organizations can see which events, and they should match each member's agreed sharing scope. | Create one group per sharing scope rather than per member, name groups for their purpose, and review membership on a schedule that the governance document sets. |
Which platform fits a community hub
A sharing hub for members usually runs one exchange platform that every member can reach, plus optional tools for analysts and an identity service that controls who gets in. The cards below separate those roles so the hub team can decide which components to host, which licenses to review, and which questions to put to an implementation partner.
MISP as the community instance
MISP is the exchange core for most sharing communities. Its sharing groups and distribution levels can be set down to individual attributes, and events and attributes can synchronize automatically with member instances and trusted communities. It also exports STIX, OpenAPI-described APIs and PyMISP, so members with different tooling can connect. The current release is 2.5.50, published on 9 October 2026, and the 2.4 line is end of life, so new hubs should start on 2.5. Confirm the AGPL-3.0 obligations your legal team needs to review and which MISP version your members run.
OpenCTI as analyst companion
OpenCTI models threat knowledge on a STIX2-based schema and offers a web application and GraphQL API, which suits analyst teams that track actors, campaigns and relationships over time. A hub typically keeps MISP for exchange and feeds selected intelligence into OpenCTI for analysis. The Community Edition is under Apache 2.0, but some features sit in the Enterprise Edition under a separate license. Confirm which features your analysts need, and whether LTS releases, which need a specific license key, fit your upgrade plan.
Keycloak for member login
Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0, so member organizations can sign in with their own identity providers through identity brokering. MISP can accept OpenID Connect logins through its OidcAuth plugin, which lets the hub manage access centrally. Keycloak is licensed under Apache-2.0, which keeps the licensing review simple. Confirm how member accounts map to MISP organizations and roles, and who approves new members before they receive access.
authentik for member login
authentik is a self-hosted identity provider that many hubs evaluate alongside Keycloak for member sign-in. Its core is under the MIT license, but its enterprise directory carries a separate enterprise license, so check which features your deployment touches before committing. Like other OIDC providers, it can serve as the upstream identity source for MISP login through the OidcAuth plugin. Confirm group mapping, MFA enforcement for member accounts and how the hub revokes access when a member organization leaves.
ZITADEL for multi-member tenancy
ZITADEL covers SSO, MFA, passkeys, OpenID Connect, SAML 2.0, SCIM and multi-tenancy in one platform, which can help a hub separate member organizations inside one identity service. It is licensed under AGPL-3.0, so the license review should cover any hub modifications and network use. Its SCIM support can simplify provisioning from member directories. Confirm whether the hub needs tenant isolation, how passkey enrollment is handled for analysts, and whether the MISP OidcAuth integration matches your chosen configuration.
Rollout phases for a community hub and the output of each
The sequence moves a sharing community from written governance to a tested, approved first exchange of intelligence. Each phase closes with a document or check that the next phase depends on, so the hub never shares before its rules and access controls exist.
Agree the charter and membership rules
The community's board or steering group, with legal and compliance counsel, defines the hub's purpose, eligible members, membership obligations, roles for hub administrators and curators, and how members leave or are suspended. DeployOpen can facilitate the drafting sessions and prepare the document, but the community owns the decisions. The step closes when the charter is signed by the authorized representatives of the founding members and stored as the governing record for every later decision.
Classify data and map TLP levels
Working with the charter's owners, the community defines what kinds of information members will share, which fields may contain personal data, and how each category maps to Traffic Light Protocol markings and to MISP distribution levels and sharing groups. The output is a written distribution policy that states who may see each class of indicator, what must be stripped before sharing, and who approves exceptions. The step is complete when the policy has been reviewed against the charter and every member representative has acknowledged it.
Build the hub on MISP 2.5
The hub engineer installs MISP 2.5, which the project recommends for new deployments, on Ubuntu 24.04 using the provided installer, or deploys it from the project's Docker images if the community's platform standard requires containers. The build covers the database and Redis backends, TLS, host hardening, backup and restore testing, logging to a central location, and patch procedures. The phase ends with a hardened instance that passes a documented configuration review and a successful restore from backup, which proves the hub can be recovered before any member data arrives.
Configure identity and audit logging
Administrators connect the hub to the community's identity provider, enforce multi-factor authentication for every account, and assign roles so that each user holds only the permissions their function requires. Member accounts are created per organization with unique identities, and administrative actions, logins and synchronization events are recorded and retained. The output is logged access: a test report showing that each role can perform only its allowed actions and that an administrator can trace a given login or sharing action to a named individual.
Run a pilot sync with two or three members
The hub configures synchronization with two or three willing member instances and creates the sharing groups defined in the distribution policy. Test events carry sample indicators at each TLP level, and the team checks that each member receives only what its group permits, that attributes are not altered in transit, and that removed or revoked content behaves as the policy states. The output is a test record covering each sharing group and each distribution level, along with a list of defects and their fixes. The phase closes when the pilot members confirm the results in writing.
Onboard members with a written runbook
The community adopts an onboarding runbook covering identity verification of each new member, account and synchronization setup, required acceptance of the distribution policy, a test exchange, and offboarding. Each member's onboarding is recorded against the runbook so that the community can show when and how every organization was admitted. The output is a completed onboarding checklist per member, and the phase is complete when the runbook has been used end to end for each onboarding batch.
Approve go-live and share the first event
The governance body reviews the evidence from the preceding phases: the signed charter, the distribution policy, the hardened build, the access logs, the pilot results and the onboarding records. Once it grants a written go-live approval, the curators publish the first real event under the agreed sharing group and TLP level, and the team confirms that it reached the intended members only. The step produces the go-live approval and a record of the first shared event, which become the baseline for ongoing review of the hub.
How hosting models change the hub's trust and control
In this model the sector body runs one MISP instance that members log into, publish to and search. The body holds the event database, the user accounts and the sharing group definitions, so it has the most direct control over what is shared and with whom. Members contribute through their own accounts rather than running software, which lowers the skills needed at each member organization.
- Data holding: The hub operator stores every event, attribute and attachment. Retention, backup and any personal data in indicators are the operator's responsibility, so the hub's contract with members must say so.
- Sharing group administration: The operator creates and maintains sharing groups and distribution rules centrally, which keeps policy consistent but makes the operator a bottleneck for member requests.
- Member access: Accounts are provisioned by the operator, usually with an identity provider the body controls, and each user's organization decides what they can publish.
- Exit and audit: Members leave by requesting deletion or export of their contributions. Audit logs sit with the operator, so the body must define who can read them and how long they are kept.
Before committing to this model, confirm with the sector body who will staff the operator role, how exports work for departing members and where the hub's data is physically hosted.
In this model each member runs its own MISP instance and synchronizes selected events with the hub or with peers. Each member keeps its own copy of its data, and the sector body coordinates the sharing agreement rather than holding every record. This suits organizations that already operate security tooling and want their intelligence to stay under their own control.
- Data holding: Each member holds its own events. The hub holds only what members choose to push to it, so a breach at the hub exposes less than in a central model.
- Sharing group administration: Members define local sharing groups and decide what leaves their instance. Shared groups must still be agreed centrally so that distribution levels mean the same thing everywhere.
- Synchronization: MISP supports automatic synchronization between instances, so each member must maintain connection settings, certificates and version compatibility with the hub.
- Exit and audit: A member can disconnect its sync and keep its data, but previously shared copies already sit with other members. Audit records are local, so the hub needs an agreed way to request them during an investigation.
Confirm with prospective members how they will upgrade their instances, since a hub and its members must run compatible MISP versions, and agree in writing what happens to shared data when a member leaves.
In a mixed model a regional or national CSIRT hosts a community instance for smaller members, while larger members run their own instances and sync with it. The CSIRT and the sector body divide responsibilities, which can match organizations whose members have very different technical capacity. The arrangement adds a layer of trust, because members rely on a third party for hosting and on the CSIRT's governance for sharing rules.
- Data holding: Data is split: members with their own instances hold their own events, while members on the CSIRT instance rely on the CSIRT to store theirs. Each hosting relationship needs its own terms.
- Sharing group administration: Responsibility is shared. The CSIRT may manage groups for its hosted members, while the sector body sets the cross-community rules that every instance must follow.
- Trust chain: Events can pass through more than one instance, so the hub must agree how distribution levels and handling instructions carry across each hop.
- Exit and audit: A hosted member's exit depends on the CSIRT's export process, and audit trails may be split across two operators, so the agreement must name who answers an audit request.
Ask the sector body and the CSIRT which of them is the accountable operator for each member, what the export format will be and how a single investigation is traced across the instances involved.
Evidence a hub produces for regulators and members
This table maps each kind of evidence a sharing hub can produce to the component that generates it and the question it answers. Read it as a checklist for what to retain from day one, since an assessor or member will ask who shared what, with whom and under which rules. DeployOpen prepares and organizes this evidence, but independent auditors and certification bodies are the ones who assess it.
| Evidence | Source component | What it shows |
|---|---|---|
| MISP audit logs | MISP community instance audit trail | Who created, edited, published or deleted events and attributes, and when |
| Synchronization logs | Sync connections with member and partner MISP instances | Which events and attributes were pushed or pulled, with which peer, and when |
| Sharing group and distribution exports | MISP sharing group and distribution level configuration | The sharing rules in force at a given date, supporting the policy claim |
| Identity provider access logs | Keycloak, authentik, ZITADEL or other SSO provider in front of MISP | Unique user identification and authentication events for each member account |
| Encryption configuration | TLS settings on the hub and sync links, storage encryption for database and backups | Evidence for transmission and at-rest protection of shared data |
| Governance documents | Membership agreement, onboarding checklist, TLP and sharing policy, review records | Why a member was admitted, under which rules, and who approved the decision |
Questions sector groups ask before building a sharing hub
What does it cost to build a sector sharing hub on MISP?
The software has no license fee, so the cost is labor, infrastructure and governance work. MISP is licensed under AGPL-3.0, and the hub's main one-time costs are installation, identity integration, sharing group design and synchronization testing. Recurring costs include hosting, backups, upgrades, monitoring and curation time. The biggest cost drivers are the number of member organizations, whether members sign in through your existing identity provider, how many synchronization links you run, and how much legal review the sharing rules need. Ask any partner for a fixed-scope quote that lists each of these items separately, with the member count and sync topology written into the scope.
How long does it take to launch a sharing community hub?
The pace is set by governance decisions and member onboarding more than by installation. Installing a current MISP release on a supported platform is the quick part. Agreeing on sharing groups, distribution levels, TLP handling, membership criteria and legal terms usually takes longer, and each member's onboarding depends on its own security and legal reviews. MISP 2.5 is the recommended version for new deployments, and the installer is documented for Ubuntu 24.04. Ask for a written timeline that separates the technical build from the governance milestones, and confirm which of them the group controls.
What must our sector group decide and supply before a build starts?
The group must make decisions that no implementation partner can make for it. These include who may join, which distribution levels and sharing groups map to member roles, how Traffic Light Protocol markings are applied, what happens to indicators that contain personal data, and who acts as the hub's administrators. The group also needs to name a technical contact and a data owner for each member, and to provide the sector's existing feeds or sharing agreements. Without these inputs, the sharing groups and onboarding forms will be rebuilt several times. Confirm the decision list with your legal and member-relations leads before signing a scope.
Can our team run the sharing hub after handover?
A small team can run a MISP hub if it has Linux operations skills, a clear owner for the community rules and a plan for recurring work. The recurring work includes applying MISP upgrades, monitoring synchronization health, onboarding and offboarding members, reviewing feeds and removing stale indicators. MISP 2.4 is end of life with security fixes only, and the project strongly advises against installing new 2.4 instances, so any hub still on that line needs a planned upgrade. Ask the partner for a written runbook, an upgrade procedure tested on a staging copy, and a support option for the period after handover.
Which parts of a sharing hub create the most ongoing work?
Ongoing effort concentrates in four places: member lifecycle, synchronization, feed curation and platform upgrades. Each new member adds identity, sharing group and sync configuration, and each departure requires revoking access and checking what it received. Synchronization links need monitoring because a failed push can silently stop indicators flowing. Curators must age out false positives and expired indicators, or analysts will lose trust in the data. MISP 2.5.47 introduced a new database migration system with PostgreSQL support, which is a useful reference point when planning upgrade windows. Confirm with the partner how each of these tasks is assigned and measured.
Does identity integration change how a sharing hub is built?
Yes. Members of a sector hub usually come from many organizations, so the hub needs a clear rule for who authenticates, how roles map to sharing groups, and how accounts are removed when a member leaves. MISP supports OpenID Connect through the OidcAuth plugin, which is documented in the project's repository for the 2.5 branch. Federating logins with your own identity provider reduces manual account work but adds a dependency you must operate. Confirm the supported authentication path for your MISP version and test removal of a departing member before go-live.
Can MISP and OpenCTI run together in one sharing program?
Yes, they can coexist, and many programs use them for different jobs. MISP is strongest as a sharing hub with distribution levels, sharing groups, synchronization and a wide set of export formats, while OpenCTI structures intelligence on a STIX 2 based knowledge schema with a GraphQL API. A common pattern is to share indicators through MISP and feed analysts' knowledge base in OpenCTI, which the OpenCTI documentation supports through connectors to tools such as MISP. Running both adds infrastructure, since OpenCTI depends on Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage. Decide the division of work before you deploy either platform.
What licensing questions should a sector group settle first?
The group should separate software licensing from content licensing. MISP software is licensed under AGPL-3.0, while MISP taxonomies and galaxy data are licensed under CC0 1.0 Universal or the 2-clause BSD license. If the group considers OpenCTI, the Community Edition is under Apache License 2.0, but some features and LTS releases depend on the Enterprise Edition under a separate license, and LTS releases need a specific license key. Ask the partner which features the scope requires, confirm whether any of them need the Enterprise Edition, and have counsel review any member agreement that touches shared content.
What to ask an implementation partner for a sharing hub
Ask the partner to show how sharing groups and distribution levels are configured against your written sharing policy before any member is connected. MISP supports distribution levels and custom sharing groups down to individual attributes, so the risk is not a missing feature but a mapping error. Ask for the policy-to-configuration table: which sharing group each member tier belongs to, what the default distribution is for new events, and which TLP-style markings are enforced at import and export. Ask who approves a change to a sharing group and how that approval is recorded. Ask them to demonstrate a restricted event being invisible to a member outside its group, using a test account, and to keep that test as a repeatable check for later upgrades.
Ask how synchronization will be tested with a pilot member before the hub opens to the whole community. The partner should set up a sync connection with one willing member instance, push a set of test events at each distribution level, and confirm what arrives, what is filtered, and what is dropped. Ask for the written test cases, the expected results and the log evidence kept for each run. For identity and audit, ask how member and analyst logins will be federated with your identity provider, whether MFA is enforced for every administrator, and where MISP audit logs are sent and how long they are retained. The answers should map to the access control, unique user identification and audit control requirements in your own sector rules, which the partner should confirm with you rather than assume.
Ask who carries out MISP upgrades and on what version path. MISP 2.5 is the recommended version for new deployments, and MISP 2.4 is end of life with security fixes only, so a hub built on 2.4 needs a documented migration. Ask whether the partner will follow the upgrade route in the project documentation, test each upgrade on a staging copy with a sync partner, and keep the sharing configuration in version control. Finally, ask how offboarding is handled: the procedure for removing a member's sync and API keys, revoking access to events already shared, and telling the rest of the community. Ask how the partner records that a revocation reached every synchronized instance. Last, ask whether they will sign a written scope, with deliverables, acceptance tests and a change process, before any work begins.
What goes wrong in shared intelligence hubs
Why do sharing groups in a MISP hub end up too broad?
Sharing groups end up too broad when the hub admin creates one large group for convenience and adds every member organization to it. Every event published to that group then reaches organizations that never needed the detail, including partners with weaker controls. MISP supports distribution levels and custom sharing groups down to individual attributes, so the control is to define groups by membership need and sensitivity before onboarding. Write the rules down: who may join each group, who approves additions, and which events may cross group boundaries. Review group membership on a fixed schedule and remove organizations that no longer meet the criteria.
What happens when members share indicators without TLP labels?
Unlabeled indicators lose their handling instructions the moment they leave the originating analyst's hands. Recipients cannot tell whether an indicator may be forwarded to a vendor, pushed to a public blocklist or kept inside a single team. The control is a mandatory marking rule: every event and attribute carries a Traffic Light Protocol label and a MISP distribution level at creation, and the hub's onboarding terms state what each label permits. Configure the instance so that events without a distribution setting cannot be published, and train members to treat an unlabeled indicator as restricted until it is confirmed. Check labels during periodic review of recent events.
Why does synchronization go stale after a MISP upgrade?
Synchronization goes stale when member instances run different MISP versions, or when a hub upgrade changes the sync protocol or database schema and some peers are not updated. Events may stop flowing without any visible error on the hub side. MISP 2.4 is end of life with security fixes only, and the project recommends MISP 2.5 for new deployments, so the first control is a version policy that sets a minimum supported release for every connected instance. Before the hub upgrades, test the migration on a copy, confirm each peer's version, and watch sync logs for failed pulls after the change. MISP 2.5.47 introduced a new database migration system with PostgreSQL support, so schedule that change as a planned migration with a tested rollback, not as a routine patch.
Who owns indicators once they are shared across a community?
Ownership is unclear when no one is accountable for correcting, expiring or withdrawing an indicator after it is published. The originating organization usually holds the most context, yet recipients import the data into their own tools and keep it indefinitely. The control is a written ownership model that names the creating organization as the owner of each event, requires that owner to update or retract it, and sets a process for disputes. Require that every event record its originator and contact point. Define how recipients should report a false positive back to the owner and how the hub admin enforces retraction when an owner leaves the community.
How do false positives spread through a shared hub?
False positives spread when indicators are exported to blocking tools without an expiry date or a confidence score, so benign infrastructure such as shared hosting or a CDN gets blocked for months. MISP exports to Suricata, Snort, Zeek and RPZ formats, which means a bad indicator can reach enforcement points quickly. Set expiry and confidence fields on every attribute that feeds detection, limit automated export to indicators that meet a defined threshold, and keep a warning list for well-known benign domains. Review the export pipeline after each sync cycle and log which indicators were pushed to which sensors so that retraction can reach them.
Why do new members get access to the wrong events during onboarding?
New members get wrong access when the hub creates their account and sharing group membership before the membership agreement is signed, or when the default role is more permissive than the member needs. The control is a staged onboarding: the organization signs the sharing terms, is verified as a sector member, and only then receives a sync connection and a role limited to its approved groups. Confirm the trust relationship through a named contact, record the decision in the hub's governance log, and test that the new instance sees only the events its groups allow before enabling automatic pulls.
What should a hub governance document cover before the first event?
A hub governance document should cover membership criteria, sharing groups and their purposes, TLP and distribution rules, indicator ownership and retraction, sync and version requirements, onboarding and offboarding steps, incident contacts, and how the hub handles disputes or misuse. Keep it short enough that members will read it, and version it so that changes are visible to every member. Agree the document before the first event is shared, because retrofitting rules after data has already moved between members is far harder. Ask your implementation partner to map each rule to a configuration setting or a process owner, so no rule exists only on paper.
How DeployOpen builds and supports sharing hubs
DeployOpen plans, implements, customizes, integrates, hardens, backs up, documents and supports self-hosted MISP community instances inside the sector's own infrastructure. The work starts with the governance rules a hub needs, so that sharing groups and distribution levels are configured to match them before the first event is shared.
How we scope
- Engagements are fixed-scope, with the hub's member types, sharing rules and deliverables agreed in writing before work starts
- Scope defines which sharing groups, distribution levels and TLP conventions the hub will use at launch
- Scope lists the trusted communities and member instances the hub will synchronize with, and who approves each connection
- Written scope names the authentication model, hosting location and integrations with member SIEMs or firewalls
How we build
- Deploy MISP as the community instance inside the sector's cloud account, data center or air-gapped network
- Configure sharing groups, organization records and synchronization links to match the agreed governance model
- Test onboarding, event publication and synchronization with a pilot member before opening the hub to all members
- Document backup, upgrade and access procedures, and confirm MISP version and database choices with the platform's current release notes
How we hand over
- Hand over runbooks for member onboarding, sharing group changes, sync troubleshooting and removal of a member
- Provide configuration records and an access matrix showing who can create, approve and publish events
- Train the hub's administrators and curators on the distribution rules and the review steps for incoming indicators
- Deliver written evidence of tests and configuration changes that the hub's governance board can review
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the build
- Retainer work can cover platform upgrades, backup restore checks and review of new member connections
- Ask the partner which MISP release line they will maintain and how security patches will be applied to the hub
- Confirm response expectations, service levels and escalation contacts in writing before the retainer starts
