Sync sightings between MISP instances

Sightings

MISP sighting is a system allowing people to react on attributes on an event. It was originally designed to provide an easy method for users to tell when they see a given attribute, giving it more credibility. As such, the sighting system in MISP allows you to get feedback from your community on the quality of the data (the indicators).

There is not immediately an option within MISP to sync sightings between instances.You can sync sightings on publishing an event but besides the mentioning in Issue 1704 I could not immediately find an option for syncing. Under the hood, the sightings all have a unique UUID in the database so in theory syncing should be possible.

Use case

The use case that I had was

  • One authoritative MISP server, providing events and attributes;
  • Multiple ‘client’ MISP, that receive these events (via a pull);
  • Whenever an attribute is seen at the client side, the sighting needs to be reported back to the authoritative MISP;
  • No events are pushed back from the client to the authoritative MISP server.

PyMISP to the rescue!

sync_sighting.py

I created a PyMISP script that

  • Runs as a cronjob every 5 (or your setting) minutes;
  • It loads a drift file containing the last time a sync was done. If no file is found a new drift file is created;
  • It checks if there are new sightings since that timestamp;
  • Any new sightings are then pushed to an authoritative server;
  • The current timestamp for the sync is then written to the drift file.

The script is available on Github cudeso/PyMISP (pending pull request PR 401).

Note that you should run this script on the clients.

Configuration

All configuration is inline in the script. First you need to set the file name where the drift timestamp has to be written. Obviously the user that you use for running the script needs to have write permissions to that path.

drift_timestamp_path = '/home/mispuser/PyMISP/examples/sync_sighting.drift'

Next you need to add two API keys for the syncing, one key is for the MISP instance on which the script runs (the client) and one key is for the ‘authoritative’ MISP instance. For PyMISP this is all done in the file keys.py.

misp_url = 'https://misp_client/'
misp_key = '' # The MISP auth key can be found on the MISP web interface under the automation section
misp_verifycert = False

misp_authoritive_url = 'https://misp_server/'
misp_authoritive_key = '' # The MISP auth key can be found on the MISP web interface under the automation section
misp_authoritive_verifycert = False

This is basically all that is needed. Optionally you can get more debug information by setting the variable module_DEBUG

module_DEBUG = True

A word of caution – sighting permissions!

A word of caution on the sighting permission. If you create an event on the authoritative MISP instance and that event is pushed to a client and that client sends sightings back, before the other clients have received the event, then these other clients will be able to see those initial sightings.

In some cases this is an undesirable situation. But this can be solved by setting the Plugin.Sightings_policy to Event Owner. To do this go to Server Settings, Server Settings & Maintenance, Plugin settings. From there choose the plugin Sightings and then select the Sightings_policy.


Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.