Synchronization and Sharing
Synchronisation
Concept
The following figure shows the concept how different MISP instances could tie together.
In MISP, two ways exist to get events from remote sources:
- Use case 1: From another MISP server (also called MISP instance), by synchronising two MISP servers.
- Use case 2: From a link, by using Feeds.
The example below illustrate the synchronisation between two MISP servers (use case 1). An organisation B (OrgB) wants to synchronise its MISP server, called ServerB, with the MISP server of an organisation A (Org A), called ServerA. The following steps can be taken to syncronise ServerB with ServerA:
FIGURE: Illustration of the synchronisation between two MISP servers
- Step 1: Add OrgB as a local organisation on ServerA (OrgB.ServerA) using OrgB’s existing UUID from their local organisation on ServerB.
- Step 2: Add a Sync User (syncuser@OrgB.ServerA) in the organisation OrgB.ServerA on the MISP ServerA.
- Step 3: Set up a sync server on MISP ServerB using the key (called Authkey) from the sync user (syncuser@OrgB.ServerA) created on MISP ServerA.
For additional information on the synchronisation process, refer to the MISP GitHub issues, for example, issue 2595.
Pull vs Push synchronisation
Synchronisation can be set up using the pull or push option. A combination of the two is possible as well. This section discusses the main practical differences between the two and the benefit of using both in conjunction.
To automatically execute pull and push synchronisations on a schedule, please use a scheduling service such as cron to execute the relevant command line functions mentioned in the related administration section.
For a table overview of which community distributions lead to a sync on push or pull scenarios as well as how the distribution level automatically decreases on sync, please refer to the syncing scenarios with communities distribution section.
Push
The push mechanism provides a seemingly real time experience. If a push connection is enabled, data created (and synchronized from other peers) will be synchronized as fast as possible. In practice, this means that an attempt to synchronise is made immediately after publication of an event.
A disadvantage of the push mechanism is that connection issues or dead workers might prevent the push from being successful.
Data with distribution set to ‘Your organisation only’ or ‘This community only’ will not be synchronised using the push mechanism (unless the internal instance flag is set for the server to be synced to).
Pull
In contrast to a push, pull synchronisation is only performed on command. This could be a manual trigger by an admin from the servers page or a cron job executing a pull command. See administration for the available command line interface commands.
A pull will also fetch objects with a distribution set to ‘this community only’ and even your ‘organisation only’, if the auth key belongs to the organisation owning the related event.
Benefits of using push and pull in conjunction
- If an unexpected issue prevented the push from happening, the data can be pulled in later
- Different rules can be set for the push and pull sync
Adding a server
Servers can be added by users via
https://<misp url>/servers/addThe Add Server form is grouped into sections — Instance identification, Instance ownership and credentials, Enabled synchronisation methods and Misc settings — and has several input fields:
Base URL The base-url to the external server you want to sync with. Example: https://foo.sig.mil.be
Instance Name A name that will make it clear to your users what this instance is. For example: Organisation A’s instance
Internal instance This checkbox will only show up if the set ‘local organisation’, see 5, is the same as the owning organisation of the instance the remote server is being configured on. If this flag is set, the distribution of pushed data will not be automatically downgraded. Please refer to the syncing scenarios with communities distribution section for a table overview of the differences.
Remote Sync Organisation Type MISP has several organisation “pools”, one for local and one for known external organisations. When adding a synchronisation connection, you need to define the host organisation of the remote instance. Select which pool you wish to pick the organisation from using this drop-down. You also have the option of adding a new external organisation directly from this interface.
Local/Known remote Organisation Choose the organisation from the selected pool that defines the host organisation on the remote side. Make sure that the remote instance is actually run by the organisation you select. When selecting data to push, this organisation will be used to determine membership of sharing groups. As a result, this setting is very important, since selecting the wrong organisation can lead to leaking confidential data (oversharing) or sharing less than intended.
Authkey You can find the authentication key on your profile on the external server. If advanced auth keys is enabled you might have to create an auth key manually. This can be done on your profile view as well. Please refer to the automation section for more information about creating an automation key.
Push Allow the upload of events and their attributes. Only Events that match the given push rules (see 19) will be pushed to the server. Sightings and relevant galaxy clusters will not be pushed unless ‘Push Sightings’ and ‘Push Galaxy Clusters’ are enabled as well.
Pull Allow the download of events and their attributes from the server. Only data matching the given pull rules (see 20) will be pulled. Relevant galaxy clusters will not be pulled in unless the ‘Pull Galaxy Clusters’ checkbox is ticked as well.
Push sightings If checked, sightings will be pushed out as well on push.
Caching Enabled Allow caching of the remote server. Once cached, caching related functionalities such as server overlap analysis can be done.
Push Galaxy Clusters If checked, relevant galaxy clusters will be pushed out as well on push.
Pull Galaxy Clusters If checked, relevant galaxy clusters will be pulled in as well on push. This also enables you to do a pull for galaxy clusters only if pull, see 8, is checked as well.
Unpublish Event Unpublish the synced event. This only works on push.
Publish Without Email Publish the event without sending out an email.
Self Signed Check this if you would like to allow a connection despite the other instance using a self-signed certificate (not recommended).
Skip proxy (if applicable) Do not connect to this server using the configured proxy (if any proxy host is set in the MISP configuration).
Server certificate file You can upload a certificate file if the instance you are trying to connect to has its own signing authority. (*.pem)
Client certificate file Set a client certificate to use when connecting to this server.
Push rules Allows you to set filtering rules for data to be pushed out (tag based and organisation based). Please see rules for more info.
Pull rules Allows you to set filtering rules for data to be pulled in (tag based and organisation based). Please see rules for more info.
Synchronising analyst data and collections (2.5)
MISP 2.5 adds four more synchronisation toggles to the server form, alongside the galaxy-cluster options, so that the newer collaborative data types can travel between instances:
- Push analyst data / Pull analyst data — synchronise Analyst Data (notes, opinions and relationships) with the remote instance.
- Push collections / Pull collections — synchronise Collections (bundles of events and galaxy clusters) with the remote instance.
Like the other sync options, each direction is independent, both instances must support the feature, and the usual distribution-degradation rules apply.
Adding, editing and removing sync servers is restricted to site administrators.
Test connection
The connection test can be used to test the connection to the remote server and will give a feedback about local and remote version of MISP.
*** 
Rules
Rules are used to limit sharing when synchronising events and attributes. In the example below, data tagged with tlp:red or owned by organisation Setec Astronomy will not be pushed out to this server. Please note any other filtering set up on the instance will still apply as well (blocklists for example).
Troubleshooting
If you have issues connecting to a remote servers try to do the following things: - manually try to do an API request, to ensure that your API key is valid - try to connect with your user account to the remote server and check your roles on the remote server - perform a package capture and analyse the traffic - if you have a SSL connection issue to a remote server with a certificate signed by a CA that is not included in OS, make sure the whole certificate path is included in the path.
Sharing and distribution
The following section describes how distribution mechanisms of events and attributes work.
Distribution settings
The below five distribution settings are available for events and attributes. Descriptions of those settings can be found here.
- Your organisation only
- This community only
- Connected communities
- All communities
- Sharing group
Events that are not published are only distributed/shared to the local organisations on the same MISP server/instance (within the limit of the distribution model). Only events that are published will be shared with remote organisations on other MISP servers via push/pull mechanisms. More details on publishing events here.
Visibility of data - events objects and attributes
Assuming that none of the ancestors of the object of attribute are too restrictive, you can view an event/object/attribute on an instance if: - You are a site admin - Your organisation is owner of the event - Neither of the above apply and one of the below statements is true: - The distribution of the event/object/attribute is ‘This community only’, ‘Connected communities’ or ‘All communities’ - Your organisation belongs to the sharing group of the event/object/attribute or the sharing group has the ‘all orgs’ flag set for the instance
Note: - As of MISP version 2.4.140: When pulling in data you can only see due to the ‘all orgs’ flag being set in the sharing group, your organisation will be added to the sharing group when creating the data locally.
Community
A community is composed of the local organisations on a MISP server and the remote organisations connected by the sync users. For more information on the concept of community, refer to an article on MISP information sharing following ISO/IEC 27010, explaining the concept of community.
Specifically, communities are not reversible. Taking the example of the above figure, illustrating the synchronisation between two MISP servers, OrgB.ServerB is part of the MISP ServerA community but OrgB.ServerA is not part of MISP ServerB community.
Distribution mechanisms
The distribution level of an event is automatically decreased as it is synchronised with other MISP instances, when it was originally set to:
- Community only (to organisation only)
- Connected community (to community only)
It is not decreased when it was originally set to:
- Organisation only
- All communities
- Sharing group
[!] This rule does not apply if “Internal instance” has been checked when creating the server.
As an example, the figure below illustrates two events e and e’ created by OrgA and respectively shared as “This community only” and “Connected communities” and how they propagate in an illustrative MISP set of intances synchronised with each others.
General syncing rules
- The owner organisation of the event on instance B is set to the organisation of the sync user.
- The creator user is the authkey user when pushing
- The creator user is the user triggering the pull when pulling. This user can be different than the authkey user.
- Rule of thumb: if the user configured to pull from instance A to B can see the event on instance A, the event will be synced.
Syncing scenarios with communities distribution
Internal instance flag not set
The below scenarios are if “Internal instance” has not been checked when creating the server. This is the usual scenario.
Push from instance A to instance B - usual scenario
Which organisation the remote sync user belongs to has no impact on which events are pushed.
| Instance A | Instance B |
|---|---|
| Your organisation only | Event/object/attribute not pushed |
| This community only | Event/object/attribute not pushed |
| Connected communities | Event/object/attribute distribution decreased to ‘This community only’ on B |
| All communities | Event/object/attribute distribution stays ‘all communities’ |
Pulling from instance A to instance B - usual scenario
Rule of thumb: if the user configured to pull from instance A can see the event on instance A, the event will be synced.
| Instance A | Instance B |
|---|---|
| Your organisation only | Event/object/attribute pulled in only if the sync user is member of the event’s owner organisation on A. Event distribution stays ‘Your organisation only’ on instance B |
| This community only | Event/object/attribute distribution decreased to ‘Your organisation only’ on B |
| Connected communities | Event/object/attribute distribution decreased to ‘This community only’ on B |
| All communities | Event/object/attribute distribution stays all communities on B |
Internal instance flag set
The below scenarios are if “Internal instance” has been checked when creating the server. This is the not the usual scenario and potentially dangerous. The internal instance flag can be used when both instances have the same hosting organisation.
Push from instance A to instance B - internal flag set scenario
| Instance A | Instance B |
|---|---|
| Your organisation only | Event/object/attribute not pushed if triggering push of already locally (on instance A) published event. Event/object/attribute synced on publication of an event, even if the organisation publishing is not the host organisation of the instance |
| This community only | Event/object/attribute distribution stays ‘This community only’ on B |
| Connected communities | Event/object/attribute distribution stays ‘Connected communities’ on B |
| All communities | Event/object/attribute distribution stays ‘All communities on B’ |
Pulling from instance A to instance B - internal flag set scenario
Rule of thumb: if the user configured to pull from instance A can see the event on instance A, the event will be synced.
| Instance A | Instance B |
|---|---|
| Your organisation only | Event/object/attribute pulled in only if the sync user is member of the event’s owner organisation. Event distribution stays ‘Your organisation only’ on B |
| This community only | Event/object/attribute distribution decreased to ‘Your organisation only’ on B |
| Connected communities | Event/object/attribute distribution decreased to ‘This community only’ on B |
| All communities | Event/object/attribute distribution stays ‘All communities’ on B |
Collaboration
Proposals
Proposals can be used to propose new attribute values that can be reviewed by the event owner.
Forums / Threats
Forums can be used to discuss non event related topics.
Discussions can be accessed on the top “Global Actions - List Discussions”
Discussions will and can not be shared with other servers
and via URL:
https://<misp url>/threads/index
Create a new Topic
To create a new topic
https://<misp url>/posts/add
Comments to events
In MISP ongoing events can be commented by every user to ask free text question to events. Comments to events will not be shared with other servers
Contact a reporter
This feature can be used to contact the person or the organisation that the person belongs to that has created the event.
All E-Mails can be enforced to be encrypted
Receive alerts
It is possible to get alerts via encrypted mail in the following cases:
- published events by other user of the MISP instance
- events pushed to the MISP instance
- events pulled by the MISP instance
These E-Mail alerts are an opt-in feature
Cerebrate
Cerebrate is a companion open-source platform that acts as a directory and distributed trust source for a community: it holds authoritative records of organisations and sharing groups that many MISP instances can then draw from, instead of each instance maintaining that information by hand. Connecting your MISP to a Cerebrate lets you pull those organisations and sharing groups in, keeping identities and sharing-group memberships consistent across the community.
Cerebrate connections are managed under Sync Actions → Cerebrates and are site-admin only. To add one, provide:
- Name and URL of the Cerebrate node,
- an Authkey for its API (stored encrypted),
- the local owner organisation that represents this connection, an optional description, and a Skip proxy option, plus
- Pull organisations and Pull sharing groups toggles for what you want to retrieve.
From a configured Cerebrate you can preview the remote organisations and sharing groups — each is annotated with whether it already exists locally and what differs — before pulling. You can then pull all organisations or sharing groups (creating the missing ones and updating the rest), or download an individual organisation or sharing group. Pulled organisations are matched by UUID; a name clash is resolved by suffixing the imported name.
TAXII 2.x servers
MISP can act as a TAXII 2.1 client, pushing your intelligence — converted to STIX 2.x — to a remote TAXII 2.1 collection, and browsing the collections and objects a TAXII server exposes. This is the standards-based path for sharing with platforms that speak TAXII rather than MISP’s native synchronisation. The STIX conversion relies on the misp-stix library.
TAXII servers are configured under Sync Actions → TAXII Servers and are site-admin only. The form asks for:
- a name and owner label,
- the discovery URL of the TAXII server and a Skip proxy option,
- an Enabled toggle,
- the authentication type — basic (username and password) or bearer (an API token),
- the API root and collection, which are populated dynamically by querying the server (only collections you can write to are offered for pushing), and
- a filters definition (a MISP REST search filter, as JSON) that decides which events are pushed.
Once a server is configured you can push events to it (filtered by the rules you set — run as a background job when jobs are enabled), and browse the server’s collections and the STIX objects within a collection. TAXII push complements the automation chapter’s STIX export formats.
Recommendation
The following section will describe what is the best practice how many MISP instances that showed to be good for orgs. Of course depending on your specific requirements an architecture could be more spread or simplified.
The architecture is divided into several systems / stages beginning with:
MISP Staging System
This systems purpose is to be linked to all available external MISP systems that you have access to. It will download all events and do enrichment between these events.
MISP SECOps System
This system is the main system used by human analysts. It will it is not linked to any external MISP instance other then the Staging System.
To publish events to the community assign the right tags to match your push Rules and publish the event
Comment a topic
A topic can be commented by any user