När en ransomware-grupp slår till mot en svensk kommun eller ett industriföretag räknas varje timme. Ju snabbare ett SOC-team kan slå fast vilka IP-adresser, domäner och filhashar som hör till angreppet, desto snabbare går det att stoppa spridningen och varna andra organisationer. Det är precis det jobbet en threat intelligence-plattform gör, och just nu är MISP (Malware Information Sharing Platform) ett av de mest aktivt utvecklade open source-alternativen på marknaden. Den 10 september 2026 släppte projektet version 2.5.46, med säkerhetshärdning och prestandaförbättringar för stora incident response-miljöer. I den här guiden bygger vi en komplett MISP-installation från grunden: Docker-uppsättning, threat-intel-flöden, ditt första event med indikatorer, automatisering mot SIEM/EDR och skarpa säkerhetsinställningar för produktion.
Vad är MISP och varför nordiska SOC-team satsar på det 2026
MISP föddes hos CIRCL, Luxemburgs nationella CERT, som ett sätt för säkerhetsteam att dela indikatorer på kompromettering (IOC:er) strukturerat i stället för via lösa PDF-rapporter och mejltrådar. Plattformen har sedan dess vuxit till en av de mest spridda öppna lösningarna för hotinformationsdelning bland CERT:er, CSIRT:er och SOC-avdelningar globalt. Projektets huvudrepo på GitHub hade vid kontroll den 13 september 2026 exakt 6 525 stjärnor och 1 631 forkar, siffror som visar en aktiv community snarare än ett dött open source-projekt. Koden ligger under AGPLv3-licens, vilket betyder att du får använda och modifiera den fritt, även i kommersiell drift, så länge du delar tillbaka ändringar du distribuerar vidare.
Det som gör hösten 2026 till ett bra tillfälle att titta på MISP är utvecklingstakten. Mellan april och september i år har projektet skeppat tio versioner i 2.5.x-serien, från 2.5.37 den 29 april till 2.5.46 den 10 september. Under den perioden har MISP fått ett helt nytt event-mallsystem, en omarbetad dashboard med analytikerfokuserade widgetar (kodnamn Overmind), bättre STIX-interoperabilitet och stöd för schemalagd TAXII-push mellan instanser. Det är alltså inte samma MISP som för två år sedan, även om grundprincipen är oförändrad: händelser (events) med attribut som IP-adresser, hashar, domäner och e-postadresser, taggade och delade enligt en tydlig känslighetsnivå.
Under huven bygger MISP på en korrelationsmotor som automatiskt matchar nya attribut mot allt som redan finns lagrat i systemet. Lägger en analytiker in en ny domän kopplad till en pågående incident, flaggar MISP omedelbart om samma domän redan förekommer i ett annat event, oavsett hur gammalt det är eller vem som skapade det. Den funktionen, i kombination med det officiella Docker-projektet misp-docker (393 stjärnor på GitHub) och API-biblioteket PyMISP (489 stjärnor), är anledningen till att MISP i praktiken fungerar som ett organisatoriskt minne snarare än bara ett verktyg för det enskilda ärendet.
Till skillnad från ett SIEM-verktyg som Wazuh, som samlar in och korrelerar loggar från dina egna system, är MISP till för att samla, strukturera och dela kontext om hot: vilka IOC:er hör ihop med vilken kampanj, vem har sett dem tidigare och hur allvarligt hotet bedöms vara. Verktygen kompletterar varandra snarare än konkurrerar, och i den här guiden bygger vi grunden som sedan går att koppla mot ditt befintliga SOC-stack. Du hittar fler grundläggande resurser om hotbild och skydd på vår samlingssida om cybersäkerhet.
MISP:s roll i den nordiska hotbilden
Svenska myndigheter som MSB och CERT-SE arbetar löpande med att sprida information om pågående hot till svenska organisationer, ett arbete som i grunden bygger på samma princip som MISP är byggt för: strukturerad delning av indikatorer i stället för spridda varningar via e-post. På EU-nivå driver ENISA liknande initiativ för att koppla samman nationella CERT-funktioner. En egen MISP-instans gör det möjligt för ett svenskt SOC-team att både konsumera den typen av delad information och bidra tillbaka med egna observationer, i stället för att bara vara mottagare.
Det är också värt att nämna FIRST, den globala sammanslutningen av incident response-team, som sedan länge förespråkar strukturerad indikatordelning som en av grundpelarna i modernt incidentarbete. MISP är inte det enda verktyget som löser det problemet, men det är i dag ett av de mest utbredda öppna alternativen, vilket gör det till en rimlig utgångspunkt för team som saknar en delningsplattform sedan tidigare.
Förkunskaper och systemkrav
Du behöver inte vara Docker-expert för att följa den här guiden, men grundläggande kommandoradsvana i Linux är en förutsättning. Tabellen nedan listar versionerna vi testat mot, samtliga aktuella vid publiceringstillfället.
| Komponent | Testad version | Anteckning |
|---|---|---|
| Serveroperativsystem | Ubuntu 26.04 LTS (“Resolute Raccoon”) | Debian 12/13 fungerar också |
| Docker Engine | 29.8.0 | Officiellt installationsskript från Docker |
| Docker Compose | v5.5.1 (plugin) | Ingår i moderna Docker-installationer |
| MISP / misp-docker | 2.5.46 | Släppt 10 september 2026 |
| Python (för PyMISP-skript) | 3.14.7 | Används i automatiseringsexemplen |
| PyMISP | senaste version från PyPI | Officiellt API-bibliotek, underhålls av MISP-projektet |
| CPU / RAM (minimum) | 4 vCPU / 8 GB RAM | Räcker för test och mindre team |
| Diskutrymme | 50 GB SSD | Mer krävs om du aktiverar stora feeds |
Utöver detta behöver du ett domännamn med giltigt TLS-certifikat (Let’s Encrypt fungerar utmärkt, se vår Certbot-guide om du inte redan har det på plats), en e-postserver eller SMTP-relä för notiser, samt en dedikerad Linux-användare utan root-rättigheter som kör Docker-kommandona. Kör aldrig en produktionsinstans av MISP direkt exponerad mot internet utan reverse proxy och brandvägg framför, det återkommer vi till i härdningsavsnittet längre ner.
Steg 1–2: Installera Docker och Docker Compose
Första steget är att få en ren Docker-installation på plats. Logga in på servern via SSH och kör följande som din vanliga användare, inte root:
# Steg 1: Uppdatera systemet och installera beroenden
sudo apt-get update && sudo apt-get upgrade -y
sudo apt-get install -y ca-certificates curl gnupg
# Steg 2: Installera Docker Engine via det officiella skriptet
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
# Lägg din användare i docker-gruppen (kräver ny inloggning)
sudo usermod -aG docker $USER
newgrp docker
# Verifiera installationen
docker --version
docker compose versionOm docker compose version returnerar ett versionsnummer är du redo att fortsätta. Får du “permission denied” mot Docker-sockeln har du glömt lägga till din användare i docker-gruppen, eller så behöver du logga ut och in igen för att gruppmedlemskapet ska slå igenom.
Steg 3–4: Klona MISP-Docker och konfigurera miljön
MISP-projektet underhåller en officiell, produktionsanpassad Docker-uppsättning i repot misp-docker. Klona det och skapa en egen kopia av mallfilen för miljövariabler:
# Steg 3: Klona det officiella misp-docker-repot
git clone https://github.com/MISP/misp-docker.git
cd misp-docker
# Steg 4: Skapa din egen .env-fil utifrån mallen
cp template.env .env
nano .envFyll i minst dessa värden i .env innan du går vidare: BASE_URL (din fulla https-adress), MYSQL_PASSWORD och MYSQL_ROOT_PASSWORD (starka, unika lösenord), ADMIN_EMAIL och ADMIN_ORG för din organisation, samt ADMIN_PASSWORD för det första administratörskontot. Byt aldrig till skarpa lösenord senare, sätt dem rätt direkt eftersom vissa värden bara läses vid första uppstart av databasen.
Steg 5–7: Starta MISP, logga in och sätt upp organisationen
Med miljöfilen på plats kan du bygga och starta hela stacken. Docker Compose drar upp separata containrar för webbgränssnittet, MySQL-databasen, Redis och de moduler som hanterar berikning av indikatorer:
# Steg 5: Hämta senaste images och starta i bakgrunden
docker compose pull
docker compose up -d
# Följ loggarna tills webbgränssnittet svarar (kan ta några minuter)
docker compose logs -f misp-coreNär loggarna visar att webbservern är igång navigerar du till https://din-domän i webbläsaren. Logga in med det administratörskonto du satte i .env-filen och byt omedelbart lösenord om systemet ber om det, MISP tvingar fram ett byte vid första inloggning som en säkerhetsspärr. Nästa steg, steg 6, är att gå till Administration → Organisations och verifiera att din organisation är korrekt uppsatt som lokal (host org), inte extern. I steg 7 skapar du minst en extra användarroll utöver admin: en “Org Admin” som sköter det dagliga arbetet, och en vanlig analytikerroll utan rätt att ändra systeminställningar. Att låta alla analytiker dela ett gemensamt adminkonto är ett vanligt nybörjarmisstag som gör det omöjligt att spåra vem som gjort vad i efterhand.
Passa också på att gå igenom vilka roller som ska få rättigheten att publicera events externt (så kallad “publish”-rättighet), skilt från rättigheten att bara skapa och redigera events internt. I ett litet team kan det kännas onödigt att lägga tid på rollindelning redan från start, men det är betydligt enklare att sätta upp rätt struktur innan systemet fylls med skarpa incidenter än att försöka reda ut behörigheter i efterhand mitt under en pågående utredning.
Steg 8–9: Aktivera threat-intel-flöden och taxonomier
Ett tomt MISP är inte till mycket nytta. MISP levereras med ett bibliotek av färdiga feed-definitioner som du kan slå på under Sync Actions → List Feeds. Bland de vanligast aktiverade som standard finns CIRCL:s egna OSINT-flöden, botvrij.eu och flera av abuse.ch samlingar för skadlig infrastruktur. Aktivera bara feeds du faktiskt tänker konsumera, ett överfullt system med hundratals oanvända feeds blir tungrott och genererar brus i korrelationssökningar.
# Steg 8: Aktivera och cacha feeds via MISP:s inbyggda CLI-verktyg
docker compose exec misp-core \
/var/www/MISP/app/Console/cake Admin enableFeeds
docker compose exec misp-core \
/var/www/MISP/app/Console/cake Admin cacheFeeds allI steg 9 går du igenom Event Actions → Taxonomies och aktiverar de klassificeringssystem ditt team faktiskt använder, till exempel TLP (Traffic Light Protocol) för känslighetsmärkning och en incident-klassificering som passar er verksamhet. Taxonomier är det som gör att sökningar och rapporter blir konsekventa över tid i stället för att varje analytiker taggar events på sitt eget sätt.
TLP i praktiken: fyra nivåer som styr vem som får se vad
Traffic Light Protocol delar in information i fyra nivåer: RED (endast namngivna mottagare), AMBER (den egna organisationen och namngivna partner), GREEN (hela din delningsgrupp, men inte offentligt) och CLEAR (fri spridning). I MISP sätts nivån som en tagg på varje event eller attribut, och den bör alltid sättas av den som skapar informationen, inte antas i efterhand av mottagaren. Ett vanligt fel i unga SOC-team är att lämna allt på AMBER som standard utan att någonsin damma av GREEN, vilket i praktiken kväver den externa delning som är hela poängen med att ha en plattform som MISP.
Steg 10: Skapa ditt första event med IOC:er via PyMISP
Du kan skapa events manuellt i webbgränssnittet, men i praktiken vill de flesta SOC-team automatisera det direkt från sina egna verktyg. Här kommer PyMISP in, det officiella Python-biblioteket för MISP:s REST-API. Installera det med pip install pymisp och testa med ett litet skript:
from pymisp import PyMISP, MISPEvent
MISP_URL = "https://din-domän"
MISP_KEY = "din-api-nyckel-från-profilsidan"
misp = PyMISP(MISP_URL, MISP_KEY, ssl_verify=True)
event = MISPEvent()
event.info = "Ransomware-incident: misstänkt C2-trafik 2026-09-13"
event.distribution = 0 # Endast din organisation
event.threat_level_id = 2 # Medium
event.analysis = 1 # Ongoing
event.add_attribute("ip-dst", "203.0.113.42", comment="C2-server observerad i brandväggslogg")
event.add_attribute("domain", "malicious-example.test", comment="DNS-uppslag från infekterad klient")
event.add_attribute("sha256", "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b85")
result = misp.add_event(event)
print("Event skapat med ID:", result["Event"]["id"])API-nyckeln hittar du under din användarprofil i webbgränssnittet. Behandla den som ett lösenord: den ger fullständig åtkomst till allt din användare får göra, inklusive att publicera events externt om din roll tillåter det.
Steg 11–12: Event-mallar och Overmind-dashboarden för hunting
Version 2.5.37, som släpptes den 29 april 2026, introducerade ett helt nytt event-mallsystem som ersatte det gamla från grunden. I steg 11 bygger du en mall under Event Actions → Templates som fångar de fält ert team alltid vill fylla i vid en incident: drabbat system, initial vektor, TLP-nivå och vilken produkt eller kund som berörs. Med en standardiserad mall slipper analytiker uppfinna strukturen varje gång, vilket gör att äldre events faktiskt går att jämföra och söka i senare.
I steg 12 tar du dig an dashboarden, internt kodnamngiven Overmind. Gränssnittet har byggts ut stegvis genom 2026 års releaser och fick i version 2.5.39 (5 juni) en ny analytikerfokuserad startvy med anpassningsbara widgetar som visar senaste events, feed-aktivitet och korrelationsträffar. För hunting-arbete är det värt att lägga till en widget som filtrerar på taggen för pågående incidenter och sortera den högst upp, så att analytikern som loggar in mitt i ett skift direkt ser vad som är aktivt just nu i stället för att gräva fram det via sökfunktionen.
Koppla indikatorer till kända hotaktörer med MISP Galaxies
En funktion som ofta förbises av nya användare är Galaxies, MISP:s system för att koppla enskilda events till kluster som beskriver kända hotaktörer, skadeprogramsfamiljer och angreppsverktyg. I stället för att bara logga att ni sett en viss IP-adress kan ni tagga eventet med rätt Galaxy-kluster, till exempel ett namngivet ransomware-gäng, och därmed automatiskt dra nytta av all tidigare kunskap som redan finns kopplad till det klustret i systemet.
Många av de fördefinierade klustren är i sin tur mappade mot MITRE ATT&CK-ramverket, vilket gör det möjligt att gå från en enskild indikator till vilka taktiker och tekniker en aktör historiskt använt, rakt i samma gränssnitt. För ett SOC-team som utreder en misstänkt ransomware-incident innebär det att en analytiker snabbt kan se om liknande TTP:er (taktiker, tekniker och procedurer) tidigare observerats hos andra organisationer i samma delningsnätverk, i stället för att utreda varje incident som om den vore den första i sitt slag. Kom ihåg att hålla Galaxy-klustren uppdaterade tillsammans med resten av systemet, projektets knowledge-base-uppdateringar (bland annat i 2.5.46-releasen) innehåller regelbundet nya eller reviderade kluster.
Steg 13: Dela indikatorer via TAXII och synka mellan MISP-instanser
Ensam är inte stark när det gäller hotinformation. Versionerna 2.5.42 (22 juni 2026) och 2.5.43 (13 juli 2026) lade till stöd för collection-synkronisering mellan MISP-instanser i båda riktningarna, samt schemalagd push via TAXII, branschstandarden för utbyte av strukturerad hotinformation. Det gör det möjligt att automatiskt skicka utvalda, godkända IOC:er vidare till exempelvis en branschgemensam delningsgrupp eller en nationell CERT-funktion, utan manuell export varje gång.
# Registrera en TAXII-mottagare som sync-server under Sync Actions
# i webbgränssnittet, ange sedan vilka events som ska pushas:
# Exempel: filtrera events med taggen "tlp:green" för extern delning
# och schemalägg push var 30:e minut via cron-liknande syntax
# i formuläret "Scheduled TAXII Push" under Sync Actions.
# Kontrollera synkstatus från kommandoraden:
docker compose exec misp-core \
/var/www/MISP/app/Console/cake Server test [server_id]Sätt alltid distribution och TLP-nivå korrekt på varje attribut innan du kopplar in extern synkronisering. Ett vanligt och allvarligt misstag är att låta interna, känsliga IOC:er (till exempel interna IP-adresser eller information som pekar ut vilket system som drabbats) följa med i en push som är tänkt för extern delning.
Steg 14: Automatisera mot SIEM och EDR med API:et
Det sista praktiska steget är att koppla MISP mot resten av ert SOC-stack. Ett vanligt mönster är att låta ett schemalagt jobb hämta nya IOC:er som publicerats de senaste timmarna och skicka dem vidare till en brandvägg, EDR-lösning eller SIEM för automatisk blockering och matchning:
from pymisp import PyMISP
import requests
from datetime import datetime, timedelta
misp = PyMISP("https://din-domän", "din-api-nyckel", ssl_verify=True)
# Hämta indikatorer publicerade senaste timmen, taggade som bekräftat illvilliga
result = misp.search(
controller="attributes",
publish_timestamp="1h",
tags=["workflow:state=complete"],
type_attribute=["ip-dst", "domain", "sha256"],
)
siem_webhook = "https://din-siem.example.com/api/ioc-import"
for attribute in result.get("Attribute", []):
requests.post(siem_webhook, json={
"type": attribute["type"],
"value": attribute["value"],
"source": "MISP",
"imported_at": datetime.utcnow().isoformat(),
}, timeout=10)
print(f"Skickade {len(result.get('Attribute', []))} indikatorer till SIEM")Kör skriptet som ett cron-jobb var femte till tionde minut beroende på hur snabbt ni behöver reagera. Lägg alltid till en tidsgräns (timeout) på HTTP-anropen, ett tillfälligt nere SIEM-API ska aldrig kunna hänga hela automatiseringskedjan.
Steg 15: Säkerhetshärda din MISP-installation
MISP innehåller per definition känslig information om pågående incidenter, vilket gör plattformen till ett attraktivt mål i sig. Ett komprometterat MISP kan i värsta fall ge en angripare full insyn i exakt vilka indikatorer ett säkerhetsteam redan känner till, information som är minst lika värdefull för angriparen som för försvararen. Version 2.5.40 (11 juni 2026) beskrevs uttryckligen av projektet som en säkerhetsfokuserad release med fixar baserade på extern forskning, och 2.5.46 (10 september) fortsatte samma linje med en bredare säkerhetsgenomgång. Det säger något om hur seriöst projektet tar sin egen attackyta, och du bör göra detsamma i din drift.
- Placera alltid en reverse proxy med giltigt TLS-certifikat framför MISP, exponera aldrig standardporten direkt mot internet.
- Aktivera tvåfaktorsautentisering för samtliga konton med publiceringsrättigheter, se vår guide om TOTP-baserad tvåfaktorsautentisering för principerna bakom.
- Ta regelbundna, krypterade säkerhetskopior av både databasen och GnuPG-nycklarna som används för signerad e-postnotifiering, en förlorad nyckel går inte att återskapa.
- Begränsa vilka roller som får sätta distribution till “All communities”, en felaktig publicering kan läcka interna IOC:er till hela delningsnätverket.
- Håll dig löpande uppdaterad, med tio releaser på fem månader kräver MISP en betydligt tätare patchcykel än många andra interna verktyg.
- Övervaka MISP:s egna loggar i ert SIEM, precis som ni skulle göra med vilket annat internetvänt system som helst.
GDPR-hänsyn när du delar indikatorer
Ett ofta förbisett problem när svenska och nordiska organisationer börjar dela hotinformation är att indikatorer ibland innehåller personuppgifter. En e-postadress som använts i en phishing-kampanj, ett användarnamn i en läckt inloggningsuppgift eller en IP-adress kopplad till en specifik anställd kan alla räknas som personuppgifter enligt GDPR, beroende på sammanhang. Innan ni pushar en indikator externt via TAXII bör ni därför ha en tydlig rutin för att bedöma om attributet behöver maskeras, generaliseras eller helt uteslutas ur den externa delningen, även om samma data är fullt rimlig att behålla internt för den egna utredningen.
Praktiskt löser många team detta genom att alltid skapa två versioner av känsliga events, en fullständig intern version med distribution satt till den egna organisationen, och en sanerad version utan personuppgifter som är den enda som får TLP-nivå GREEN eller CLEAR och därmed blir kandidat för extern delning. Kopplar ni MISP till er NIS2-incidentplan är det här ett bra tillfälle att skriva in ansvarsfördelningen svart på vitt: vem som godkänner extern delning, och vem som har sista ordet om en indikator bedöms vara för känslig för att lämna organisationen.
MISP mot andra IR-verktyg: TheHive, Velociraptor och GRR
MISP löser inte hela incident response-flödet ensamt, och det är inte tänkt att göra det heller. Tabellen nedan visar hur det förhåller sig till tre andra vanliga open source-verktyg inom fältet, så att du kan avgöra vilka som behövs i just er stack.
| Verktyg | Huvudsyfte | Passar bäst för |
|---|---|---|
| MISP | Threat intelligence-plattform: lagra, korrelera och dela IOC:er | Hotinformationsdelning mellan team och organisationer |
| TheHive + Cortex | Ärendehantering (case management) för incidenter, med berikningsmoduler | Att strukturera och spåra själva utredningsarbetet dag för dag |
| Velociraptor | Endpoint-forensik och triage i realtid via VQL-frågor | Att snabbt samla bevis direkt från drabbade klienter |
| GRR Rapid Response | Fjärrforensik i stor skala för Windows, macOS och Linux | Utredningar som spänner över tusentals endpoints samtidigt |
I praktiken kombinerar många mogna SOC-team flera av dessa: MISP för delad hotinformation, TheHive för själva ärendet, och Velociraptor eller ett verktyg för minnesforensik som Volatility3 för att samla in bevis från drabbade maskiner. Ingen enskild plattform ersätter en genomtänkt incidenthanteringsplan, verktygen stödjer processen, de ersätter den inte. När en svensk kommun drabbas, som i fallet med Miljödata-attacken som berörde 200 kommuner, är det just den här typen av verktygskedja, tydlig process plus rätt teknisk plattform i varje steg, som avgör hur snabbt en organisation kan gå från upptäckt till kontrollerad situation.
När räcker MISP ensamt, och när behöver du fler verktyg?
Ett litet team med begränsad budget klarar sig ofta länge på enbart MISP kombinerat med manuella rutiner för själva ärendehanteringen, till exempel ett delat kalkylark eller en enkel ärendehanteringsmodul i ett befintligt verktyg. Behovet av TheHive, Velociraptor eller GRR växer i takt med antalet samtidiga incidenter och antalet analytiker som behöver arbeta parallellt i samma utredning. En tumregel är att så länge en person kan hålla reda på alla pågående ärenden i huvudet räcker MISP och enkla rutiner, men så fort flera analytiker arbetar på olika delar av samma incident blir en dedikerad ärendehanteringslösning värd investeringen.
Fem konkreta användningsfall för MISP i ett nordiskt SOC
Teori och installationssteg är en sak, men det är i det dagliga arbetet en threat intelligence-plattform bevisar sitt värde. Här är fem scenarier där en fungerande MISP-installation gör konkret skillnad för ett svenskt eller nordiskt säkerhetsteam.
- Ransomware-utbrott i en kommunal miljö. När en fil-server börjar kryptera dokument kan analytikern omedelbart slå upp om de observerade filhasharna eller C2-domänerna redan finns registrerade i MISP från tidigare liknande angrepp mot andra svenska organisationer, i stället för att starta utredningen från noll.
- Branschgemensam varning inom en sektor. Ett företag inom exempelvis tillverkningsindustrin som upptäcker en ny phishing-kampanj riktad mot sin bransch kan via TAXII-push varna andra organisationer i samma delningsgrupp inom minuter, i stället för att vänta på en sammanställd rapport dagen efter.
- Berikning av larm från EDR eller brandvägg. Genom API-integrationen kan ett larm om en misstänkt IP-adress automatiskt slås upp mot MISP:s korrelationsdatabas för att avgöra om samma adress redan är kopplad till en känd hotaktör eller kampanj.
- Standardiserad incidentrapportering internt. Med event-mallarna som kom i version 2.5.37 kan ett team säkerställa att varje ny incident dokumenteras med samma fält och samma struktur, vilket gör efterföljande analys och rapportering till ledningen betydligt enklare att sätta ihop.
- Uppföljning av tidigare kampanjer via Galaxies. När en ny indikator dyker upp går det snabbt att se om den hör till ett tidigare identifierat hotaktörskluster, vilket sparar tid jämfört med att manuellt googla efter kontext kring varje enskild IOC.
Vanliga fallgropar att undvika
De flesta MISP-installationer som fallerar gör det av samma återkommande skäl, och de flesta av dem har lite att göra med själva Docker-installationen och desto mer med hur teamet arbetar i systemet efteråt. Här är fem misstag värda att undvika redan från start.
- Att köra på standardlösenord längre än nödvändigt. Byt admin-lösenordet direkt vid första inloggning, lämna det aldrig kvar “tills senare”.
- Att aktivera alla feeds direkt. Ett system med hundratals oanvända feeds blir tungrott, drar onödig disk och gör korrelationsträffar svårare att tolka. Aktivera det du faktiskt använder aktivt.
- Att lita blint på extern feed-data utan validering. Feeds kan innehålla föråldrade eller felaktiga indikatorer. Automatisk blockering direkt från en feed utan mänsklig granskning riskerar att stänga ute legitim trafik.
- Att sätta fel distributionsnivå på känsliga attribut. Kontrollera alltid TLP och distribution innan publicering, särskilt om ni kopplat på TAXII-synkronisering mot externa parter.
- Att underdimensionera servern. MISP med flera aktiva feeds och en stor korrelationsdatabas kräver mer RAM än den minimigräns som räcker för en ren testinstallation, övervaka minnesanvändningen och skala upp i tid.
Felsökning: vanliga problem och lösningar
Stöter du på problem under installationen är chansen stor att någon annan redan löst exakt samma sak, MISP:s community är stor nog att de flesta driftfel redan finns dokumenterade i projektets GitHub-diskussioner. Innan du felsöker på djupet, kontrollera alltid att alla containrar faktiskt är igång med docker compose ps och att ingen av dem loopar i ett omstartsläge, det är den vanligaste bakomliggande orsaken till flera av problemen nedan. Tabellen täcker de vanligaste felen vid en Docker-baserad MISP-installation.
| Problem | Trolig orsak | Lösning |
|---|---|---|
| Containern startar men webbsidan svarar aldrig | Databasmigrering pågår fortfarande vid första uppstart | Vänta 3–5 minuter och följ docker compose logs -f misp-core innan du felsöker vidare |
| Vitt eller tomt 500-fel efter inloggning | Felaktiga behörigheter på volymer för uppladdade filer | Kontrollera ägarskap på de monterade Docker-volymerna och starta om stacken |
| API-nyckeln fungerar inte i PyMISP | Nyckeln har kopierats med extra blanksteg eller radbrytning | Generera en ny nyckel under användarprofilen och klistra in den utan formatering |
| E-postnotiser skickas aldrig | SMTP-inställningar saknas eller är felaktiga i .env | Testa SMTP-uppkopplingen separat med swaks eller motsvarande innan du felsöker i MISP |
| Feed-synkronisering misslyckas med SSL-fel | Servern saknar uppdaterade root-certifikat | Uppdatera ca-certificates-paketet i containern och bygg om |
| Hög minnesanvändning och långsamt gränssnitt | För många aktiva feeds i kombination med stor korrelationsdatabas | Inaktivera oanvända feeds och höj RAM-tilldelningen till containrarna |
| Synkronisering mot en annan MISP-instans nekas | Fel eller utgången sync-nyckel mellan de två servrarna | Regenerera sync-nyckeln på båda sidor och verifiera med cake Server test |
| GnuPG-relaterade fel vid signerad e-post | Ingen GPG-nyckel har genererats för instansen | Skapa en dedikerad GPG-nyckel för MISP och peka ut den i konfigurationen innan signerad utskick aktiveras |
Så ser det kompletta projektet ut
Sätter du ihop alla steg ovan får du en katalogstruktur och ett arbetsflöde som ser ut ungefär så här på en färdig, körbar installation:
misp-docker/
├── .env # Dina lösenord, BASE_URL och admin-uppgifter
├── docker-compose.yml # Definierar misp-core, db, redis och moduler
└── configs/ # Egna anpassningar av GnuPG och SMTP
misp-automation/
├── create_event.py # Steg 10: skapa events och attribut via PyMISP
├── siem_forwarder.py # Steg 14: cron-jobb som pushar IOC:er till SIEM
└── requirements.txt # pymisp, requestsDet fullständiga arbetsflödet går i tur och ordning: containrarna startas med docker compose up -d, admin loggar in och byter lösenord, feeds och taxonomier aktiveras, en organisationsstruktur med minst två roller sätts upp, och därefter tar automatiseringsskripten över det löpande arbetet. Nya IOC:er skapas antingen manuellt vid en pågående incident eller importeras från en aktiverad feed, korreleras automatiskt mot tidigare events, och kan sedan både pushas vidare via TAXII till externa mottagare och hämtas av siem_forwarder.py för blockering i er egen infrastruktur. Det är denna kedja, från rå indikator till åtgärd, som gör skillnaden mellan ett MISP som bara samlar damm och ett MISP som faktiskt förkortar tiden det tar att stoppa en pågående attack.
Avancerade tips och nästa steg
När grundinstallationen fungerar finns det flera sätt att ta driften vidare mot en mer produktionsanpassad uppsättning.
Bygg en synk-hierarki för flera kontor
För organisationer med flera dotterbolag eller kontor går det att bygga en synk-hierarki där en central MISP-instans agerar nav och lokala instanser pushar upp godkända IOC:er, snarare än att alla delar en enda gemensam databas. Det ger tydligare ägarskap per organisation samtidigt som central överblick bevaras, och det gör det möjligt för varje lokalkontor att hålla vissa events strikt lokala medan andra medvetet delas uppåt i hierarkin.
Skala för hög tillgänglighet
För hög tillgänglighet i produktion bör du lägga en lastbalanserare framför flera webb-noder som delar samma databas och Redis-instans, snarare än att köra allt på en enda server utan redundans. Det blir särskilt viktigt om MISP kopplas in i den automatiserade kedjan mot SIEM och brandvägg, eftersom ett stopp i MISP då indirekt kan bromsa hela er förmåga att blockera nya hot i realtid.
Koppla på SOAR och håll koll på warninglists
Många team kopplar MISP mot en SOAR-plattform för att automatisera hela kedjan från ny indikator till åtgärd, till exempel att en ny bekräftad C2-domän automatiskt triggar en blockeringsregel i brandväggen utan manuellt mellansteg. Håll samtidigt koll på MISP:s inbyggda “warninglists”, listor över kända falska positiva som CDN-adresser och vanliga DNS-resolvers, så att ni inte av misstag flaggar halva internet som skadligt när automatiseringen väl är på plats. Kombinerat med praxis från ramverk som OWASP för hur applikationer och API:er bör härdas ger det en betydligt stabilare grund att bygga vidare incidenthantering på.
Vanliga frågor
Är MISP gratis att använda för ett kommersiellt SOC-team?
Ja. MISP är öppen källkod under AGPLv3-licens och kostar inget i licensavgifter. Du behöver bara stå för egen drift, det vill säga server, lagring och personaltid.
Ersätter MISP ett SIEM-verktyg?
Nej. MISP hanterar delning och strukturering av hotinformation, medan ett SIEM som Wazuh samlar in och korrelerar loggar från era egna system. De flesta mogna SOC-team använder båda tillsammans.
Hur ofta släpper MISP-projektet nya versioner?
Mycket ofta jämfört med många andra säkerhetsverktyg. Mellan april och september 2026 skeppade projektet tio versioner i 2.5.x-serien, i snitt ungefär en release varannan till var tredje vecka.
Kan jag köra MISP utan Docker?
Ja, MISP kan installeras direkt på en Linux-server via ett skript eller manuellt, men Docker-varianten är i dag den väg projektet själva rekommenderar för de flesta nya installationer eftersom den är enklare att uppgradera och återskapa.
Vad är skillnaden mellan ett event och ett attribut i MISP?
Ett event motsvarar en incident eller kampanj i sin helhet, medan attribut är de enskilda indikatorerna inuti eventet, till exempel en IP-adress, en filhash eller en domän kopplad till samma incident.
Behöver jag PyMISP, eller räcker webbgränssnittet?
Webbgränssnittet räcker för manuellt arbete, men de flesta team som vill automatisera inhämtning eller vidarebefordran av IOC:er använder PyMISP eller REST-API:et direkt, som visat i stegen ovan.
Är det säkert att koppla MISP mot externa delningsnätverk?
Ja, om du sätter rätt distributions- och TLP-nivåer på varje attribut innan publicering. Risken ligger inte i TAXII-tekniken i sig, utan i att av misstag dela interna eller känsliga indikatorer som borde stannat inom organisationen. Gå igenom era publiceringsrutiner regelbundet och begränsa vilka roller som faktiskt får trycka på “publish” externt.
Hur stor server behöver jag för en produktionsinstans?
Minst 4 vCPU och 8 GB RAM för en mindre installation, men behovet växer snabbt med antalet aktiva feeds och storleken på korrelationsdatabasen. Övervaka minnesanvändningen och skala upp innan gränssnittet börjar bli trögt, snarare än efter att analytikerna redan börjat klaga på väntetider.
Kan flera team dela på samma MISP-instans utan att se varandras känsliga events?
Ja, det är precis vad distributionsnivåerna och organisationsstrukturen är byggda för. Genom att sätta rätt organisation och distribution på varje event kan flera avdelningar eller till och med flera separata bolag dela infrastruktur utan att automatiskt se varandras interna incidenter.
