MISP vs. STIX — Cosive

The STIX graph model vs. the MISP event model

STIX GRAPH MODEL

STIX was created by an OASIS committee with the goal of making it easier to share cyber threat intelligence (CTI) between different systems. STIX was designed so that any software can add support for it, allowing it to easily exchange CTI with other tools that support STIX.

STIX covers everything from the nitty-gritty details like IP addresses and file hashes, to higher-level information like threat actor profiles, attack patterns (AKA tactics, techniques, and procedures or TTPs), and even big campaigns that involve multiple incidents across organisations. All these CTI pieces are linked together using a directed graph, which we'll get into a bit later.

Here’s a simple STIX graph that shows a campaign along with its targets, attack patterns, and indicator objects:

*Example of a STIX graph showing a campaign along with targets, attack patterns and indicator objects (source*).

MISP EVENT MODEL

MISP was originally designed with a focus on events to describe past incidents

With MISP, events are the core data object, and they can have many attributes. At first, MISP events were focused on observables like IP addresses and domain names, but over time, tagging and MISP Galaxies came into play, which let MISP describe more complex threat intelligence concepts like ATT&CK techniques and threat actor attribution. People still call them "MISP Events," but that term doesn't quite capture how they’re often used now.

Here’s what a MISP event looks like via the MISP UI:

*Sample MISP event showing observable attributes along with MISP Galaxies describing MITRE ATT&CK patterns.*

MISP can also produce graphs. These typically visualise correlation between attributes.

MISP may make a connection on the graph between the IP address on an Azure host, for example, but this may just reflect reuse by different threat actors and not a meaningful association. Meanwhile, STIX is more explicit about the relationships between different objects.

Philosophical differences: agnostic STIX VS. tool-centric MISP

A second big difference in philosophy when comparing MISP vs. STIX is how bound they are to particular software.

STIX was designed to be read by any piece of software which can create or receive threat intelligence; MISP’s data representation was primarily designed for use by the MISP system so is primarily bound to a singular piece of software (MISP).

That said, both STIX 2.1 and MISP’s data format are represented in JSON format and are accessible for custom parsing should you wish to write a processing script.

STIX’s agnostic attitude does sound very appealing, but can have challenges in practice.

Anything consuming STIX - say, any number of threat intelligence platforms (TIPs) or SIEMs - can have its own interpretation on how to store and represent STIX data in its own platform.

If it’s a systems log-focused SIEM, it may completely ignore higher-level threat intelligence in favour of observables it can search logs for.

Further, two TIPs which are nominally used for the same purpose of storing higher-level threat intelligence may have very different opinions on presentation.

This is not necessarily a weakness since it grants freedom to CTI producers and consumers on how to best represent concepts, but be aware that the receiver of your carefully structured STIX bundle may experience it in a very different way.

In contrast, two MISPs speaking MISP protocol get pretty much exactly the same representation of data on both sides, in spite of some limitations in the data format.

This means that sending a MISP event to another MISP user nearly guarantees they’re seeing CTI presented the same way as you are. The obvious downside to this is that you need to be running MISP, although there are many integrations with TIPs and SIEMs to enable ingesting MISP data with various results.

MISP events are similar to STIX “Incidents”

MISP’s “Events” are nominally closest to STIX’s “Incidents”, although not totally analogous. That’s because MISP uses events to store both intelligence relating to behaviour (e.g. “Black Widow group uses Powershell extensively”) alongside confirmed historical incidents (e.g. “the intrusion used a file of hash 5d41402abc4b2a76b9719d911017c592”), whereas the STIX standard differentiates between confirmed malicious activity (an “Incident”) and behaviour-based intelligence (attack patterns / TTPs).

This is particularly a challenge for MISP to STIX conversion, or for TIPs which ingest MISP events. A common solution is to convert all MISP events to STIX incident objects, but this results in STIX incident objects which inappropriately might reflect CTI reports or CVE notifications, not historical events or incidents.

Which one should I choose?

Your choice of whether to focus on the MISP or STIX ecosystem should in part be determined by the threat intelligence feeds that matter to your organisation, since some threat intel feeds are only available in a single format.

For example, if the threat intelligence feeds most relevant to your industry and geography are primarily available in MISP format, you may want to use a TIP like MISP. Likewise, if you’re offered STIX feeds over TAXII protocol by threat intelligence providers, this may make more sense.

Which format you primarily use will also be influenced by the software you have available to you. If you already have MISP the choice is obvious, whereas if you have a SIEM that speaks STIX 2.1 natively, like Azure Sentinel, STIX makes more sense.

It’s worth noting that MISP has support for at least a subset of STIX 2.1 and many other CTI tools have integrations with MISP. Converting between the two data models with no loss of fidelity is certainly challenging, but often good enough for many purposes and possible with open source software such as MISP-STIX. IOC translation can be relatively simple, while translating higher-level threat intelligence like attack patterns often proves more challenging.

If working with the MISP data format for feed ingestion and peer group sharing seems like the best fit for your organisation, we recommend CloudMISP, our managed MISP service.

If the STIX standard to perform threat graphing and modelling work is of more interest, perhaps a TIP like EclecticIQ is worth considering. That said, many organisations run both!

We hope this has given you some insight into how these two standards overlap and differ. There’s a lot more to say on both topics, and we’re always keen on a chat since we’ve done extensive work in this space.