TheHive: Bygg Incidenthantering i 12 Steg [2026]

Ett dataintrång upptäcks sällan av den som orsakar det. Det upptäcks av en analytiker som sitter med ett larm, en misstänkt IP-adress och tjugo flikar öppna samtidigt. Utan ett gemensamt system för att samla bevis, tilldela uppgifter och dela indikatorer med andra team blir varje utredning en enmansshow som är svår att återskapa senare. Det är precis det problemet TheHive löser. Plattformen är öppen källkod, byggd för SOC-team, CERT och CSIRT, och kopplar ihop fallhantering med automatisk berikning via Cortex och hotunderrättelser via MISP.

I den här guiden bygger vi en fullständig TheHive-installation från grunden: server, databas, Cortex-motor med analyzers, MISP-koppling och ett komplett triageflöde för din första incident. Du får 12 konkreta steg, sju kodblock att kopiera rakt av, tre datatabeller med aktuella siffror och en felsökningssektion med åtta vanliga problem. Räkna med cirka 90 minuter för hela installationen på en testserver.

Behovet är verkligt. Många säkerhetsteam hanterar fortfarande incidenter i en blandning av e-post, kalkylark och delade dokument, vilket fungerar tills två analytiker jobbar på samma spår utan att veta om varandra, eller tills en revisor frågar exakt när en observabel först dök upp i en utredning. Ett dedikerat verktyg löser inte problemet med för få analytiker, men det tar bort friktionen som gör varje enskild timme mindre effektiv. Den friktionen är precis det TheHive, Cortex och MISP tillsammans är byggda för att eliminera.

Vad är TheHive och varför behöver svenska SOC-team det 2026

TheHive beskrivs av utvecklarna själva som “a scalable, open source and free Security Incident Response Platform, tightly integrated with MISP (Malware Information Sharing Platform), designed to make life easier for SOCs, CSIRTs, CERTs and any information security practitioner dealing with security incidents that need to be investigated and acted upon swiftly”, enligt projektets officiella README på GitHub. Det säger en hel del om vem verktyget är byggt för: team som redan drunknar i larm och behöver en gemensam arbetsyta snarare än ett nytt Excel-ark per incident.

Arkitekturen består av tre delar som fungerar tillsammans men kan köras separat. TheHive själv hanterar fall (cases), uppgifter (tasks) och observabler (IP-adresser, hashvärden, domäner). Cortex är motorn som anropar analyzers, alltså moduler som slår upp en observabel mot VirusTotal, Shodan eller interna verktyg och returnerar en riskbedömning. MISP är plattformen där hotunderrättelser delas mellan organisationer, ofta mellan CERT:er i olika länder. Enligt projektets egen dokumentation är TheHive “the perfect companion to MISP”, och det är just den kopplingen som gör att en observabel du hittar i en svensk utredning kan matchas mot ett globalt IOC-flöde på sekunder.

Projektet drivs numera av företaget StrangeBee, som tog över underhållet efter att det ursprungliga TheHive-repot arkiverades i december 2025. Den aktiva utvecklingslinjen är version 5.6, med 5.6.6 släppt den 6 augusti 2026 och en parallell stödlinje 5.5.16 släppt den 30 juni 2026. Cortex och dess analyzer-bibliotek underhålls separat, med Cortex-Analyzers version 3.9.3 släppt den 20 augusti 2026. Det betyder att verktyget fortfarande får aktiva säkerhetsuppdateringar och nya funktioner, vilket är avgörande om du ska driftsätta det i produktion och inte bara i ett labb.

I det dagliga arbetet märks styrkan i detaljerna snarare än i en enskild flashig funktion. En analytiker öppnar en instrumentpanel med öppna fall sorterade efter allvarlighetsgrad, klickar sig in i ett fall och ser en tidslinje över varje observation, kommentar och statusändring. Taggar och taxonomier gör fallen sökbara på ett sätt ett vanligt ärendehanteringssystem inte klarar, eftersom varje observabel är strukturerad data snarare än fritext. Vill ledningen ha en kvartalsrapport över hur många phishing-incidenter som triagerats går det att exportera direkt ur samma data i stället för att någon manuellt räknar mejl i en delad brevlåda.

Bakgrunden till dagens ägarskap är värd att känna till innan du bygger en långsiktig plan runt verktyget. Det ursprungliga TheHive-repot på GitHub arkiverades i december 2025, ett steg som fick en del användare att oroa sig för projektets framtid. StrangeBee, bolaget grundat av flera av de ursprungliga TheHive-utvecklarna, driver i dag både vidareutvecklingen och en kommersiell supportmodell parallellt med den öppna kärnan. Cortex och Cortex-Analyzers underhålls fortsatt under TheHive-Project-organisationen på GitHub, med Cortex-huvudrepot runt 1,5 tusen stjärnor och Cortex-Analyzers runt 455 stjärnor, vilket ger en fingervisning om hur aktiv och etablerad communityn kring analyzer-biblioteket faktiskt är.

Förutsättningar: hårdvara, mjukvara och versioner

Innan du börjar behöver du en Linux-server (Ubuntu 24.04 LTS eller Debian 12 fungerar bäst), minst 8 GB RAM för ett testlabb och 16 GB om du planerar att köra Cortex med flera analyzers samtidigt. Elasticsearch är minneshungrigt, så snåla inte på RAM om du vill undvika krascher senare i guiden. Docker och Docker Compose är obligatoriska eftersom både TheHive-projektet och communityn kring det rekommenderar containerdrift för att slippa manuell hantering av Java-versioner och beroenden.

Komponent	Version i denna guide	Minsta hårdvarukrav
TheHive	5.6.6 (augusti 2026)	2 vCPU, 4 GB RAM
Cortex	Senaste 3.x-linjen från TheHive-Project	2 vCPU, 4 GB RAM
Cortex-Analyzers	3.9.3 (20 augusti 2026)	Delar Cortex-instansen
Elasticsearch	7.x (krävs av TheHive 5.x)	2 GB RAM minimum, 4 GB rekommenderat
MISP	Senaste stabila release	Egen server, 4 GB RAM
Docker Engine	Senaste stabila version	Ingår i serverkravet ovan
Java (för Cortex-analyzers)	OpenJDK 11 eller senare	Delar Cortex-instansen

Du behöver också ett domännamn eller en intern DNS-post om du vill nå TheHive över HTTPS, en MISP-instans att koppla mot (egen eller en delad community-instans), samt grundläggande kunskap i Docker Compose och YAML. Kör du redan en egen MISP-installation enligt vår tidigare guide kan du återanvända den servern direkt i steg 8 nedan.

Nätverksmässigt behöver du öppna port 9000 för TheHive och 9001 för Cortex mot de klienter som ska nå gränssnitten, gärna bakom en brandvägg som bara tillåter interna IP-intervall. Planerar du att köra allt i produktion från start, håll isär labbet och skarpa miljön redan nu, eftersom det är betydligt enklare att exportera konfiguration från ett fungerande labb än att städa upp en produktionsmiljö som växt fram organiskt. Grundläggande kunskap i Linux-administration räcker gott, du behöver inte vara Scala- eller Java-utvecklare för att driftsätta och underhålla plattformen.

Steg 1–2: Förbered servern och installera Docker-stacken

Börja med att uppdatera systemet och installera Docker Engine samt Docker Compose-pluginet. TheHive-projektets community-guider, bland annat SOC-labbdokumentationen som beskriver en TheHive 5.2-uppsättning med Cortex och MISP, rekommenderar att du drar samtliga images innan du startar stacken för att undvika timeout-fel under första uppstarten.

sudo apt update && sudo apt upgrade -y
sudo apt install -y ca-certificates curl gnupg apt-transport-https
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin
sudo usermod -aG docker $USER
mkdir -p ~/soc-lab && cd ~/soc-lab

Verifiera installationen med docker --version och docker compose version innan du går vidare. Om kommandona inte hittas, kontrollera att apt-källan för Docker faktiskt lades till korrekt i föregående steg, ett vanligt fel är att arkitekturvariabeln inte matchar servern om du kör på ARM i stället för x86.

Logga ut och in igen så att gruppmedlemskapet i docker-gruppen träder i kraft. Öka därefter gränsen för virtuellt minne på värden, vilket Elasticsearch kräver för att inte krascha vid start. Detta är ett av de vanligaste felen nya installationer stöter på, så hoppa inte över det.

sudo sysctl -w vm.max_map_count=262144
echo "vm.max_map_count=262144" | sudo tee -a /etc/sysctl.conf

Steg 3–4: Starta TheHive med Docker Compose och skapa din organisation

Skapa en docker-compose.yml som startar Elasticsearch och TheHive tillsammans. TheHive lagrar case-data i Elasticsearch och filer i ett lokalt eller S3-kompatibelt datalager, så håll koll på diskutrymmet om du planerar att importera stora mängder bilagor.

version: "3.7"
services:
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.17.24
    environment:
      - discovery.type=single-node
      - ES_JAVA_OPTS=-Xms2g -Xmx2g
      - xpack.security.enabled=false
    ulimits:
      memlock: { soft: -1, hard: -1 }
    volumes:
      - esdata:/usr/share/elasticsearch/data
    ports: ["9200:9200"]

  thehive:
    image: strangebee/thehive:5.6
    depends_on: [elasticsearch]
    ports: ["9000:9000"]
    volumes:
      - thehive_data:/opt/thp/thehive/files
      - thehive_index:/opt/thp/thehive/index
    command:
      - --es-hostname
      - elasticsearch
      - --cortex-keys
      - ""

volumes:
  esdata:
  thehive_data:
  thehive_index:

Starta stacken och vänta ett par minuter medan Elasticsearch initieras klart, annars kastar TheHive anslutningsfel vid start.

docker compose up -d
docker compose logs -f thehive

Öppna http://din-server:9000 i webbläsaren när loggarna visar att applikationen lyssnar. Standardinloggningen är [email protected] med lösenordet secret. Byt lösenordet omedelbart, gå därefter till Administration och skapa din organisation, till exempel “SOC-Sverige”. Under organisationen skapar du ett analytikerkonto med rollen “analyst” som du använder för det dagliga arbetet i stället för adminkontot.

Rollerna i TheHive styr vad ett konto får göra inom organisationen: en administratör hanterar användare och kopplingar, en analytiker skapar och arbetar med fall, medan en read-only-roll passar revisorer eller chefer som bara behöver följa läget utan att kunna ändra data. Skapa gärna en separat roll för externa konsulter redan nu, så slipper du bråttom-beslut om åtkomst mitt under en pågående kris.

Steg 5–6: Installera Cortex och aktivera analyzers för observabelberikning

Cortex körs som en egen tjänst med sin egen Elasticsearch-instans, eller delar en instans om du separerar index korrekt. Lägg till Cortex i samma compose-fil eller kör den som en fristående stack, beroende på hur du vill separera driften.

  cortex:
    image: thehiveproject/cortex:latest
    depends_on: [elasticsearch]
    ports: ["9001:9001"]
    environment:
      - job_directory=/tmp/cortex-jobs
    volumes:
      - cortex_jobs:/tmp/cortex-jobs
      - /var/run/docker.sock:/var/run/docker.sock

Efter uppstart går du till http://din-server:9001, skapar en superadmin och lägger till en organisation, precis som i TheHive. Därefter aktiverar du analyzers under Organization > Analyzers. Cortex-Analyzers-repot innehåller ett stort bibliotek av moduler, från VirusTotal och Shodan till interna Sandbox-lösningar, och nya analyzers publiceras löpande i changeloggen som senast uppdaterades den 20 augusti 2026 med version 3.9.3. Aktivera bara de analyzers du faktiskt har API-nycklar till, annars fyller du loggarna med onödiga felmeddelanden.

Analyzers grupperas grovt i tre kategorier. Reputationsanalyzers slår upp en observabel mot kända databaser för att se om den redan är flaggad som skadlig. Sandbox-analyzers kör en fil i en isolerad miljö och observerar dess beteende, vilket tar längre tid men ger djupare insikt. Geolokaliserings- och WHOIS-analyzers ger snabb kontext om varifrån en IP-adress eller domän härstammar. En rimlig startpunkt för de flesta svenska team är att aktivera två till tre reputationsanalyzers, en WHOIS-analyzer och en sandbox-lösning, och sedan bygga ut listan efter hand som behoven blir tydligare.

Skapa sedan en API-nyckel för din Cortex-organisation under Organization > API Keys. Den nyckeln är det som kopplar ihop Cortex med TheHive i nästa steg, så spara den säkert och dela den aldrig i klartext i chattkanaler eller tickets.

Steg 7: Koppla Cortex till TheHive

Med Cortex-nyckeln på plats redigerar du TheHive-konfigurationen så att applikationen känner till Cortex-instansen. Lägg till följande i application.conf, eller motsvarande miljövariabel om du kör allt i containrar.

cortex {
  servers = [
    {
      name = "CortexLocal"
      url = "http://cortex:9001"
      auth {
        type = "bearer"
        key = "DIN_CORTEX_API_NYCKEL"
      }
      wsConfig {}
    }
  ]
}

Starta om TheHive-containern och gå till Administration > Cortex i gränssnittet. Om anslutningen lyckas ser du en grön status och en lista över tillgängliga analyzers direkt i TheHives observabel-vy. Nu kan en analytiker högerklicka på en IP-adress i ett fall och köra en berikning utan att lämna gränssnittet, vilket är hela poängen med att koppla ihop de två plattformarna.

Steg 8: Anslut en MISP-server för hotunderrättelser

MISP-integrationen är enligt TheHives officiella dokumentation uppbyggd i flera lager: automatisk import av MISP-taxonomier vid installation, automatiska kopplingar som hämtar MISP-events som larm, manuell import av events som fall, och manuell export av fall tillbaka till MISP som events. Det är en tvåvägsrelation, inte bara en envägs flödeskälla.

Anslutningen konfigureras av en administratör med rättigheten managePlatform, under fliken Connectors i Platform Management. Du behöver MISP-serverns URL och en API-nyckel från ditt MISP-konto.

misp {
  servers = [
    {
      name = "MISP-Sverige"
      url = "https://misp.dinorganisation.se"
      auth {
        type = "key"
        key = "DIN_MISP_API_NYCKEL"
      }
      tags = ["misp:threatlevel=2"]
    }
  ]
}

Vill du koppla mot flera MISP-servrar samtidigt kräver det en betallicens från StrangeBee. Community-versionen klarar en aktiv MISP-koppling, vilket räcker för de flesta organisationer som delar underrättelser med en nationell CERT eller en branschspecifik ISAC.

Testa kopplingen genom att skapa ett testevent i MISP och kontrollera att det dyker upp som ett larm i TheHive inom loppet av en minut eller två, beroende på hur ofta pollningsintervallet är satt. Fungerar inte det direkt, dubbelkolla att MISP-serverns certifikat är giltigt (TheHive vägrar ofta ansluta mot självsignerade certifikat utan extra konfiguration) och att API-nyckeln har rätt behörighetsnivå på MISP-sidan.

Så fungerar TLP och PAP i praktiken

Två fält dyker upp överallt i TheHive och förtjänar en egen förklaring: TLP (Traffic Light Protocol) och PAP (Permissible Actions Protocol). TLP styr vem informationen får delas med, från TLP:RED som stannar hos de direkt inblandade till TLP:CLEAR som får spridas fritt. PAP styr i stället vilka åtgärder som får vidtas mot en observabel, exempelvis om ett IOC får matas in i ett externt verktyg för aktiv blockering eller bara användas passivt för övervakning. Skillnaden är viktig eftersom en observabel kan vara fritt delningsbar men samtidigt kräva försiktighet innan den används aktivt, till exempel om en blockering riskerar att avslöja för en angripare att denne är upptäckt.

I praktiken sätter analytikern TLP och PAP på varje observabel och varje fall, och TheHive respekterar dessa nivåer automatiskt vid export till MISP. Ett fall märkt TLP:AMBER exporteras bara till mottagare som är godkända för den nivån, vilket gör att svenska organisationer kan dela brett med sin sektors-CERT samtidigt som känsligare detaljer stannar internt. Bygg en tydlig intern policy för vilken nivå som gäller som standard innan ni sätter plattformen i drift, annars hamnar beslutet hos varje enskild analytiker och blir inkonsekvent över tid.

En konkret regel att sätta upp direkt: allt som rör interna system som standard märks TLP:AMBER tills en analytiker aktivt bedömer att det kan sänkas, snarare än tvärtom. Det är enklare att i efterhand bredda delningen av en indikator som visat sig ofarlig än att försöka dra tillbaka information som redan spridits för brett. Samma logik gäller PAP: sätt WHITE (fri användning) bara på observabler ni är helt säkra på, och låt allt annat starta på AMBER eller RED tills motsatsen är bevisad.

Steg 9–10: Skapa ditt första incident-case och bygg triagemallar

Nu är plattformen redo att användas. Skapa ett nytt fall via gränssnittet, eller använd API:et om du vill automatisera intaget från exempelvis en mejlbrevlåda eller ett SIEM-verktyg som Wazuh. Detta skiljer sig från att bara skriva anteckningar i ett delat dokument, för varje fält blir sökbart och kopplat till observabler, uppgifter och en tidslinje.

curl -X POST "http://din-server:9000/api/v1/case" \
  -H "Authorization: Bearer DIN_THEHIVE_API_NYCKEL" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Misstänkt phishing mot ekonomiavdelningen",
    "description": "Flera anställda rapporterade ett mejl med skadlig länk 2026-09-15.",
    "severity": 2,
    "tlp": 2,
    "pap": 2,
    "tags": ["phishing", "ekonomi", "2026-q3"]
  }'

Lägg till observabler i fallet, till exempel avsändaradress, länk-URL och eventuella filhashar från bilagan. Kör en Cortex-analys på varje observabel direkt från fallvyn för att snabbt se om domänen redan är flaggad som skadlig hos externa källor. Bygg sedan en case-mall (case template) för återkommande incidenttyper som phishing, ransomware-larm eller läckt autentiseringsuppgift. En mall sparar tid genom att fördefiniera uppgiftslistan, till exempel “isolera enhet”, “återställ lösenord” och “informera drabbad avdelning”, så att varje ny incident av samma typ startar med rätt checklista redan på plats.

Taxonomier importeras automatiskt från MISP vid installation och används för att standardisera hur analytiker klassificerar hot, allt från malware-familjer till attackens ursprung. Att alla i teamet använder samma taxonomi gör statistik och rapportering till ledningen mycket enklare efter några månaders drift.

Uppgiftshanteringen (tasks) i ett fall fungerar ungefär som en checklista, men med spårbarhet per person och tidsstämpel. Tilldela varje uppgift till en namngiven analytiker, sätt en förfallotid om åtgärden är tidskritisk, och använd kommentarsfältet för att dokumentera varför ett beslut togs, inte bara vad som gjordes. Sex månader senare, när en extern revisor eller en tillsynsmyndighet ber om underlag för hur en viss incident hanterades, är det den dokumentationen som avgör om svaret tar fem minuter eller en hel eftermiddag att ta fram.

Steg 11–12: Exportera IOC:er till MISP och härda plattformen för produktion

När en utredning är klar och du har bekräftade indikatorer på kompromettering, markera observablerna som “IOC” i fallet och exportera dem till MISP som ett nytt event. På så sätt bidrar din organisation tillbaka till samma delningsnätverk ni själva drar nytta av, vilket är särskilt värdefullt för svenska organisationer som delar underrättelser via nationella CERT-kanaler.

Innan du sätter plattformen i produktion, gå igenom denna härdningslista: aktivera TLS med ett giltigt certifikat framför TheHive och Cortex (en omvänd proxy som Nginx fungerar bra), tvinga multifaktorautentisering för samtliga analytikerkonton, begränsa API-nycklar till minsta möjliga behörighet, och sätt upp regelbunden säkerhetskopiering av Elasticsearch-index och filkatalogen. Kör dessutom Cortex-analyzers i isolerade containrar utan direkt internetåtkomst där det går, eftersom vissa analyzers exekverar kod mot potentiellt skadliga filer.

Slå även på granskningsloggar (audit log) för samtliga administrativa åtgärder, inklusive vem som ändrat en Cortex-koppling eller exporterat ett fall till MISP. Den loggen blir avgörande om ni någon gång behöver utreda en intern avvikelse, till exempel om en observabel raderats av misstag eller om en behörighet ändrats utan godkänd process.

Sätt även upp loggrotation och övervaka Docker-volymernas diskanvändning. Elasticsearch-index växer snabbt när fall ackumuleras över tid, och en full disk stoppar hela plattformen mitt i en pågående utredning, vilket är det sämsta tänkbara tillfället.

Eftersom TheHive är självhostad (self-hosted) bestämmer ni själva var data lagras, vilket är en fördel för organisationer som omfattas av dataskyddsförordningen och vill undvika att incidentdata, som ofta innehåller personuppgifter om anställda eller kunder, hamnar hos en molnleverantör utanför EU. Sätt en tydlig gallringspolicy för hur länge stängda fall sparas, dokumentera vilka personuppgiftskategorier som typiskt förekommer i ett fall (namn, e-postadresser, IP-adresser), och koppla ihop den policyn med er organisations dataskyddsombud innan plattformen fylls med skarp incidentdata.

TheHive vs Splunk SOAR vs Cortex XSOAR: vilken passar din organisation

De flesta team som utvärderar TheHive jämför det mot kommersiella SOAR-plattformar som Splunk SOAR och Palo Alto Networks Cortex XSOAR. Skillnaden handlar mindre om vem som är “bäst” och mer om vilken driftmodell och budget organisationen har. Splunk SOAR marknadsför sig med koppling till över 300 tredjepartsverktyg och stöd för fler än 2 800 automatiserade åtgärder, enligt Splunks egen produktsida. Splunk App for SOAR nådde version 8.7.0 den 2 september 2026, en release som Splunk knyter till sin bredare Enterprise Security-uppdatering. Cortex XSOAR från Palo Alto Networks underhåller parallellt flera produktlinjer, med 8.13 som senaste huvudversionen och en äldre 6.x-linje som fortfarande får säkerhetspatchar.

Prissättningen skiljer sig också radikalt mellan de tre. TheHive kostar inget i licensavgift så länge du klarar dig med community-funktionerna, vilket gör den totala kostnaden i praktiken en fråga om serverdrift och personaltid. Splunk SOAR och Cortex XSOAR prissätts i stället per användare eller per volym data, en modell som snabbt blir dyr när ett team växer från tre till femton analytiker. För en mindre svensk myndighet eller ett mellanstort företag kan den skillnaden avgöra om ett incident response-program över huvud taget får budget godkänd.

Cortex XSOAR har dessutom under 2026 fått flera säkerhetsrådgivningar publicerade av Palo Alto Networks, bland annat en sårbarhet i XSOAR-motorn som beskrevs som en path traversal-brist kopplad till en man-in-the-middle-attack mot Linux-baserade installationer. Det understryker en poäng som gäller oavsett vilken plattform ni väljer: en incident response-plattform är själv en del av er attackyta och måste patchas och övervakas med samma disciplin som ni förväntar er av resten av infrastrukturen.

Egenskap	TheHive	Splunk SOAR	Cortex XSOAR
Licensmodell	Öppen källkod (AGPL), betallicens för avancerade funktioner	Kommersiell, prenumeration	Kommersiell, prenumeration
Senaste version (2026)	TheHive 5.6.6, Cortex-Analyzers 3.9.3	Splunk App for SOAR 8.7.0	Cortex XSOAR 8.13
Kärnstyrka	Fallhantering kopplat direkt till MISP-baserad hotdelning	Bred integrationskatalog och automatisering i stor skala	Djup Palo Alto-ekosystemintegration
Driftansvar	Egen drift (self-hosted) eller partneravtal	Egen drift eller Splunk Cloud	Egen drift eller SaaS
Bäst för	Mindre till medelstora SOC, CERT och CSIRT med MISP-behov	Stora SOC med redan etablerad Splunk-miljö	Organisationer som redan kör Palo Alto-nätverksprodukter

Om er organisation redan investerat tungt i Splunk för loggning ger Splunk SOAR en naturlig utökning utan att byta ekosystem. Kör ni redan Palo Alto-brandväggar och vill ha djup automatisering mot dem passar Cortex XSOAR bättre. TheHive vinner däremot när budgeten är begränsad, när ni behöver full kontroll över var data lagras, eller när MISP-integration är en central del av ert arbetssätt, exempelvis inom en nationell CERT-struktur eller en bransch-ISAC.

Det finns också ett mellanläge värt att nämna: flera svenska MSSP:er kör TheHive internt för sina egna analytiker samtidigt som de erbjuder kunder en instrumentpanel byggd ovanpå samma data. Den modellen håller licenskostnaden nere för leverantören samtidigt som kunden får insyn i sina egna ärenden, ett upplägg som är svårare att replikera lika billigt med en licensbelagd SOAR-plattform där varje användarplats kostar extra.

Vanliga fallgropar när du sätter upp TheHive

De flesta problem nya team stöter på handlar inte om buggar i TheHive själv, utan om antaganden som visar sig fel först när plattformen redan är i drift. Här är de vanligaste vi sett upprepas i community-guider och driftsättningsrapporter.

Glömt vm.max_map_count. Elasticsearch kraschar tyst vid uppstart om värdet inte är satt till minst 262144, och felmeddelandet i loggen pekar sällan direkt på orsaken.
Fel Elasticsearch-version. TheHive 5.x kräver Elasticsearch 7.x. Kör du 8.x av misstag misslyckas indexeringen med kryptiska mappningsfel.
API-nycklar delade i klartext. Cortex- och MISP-nycklar hamnar ofta i Slack-meddelanden eller Git-repon av misstag. Rotera nycklarna regelbundet och lagra dem i en secrets manager.
För många analyzers aktiverade samtidigt. Aktiverar du analyzers utan giltiga API-nycklar fylls Cortex-jobblistan av felande jobb, vilket gör det svårt att se vilka analyser som faktiskt fungerar.
Ingen backup-rutin från start. Många team sätter upp TheHive, fyller det med ett halvårs incidentdata, och inser först då att ingen säkerhetskopiering av Elasticsearch-index finns konfigurerad.
Enda MISP-anslutning missas i planeringen. Community-licensen tillåter en aktiv MISP-server. Organisationer som planerar att koppla flera MISP-instanser måste budgetera för en betallicens redan i projektplaneringen.

Ett gemensamt drag hos nästan alla dessa fallgropar är att de går att undvika helt genom att testa flödet i ett labb innan skarp incidentdata börjar flöda in. Avsätt en vecka för ett sådant test innan ni sätter datum för produktionssättning.

Felsökning: vanliga problem och lösningar

Container-loggarna är alltid första anhalten vid problem. Kör docker compose logs -f för respektive tjänst innan du börjar felsöka mer djupgående, eftersom både TheHive och Cortex loggar tydliga felmeddelanden vid de flesta konfigurationsmisstag. Nedan är de nio problem vi stöter på oftast, med trolig orsak och en konkret åtgärd för varje.

Problem	Trolig orsak	Lösning
TheHive-containern startar om i loop	Elasticsearch inte redo eller fel vm.max_map_count	Sätt vm.max_map_count=262144 och vänta tills Elasticsearch svarar på port 9200 innan TheHive startas
“Connection refused” mot Cortex	Fel URL eller port i application.conf	Kontrollera att Cortex-tjänsten är nåbar från TheHive-containern med curl internt i nätverket
Analyzer-jobb fastnar i “InProgress”	Saknad eller ogiltig API-nyckel för analyzern	Verifiera nyckeln under Cortex > Organization > Analyzers och kör om jobbet
MISP-events importeras inte automatiskt	Fel behörighet eller inaktiv anslutning	Kontrollera att kontot har managePlatform-rättighet och att anslutningen visar grön status
Inloggning misslyckas efter lösenordsbyte	Cachead session i webbläsaren	Rensa cookies för TheHive-domänen eller testa i inkognitoläge
Elasticsearch tar slut på minne	ES_JAVA_OPTS satt för lågt i förhållande till dataset	Höj Xms/Xmx-värdena stegvis och övervaka med docker stats
Observabler dubbletteras i samma fall	Manuell import utan avstämning mot befintliga observabler	Använd TheHives inbyggda deduplicieringskontroll innan import av stora listor
Diskutrymmet tar slut plötsligt	Elasticsearch-index och bilagor växer okontrollerat	Sätt upp indexrotation och larm på diskanvändning innan produktionssättning
Export till MISP misslyckas tyst	TLP/PAP-nivån på fallet blockerar delning enligt policy	Kontrollera TLP-inställningen på fallet och justera enligt er delningspolicy innan export

Om ett problem inte täcks av listan ovan, sök i TheHive-projektets dokumentation och i Cortex-Analyzers changelog innan du öppnar en supportfråga, eftersom många kantfall redan är dokumenterade där tillsammans med en känd lösning. Spara även en enkel eskaleringsrutin internt: vem kontaktas om plattformen ligger nere mitt i en pågående utredning, och finns det en reservprocess (till exempel en delad mejlbrevlåda) som teamet kan falla tillbaka på under tiden.

Avancerade tips för skalning och automatisering

När teamet växer förbi ett par analytiker blir det värt att automatisera intaget av larm i stället för att skapa fall manuellt. Många team kopplar sitt SIEM-verktyg, till exempel en Wazuh-installation, direkt mot TheHives API så att högriskregler automatiskt skapar ett förifyllt larm i TheHive. Analytikern behöver då bara triagera och eskalera larmet till ett fall, i stället för att skriva in grunddata manuellt varje gång.

För organisationer med flera analytiker i olika tidszoner eller skift är rollbaserad åtkomst värt att konfigurera noggrant från start. Separera vem som får stänga fall, vem som får exportera till MISP och vem som bara får observera. Kör Cortex-analyzers som kräver filkörning, exempelvis sandbox-analys av bilagor, i en separat och nätverksisolerad Cortex-nod för att minska risken att en skadlig fil når resten av infrastrukturen.

Bygg också en enkel KPI-rapport ovanpå TheHives API för ledningsgruppen: antal öppna respektive stängda fall per vecka, genomsnittlig tid från upptäckt till stängning, och fördelning per incidenttyp. Den typen av statistik tar minuter att hämta ur TheHive men skulle ta timmar att sammanställa manuellt, och den ger ledningen konkret underlag för att motivera fler analytiker eller mer verktygsbudget nästa år.

Många team kopplar också TheHives webhooks mot en ChatOps-kanal i Slack eller Microsoft Teams, så att ett nytt fall med hög allvarlighetsgrad triggar ett meddelande direkt till jourhavande analytiker i stället för att bero på att någon råkar kolla instrumentpanelen. Kombinerat med en enkel bot som svarar på statuskommandon (“visa öppna fall”, “vem äger fall 482”) blir tröskeln för att interagera med plattformen ännu lägre, vilket i sin tur ökar chansen att hela teamet faktiskt använder den konsekvent i stället för att falla tillbaka på gamla vanor.

Slutligen: bygg in TheHive i er NIS2-relaterade incidenthanteringsprocess om organisationen omfattas av lagkravet. Vår tidigare guide om NIS2-incidentplaner beskriver tidsfristerna för anmälan, och TheHives tidsstämplade tidslinje per fall gör det enklare att visa myndigheter exakt när upptäckt, triage och åtgärd skedde.

Komplett exempelprojekt: från larm till stängt fall

Låt oss knyta ihop hela flödet med ett konkret scenario. En anställd rapporterar ett misstänkt mejl. Så här ser hela kedjan ut i en färdig TheHive-installation, från första larm till stängt fall med data delad tillbaka till hotunderrättelsenätverket.

Scenariot bygger vidare på allt vi konfigurerat i guiden: Cortex-anslutningen från steg 7 används för att berika observabeln, MISP-kopplingen från steg 8 används för export, och case-mallen från steg 9–10 avgör vilka uppgifter som automatiskt läggs till i fallet. Det är just den här sammankopplingen, inte någon enskild funktion, som gör att en fristående installation känns som en färdig plattform snarare än tre separata verktyg.

# 1. Skapa fallet via API från en intern rapporteringsbot
curl -X POST "http://din-server:9000/api/v1/case" \
  -H "Authorization: Bearer $THEHIVE_KEY" \
  -d '{"title":"Phishing-rapport HR","severity":2,"tlp":2,"tags":["phishing"]}'

# 2. Lägg till observabler (avsändare och länk)
curl -X POST "http://din-server:9000/api/v1/case/CASE_ID/observable" \
  -H "Authorization: Bearer $THEHIVE_KEY" \
  -d '{"dataType":"domain","data":["skadlig-domän.example"],"tlp":2}'

# 3. Kör Cortex-analys på observabeln (utförs i gränssnittet eller via /api/v1/connector/cortex/job)

# 4. Om domänen bekräftas skadlig: markera som IOC och exportera till MISP
curl -X POST "http://din-server:9000/api/v1/connector/misp/export/CASE_ID" \
  -H "Authorization: Bearer $THEHIVE_KEY"

# 5. Stäng fallet med sammanfattning och lärdomar
curl -X PATCH "http://din-server:9000/api/v1/case/CASE_ID" \
  -H "Authorization: Bearer $THEHIVE_KEY" \
  -d '{"status":"Resolved","summary":"Phishing blockerad innan klick, domän exporterad till MISP"}'

Resultatet är en fullständig, sökbar utredning där varje beslut, varje observabel och varje kommunikation ligger samlad. Sex månader senare, när en liknande domän dyker upp i en ny utredning, hittar Cortex matchningen direkt eftersom indikatorn redan finns registrerad, antingen lokalt eller via MISP-flödet.

Det här är också måttet på om installationen faktiskt lyckats: inte hur snyggt gränssnittet ser ut vid lansering, utan hur mycket snabbare den tredje, fjärde och femte liknande incidenten hanteras jämfört med den första. Ett team som sätter upp TheHive korrekt enligt stegen ovan bör se en märkbar minskning i triagetid redan efter de första månaderna, i takt med att både case-mallar och MISP-flödet fylls med verklig, relevant data från de egna utredningarna.

Vanliga frågor

Är TheHive gratis att använda?
Ja, kärnplattformen är öppen källkod under AGPL-licens. StrangeBee säljer support och betallicenser för avancerade funktioner som flera samtidiga MISP-anslutningar, men grundinstallationen kostar inget i licensavgifter.

Behöver jag MISP för att köra TheHive?
Nej, TheHive fungerar fristående för fallhantering. Men den stora fördelen, automatisk matchning mot delade hotindikatorer, uteblir helt utan en MISP-koppling.

Vilken TheHive-version bör jag installera 2026?
Den aktiva huvudlinjen är 5.6, med 5.6.6 som senaste release i augusti 2026. Den äldre 5.5-linjen får fortfarande säkerhetsuppdateringar (5.5.16 i juni 2026) men ny funktionalitet läggs bara till i 5.6.

Kan TheHive ersätta ett kommersiellt SOAR-verktyg helt?
För mindre och medelstora team, ja. Har ni redan stora investeringar i Splunk eller Palo Alto-produkter kan ett kommersiellt alternativ ge djupare inbyggda integrationer, men kostnaden och den externa driften väger tungt åt andra hållet.

Hur många analytiker klarar en enskild TheHive-installation?
Det finns ingen hård gräns i mjukvaran. Praktiskt sett skalar en instans med rimlig hårdvara (8–16 GB RAM) bekvämt för team på upp till tjugo till trettio analytiker innan man bör överväga att dela upp Elasticsearch-klustret.

Fungerar TheHive med NIS2-kraven på incidentrapportering?
TheHive är inget rapporteringsverktyg mot myndigheter i sig, men den tidsstämplade fallhistoriken hjälper er dokumentera upptäckt, åtgärd och tidslinjer, vilket är precis den typen av bevisning tillsynsmyndigheter efterfrågar vid en NIS2-anmälan.

Var hittar jag fler Cortex-analyzers?
Det officiella Cortex-Analyzers-repot på GitHub innehåller hela biblioteket och uppdateras löpande, senast till version 3.9.3 den 20 augusti 2026. Communityn bidrar också med egna analyzers utanför huvudrepot.

Kan jag köra TheHive utan Docker?
Ja, men det kräver manuell hantering av Java-version, Elasticsearch och systemtjänster. För de flesta installationer, särskilt i test- och labbmiljö, är Docker Compose enklare att underhålla och felsöka.

Kan jag migrera befintliga incidentärenden till TheHive från ett annat system?
Ja, via API:et. De flesta team skriver ett litet migreringsskript som läser ut ärenden från det gamla systemet (ofta ett kalkylark eller ett generiskt ärendehanteringsverktyg) och skapar motsvarande fall och observabler i TheHive via POST-anrop mot /api/v1/case. Räkna med att lägga mest tid på att städa och strukturera den gamla datan snarare än på själva importskriptet.

Vad kostar det att driva TheHive själv jämfört med att köpa en molntjänst?
Den direkta licenskostnaden är noll, men räkna med kostnad för serverdrift (egen hårdvara eller en molninstans), tid för underhåll och uppdateringar, samt eventuell supportlicens från StrangeBee om ni vill ha garanterad svarstid vid problem. För de flesta team som redan har viss Linux- och Docker-kompetens internt blir totalkostnaden ändå betydligt lägre än en motsvarande kommersiell SOAR-prenumeration.

TheHive: Bygg Incidenthantering i 12 Steg, 90 Min [2026]