* **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](../managing-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:
* **Step 3**: [Set up a sync server](#adding-a-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](https://github.com/MISP/MISP/issues), for example, [issue 2595](https://github.com/MISP/MISP/issues/2595).
Click this, if you would like to allow a connection despite the other instance using a self-signed certificate (not recommended). (server certificate file still needed)
Rules are used to limit sharing when synchronising events and attributes, to e.g. events with a given tag, or disabling sharing for events containing a certain Tag.
- with connection issues do a package capture to find out more
- if you have a SSL connection issue to a remote server with a signed by a CA that is not included in OS, make sure the whole certificate path is included in the path.
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](../using-the-system/#creating-an-event).
* 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](../using-the-system/#publish-an-event).
### 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](https://github.com/MISP/misp-compliance/blob/master/ISO_IEC_27010/misp-sharing-information-following-ISO-IEC-27010.md), explaining the concept of community.
Specifically, communities are not reversible. Taking the example of <ahref="misp-server-sync">the above figure</a>, 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.
<palign="center">
<aname="misp-server-sync"></a><imgsrc="https://github.com/MISP/misp-compliance/blob/master/ISO_IEC_27010/images/misp-compliance-iso-concepts.svg"alt="Illustration of MISP organisations and community interactions"style="width: 100%;"/></br>
<span><i>FIGURE: Illustration of MISP organisations and community interactions</i></span>
</p>
### Sharing-groups
There is an article about sharing groups in [here](../using-the-system/#create-and-manage-sharing-groups)