Open source threat intelligence platform for public sector: why government sharing is different
A CERT or government agency that runs a threat intelligence platform has two jobs that pull in opposite directions: receive and send indicators with national and partner communities, and keep restricted material inside government systems. Public sector sharing turns on sharing groups, distribution rules and who is allowed to host the data. A commercial feed can be switched on in an afternoon. A government sharing arrangement needs a clear answer to which partners may see each indicator, which systems store it, and who administers those systems. Those answers should be written down before the first event is imported.
For most teams the short answer is that MISP is the usual starting point, because it was built for sharing: distribution levels and custom sharing groups can be set down to individual attributes, and events can synchronize automatically with other MISP instances and trusted communities. OpenCTI is a useful complement when analysts need a knowledge graph and STIX2-based relationship analysis across campaigns, but it does not replace the sharing controls MISP provides. Confirm with your national CERT or partner community which platform and which exchange formats they expect before you choose the stack, since that decision shapes your onboarding and governance work.
Do not assume the NIS2 information-sharing regime applies to your organization. NIS2 covers central government entities regardless of size, but it does not apply to entities working in national security, public security, defense or law enforcement. Your agency may therefore sit under a different legal basis, and that determines which sharing arrangements you can join and what you must report. Ask your legal and security governance teams to confirm the applicable regime for each entity in writing, and record which sharing groups and external communities that regime permits before any indicator leaves the platform.
Which government requirements shape the build
This table maps the government requirements that most affect a self-hosted MISP deployment for agencies and CERTs to what each one means for hosting location, access control and sharing configuration. Read each row as a question to answer before the architecture is fixed, since several requirements decide where the platform can run at all.
| Requirement | What it asks for | Build impact on MISP |
|---|---|---|
| NIST SP 800-53 baselines | Low, moderate and high baselines select 149, 287 and 370 controls and enhancements respectively, per SP 800-53B Release 5.2.0. | Confirm the system's impact level first, then select the baseline. Map MISP audit logs, account controls and encryption settings to the control families in scope. |
| FISMA oversight | Inspectors General independently assess agency system security and report to OMB. | Keep configuration baselines, change records and authorization evidence ready for an IG review. Ask your IG office what artifacts it expects. |
| FedRAMP scope for cloud hosting | Applies to cloud products that process federal information on behalf of an agency. Single-agency systems not offered as a shared service may fall outside scope. | If MISP runs in a commercial cloud and serves multiple agencies or a shared community, confirm whether FedRAMP authorization applies before choosing the hosting provider. |
| CJIS Security Policy v6.1 | Requires FIPS 140-3 validated modules or AES with at least 256-bit keys for criminal justice information in transit and at rest outside physically secure locations, plus vulnerability scanning at least monthly. | Confirm TLS and disk encryption use validated modules. Schedule monthly scans of the MISP host, database and Redis. Keep CJI out of events unless the sharing group is approved for it. |
| CUI on non-federal systems (32 CFR 2002.14) | Agencies use NIST SP 800-171 when setting requirements for controlled unclassified information on non-federal systems, unless the CUI category prescribes other safeguards. | Where partner organizations host MISP, define sharing groups and distribution levels that keep CUI-tagged attributes within approved members and systems. Confirm the 800-171 requirements in the agreement. |
| CMMC cloud rule for contractors (32 CFR 170.17) | A defense contractor seeking CMMC Level 2 may store or process CUI in a cloud service only if it is FedRAMP Authorized at Moderate or higher, or meets equivalent requirements. | Contractors hosting MISP for defense indicators should confirm the cloud hosting choice against this rule before onboarding partner communities. |
| NIS2 scope exclusions (Articles 2 and 3) | NIS2 does not apply to entities working in national security, public security, defense or law enforcement, although central government entities are otherwise in scope. | Determine whether the MISP instance falls under NIS2 or under national security rules. The governing regime sets the sharing rules, retention and who may join the community. |
| WCAG 2.1 for public-facing portals (28 CFR 35.200) | State and local government web content and mobile apps, including contracted content, must meet WCAG 2.1 Level A and AA from 26 April 2027 for entities serving 50,000 or more people and from 26 April 2028 for smaller entities and special districts. | Any public portal for sharing status, onboarding or advisories built around MISP needs WCAG 2.1 AA testing. Confirm your population category and the deadline that applies to you. |
How sharing groups keep restricted indicators inside the right circle
Agencies should decide who may see each indicator before anything is imported or synchronized. MISP supports distribution levels and custom sharing groups that can be applied down to individual attributes, so one event can hold material that stays internal, material that goes to a partner community and material that reaches a national sharing group. The sharing group and distribution settings must be designed as a governance model first, then configured in the platform. Confirm with your legal and security leads which classes of indicator are restricted, which partners are authorized to receive each class, and who approves a change to a sharing group's membership. Synchronization is the other control point. MISP instances exchange events and attributes only with the instances and communities you configure, so each synchronization link should be reviewed as a trust relationship, with the same scrutiny you would apply to a data-sharing agreement.
Agencies also need a decision on marking. Traffic Light Protocol (TLP) labels and similar schemes tell recipients how far an indicator may travel, but they only work if the agency defines what each label means internally and maps it to MISP distribution levels consistently. A mismatch, such as an event marked for restricted sharing that is published at a wider distribution level, is the kind of error a periodic check of event metadata should catch. Ask your sharing partners which marking scheme they use and confirm how their labels translate into your settings before the first exchange. Note that the MISP project publishes taxonomies and galaxies under CC0 1.0 Universal or the 2-clause BSD license, separate from the AGPL-3.0 software license. Those datasets can usually be reused in a different form, but the license terms still apply when you republish or redistribute feed content, so have counsel confirm the terms before an agency publishes MISP-derived lists to third parties.
Restricted indicators also need an exit path. When a partner leaves a community or a sharing group loses its purpose, you must be able to remove that circle's access and withdraw content that should no longer be visible. Test this in a non-production instance: create a sharing group, publish a test event to it, remove a member, and confirm the member no longer retrieves the event through the API or synchronization. Record the result as evidence for your sharing governance file. An illustrative runbook might assign the data owner to approve membership changes and the MISP administrator to execute them, with a quarterly review of every sharing group and synchronization partner.
Which platforms fit government threat intelligence and why
Government threat intelligence usually splits into three jobs: sharing indicators with national and partner communities, analyzing them against the agency's own environment, and pushing the results into detection tools. The cards below map which open-source platform handles each job, what it depends on, and what to confirm before committing to a design.
MISP as the sharing hub
MISP is the usual choice when the main requirement is exchanging indicators with national and partner communities. It is licensed under AGPL-3.0, and the project recommends the 2.5 line for new deployments, with MISP 2.5.50 published on October 10, 2026. Its sharing groups and distribution levels can be set down to individual attributes, which is the control agencies need for restricted indicators. Confirm which community instances you must synchronize with and whether your agency is permitted to host one.
Correlation and STIX exchange in MISP
MISP's correlation engine links events through exact matches and advanced patterns such as fuzzy hashes and CIDR overlaps, which helps analysts see related campaigns across partner submissions. Exports cover STIX 1 and 2 alongside Suricata, Snort, Zeek and RPZ formats, so one curated event can feed several tools. Ask which STIX version your partners consume, since older partners may still expect STIX 1. Test the export path with a partner before go-live.
OpenCTI Community Edition for analysis
OpenCTI, maintained by Filigran, suits analysis work that needs a knowledge graph built on the STIX2 schema and a GraphQL API. The Community Edition is licensed under Apache 2.0, and a dedicated connector brings in MITRE ATT&CK. The platform depends on Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage such as MinIO, so plan the infrastructure as a service in its own right. Confirm the operating model before relying on it for sharing.
OpenCTI LTS and Enterprise feature checks
OpenCTI LTS releases are distributed as container images but require a specific LTS license key, and they receive only critical bug and security fixes after the first month of stabilization. Some capabilities are documented under the proprietary Enterprise Edition license rather than the Community Edition. Before design approval, ask the implementation partner to list every feature your use case needs and confirm in writing which edition and license key each one requires, since procurement rules for government software often hinge on this.
Wazuh, Suricata and Zeek as consumers
Exported indicators are only useful if sensors act on them. Wazuh, licensed under GPL version 2, works as an XDR and SIEM platform that can match alerts against threat intelligence, with the latest release v4.14.9 published on October 15, 2026. Suricata 8.0.7 (GPL-2.0) enforces network signatures, and Zeek 9.0.0 (BSD-style license) logs network activity for retrospective hunting. Confirm which sensors sit in each enclave and how rule updates are pushed to them.
Shuffle for automated sharing workflows
Shuffle is a security automation (SOAR) platform licensed under AGPL-3.0, with v2.3.0 published on September 28, 2026. In an agency setting it can automate triage of incoming indicators, enrichment lookups and the publication of approved events to sharing partners, keeping a human approval step where policy requires one. Define which actions may run without review and record each playbook run for audit. Confirm that your connectors and integrations are maintained for the version you deploy.
What STIX and TAXII exchange requires from the agency
The agency has to decide, before go-live, which STIX version and transport each sharing partner expects, because the platform choice sets the default. MISP exports STIX 1 and STIX 2 alongside its native MISP JSON, so a national or partner community that still exchanges STIX 1 can be served from a MISP instance. OpenCTI structures its data on the STIX2 knowledge schema, so it is the natural fit when the agency wants graph-based analysis and STIX 2 objects as the working format. Record the chosen format per partner in the sharing agreement, and confirm with each community whether it accepts MISP JSON, STIX 2 bundles, or both. Do not assume a partner's import tool reads the same STIX dialect that your instance produces.
The TAXII transport question is one to confirm for each community, not one to assume. Some communities push and pull through a TAXII server, others run MISP-to-MISP synchronization, and some accept file drops reviewed by a human. Ask each partner which TAXII version and collection structure it uses, who hosts the server, which authentication method it requires, and whether it needs the agency to publish or only subscribe. Those answers determine whether the agency runs its own TAXII endpoint inside its network or relies on the partner's infrastructure, and that choice affects accreditation boundaries and who can see restricted indicators in transit.
Format conversion can drop context. Distribution levels, sharing group membership, TLP markings, object relationships and free-text comments may not survive a round trip between MISP and STIX 2, or between STIX 2 and a partner's platform, and a field that is absent from the mapping will often fail silently. Before any production exchange, run a test with each partner's sample feed, compare the imported objects against the source event field by field, and confirm that restricted indicators are not published under a looser marking. Repeat the test after every platform upgrade, since mapping behavior can change between releases.
How a government MISP rollout moves from pilot to sharing
The sequence takes a public sector MISP instance from agreed governance and an accreditation boundary to a tested sharing design, validated detection exports and a handover the agency can run on its own.
Agree governance and classification rules in writing
Before any server is built, the agency, its legal and records function and the security team agree in writing what the platform may hold, which classification levels and handling markings apply, who may publish events, and which partner communities the agency will share with. DeployOpen facilitates these workshops and drafts the rules document, but the agency's authorizing officials own the decisions. Done means a signed governance document that names the data owners, curators and approvers, and states how TLP markings and restricted indicators are treated. Confirm with your own legal and classification authorities which marking schemes apply to your information.
Decide hosting location and accreditation boundary
The team decides where the instance runs, whether in an on-premises data center, a government cloud tenancy or an enclave, and draws the accreditation boundary around the MISP application, database, Redis, backups and any connected sensors. This decision determines which compliance regime applies. For example, if the instance would store criminal justice information, the CJIS Security Policy requirements for encryption and vulnerability scanning would govern the boundary. Done means a boundary diagram, a data flow diagram and a written hosting decision that the accrediting authority has reviewed. Ask your authorizing official which baseline and assessment path apply before procurement starts.
Install MISP 2.5 in a hardened build
DeployOpen installs MISP 2.5 inside the agreed boundary, using the project's supported installation path on a current supported Ubuntu release, and applies hardening to the operating system, web server, database, Redis and administrative interfaces. The team starts on 2.5 rather than upgrading an existing 2.4 instance, because the project states 2.4 is end of life with security fixes only and advises against new 2.4 installations. Done means a documented build with configuration under version control, a passing configuration review and a recorded baseline of the installed version and components.
Integrate identity provider and MFA
The agency's workforce identity provider is connected to MISP so analysts sign in with their own accounts and multi-factor authentication, and local accounts are limited to documented break-glass use. MISP's OidcAuth plugin documents an OpenID Connect path that the team tests against the agency's identity service. Done means a test matrix showing that each role logs in through the identity provider, that MFA is enforced for every user, that unique user identification is preserved in audit logs, and that break-glass access is tested and sealed. Confirm the supported identity protocols with your identity team before design.
Test sharing groups and distribution with a partner instance
Before any real indicator leaves the agency, the team builds a test sharing design on a separate partner or test MISP instance and exercises distribution levels, custom sharing groups and synchronization. Testers confirm that an attribute marked for a restricted group never reaches an instance outside that group, and that events synchronize only to the intended communities. Done means a written test report listing each distribution scenario, the observed result and the sign-off by the data owner. Repeat tests after every configuration change to sharing rules.
Onboard feeds and connectors under review
The team connects only the feeds and taxonomies the governance document approved, imports default and warning lists deliberately, and sets review rules for incoming intelligence so that curators decide what becomes an active indicator. Any connector that calls an external service is documented with its data flow and owner. Done means an approved feed register, a curation procedure in writing and a test import that a curator has reviewed. Ask your partner to confirm which connectors are maintained by the community and which need your own maintenance.
Validate SIEM and firewall exports
Indicators are exported to the detection tools the agency runs, such as Suricata, Zeek, Snort or firewall block lists, using MISP's export formats. Testers confirm that the exported rules load, that a known test indicator produces the expected alert in a staging sensor, and that only indicators cleared for that tool are exported. Done means test evidence showing the export, the load result and the alert, plus a rollback procedure for bad rules. Coordinate with the SIEM and network monitoring owners so the export path matches their change control.
Hand over operations and evidence
DeployOpen hands the instance to the agency's operations team with runbooks for upgrades, backups, restores, user onboarding, sharing group changes and incident response on the platform. The handover includes the evidence pack: the governance document, boundary diagrams, configuration baselines, test reports and the access review record. Done means a completed handover checklist signed by the platform owner and a first operations review scheduled. Ongoing support, upgrades and continuous testing can be agreed as a separate retainer, and the scope of any retainer should be written before work starts.
Evidence auditors and oversight bodies ask for
This table maps the evidence a reviewer typically asks for in a public sector MISP deployment to the component that produces it and who prepares it. Read it as a checklist to agree with your assessor before the deployment is built. DeployOpen prepares the configuration exports, logs and records described here, but an independent assessor or certification body issues any assessment result.
| Evidence item | What it shows | Where it comes from and who prepares it |
|---|---|---|
| Distribution and sharing group configuration exports | Which sharing groups exist, who belongs to them and the distribution level applied to each event and attribute | MISP sharing group and distribution settings exported on a schedule. DeployOpen prepares the export procedure and baseline; the agency approves the membership lists |
| Synchronization audit logs | Which events and attributes left or entered the instance, with which partner and when | MISP audit log and sync records retained in the SIEM. DeployOpen configures forwarding and retention; the agency defines the retention period |
| Access control records | Unique user accounts, roles, and the approval trail for access to restricted sharing groups | MISP user and role exports, linked to the central identity provider. Confirm with your identity team how joiner and leaver events reach MISP |
| Authentication and MFA configuration | How users sign in to the instance and whether multi-factor authentication applies to every account | Identity provider and MISP authentication settings. Confirm the MFA method accepted for CJI scope with your assessor |
| Monthly vulnerability scan results | That the host, the MISP application and its dependencies were scanned at the cadence the CJIS scope requires | Scanner reports from the scanning tool the agency selects, with remediation tickets. Confirm the required cadence against the current CJIS Security Policy version |
| Encryption configuration | Whether data in transit and at rest uses FIPS 140-3 validated modules or AES with 256-bit keys | TLS settings, disk and database encryption settings and key custody records. Confirm module validation status with the vendor and your assessor, since validation is a property of the specific module |
| Sharing agreement records | The terms under which each partner or community receives and returns intelligence, including TLP handling | Signed agreements and onboarding records kept by the agency. DeployOpen can prepare the register and link each partner to its sync configuration |
| Retention records for exported indicators | How long exported indicators, Suricata or Zeek rules and STIX files are kept and when they are deleted | Retention schedule, export logs and deletion records. The agency sets the schedule; DeployOpen implements and documents it |
Questions agencies ask before hiring help with MISP
What drives the cost of a MISP deployment for a public sector agency?
Most of the cost sits in people and hosting, not software, because MISP is licensed under AGPL-3.0 and carries no license fee. Costs fall into four groups: the implementation scope (hosting design, hardening, authentication, backups and upgrades), the integrations into your SIEM, firewalls and SOAR, the analyst time to curate indicators and manage sharing groups, and ongoing support or retainers. Hosting is paid for in your own cloud account or data center, and the cloud or hardware choice is usually the largest recurring line. Ask any partner for a quote that separates one-time work from recurring operations, and that names which integrations and sharing communities are in scope. Scope drives price more than anything else.
How long does a MISP rollout take in government?
The duration depends on the number of integrations, the accreditation path, and how quickly approvals arrive, so it cannot be stated as a fixed figure before scoping. The main drivers are the hosting approval, the authentication design, the sharing group model agreed with partners, and the number of feeds and tools to connect. MISP 2.5 is the recommended version for new deployments, and MISP 2.4 is end of life, so the build starts on the current line. Ask a partner to show a written schedule with named milestones, the approvals each milestone depends on, and what you must supply and when.
What must our agency provide before a MISP implementation starts?
An agency needs to supply four things before work begins: a governance owner who approves sharing rules, a named accreditation owner who accepts the hosting and data handling design, technical contacts who can grant network and identity access, and contacts at the partner communities that will exchange data. Sharing rules should define who may see which distribution level, how Traffic Light Protocol markings are applied, and what must never leave the agency. Without these decisions, the partner cannot configure sharing groups correctly. Confirm these owners in writing in the scope document, along with the authority that signs off on classified or restricted indicators.
Can our own staff run a MISP instance without outside help?
Yes, many teams operate MISP internally, but they need skills in Linux administration, database and Redis operations, TLS and authentication, and the MISP sharing model. The project supports installation through an installer for Ubuntu 24.04, Docker images, Ansible roles, Puppet and RPM packages, so the initial build is not the hard part. The harder work is ongoing: upgrades, backups, synchronization with partner instances, and keeping feeds and taxonomies current. Assess your team against those duties. A retainer can cover upgrades and support while your staff keep curation and governance decisions in-house.
Is MISP enough for our agency, or do we need OpenCTI?
MISP covers sharing, indicator storage, correlation and export well, and it is the usual choice when the main goal is exchanging indicators with national and partner communities. OpenCTI is better suited when analysts need a knowledge graph, STIX2-based relationship modeling and MITRE ATT&CK mapping as a central analysis workspace. Many agencies run MISP for exchange and feed analysis into other tools. OpenCTI has a Community Edition under Apache License 2.0, but some features sit in the Enterprise Edition under a separate license, so confirm which capabilities you need before choosing. OpenCTI also depends on Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage, which adds operational load.
How is indicator sharing with partners governed in MISP?
Sharing is governed by distribution levels, sharing groups and synchronization rules that your agency defines before any event is shared. MISP supports distribution levels and custom sharing groups down to individual attributes, so you can limit a restricted indicator to named partners. Automatic synchronization with trusted communities depends on the connection rules you configure. Governance should also cover who approves a new partner, how membership is revoked, how false positives are retracted, and what happens to data shared under a classified or restricted marking. Document these rules in a sharing policy that the accreditation owner signs off on.
Which standards does MISP use to exchange indicators with partners?
MISP exports and imports several formats, including MISP JSON, STIX 1 and STIX 2, OpenIOC, CSV, Suricata, Snort, Zeek and RPZ, and it offers an OpenAPI-described API with a bundled PyMISP library. For partners that use TAXII servers, confirm during scoping whether a TAXII connection is included and how it is secured, because the supplied facts do not confirm the transport configuration for your environment. Standard formats let you feed Suricata and Zeek sensors directly, which helps move intelligence into detection. Ask the partner to show a working export to each format your partners use.
What to ask an implementation partner before you commit
Start with the accreditation boundary. Ask the partner which boundary they design for and where it ends: the MISP host, its database and Redis, the sync links to partner instances, the SIEM and SOAR consumers, and any backups. A partner who cannot draw that boundary on a diagram before design starts will struggle to scope FIPS-validated cryptography, CJIS Security Policy handling or CUI controls. Ask them to show how they would keep criminal justice information or CUI out of the threat intelligence platform unless the scope was agreed in writing, and who in your organization signs off on that decision.
Next, ask how sharing groups and distribution levels are configured in practice. Request the written model for who can create events, which sharing groups exist, which distribution levels apply to each attribute, and how TLP markings map to those settings. Ask whether they will test synchronization with a partner instance using non-sensitive sample events before any production indicator moves. Ask them to demonstrate the STIX and TAXII exchange with your partners, including the STIX version each partner uses, and to show the export output for a sample event so your analysts can confirm nothing outside the intended group is published.
Finally, ask how connectors, modules and the underlying stack are kept current, and how evidence is produced. Ask who tracks MISP and OpenCTI releases, who applies security fixes to the MISP 2.5 line, and whether OpenCTI Enterprise Edition features are part of the scope, since LTS releases need a license key. Request a written patching and testing procedure, a list of every component with its version, and a sample of the audit and configuration records they will hand over. Confirm with the partner which of those records your assessor will accept, because DeployOpen prepares evidence but does not issue audit reports or certifications.
How DeployOpen scopes and supports government threat intelligence
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted MISP or OpenCTI inside the agency's own infrastructure, whether that is a government cloud account, a data center or an air-gapped enclave. Each engagement starts with a written scope that sets which sharing communities, marking rules and integrations are in play before any platform work begins.
How we scope
- Written scope fixes which sharing communities, partner groups and national channels the instance will connect to
- Sharing groups, distribution levels and TLP handling rules are agreed with the data owners before any feed is loaded
- Scope records the hosting boundary, classification constraints and which systems receive exported indicators
How we build
- Deploy MISP on the agency's own infrastructure, with the database, Redis and sync settings documented as built
- Configure STIX and TAXII exchange, export formats and connectors into the SIEM and network sensors the agency already runs
- Test sharing-group isolation and access roles, and document the results alongside the configuration baseline
How we hand over
- Handover package covers architecture, configuration, sharing group settings, runbooks and an upgrade procedure
- Analysts and administrators are trained on curation, publishing and retraction workflows for restricted indicators
- Evidence for assessors, such as access reviews and audit log samples, is delivered in a form the agency can keep
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Upgrades track the supported MISP line, with the agency approving each change in its own change process
- Confirm with DeployOpen during scoping which support hours, response paths and clearance requirements apply to your staff
