MISP/MISP: self-hosted threat intelligence sharing for analysts who need structured data, not another feed

What MISP actually solves for incident analysts

MISP is a platform for collecting, storing, distributing and sharing cyber security indicators and threats about incident analysis and malware analysis. The README frames the audience narrowly: incident analysts, security and ICT professionals, and malware reversers. That framing matters, because MISP is not a feed reader. It is a place where a team writes down what it knows in a structured data model, and then decides who else gets to see each piece of it.

The problem it addresses is distribution control. A threat intelligence team often has indicators it can share with a sector partner but not with a competitor, and indicators it can share with everyone. MISP models this with sharing groups and distribution levels that go down to the atomic attribute level. The README describes a flexible sharing group capability and granularity up to the atomic attribute level. That is the core design decision: sharing policy is a property of the data, not a separate export process.

The second problem is correlation. Indicators rarely arrive alone. MISP's correlation engine links matching attributes and handles patterns the README calls fuzzy hashing overlaps (e.g. ssdeep) and CIDR block matching. Correlations can be enabled or disabled at different levels of granularity, which is useful when a noisy correlation is worse than none.

The data model and correlation engine behind the sharing

MISP stores atomic data points, indicators and complex objects in what the README calls a fast database for selectors. Objects can be linked together to express threat intelligence, incidents or connected elements. On top of that sits a reporting system that lets analysts write Markdown reports with cross-references to the machine-readable components, so a narrative and its indicators live in the same event.

Data leaves MISP through export modules. The README lists native IDS formats, OpenIOC, plain text, CSV, MISP JSON, STIX versions 1 and 2 in XML and JSON, NIDS exports for Suricata, Snort and Bro/Zeek, RPZ zones, and cache formats for forensic tools. Import covers free-text, URL, bulk and batch import, plus MISP's own format, STIX 1.x/2.0, CSV and various proprietary formats. The Python dependencies in requirements.txt show the machinery underneath: misp-stix for STIX conversion, plyara for YARA parsing, pydeep2 for ssdeep hashing, python-magic for file type detection, and pymisp as the Python API client.

Everything stored is reachable through the UI or through a ReST API described as OpenAPI. That API is what makes MISP usable as a component rather than a destination: a SIEM, a NIDS or a custom script can pull events without a human clicking through a web interface. The workflow system adds automatic pipelines for data qualification, analysis, modification and publication control, which is the part that turns a shared database into something closer to an automated process.

Installing MISP and running a first event through the API

The README does not contain install commands. It has an Installation section that links onward, and the repository carries an INSTALL/ directory and a docs/ directory, plus debian/ packaging and a build-deb.sh script. The honest answer to how to install this is: read INSTALL/ and docs/, because the deployment paths differ and the README does not pick one for you.

What the repository does give you is the Python client, pymisp, pinned at 2.5.34.2 in requirements.txt. The PyMISP directory at the top level is that client's source. The dependency set is listed in requirements.txt:

jsonschema>=4.19.1
lief>=0.13.1
misp-stix>=2026.9.16
plyara>=2.1.1
pydeep2>=0.5.1
pymisp==2.5.34.2
python-magic>=0.4.27
pyzmq>=25.1.1
redis>=5.0.1
taxii2-client>=2.3.0

Those are the packages the Python side of MISP needs, including pymisp, the client the repository ships in the PyMISP directory. The API surface is documented as OpenAPI on the project site, so the client's methods track the endpoints rather than inventing their own vocabulary.

For the server side, the repository layout is the guide. There is a db_schema.json at the top level, a VERSION.json, and a debian/ directory for Debian packaging. Release v2.5.47 introduced what the release notes call a new database migration system with PostgreSQL support, so schema changes now have a migration path rather than a manual step.

Where MISP gets expensive: operations, not licence

The licence is AGPL-3.0, which is a copyleft licence with a network clause. If you modify MISP and let users interact with it over a network, the AGPL's terms reach that modified version. For most internal deployments that changes nothing, because you are not distributing anything. For a vendor embedding MISP in a hosted product, it is the first thing to read. This is not legal advice, and the LICENSE file plus the project's own guidance are the sources that matter.

The real cost is operational. MISP is a PHP application with a database, a Redis dependency, and a Python module ecosystem for enrichment and export. The README describes deployment on-premise, in the cloud, or as a SaaS solution, which is accurate but also means you own the deployment. There is no hosted tier run by the project. Someone has to keep the PHP runtime, the database and the misp-modules in step, and the recent release history shows why: v2.5.47 is described as a major security hardening round, and v2.4.221 exists as a security backport release for the older branch. That means two branches receive security fixes, and you have to know which one you are on.

A second cost is data quality. MISP will store whatever you feed it. Warning lists exist to limit false positives, but they are a mitigation, not a filter. An instance with loose import habits accumulates indicators that correlate with everything, and the correlation engine will faithfully show you those relationships. Curation is the workload, and the platform does not remove it.

MISP compared with OpenCTI, and the case for neither

OpenCTI is the comparison people search for, and the difference is architectural. MISP's centre of gravity is the event and the attribute: discrete indicators with sharing controls attached, exported to the tools that consume them. OpenCTI, by contrast, is built around a knowledge graph of entities and relationships, which suits teams that want to model actors, campaigns and infrastructure as first-class connected objects and query across them.

In practice the split shows up in what you do all day. If your work is receiving a malware sample report, extracting indicators, tagging them with a distribution level and pushing Suricata rules to a sensor, MISP's data model is closer to that workflow. If your work is mapping an intrusion set across campaigns and infrastructure over time, a graph-first tool fits better. The two are not mutually exclusive; the searches for MISP to MISP integration suggest people run more than one instance, and the ReST API is the reason that is feasible.

There is also a case for neither. If all you need is a list of malicious domains refreshed daily, a feed and a blocklist are sufficient. MISP's cost is justified by the sharing policy and the correlation, and neither is worth paying for if nobody is going to write events.

Release cadence, branches and what upgrading involves

The last push to the repository was on 2026-09-21, and the default branch is 2.5. The release history shows a 2.5 line and a 2.4 line maintained in parallel: v2.5.47 and v2.4.221 were both published on 2026-09-17, with 2.4.221 described as a security backport release. If you run 2.4, you are on a branch that receives security fixes rather than features, and the migration system introduced in 2.5.47 is not available to you.

Upgrade cost depends on how you deployed. The debian/ directory and build-deb.sh indicate a packaging path, which usually means the upgrade is a package operation plus a database migration. The new migration system with PostgreSQL support in v2.5.47 is the part to read the release notes for before upgrading a production instance, because that is where schema changes land. The README does not document rollback, so the safe assumption is that a downgrade is not a supported path and a database backup precedes any migration.

The Python side has its own pinning. pymisp is fixed at 2.5.34.2 and misp-stix at 2026.9.16 in requirements.txt. If you build automation on the client, those pins are what your code was tested against, and loosening them is a decision you make deliberately.

Editorial conclusion

Adopt MISP if you have analysts who need to describe incidents, malware and indicators in a shared data model and control distribution down to the attribute level; skip it if you only want a read-only feed of indicators, because the platform's value is in what you put into it. Before committing, verify how your organisation's sharing policy maps onto sharing groups and distribution levels, and check that the INSTALL and docs directories cover the deployment path you intend to use, since the README itself only points at them.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. MISP/MISP on GitHub
3. Project website
4. README
5. Releases