An indicator of compromise that travels inside a PDF or in the body of an email is not readable by any machine: you have to transcribe it by hand into an IDS (Intrusion Detection System) or a spreadsheet, with the copying errors that follow. MISP — Malware Information Sharing Platform — solves the problem by turning indicators into a queryable data structure that can be synchronised between organisations. Released as open source in 2013, the project comes from an internal tool called CyDefSIG (Cyber Defence Signatures), started in 2011 by Christophe Vandeplas at Belgian Defence, and is now developed and maintained mainly by CIRCL, the Computer Incident Response Centre of Luxembourg.

Context

Among European CERTs, indicators travel mostly over unstructured channels: email, text attachments, spreadsheets. Each team receives the same IP addresses, the same domains and the same hashes from different sources, and each re-enters them by hand into its own detection systems. At a malware analysis workshop in 2012, several groups found they had each analysed the same sample on their own: the same work redone in parallel, with nobody aware of what the others were doing.

The problem lies in the form of the data, before its volume. An MD5 hash written into a report is information for a person; the same hash in a typed field, with a timestamp, an attribution and an export flag, is something a system reads on its own, without anyone stepping in. MISP is what moves indicators from the first state to the second.

Architecture

MISP is a PHP web application built on CakePHP, with MySQL as its store. The data model turns on two entities.

An event represents an incident, a campaign or a piece of analysis: it carries a date, the originating organisation, a risk level and a distribution setting. To each event belong one or more attributes: the indicators themselves, typed by category (source or destination IP address, domain, file hash in MD5/SHA1, URL, email address, filename, registry key). Every attribute carries a flag saying whether it should be exported to a detection system — a distinction that keeps investigative context separate from the indicators you act on.

On top of this model MISP builds three mechanisms.

Correlation compares attributes across events automatically: if the same domain appears in two incidents uploaded by different organisations, MISP links them and flags it. An overlap comes out that would otherwise have stayed shut inside two separate silos.

IDS export generates the rules for Snort and Suricata from the network attributes marked as exportable. The platform also produces other formats ready to feed straight into the detection systems, network and host alike.

Synchronisation connects separate MISP instances: an organisation runs its own server and peers with those of the partners it trusts, pulling their events according to the distribution rules the source has set. There is no mandatory central repository; the topology is one the organisations draw between themselves.

Formats and interoperability

MISP imports and exports OpenIOC, the XML schema Mandiant published in 2011 to describe host indicators. On the exchange-standards side, STIX (Structured Threat Information Expression), curated by MITRE, released version 1.0 in April 2013 as a language for representing observables, indicators and threat context in a structured way; TAXII (Trusted Automated Exchange of Indicator Information), first drafted in 2012, defines the transport protocols for moving STIX content in hub-and-spoke or peer-to-peer models.

It helps to keep the roles separate. STIX describes what is shared, TAXII how it is carried, OpenIOC and MISP’s own format how an indicator is represented inside a particular platform. IODEF already exists too (RFC 5070, 2007), the IETF format for exchanging incident data between CSIRTs (Computer Security Incident Response Teams). None of these formats has yet won: they coexist, and an exchange platform is worth as many conversions as it can handle without losing semantics along the way.

The hard part

The hard part of sharing is trust, far more than the format. A shared IoC carries an implicit assertion — “this is malicious” — that the receiver cannot verify and might still act on by blocking traffic. A false positive propagated through automatic synchronisation becomes a disruption replicated across every downstream instance.

MISP handles this with per-event distribution levels (your organisation only, a community, onward-shareable, public) and with the Traffic Light Protocol, the convention introduced by Britain’s NISCC (National Infrastructure Security Co-ordination Centre) in the early 2000s and now a de facto standard among CSIRTs: four labels (red, amber, green, white) that declare how far a piece of information may be redistributed. These stay social conventions enforced by a technical tool, though: nothing stops a receiver from breaking TLP or propagating a wrong indicator. The platform lowers the friction of sharing; it does not replace the trust between the organisations that use it.

Limits

As of today MISP is a young tool, with a single full-time lead developer and adoption concentrated in the CERT community it came from — Belgian Defence, CIRCL, a few organisations that reached it through NATO. The data model holds atomic indicators well (IPs, domains, hashes) but is less expressive for complex relationships between entities, precisely the ground STIX 1.0 sets out to cover. Synchronisation asks organisations to agree on topology and distribution rules: an organisational investment the platform enables but does not resolve on its own.

The verifiable fact remains: an IoC that once travelled as text in an email becomes, once inside MISP, a typed record — correlated, exportable into a Suricata rule, and synchronisable to those entitled to see it. It is a small, concrete step, and exactly the step that was missing.

Cover image: Hex editor screenshot showing the dump of a Master Boot Record infected by the Stoned virus, with columns of hexadecimal bytes and… — screenshot by Ralf Roletschek, public domain — https://commons.wikimedia.org/wiki/File:Stoned-virus-hexacode.jpg