MISP und TheHive: Threat Intel und Case Management aus einer Hand

MISP und TheHive schließen die zwei Lücken, die fast jedes Blue Team hat, sobald es mehr als einen Analysten und mehr als ein Werkzeug gibt: Wo liegen unsere Indikatoren, und wo liegen unsere Fälle? Ohne Antwort auf die erste Frage lebt Threat Intelligence in Tabellen und Mailanhängen; ohne Antwort auf die zweite läuft die Vorfallbearbeitung im Chat, und niemand weiß bei der Schichtübergabe, was schon geprüft wurde. MISP ist die Plattform für Indikatoren und deren Austausch, TheHive die Plattform für Alarme, Fälle und Aufgaben, und beide sind dafür gebaut, zusammenzuarbeiten. Dieser Beitrag erklärt, was jedes der beiden tut, wie das Zusammenspiel abläuft, wie der Aufbau im Lab aussieht, wo die Grenzen liegen und für wen sich welches lohnt.

MISP: die Plattform für Threat Intelligence

MISP entstand 2011 im Umfeld des luxemburgischen CERT CIRCL und der belgischen Verteidigung, ist quelloffen und heute die verbreitete Plattform, über die CERTs, Branchenverbünde und Unternehmen Indikatoren austauschen. Die Grundeinheit ist das Ereignis: eine Kampagne, ein Vorfall, ein Bericht, mit Attributen wie IP-Adressen, Domains, Hashes, URLs, E-Mail-Absendern und Dateinamen, die zu Objekten wie einer Datei oder einer Netzwerkverbindung gruppiert werden. Tags und Taxonomien ordnen ein: TLP für die Weitergabe, Vertrauensstufe, Branche. Galaxien verknüpfen Ereignisse mit Angreifergruppen, Werkzeugen und ATT&CK-Techniken, sodass aus einer Liste von Indikatoren eine Beschreibung des Vorgehens wird.

Drei Funktionen machen MISP für das Blue Team wertvoll. Die Korrelation: Sobald ein Attribut in zwei Ereignissen auftaucht, zeigt MISP die Verbindung, und aus dem Phishing-Absender von gestern und der C2-Adresse einer Kampagne von letztem Monat wird ein Zusammenhang. Die Synchronisation: MISP-Instanzen tauschen Ereignisse untereinander aus, gesteuert über Freigabegruppen, sodass ein Unternehmen an einem Branchenverbund teilnimmt, ohne seine internen Ereignisse zu teilen. Und der Export: Indikatoren lassen sich in den Formaten ziehen, die Werkzeuge verstehen, als Suricata-Regeln, als Blocklisten für Firewall und DNS, als STIX für andere Plattformen, oder per API direkt in das SIEM. Sichtungen laufen zurück: Wenn ein Indikator im eigenen Netz gesehen wurde, weiß MISP das, und der Wert des Indikators steigt. Feeds von öffentlichen Quellen füllen die Instanz vom ersten Tag an; was davon brauchbar ist, hat der Beitrag zu Threat Intelligence beschrieben.

TheHive: Fallmanagement für Vorfälle

TheHive ist die Plattform, in der aus Alarmen Fälle werden. Alarme kommen aus dem SIEM, dem EDR, dem Mail-Gateway oder aus MISP-Ereignissen; ein Analyst prüft sie, verwirft sie oder macht sie zum Fall. Ein Fall hat Aufgaben mit Zuständigkeit und Status, Beobachtungen wie Adressen, Hashes und Dateien, eine Zeitlinie, Anhänge und eine Zuordnung zu ATT&CK-Techniken. Fallvorlagen bilden Playbooks ab: Ein Fall vom Typ Phishing bringt seine Aufgabenliste mit, und die Schichtübergabe besteht aus dem Blick auf den Fall statt aus einer Erzählung. Mehrere Organisationen können getrennt auf einer Instanz arbeiten, weshalb TheHive bei MSSPs und CERT-Verbünden verbreitet ist.

Neben TheHive steht Cortex, die Analyse- und Reaktionsmaschine: Analyzer reichern Beobachtungen automatisch an, etwa mit VirusTotal, AbuseIPDB, Passive DNS, Sandbox-Ergebnissen oder einer Abfrage in MISP, und Responder lösen Aktionen aus, etwa eine Adresse in der Firewall sperren oder ein Konto deaktivieren. Cortex ist vollständig quelloffen. Bei TheHive selbst ist der Lizenzstand wichtig: Seit Version 5 ist TheHive ein kommerzielles Produkt des Herstellers StrangeBee mit einer kostenlosen Community-Lizenz, die beantragt werden muss und im Funktionsumfang begrenzt ist; ohne gültige Lizenz fällt die Installation nach der Testphase in einen Nur-Lese-Modus. Wer eine vollständig quelloffene Alternative sucht, findet sie in DFIR-IRIS, das denselben Zweck mit einem kleineren Funktionsumfang erfüllt.

Das Zusammenspiel

1. Alarm. Das SIEM meldet eine Verbindung zu einer verdächtigen Domain. Der Alarm landet per Webhook oder API als Alarm in TheHive.
2. Anreicherung. Cortex fragt für die Domain automatisch MISP ab: Ist sie in einem Ereignis bekannt, zu welcher Kampagne gehört sie, welche Gruppe? Dazu externe Quellen wie Passive DNS und Reputation.
3. Fall. Der Analyst macht den Alarm zum Fall, die Vorlage bringt die Aufgaben mit, weitere Beobachtungen aus der Untersuchung kommen dazu und werden ebenfalls angereichert.
4. Reaktion. Ein Responder sperrt die Domain im DNS-Filter, ein anderer isoliert den Host über das EDR. Beides protokolliert im Fall.
5. Rückfluss. Die Beobachtungen, die sich als bösartig erwiesen haben, werden als Indikatoren markiert und aus dem Fall als MISP-Ereignis exportiert, mit TLP und Tags. Die eigene Instanz kennt sie ab jetzt, und wenn die Organisation an einem Verbund teilnimmt, kennen die anderen sie auch.
6. Verteilung. MISP exportiert die neuen Indikatoren als Blockliste an Firewall und DNS-Filter und als Abfrage ins SIEM, wo sie ab jetzt Alarme erzeugen. Der Kreis ist geschlossen.

Das ist die Schleife, die ein SOC ohne diese beiden Werkzeuge per Hand, per Tabelle oder gar nicht macht. Mit beiden ist sie nach dem ersten Fall Routine.

Aufbau im Lab

Beide Projekte liefern Docker-Compose-Dateien, mit denen eine Instanz in Minuten läuft; für das Homelab reicht eine Linux-VM mit 8 GB RAM für MISP und eine zweite für TheHive mit Cortex, weil TheHive mit seiner Datenbank und dem Index nicht genügsam ist. Die ersten Schritte in MISP: die öffentlichen Feeds aktivieren, ein eigenes Ereignis aus einem gemeldeten Phishing anlegen, Attribute taggen und die Korrelation beobachten. In TheHive: einen API-Schlüssel für das SIEM anlegen, die MISP-Verbindung für Import und Export einrichten, in Cortex den MISP-Analyzer und zwei kostenlose Anreicherungsquellen aktivieren, eine Fallvorlage für Phishing bauen. Dann einen Alarm aus Wazuh oder Security Onion hineinschicken und die Schleife einmal von Hand durchlaufen. Danach ist klar, welche Teile automatisiert werden sollen und welche der Analyst behalten will.

Grenzen

• Datenqualität in MISP. Feeds bringen Masse, nicht Wahrheit. Ohne Ablaufdaten, Sichtungen und eine Bewertung der Quellen wird MISP zur Sammlung veralteter Indikatoren, die im SIEM Fehlalarme erzeugen. Die Pflege ist Arbeit, und sie gehört jemandem.
• Lizenz bei TheHive. Die Community-Lizenz reicht für kleine Teams, aber Funktionen wie mehrere MISP-Verbindungen oder erweiterte Automatisierung sind bezahlpflichtig. Wer plant, prüft vorher, was die eigene Stufe kann, und rechnet die Lizenz gegen den Aufwand einer quelloffenen Alternative.
• Betrieb. Zwei Plattformen mit Datenbanken, Indizes, Updates und Backups. Die Dokumentation beider Projekte ist gut, aber jemand muss sie lesen und die Systeme pflegen.
• Kein vollständiges SOAR. Cortex-Responder decken die häufigen Aktionen ab. Komplexe Automatisierungen mit Verzweigungen und Freigaben brauchen ein eigenes Werkzeug oder Skripte um die APIs.
• Datenschutz beim Teilen. Ein Indikator kann personenbezogen sein, etwa eine E-Mail-Adresse. Freigabegruppen, TLP-Kennzeichnung und eine Regel, was die Organisation verlässt, gehören vor die erste Synchronisation.

Für wen sich was lohnt

Ein kleines Team mit einem SIEM und ohne Austausch nach außen braucht zuerst das Fallmanagement, weil dort die meiste Zeit verloren geht; MISP kommt, sobald Indikatoren aus mehr als einer Quelle verwaltet werden oder ein Branchenverbund Austausch anbietet. Ein Team, das an einem CERT-Verbund teilnimmt, braucht MISP zuerst, weil der Verbund darauf läuft. Ein MSSP oder ein Konzern mit mehreren Gesellschaften braucht beides und die Mandantenfähigkeit von TheHive. Und wer Wazuh betreibt, dem fehlt das Fallmanagement ohnehin; Security Onion bringt ein eigenes mit, das für den Netzwerkanteil reicht, aber nicht für eine Organisation mit mehreren Quellen.

Fazit

MISP und TheHive machen aus Threat Intelligence und Vorfallbearbeitung Prozesse mit Gedächtnis: Jeder Fall hinterlässt Indikatoren, jeder Indikator verbessert den nächsten Fall, und beides ist nachvollziehbar dokumentiert, statt in Chatverläufen zu verschwinden. Der Preis ist der Betrieb zweier Plattformen und bei TheHive die Lizenzfrage. Ein Blue Team, das den Incident-Response-Prozess mehr als ein paar Mal im Jahr durchläuft, holt diesen Preis mit dem ersten Vorfall herein, bei dem die Schichtübergabe aus einem Blick auf den Fall besteht.