MISP
/
misp-book
mirror of https://github.com/MISP/misp-book
2
0
Fork 0
Code Issues Releases Wiki Activity

Merge pull request #218 from Wachizungu/add-internal-instance-syncing-scenarios 

chg: [Synchronisation] add internal instance syncing scenarios
pull/219/head
Alexandre Dulaunoy 2021-02-23 23:04:42 +01:00 committed by GitHub
parent 6084f01e3d 0315c633bd
commit 258b37c602
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 53 additions and 25 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

68
sharing/README.md
View File

@ -1,13 +1,13 @@
<!-- toc -->
## Sharing / Synchronisation
# Sharing / Synchronisation
* MISP's core functionality is sharing where everyone can be a consumer and/or a contributor/producer.
* Quick benefit without the obligation to contribute
* Low barrier access to get acquainted to the system
## Synchronisation
### Concept
# Synchronisation
## Concept
The following figure shows the concept how different MISP instances could tie together.
@ -32,7 +32,7 @@ An organisation B (OrgB) wants to synchronise its MISP server, called ServerB, w
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).
### Adding a server
## Adding a server
Servers can be added by users via
@ -98,15 +98,15 @@ https://<misp url>/servers/add
You can also upload a certificate file if the instance you are trying to connect to has its own signing authority. (*.pem)
### Test connection
## Test connection
Test connection 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
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.
### Troubleshooting
## Troubleshooting
If you have issues connecting to a remote servers try to do the following things:
@ -139,6 +139,10 @@ A community is composed of the local organisations on a MISP server and the remo
Specifically, communities are not reversible. Taking the example of <a href="#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.
### Sharing-groups
There is an article about sharing groups in [here](../using-the-system/#create-and-manage-sharing-groups)
### 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:
@ -158,32 +162,56 @@ As an example, the figure below illustrates two events **e** and **e'** created
![Illustration of MISP organisations and community interactions](figures/misp-compliance-iso-concepts.png)
#### Syncing scenarios with communities distribution
***The below scenarios are if “Internal instance” has not been checked when creating the server.***
#### 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.
##### Push from instance A to instance B
In this scenario, which organisation the sync user belongs to does not influence the outcome of the push.
#### 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 |
| All communities | Event/object/attribute distribution stays 'all communities' |
##### Pulling from instance A to instance B
Rule of thumb: if the user configured to pull from server A can see the event on instance A, the event will be synced.
###### 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 host organisation on A |
| ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| 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 |
| All communities | Event/object/attribute distribution stays all communities on B |
### Sharing-groups
##### 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.
There is an article about sharing groups in [here](../using-the-system/#create-and-manage-sharing-groups)
###### 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