MISP Guide: Events, Taxonomies and Sharing Groups

Threat intelligence only helps defenders when it reaches the right people, with the right context and the right sharing limits, fast enough to act on. MISP is the open source threat intelligence and sharing platform that most CERTs, CSIRTs and ISACs use to do that: it stores indicators and context as structured events, correlates them, and synchronises them between organisations under explicit distribution rules. This guide explains the MISP data model, how distribution levels, sharing groups and TLP labels work together, how to feed MISP data into detection without flooding analysts with false positives, and how to run an instance safely, including the API keys and sync accounts that are its most powerful credentials. It is written for SOC engineers, CTI analysts and sharing community operators.

Key takeaways

Events are the unit of sharing: an event holds attributes, objects and reports, and its distribution level and tags propagate to everything inside it.
Distribution and TLP do different jobs: distribution levels and sharing groups are enforced by MISP during sync, while TLP tags tell humans what they may do with the data. Set both, and filter sync on TLP:RED.
The to_ids flag is your detection switch: only attributes marked for IDS use should reach SIEM and firewall exports, and warning lists and decaying models should prune them before they do.
Sync users and API keys are privileged machine identities: a sync key can pull an entire community's data, so scope, expire, IP restrict and rotate every key.
MISP is AGPL-3.0 licensed: it is free to run, but changes you offer to others over a network carry source obligations, while PyMISP and the taxonomies and galaxies use permissive licences.

What the tool does

MISP describes itself as an open source threat intelligence and sharing platform for gathering, storing, distributing and sharing cyber security indicators and threat information. The code base dates from 2012, with copyright notices crediting Belgian Defence and NATO NCIRC, and CIRCL, the Computer Incident Response Center Luxembourg, from 2015. CIRCL runs public MISP training and hosts the user guide, and the project is co-funded by the European Union.

The data model

Building block	What it is	Practical note
Event	Container for contextually linked data: attributes, objects and event reports	Distribution and tags set on the event propagate to its children
Attribute	A single data point with a category and type (ip-dst, domain, sha256, url)	Set `to_ids` only when the value is fit for automated detection; duplicates are not allowed in one event
Object	Template-based group of related attributes (file, domain-ip, email)	Object references link objects with a labelled relationship
Galaxy and cluster	Knowledge items such as MITRE ATT&CK techniques, threat actors and ransomware families	Attach clusters so consumers can pivot from indicators to behaviour
Taxonomy tag	Machine-readable label, for example `tlp:amber` or estimative language	Drives sync filters, decaying model scores and export filters
Sighting	Record that a value was seen, or reported as a false positive	Feeds back into decay scores and tells the producer the indicator is live
Event report, analyst note, opinion	Markdown narrative and analyst annotations (opinions score 0 to 100, 50 is neutral)	Keeps the "why" next to the indicators
Proposal	Suggested change to someone else's attribute	Synced to the creating organisation (Orgc), which accepts or discards it

Orgc created the data and can modify it; Org owns the local copy and sees it regardless of distribution. The correlation engine links matching values across events automatically, using exact string matching, ssdeep fuzzy hashes and CIDR blocks.

Distribution levels and sharing groups

Distribution level	Who can see it	What happens on sync
Your organisation only	Members of the creating organisation	Not downgraded; only pulled by a key belonging to the owning organisation
This community only	All organisations on this instance	Becomes organisation only on the receiving instance
Connected communities	This instance plus instances that sync with it	Becomes this community only, so it travels one hop
All communities	Anyone with access, propagated freely	Not downgraded
Sharing group	A named list of organisations, optionally across instances	Not downgraded; membership is checked on every instance

Downgrading does not apply when a server connection is flagged as an internal instance, which is intended for an organisation's own linked instances. Sharing group blueprints can generate and maintain groups from rules, which helps ISACs keep sector groups current.

TLP 2.0 alongside distribution

FIRST's Traffic Light Protocol 2.0 has been authoritative since August 2022, replacing TLP 1.0. The labels are TLP:RED (individual recipients only), TLP:AMBER (need to know within the recipient organisation and its clients), TLP:AMBER+STRICT (recipient organisation only), TLP:GREEN (the community, not public channels) and TLP:CLEAR (no limit). In MISP, TLP is a taxonomy tag, not an access control. A TLP:RED event with distribution "All communities" will still sync, which is why the CIRCL sync documentation shows push and pull rules that block the tlp:red tag. Treat TLP as a statement of intent that you back with distribution settings and sync filters. See the Threat Intelligence Guide.

Defender use cases

Sector and national sharing communities: ISACs and national CERTs run a hub instance, members sync with it, and sharing groups carve out subsets such as a regional or supply chain group. Distribution levels let a member share broadly while keeping sensitive victim context local.
Feeding detection: export attributes with to_ids set to SIEM lookups, IDS rule formats, DNS blocklists and EDR watchlists through /attributes/restSearch. See the SIEM Guide and the Detection Engineering Guide.
Incident response context: during an investigation, search observables against MISP and cached feeds to see whether others have reported them, then publish your own event with sightings. See the Incident Response Guide.
Linking indicators to behaviour: attach ATT&CK galaxy clusters so hunters can move from a hash to the technique it supports. Short-lived indicators of compromise need behavioural context to stay useful. See the Indicators of Compromise vs Indicators of Attack Guide and the Threat Hunting Guide.
Open feed aggregation: load the default feed metadata, enable a curated subset, and cache feeds so that matching values show as feed hits on your events without importing every feed as events.

Feeds, warning lists and decaying models

Feature	What it does	Key settings
Feeds	Ingest MISP-format, freetext or CSV sources, remote or local	Cache (stored in Redis, gives feed hits without creating events) versus Fetch (imports into the database); overlap matrix shows duplicated feeds; site admin only
Warning lists	Flag known benign or misleading values: RFC 1918 ranges, public DNS resolvers, multicast, empty-value hashes, large cloud and search provider domains	Match types string, substring, hostname, CIDR and regex; by default only IDS-flagged attributes are checked (`MISP.warning_for_all` widens this); `enforceWarninglist` drops hits from restSearch exports
Decaying models	Score each attribute over time, starting from a base score derived from taxonomy tag values and their weights	Lifetime and decay speed per model; a new sighting resets the score to the base score; restSearch accepts `includeDecayScore`, `excludeDecayed`, `decayingModel` and `modelOverrides` (for example a threshold)

A sound detection export therefore looks like: published events only, to_ids true, enforceWarninglist true, excludeDecayed true, filtered by tags you trust.

Deployment and safe use

MISP can be run on premises, in the cloud or as a hosted service, and the project points to its download page for supported installation options and Debian packaging. Plan for the web application, its database, Redis (used by feed caching and background workers) and the background workers that perform push sync and other jobs. Monitor workers: when they die, push sync silently stops.

A phased rollout

Define the sharing model first: decide which communities you join, which sharing groups you need, your default distribution level for new events and how TLP maps to distribution. Write it down as policy before anyone publishes.
Build a test instance: install, enable HTTPS with an HTTP redirect, keep debug off, and run Admin securityAudit from the CLI. Turn on Security.otp_required for interactive users and Security.advanced_authkeys so keys are hashed and can expire.
Load feeds in cache mode: enable a small set of feeds, review the overlap matrix and false positive rate, then decide which to fetch.
Connect one sync partner: on the remote side, the partner creates a sync user in the organisation that represents you; you add the server at /servers/add, choose the correct remote organisation, validate the certificate, run the connection test, and start with pull only and filter rules that block tlp:red.
Pilot a detection export: point one SIEM lookup or blocklist at restSearch with the filters above, in alert-only mode, and record sightings for true and false positives.
Enable push and widen: once filters behave, enable push on publish, add partners and move exports to blocking where the false positive rate allows.
Rollback: unpublishing stops further sharing of an event but does not recall copies already synced, so a mistaken publication needs a message to partners and a deletion request. Exports can be rolled back by repointing the consumer to a previous known good list.

Securing the instance: API keys and sync accounts as machine identities

Every MISP integration is a non-human identity. API requests pass the key in the Authorization header (keys in URLs are no longer supported), and with advanced auth keys each key can carry a comment, an expiry date, an allowed IP list and a read-only flag, and is shown only once. A pushing sync key acts as the creator of the data it pushes, and a pulling key can retrieve organisation-only data belonging to its own organisation, so a leaked sync key exposes the community, not just one tool.

One key per integration: give the SIEM export, each connector and each sync partner its own user and key, named for the purpose, with read-only set wherever it only reads. See the API Key Management Guide.
Least privilege roles: MISP ships Admin, Org Admin, User, Publisher, Sync user and Read Only roles. Sync accounts need the Sync Actions permission and nothing more; Skip OTP Reqs should apply only to service accounts that genuinely cannot do OTP. See the Service Account Security Guide.
Expire and pin: set expiry dates, restrict keys to the consumer's IP range, and review the seen IP list MISP records against each key.
Store keys in a vault: never in PyMISP scripts committed to a repository (ATT&CK T1552.001 Credentials In Files). See the Secrets Management Guide.
Protect instance secrets: rotate Security.encryption_key with Admin reencrypt, and use the instance GnuPG key only for signing notifications.

Detection and hardening value

MISP supports NIST CSF 2.0 ID.RA-02 (threat intelligence received from information sharing forums) and DE.AE-07 (threat intelligence integrated into analysis), NIST SP 800-53 PM-16 Threat Awareness Program and PM-16(1) Automated Means for Sharing Threat Intelligence, and ISO/IEC 27001:2022 Annex A control 5.7 Threat intelligence.

Control area	MISP capability	Framework reference
Receive and share intelligence	Sync, feeds, sharing groups	CSF ID.RA-02; SP 800-53 PM-16, PM-16(1); ISO 27001 A.5.7
Act on advisories	Events from CERTs and ISACs, notification emails	SP 800-53 SI-5
Detection content	IDS-flagged exports to SIEM, IDS and EDR	CSF DE.AE-07; SP 800-53 SI-4
Protect the platform	Advanced auth keys, OTP, roles	SP 800-53 IA-5, AC-6
Audit	Audit and authentication failure logs	SP 800-53 AU-2
Protect sync in transit	TLS with certificate validation on server connections	SP 800-53 SC-8

What to monitor on the instance: failed authentication (MISP has brute-force protection and Security.log_each_individual_auth_fail), API use from IPs not pinned to a key, new keys created for sync or admin users, changes to server connections and sync rules, and sudden large pulls. A stolen key used from a new location is a Valid Accounts pattern (ATT&CK T1078). Forward MISP logs to your SIEM.

Metrics that show it is working:

Share of exported indicators with at least one sighting within 30 days.
False positive rate of MISP-sourced alerts, and the share removed by warning lists before export.
Median time from partner publication to the indicator being live in your SIEM or blocklist.
Events your organisation publishes or sights per quarter; communities decline when members only consume.
Percentage of API keys with an expiry date and IP restriction.

Common failure patterns

Relying on TLP tags alone: a TLP:RED tag on an "All communities" event still syncs. Back TLP with distribution and sync filters.
Wrong remote organisation on a server connection: CIRCL warns this causes oversharing or undersharing through sharing groups.
Exporting everything to blocking controls: without to_ids discipline, warning lists and decay, a shared resolver address or CDN range ends up blocked.
Shared, never-expiring keys: one admin key reused across scripts and partners, with no IP restriction.
Unwatched workers: push silently stops when background workers die; monitor them.

Alternatives

Option	Strength	When it fits
MISP	Peer to peer sharing with distribution levels, sharing groups and a large community	CERTs, ISACs and teams that exchange indicators with many partners
OpenCTI	STIX 2.1 knowledge graph for analysis of actors, campaigns and relationships	CTI teams producing finished analysis; often runs alongside MISP. See the OpenCTI Guide.
TAXII servers and clients	Standard transport for STIX collections	Consuming government or vendor STIX feeds directly. See the STIX and TAXII Guide.
Commercial threat intelligence platforms	Bundled premium feeds, support and scoring	Large programmes with budget and limited engineering time. See the Threat Intelligence Platform Buyer's Guide.
SIEM native threat intelligence	No extra platform to run	Small teams consuming a few feeds with no sharing obligations

Licensing: MISP core is AGPL-3.0-or-later, held jointly by contributors. Running it internally carries no fee; if you modify MISP and offer it to users over a network, for example as a community hub, plan to publish those modifications. PyMISP is BSD 2-Clause, and taxonomies and galaxies are CC0 or BSD 2-Clause.

Practitioner checklist

Publish a written sharing policy mapping TLP 2.0 labels to MISP distribution levels and sharing groups.
Set a conservative default distribution for new events and require analysts to choose deliberately.
Add push and pull filter rules that block tlp:red on every server connection.
Verify the remote organisation and certificate on each sync connection, and test before enabling push.
Export only published, to_ids attributes with enforceWarninglist and excludeDecayed set.
Enable Security.advanced_authkeys and Security.otp_required; give each integration its own expiring, IP restricted, read-only where possible key held in a vault.
Run Admin securityAudit after install and upgrades, and forward MISP logs to the SIEM.
Record sightings for true and false positives so decay scores and partners benefit.

MISP Threat Sharing Guide: Events, Attributes, Taxonomies and Sharing Groups