MISP instance synchronization and sharing groups

The choice between push and pull decides which side of a sync relationship holds the initiative. In a push connection, your MISP instance selects events and sends them to a remote server. In a pull connection, your instance contacts the remote server and fetches what it is permitted to see. The mechanism looks like a small configuration detail, but it changes who controls visibility, timing and troubleshooting. Before you configure either direction on a partner or ISAC connection, decide which party should be making that choice for each dataset you exchange. With push, your organization controls what leaves the building. Your administrators decide which events are published to the remote server and under which distribution level, and the remote side only receives what you chose to send. That control is useful when you want to share a curated subset with a partner who has no need to browse your whole collection. The trade-off is that the remote side depends on your instance to stay reachable and to run its publishing and synchronization jobs. If your scheduler stops or a publishing rule is misconfigured, the partner quietly stops receiving updates, and the gap may not be noticed until someone asks why an indicator is missing. With pull, the remote server decides what it offers, and your instance decides when to ask. You control your own inbound schedule and can keep your collection local, but you depend on the remote side's filters, distribution settings and availability. Whatever the partner has filtered out never reaches you, and you may not know what was withheld. Failures tend to appear on your side as stale data or authentication errors on the connection, which means your monitoring should track the last successful fetch for each remote, not only whether the sync job ran. In practice, most sharing groups use both directions, and the decision is made per connection and per dataset. Review the sync settings of your MISP version against the official documentation, since option names, default behaviour and job handling change between releases. Then write down, for each partner, who selects the data, who can revoke it, and who is alerted when the connection breaks. Those three answers will do more to keep sensitive attributes inside the organization than the direction of the connection alone.

Test the design before it goes live. Use a non-production remote or a partner-agreed test event to confirm that a published item reaches the other side only at the distribution level you intended, and that an attribute restricted to your organization does not appear in the outbound payload. Repeat the check after upgrades, because a change in default filtering can alter what a connection carries without any visible change in your configuration screens.

The most important rule for a MISP instance that synchronizes with partners is that distribution decisions are made when data enters MISP, not when it leaves. Sensitive events should be created with distribution set to your own organization only, and that setting should be checked before any sync partner is connected. Attribute-level distribution and sharing groups give finer control when one event mixes material that can travel with material that cannot. Use them deliberately: a sharing group that includes an external organization is a sharing decision, and it should be recorded as one. Confirm in your own instance how the default distribution for new events and attributes is set for each user role, because a permissive default is the most common way sensitive data leaves a deployment unnoticed.

Sync filters are a second line of control, not the first. A pull or push rule can exclude events by organization, tag, distribution level or type, and tags that mark internal material, such as a local classification tag agreed with your team, are a practical basis for those rules. Test each filter against known events before enabling it, and record which tags the filter depends on. A filter that relies on a tag will fail silently if analysts forget to apply that tag, so pair tag-based filtering with a review of events that carry no classification at all. Filters also need an owner who reviews them after each sync partner change or MISP upgrade, since rules that worked on one version may be interpreted differently after a migration.

A correct sync filter does not protect attributes that were already published with a wider distribution level. Once an attribute has been shared with a community or a sharing group, a later change to the filter does not recall it from partners that already received it, and a downgrade in your own instance does not undo a previous synchronization. Before connecting a new partner, search existing events for attributes at broader distribution levels and review the ones that should have stayed internal. Treat that review as part of the onboarding checklist, not an occasional cleanup task, and document who approved each widening decision.

Enrichment results and feed-imported data need the same scrutiny. Expansion modules and enrichment lookups can attach new attributes to an event, and those attributes may inherit a broader distribution than the original sensitive indicator. Default intelligence feeds and imported warning lists also create events at distribution levels chosen by their publishers, not by you. Check the distribution of attributes added by enrichment and feeds, and decide whether they should be copied into an internal event with a stricter setting. Ask the team that maintains your feeds and enrichment configuration to confirm which of these paths can create events that sync outward.

Analysts need a written rule for when to downgrade distribution, withhold an attribute, or keep it entirely internal. A practical rule names the trigger, such as the source being a customer, a regulator, an incident under legal hold or a partner's restricted report, and the action, such as setting distribution to organization only, removing the attribute before sharing, or splitting the event. It also names who can override the rule and how the override is logged. Test the rule with two or three illustrative cases before publishing it, and review it after each sync partner is added. Without this rule, each analyst makes an individual judgment, and the sharing outcome depends on who handled the event.

The goal of this test plan is to prove, before any partner relies on the connection, that each sync rule releases exactly the events and attributes its owner intended and nothing else. Treat the sync configuration as code under test. Write down the expected outcome for every case first, then run the cases against a staging pair of instances or against a partner that has agreed to a short test window. Record the event UUIDs, the distribution setting, the tags and the organisation that created each test item, so that every result can be traced back to a specific expectation.

Start with distribution levels. In a test instance, create one controlled event per level your policy uses (your own organisation only, this community, connected communities, all communities, and sharing group), and add one attribute at each level where the attribute-level setting differs from the event. Use clearly marked dummy values, such as documentation-range IP addresses and invented domain names, so no real indicator leaks if a test slips through. Then check the remote side. Events marked for your organisation only must be absent on the partner, the sharing group event must appear only for members of that group, and community-wide events must arrive with the distribution level preserved. Confirm the same results through both push and pull, because the two directions can be configured with different filters.

Next, test the filters. Create test events carrying a tag that your rules are meant to exclude, plus one event owned by an organisation that must never be shared, and confirm that neither reaches the partner. Include a positive control with an allowed tag so that a silent failure in the whole sync is not mistaken for a successful filter. Check both the event-level and attribute-level results, because an event can pass a filter while a single attribute inside it should not. Repeat the check after any change to tag names or organisation records, since a renamed tag can quietly fall outside the rule.

Verify the sync user's permissions separately. The account used for synchronisation should be a dedicated user with the minimum role and sharing group access needed. Log in as that user, or query the API with its key, and try to read events that sit outside its scope, including events that belong to other organisations at higher distribution levels. Any result beyond the agreed scope is a finding that must be fixed before go-live. Also confirm that the API key for the sync user is stored and rotated as your key policy requires, since a leaked sync key can expose more than the sync itself.

Test failure behaviour and rollback. Take the remote server offline for a defined period, create new test events locally, and then confirm that the local instance either queues them for later delivery or reports the failed pushes in its sync and job logs. Nothing should disappear silently, and nothing should be sent to a wrong or fallback destination. Bring the partner back and confirm that the queued items arrive once and in the right scope. For rollback, keep the previous filter rules as a saved, exported configuration. If a rule is found to over-share or to block needed data, disable the faulty rule or the sync connection, remove the affected test or live items from the partner through the agreed process, and restore the saved rule. Ask your partner to confirm in writing what they retained, and ask the implementation team to document the time taken to complete each step.

DeployOpen is a Chainscore Labs company. We plan, implement, customize, harden, document and support self-hosted open-source platforms inside the client's own infrastructure, and MISP synchronization is handled the same way. For sync work, the first scoping question is which partners and communities the instance will exchange events with, because that answer decides how many sync connections exist, which direction each one runs (push, pull or both), and which distribution levels and sharing groups each connection is allowed to carry. Those decisions are written down before any server is configured, so the scope reflects real trust relationships rather than assumed ones.

Most engagements of this kind are fixed-scope. The scope, deliverables and timelines are agreed in writing before work starts, and the written scope is the basis for any quote. DeployOpen does not publish a price list, so the reader should expect a quote that follows directly from the listed sync partners, the number of MISP instances involved, the sharing group design, and the filtering rules that need to be built and tested. When requesting a quote, ask the vendor to name each sync connection, the agreed direction, the distribution policy it will enforce, and which items are out of scope, such as partner-side configuration or changes to a community's own sharing rules.

The handover is where the value of the work is either kept or lost. DeployOpen's handover package includes the sync configuration records (remote server entries, API key ownership, push and pull settings, and the filtering rules attached to each connection), the distribution policy that maps sharing groups and distribution levels to what may leave the organization, test evidence showing that restricted attributes were not pushed to a partner and that expected events did arrive, and runbooks for adding a partner, rotating a sync key, and handling a failed sync job. Ask for these artifacts by name in the statement of work, and confirm where they will be stored and who on your side owns them.

Ongoing support is available as a retainer for teams that do not want to maintain sync rules, partner connections and upgrades in-house. A retainer typically covers monitoring of sync health, reviewing changes to partner connections, and applying patches to the MISP instance. Confirm in the agreement exactly what the retainer includes, how changes to sharing groups are requested and approved, and how quickly the vendor will respond to a broken sync. Any service levels should appear in writing in the agreement, and any figure you are given should be checked against the signed document rather than a verbal estimate.

Before signing, check three things with your team. First, confirm that your data classification rules match the distribution levels you plan to use, because the technical settings will only enforce what the policy defines. Second, decide who approves a new sync partner and who can change a sharing group, since those permissions are the main path by which sensitive attributes can leave the organization. Third, agree the acceptance test for each sync connection, including a sample event that is intentionally marked restricted and must not appear on the partner side. Those three decisions shape the scope more than any other factor.