Standing up MISP, and where OpenCTI fits
MISP is the open-source threat intelligence platform most teams reach for first: a place to collect indicators (IPs, domains, hashes, URLs), group them into events, and share them with partners in a structured way. This is a note on getting a MISP instance up with the official installer, and then on where OpenCTI fits once you have more than one feed to make sense of.
This was done on a Debian/Ubuntu host in 2020. The installer has moved on since, but the shape of the install, and the credential handling in particular, is the same.
Install MISP
The project maintains a single installer script. Read its options before you run it, because it can lay down the whole stack or just the core:
wget -O /tmp/INSTALL.sh https://raw.githubusercontent.com/MISP/MISP/2.4/INSTALL/INSTALL.sh
bash /tmp/INSTALL.sh
To install MISP core specifically, pass -c:
bash /tmp/INSTALL.sh -c
Handle the generated credentials properly
This is the part to pay attention to. When the installer finishes it prints, and writes to files, a set of secrets it generated for you:
- the database root and application (
misp) passwords - the API authkey for the application user
- the GnuPG passphrase used to sign events
- the default web login
Treat every one of those as a secret from the first second. The default web credentials are the documented placeholder admin@admin.test with password admin; log in and change them immediately, then set a real password for the account.
The installer also drops the generated passwords and the authkey into plain text files in the misp user's home directory and tells you so. Copy anything you need into your password manager, then destroy those files rather than deleting them normally:
shred -u /home/misp/mysql.txt /home/misp/MISP-authkey.txt
That authkey is the keys to the kingdom for the API: anyone holding it can read and write your intelligence. Rotate it from the web UI if it has ever been on screen or in a file you are not certain was shredded.
Outbound mail
MISP sends notifications, so it needs a way out for mail. Pointing postfix at a relay you control is the simplest:
sudo postconf -e 'relayhost = example.com'
sudo postfix reload
At that point you have a working MISP: create an organisation, start an event, add attributes, and (when you are ready) connect to a sharing community.
Where OpenCTI fits
MISP is excellent at events and indicators. What it does not give you is a connected picture: this malware family, used by that actor, seen in this campaign, against that sector. OpenCTI is built for exactly that. It is a knowledge graph on top of the STIX 2 data model, so the things in it are entities (threat actors, malware, intrusion sets, campaigns, indicators) with typed relationships between them.
The two are complementary, and the normal pattern is to run both:
- MISP is the collection and sharing layer. It is where indicators come in and go out, and where partner communities exchange events.
- OpenCTI is the analysis and correlation layer. It ingests from MISP and other sources and stitches everything into one graph you can pivot around.
OpenCTI brings data in through connectors, small services that pull from a source and translate it into STIX. There is a MISP connector that imports your events straight into the graph, and connectors for commercial and open feeds that do the same for their data. A couple of things are worth knowing before you lean on them:
- Each connector decides how a source's fields map onto STIX objects, and that mapping is where quality is won or lost. Spend time on it rather than trusting the defaults.
- Document-based imports (pulling indicators out of PDF reports, for example) tend to be pattern-matching under the hood and will quietly miss things, IPv6 addresses are a classic gap. Treat an automated PDF import as a first pass, not ground truth.
- Decide the priority order of your sources up front. When two feeds disagree about an indicator, the graph needs to know which one wins.
Start with MISP on its own. Add OpenCTI when you have enough sources that the question has shifted from "what indicators do I have" to "how do they relate to each other".