Shuffle SOAR v2.3.0: Incidenthantering, 14 Steg [2026]

Säkerhetsteam i Norden drunknar i larm. En genomsnittlig SOC-analytiker hinner inte triagera alla notiser från SIEM, EDR och brandväggar manuellt, och varje minut en incident ligger obearbetad ökar risken att ett intrångsförsök blir en fullskalig attack. Lösningen många väljer är SOAR, Security Orchestration, Automation and Response, men de kommersiella plattformarna kostar ofta mer än ett säkerhetsteam har i hela sin verktygsbudget. Shuffle är ett öppen källkod-alternativ som gör samma jobb, och i den här guiden bygger du en fungerande installation från grunden.

Shuffle beskriver sig som en generell säkerhetsautomationsplattform byggd för och av säkerhetspersonal, och projektet drivs aktivt på GitHub med regelbundna releaser. Den senaste stabila versionen är v2.3.0, publicerad den 28 september 2026, och den lägger till stöd för AI-agenter i hybrid- och lokala miljöer, bättre triggerhantering och automatisk återstart av fastnade exekveringar. Du kommer att installera den versionen, bygga ditt första arbetsflöde och koppla ihop det med verkliga säkerhetsverktyg via API:er och webhooks.

Till skillnad från TheHive, som vi tidigare har gått igenom för ärendehantering, eller MISP för delning av hotunderrättelser, fokuserar Shuffle på att faktiskt agera på larm. Plattformen tar emot en händelse, kör den genom ett visuellt arbetsflöde, anropar externa API:er för att berika data, och returnerar ett beslut eller en åtgärd, allt utan att en analytiker behöver klicka sig igenom tio olika konsoler. Målet med den här guiden är att du vid slutet har en körande Shuffle-instans som automatiskt tar emot en webhook, slår upp en IP-adress mot ett hotunderrättelse-API och skapar en biljett om träffen är skadlig.

Vad är SOAR och varför behöver du det 2026

SOAR-begreppet myntades av Gartner för att beskriva verktyg som kombinerar tre saker: orkestrering av olika säkerhetssystem, automation av repetitiva uppgifter, och ett strukturerat svar på incidenter. Det strukturerade svaret är inte en nordisk uppfinning, men principerna bakom det finns beskrivna i NIST Cybersecurity Framework, som många svenska säkerhetschefer redan använder som referensram när de bygger sina egna incidentprocesser. Innan SOAR fanns gjorde analytiker allt manuellt: logga in i SIEM, kopiera en IP-adress, klistra in den i en hotunderrättelsetjänst, kopiera resultatet till en logg, öppna en biljett i ett ärendesystem. Samma rörelse, om och om igen, flera gånger per skift.

Det som sällan syns i säljmaterial för säkerhetsverktyg är hur mycket av en analytikers arbetsdag som går åt till just den typen av kopiera-klistra-logga-rörelse snarare än till faktisk hotjakt. SOAR flyttar den tiden från ren handpåläggning till att bygga och underhålla logiken en gång, och låta den köra sig själv tusen gånger om. Det är också varför intresset för öppen källkod-alternativ som Shuffle har vuxit parallellt med att NIS2-regelverket skärper kraven på hur snabbt svenska företag måste kunna upptäcka och rapportera incidenter.

Shuffle löser det genom att låta dig rita arbetsflödet en gång, i en visuell editor med noder du drar och kopplar ihop, och sedan låta plattformen köra det varje gång en ny händelse kommer in. Varje nod är en Docker-container som pratar med en extern tjänst via ett OpenAPI-baserat gränssnitt, vilket betyder att du inte skriver integrationskod för hand för varje verktyg du ansluter. Shuffles egen arkitekturdokumentation beskriver systemet som byggt kring containrar och mikrotjänster, med en komponent som heter Orborus som schemalägger exekveringar.

Det som gör Shuffle intressant för svenska och nordiska team är prismodellen. Plattformen är öppen källkod och gratis att självhosta, enligt både GitHub-repot och Shuffles AWS Marketplace-listning, där det uttryckligen står att mjukvaran inte har någon licenskostnad och att du bara betalar för din egen infrastruktur. Det skiljer sig från kommersiella konkurrenter som Tines och Torq, där prissättning sker per seat eller per automationskörning och sällan publiceras öppet. Shuffle erbjuder också en molnversion med egen prissättning, men den här guiden fokuserar på självhostad drift, eftersom det ger full kontroll över var känslig säkerhetsdata bearbetas, vilket är relevant givet GDPR och NIS2-kraven som redan gäller för tusentals svenska företag.

Förkunskaper och versioner du behöver

Innan du börjar, se till att du har följande på plats. Shuffle är byggt runt Docker, och enligt den officiella arkitekturdokumentationen är standardinstallationen en enda server som kör Docker Compose, vilket räcker gott och väl för labbmiljö, test eller ett mindre säkerhetsteam.

Komponent	Krav	Kommentar
Operativsystem	Linux (Ubuntu 22.04/24.04 rekommenderas)	Fungerar även på macOS för test, Windows via WSL2
Docker Engine	Senaste stabila versionen	Krävs för alla containrar och appar
Docker Compose	Plugin-versionen (docker compose, inte docker-compose)	Följer med moderna Docker-installationer
Shuffle	v2.3.0 (släppt 28 september 2026)	Senaste release på GitHub vid publicering
Diskutrymme	Minst 20 GB fritt	Containeravbilder och loggar växer snabbt
Nätverksåtkomst	Portarna 3001 och 5001 öppna lokalt	Frontend respektive backend-API
Behörighet	Root eller sudo, åtkomst till /var/run/docker.sock	Orborus behöver kunna starta containrar

Du behöver också ett konto hos minst en extern tjänst att integrera mot. I exemplen nedan används ett hotunderrättelse-API och ett ärendehanteringssystem som exempel, men principen gäller oavsett vilket verktyg du vill koppla in. Har du redan en Wazuh- eller Suricata-installation från tidigare guider på sajten, kan du återanvända den som händelsekälla till Shuffle.

Steg 1: Förbered servern och installera Docker

Börja med en ren server eller virtuell maskin. Uppdatera paketlistan och installera Docker enligt den officiella metoden, eftersom distributionernas inbyggda Docker-paket ofta ligger flera versioner bakom. Shuffle förlitar sig specifikt på funktioner i Docker Compose för att starta hela stacken, så en gammal Compose-version ger ofta kryptiska felmeddelanden snarare än ett tydligt “fel version”.

sudo apt-get update && sudo apt-get upgrade -y
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
sudo usermod -aG docker $USER
newgrp docker
docker --version
docker compose version

Kontrollera att båda kommandona svarar med ett versionsnummer innan du går vidare. Om docker compose version inte hittas, installera compose-pluginet separat med sudo apt-get install docker-compose-plugin. Ett vanligt misstag här är att köra installationen som root men sedan försöka starta Shuffle som en vanlig användare utan att den användaren är medlem i docker-gruppen, vilket ger ett permission denied-fel på docker.sock längre fram.

Steg 2: Hämta Shuffle från GitHub

Klona det officiella repot. Undvik att ladda ner zip-filer från tredjepartssidor, eftersom projektet uppdateras ofta och forks kan ligga långt efter huvudgrenen.

git clone https://github.com/Shuffle/Shuffle.git
cd Shuffle
git checkout v2.3.0
ls -la

Du bör se filer som docker-compose.yml, en .env-mall och mappar för backend, frontend och shuffle-apps. Om du vill följa den absolut senaste koden i stället för en fast release kan du hoppa över git checkout-raden, men för en reproducerbar produktionsmiljö rekommenderas att alltid låsa till en taggad version.

Steg 3: Konfigurera miljövariabler

Kopiera miljömallen och fyll i de värden som styr hur Shuffle exponeras och vilka hemligheter den använder internt.

cp .env.example .env
nano .env

# Viktiga värden att sätta:
# SHUFFLE_FRONTEND_PORT=3001
# SHUFFLE_BACKEND_PORT=5001
# SHUFFLE_HOSTNAME=din-servers-ip-eller-domän
# SHUFFLE_APP_SDK_TIMEOUT=300
# BASE_URL=http://din-servers-ip-eller-domän:5001

Sätt alltid ett eget, slumpmässigt lösenord för eventuella databasfält i stället för exempelvärdena som ligger i mallen. Ett av de vanligaste säkerhetsfelen i självhostade SOAR-installationer är att lämna standardlösenord kvar, vilket gör hela orkestreringslagret till en enkel måltavla om servern exponeras mot internet av misstag.

Steg 4: Starta Shuffle med Docker Compose

Nu startar du hela stacken. Första uppstarten tar längre tid eftersom Docker laddar ner samtliga avbilder för backend, frontend, databas och Orborus.

docker compose up -d
docker compose ps
docker compose logs -f shuffle-backend

Vänta tills loggen visar att backend-tjänsten lyssnar och att databasen är ansluten. Om en container går in i en omstartsloop, kontrollera först att portarna 3001 och 5001 inte redan används av en annan tjänst med sudo ss -tulpn | grep -E '3001|5001'. Navigera sedan till http://din-server:3001 i webbläsaren och skapa ditt administratörskonto vid första inloggningen.

Steg 5: Utforska gränssnittet och apputbudet

Efter inloggning möts du av tre huvudvyer: Workflows, Apps och Admin. Apps-fliken listar de integrationer som följer med Shuffle, byggda på OpenAPI-definitioner, och täcker kategorier som SIEM, EDR, brandväggar, molnplattformar och ärendehanteringssystem enligt Shuffles egen produktbeskrivning på AWS Marketplace. Varje app är i grunden en liten Docker-container som paketerar logiken för att prata med ett specifikt API, vilket betyder att du kan bygga din egen app om något system saknas i katalogen.

Admin-vyn ger dig översikt över exekveringar, miljöer och organisationer (vad dokumentationen numera kallar “tenants” i stället för tidigare “organizations”). Här ser du också om Orborus-processen, som faktiskt schemalägger och kör själva arbetsflödena, rapporterar att den är aktiv. Lägg märke till statusindikatorn i det nedre hörnet, den är det snabbaste sättet att upptäcka om en container har kraschat utan att du behöver gå in i terminalen.

Steg 6: Bygg ditt första arbetsflöde

Klicka på “New Workflow” och ge det ett namn, exempelvis “IP-berikning och biljett”. Dra in en Webhook-trigger som startnod, den tar emot inkommande data från en extern källa, till exempel ditt SIEM eller en brandväggslogg som skickar ett larm.

Kedjan du bygger ser ut så här konceptuellt:

Webhook (tar emot larm med IP-adress)
   -> Berikningsnod (slår upp IP mot hotunderrättelse-API)
      -> Villkorsnod (om riskpoäng > tröskelvärde)
         -> Skapa biljett (i ärendehanteringssystem)
         -> Skicka notis (Slack/e-post)
      -> annars: logga och avsluta tyst

Dra en linje från webhooken till nästa nod för att koppla dem. Varje nod har ett konfigurationspanel till höger där du mappar fält från föregående nods utdata, till exempel att hämta $webhook.ip_address och skicka det som indata till berikningsappen.

Steg 7: Konfigurera webhook-triggern

Klicka på webhook-noden och kopiera den unika URL:en Shuffle genererar. Den ser ut ungefär som nedan, och du använder den som mål när du konfigurerar ditt SIEM eller en annan källa att skicka larm till Shuffle.

curl -X POST "https://din-server:5001/api/v1/hooks/webhook_abc123" \
  -H "Content-Type: application/json" \
  -d '{
    "ip_address": "198.51.100.42",
    "source": "firewall-01",
    "severity": "medium",
    "timestamp": "2026-10-01T09:14:00Z"
  }'

Testa webhooken direkt från terminalen med curl-kommandot ovan innan du kopplar in ett riktigt system. Då ser du omedelbart i Shuffles exekveringslogg om datan kommer fram i rätt format, utan att behöva felsöka mot en extern integration samtidigt som du felsöker arbetsflödet självt.

Steg 8: Lägg till en berikningsnod med externt API

Sök i Apps-katalogen efter en hotunderrättelsetjänst, dra in den som nästa nod efter webhooken, och autentisera med din API-nyckel under organisationens autentiseringsinställningar, inte hårdkodad i arbetsflödet. Shuffle lagrar autentiseringsuppgifter separat så att du kan återanvända samma nyckel i flera arbetsflöden utan att klistra in den på nytt varje gång.

Mappa sedan indatafältet för berikningsappen till webhookens IP-fält. Ett körningsexempel, där du inspekterar utdata i exekveringsloggen, kan se ut så här:

{
  "execution_id": "7f3a9c21-88b1-4e2a-9c4d-11a2f3b9d001",
  "status": "FINISHED",
  "results": [
    {
      "action": "ip_lookup",
      "app": "threatintel",
      "result": {
        "ip": "198.51.100.42",
        "risk_score": 87,
        "categories": ["botnet", "scanning"],
        "last_seen": "2026-09-29"
      }
    }
  ]
}

En riskpoäng på 87 av 100 är exakt den typ av signal du vill agera på automatiskt, snarare än att låta den ligga i en kö tills en analytiker har tid. Spara arbetsflödet och kör en testexekvering innan du går vidare till nästa nod.

Steg 9: Bygg villkorslogik för automatiska beslut

Dra in en villkorsnod (Condition) efter berikningssteget. Här definierar du regeln som styr om arbetsflödet ska eskalera eller avsluta tyst. Ett vanligt mönster är att jämföra riskpoängen mot ett tröskelvärde, till exempel “om risk_score är större än 70, fortsätt till eskalering”.

# Villkorslogik i Shuffles condition-nod (pseudokod för fältmappning)
IF $threatintel.result.risk_score > 70
  THEN gå till nod "Skapa_biljett"
  ELSE gå till nod "Logga_tyst"

Testa med flera olika indata, både ett lågt och ett högt riskvärde, för att säkerställa att båda grenarna fungerar som tänkt. Ett klassiskt fel är att bara testa happy path, det vill säga den gren som leder till eskalering, och aldrig verifiera att lågriskfall verkligen avslutas tyst i stället för att skapa onödiga biljetter.

Steg 10: Koppla in ärendehantering och notifiering

I eskaleringsgrenen lägger du till en nod som skapar ett ärende i ditt ärendehanteringssystem, till exempel samma typ av case management som TheHive erbjuder, eller ett ticketingsystem ditt team redan använder. Mappa in riskpoängen, IP-adressen och källan från tidigare noder som fält i det nya ärendet, så att analytikern som tar över inte behöver gräva i loggar för att förstå kontexten.

Lägg därefter till en notifieringsnod, exempelvis Slack eller e-post, som meddelar jourhavande analytiker direkt. Hela poängen med SOAR är att korta ner tiden mellan larm och mänsklig handläggning för de fall som verkligen behöver det, samtidigt som de triviala fallen hanteras utan att någon människa behöver bry sig.

Steg 11: Schemalägg och aktivera arbetsflödet

Utöver webhooks stödjer Shuffle schemalagda körningar, vilket är användbart för arbetsflöden som inte triggas av en händelse utan ska köras periodiskt, till exempel en daglig genomgång av nya CVE:er mot din tillgångsdatabas. Gå till arbetsflödets inställningar och välj “Schedule” i stället för eller som komplement till webhook-triggern.

# Exempel på cron-uttryck för schemalagd körning i Shuffle
0 */6 * * *   # Kör var 6:e timme
0 8 * * 1-5   # Kör klockan 08:00 måndag till fredag

Slå på arbetsflödet med den gröna “Activate”-knappen uppe till höger. Ett arbetsflöde som bara är sparat men inte aktiverat tar aldrig emot verklig trafik, vilket är en vanlig anledning till att team tror att en integration är trasig när den i själva verket bara aldrig startades.

Steg 12: Använd AI-agenter för komplexa beslut

Version 2.3.0 av Shuffle utökar stödet för AI-agenter till att även fungera i lokala och hybrida miljöer, inte bara i molnversionen. Enligt release-anteckningarna på GitHub kan agenter nu återhämta sig från sena svar, välja rätt backend-adress automatiskt och använda antingen lokala AI-autentiseringsuppgifter eller synkade molnuppgifter på självhostade installationer. Det betyder att du kan låta en agent-nod läsa berikningsdata och avgöra nästa steg med naturligt språk som regelverk, i stället för att hårdkoda varje villkor manuellt.

Samma version förbättrar matchningen mellan agent-anrop och faktiska verktygsnamn i dina arbetsflöden, så att en agent som instrueras att “slå upp indikatorn” hittar rätt app automatiskt även om namnet inte är identiskt. Var medveten om att agent-noder kör mot en extern AI-leverantör om du inte har konfigurerat en helt lokal modell, vilket har konsekvenser för var känslig data skickas, särskilt relevant under GDPR.

Steg 13: Skala till Docker Swarm för produktion

Enserver-installationen du byggt i tidigare steg räcker för labb och mindre team, men Shuffles egen dokumentation beskriver även en distribuerad modell baserad på Docker Swarm, där Orborus schemalägger arbetar- och applikationscontainrar över flera noder i stället för en enda server. Det är rätt väg att gå när arbetsflödena blir många och körs parallellt i stor skala, eftersom en enda server annars blir en flaskhals för hur många exekveringar som kan köras samtidigt.

docker swarm init --advertise-addr 
docker stack deploy -c docker-compose.yml shuffle
docker stack services shuffle
docker node ls

Lägg till ytterligare worker-noder med docker swarm join-kommandot som skrivs ut när du initierar svärmen. Testa migreringen i en separat miljö innan du rullar om en produktionsinstallation, eftersom en felkonfigurerad övergång kan leda till att pågående exekveringar förloras. Räkna också med att övervaka minnesanvändningen per nod noggrant den första tiden efter migreringen, eftersom en felaktigt balanserad svärm kan koncentrera för många exekveringar till en enda nod medan övriga står still.

Steg 14: Säkra installationen innan den går live

Innan du låter Shuffle hantera riktiga larm, gå igenom en kort säkerhetscheck. Eftersom Orborus behöver åtkomst till Docker-sockeln för att starta containrar, är en Shuffle-server i praktiken en maskin med hög behörighet, och den ska behandlas som sådan i din nätverkssegmentering.

• Exponera aldrig port 3001 eller 5001 direkt mot internet, lägg en omvänd proxy med TLS och autentisering framför.
• Rotera API-nycklar för alla anslutna appar regelbundet, och lagra dem endast i Shuffles autentiseringsvy, aldrig i klartext i arbetsflödesvariabler.
• Begränsa vilka användare som har admin-rollen, eftersom admin kan läsa alla sparade autentiseringsuppgifter i organisationen.
• Aktivera loggning av samtliga exekveringar och exportera dem till din SIEM, så att SOAR-plattformen själv blir en del av din övervakade yta, inte en blind fläck.
• Begränsa docker.sock-åtkomsten på värdnivå och håll Docker Engine uppdaterad, eftersom en kompromiss av Orborus-containern annars kan ge kontroll över hela värden.

Vanliga fallgropar när du bygger SOAR-arbetsflöden

Även med en korrekt installerad Shuffle-instans stöter de flesta team på liknande problem första gången de bygger automation på riktigt. Här är de du bör se upp för.

• Att automatisera innan processen är dokumenterad. Om du inte vet exakt vilka steg en analytiker tar manuellt idag, bygger du en gissning i stället för en automation, och den gissningen missar edge cases.
• Ingen felhantering i grenarna. Om det externa API:et som berikar data är nere, måste arbetsflödet veta vad det ska göra, annars hänger exekveringen eller faller tyst utan att någon märker det.
• För breda villkor. Ett tröskelvärde satt för lågt skapar en biljettstorm som drunknar analytikerna i falska positiva, vilket snabbt dödar förtroendet för hela plattformen.
• Hårdkodade hemligheter i noder. API-nycklar klistrade direkt i en nods konfiguration i stället för i autentiseringsvyn läcker ut så fort någon exporterar eller delar arbetsflödet.
• Ingen testmiljö. Att testa nya arbetsflöden direkt mot produktionslarm riskerar att skapa riktiga biljetter eller skicka notiser till fel kanal under utveckling.
• Glömda inaktiva arbetsflöden. Ett arbetsflöde som pausades för felsökning och aldrig återaktiverades ger falsk trygghet, teamet tror att automationen körs när den i själva verket står still.
• Att lita blint på en enda datakälla. En riskpoäng från ett API är en signal, inte en sanning, och ett arbetsflöde som agerar autonomt på ett enda värde utan korsreferens kan både missa riktiga hot och blockera legitim trafik.

Felsökning: 8+ vanliga problem och lösningar

Problem	Trolig orsak	Lösning
Containrar startar om i loop	Portkonflikt eller otillräckligt minne	Kontrollera docker compose logs och frigör portarna 3001/5001
Webhook svarar aldrig	Arbetsflödet är inte aktiverat	Klicka “Activate” i övre högra hörnet av editorn
Permission denied på docker.sock	Användaren saknas i docker-gruppen	Kör sudo usermod -aG docker $USER och logga in igen
App-nod visar “Authentication failed”	Fel eller utgången API-nyckel	Uppdatera nyckeln under organisationens autentiseringsvy
Exekvering hänger i “EXECUTING”	Extern tjänst svarar inte inom timeout	Höj SHUFFLE_APP_SDK_TIMEOUT i .env och starta om
Frontend laddar inte på port 3001	Backend-tjänsten är inte uppe än	Vänta till docker compose ps visar alla tjänster som “healthy”
Fältmappning ger tomt värde	Felaktig sökväg till föregående nods utdata	Inspektera exekveringsloggen och kopiera exakt fältnamn från JSON-svaret
Swarm-noder syns inte i klustret	Brandvägg blockerar Swarm-portarna 2377/7946/4789	Öppna dessa portar mellan noderna innan du kör join
Agent-nod svarar inte i självhostad miljö	Ingen lokal eller synkad AI-autentisering konfigurerad	Lägg till lokala AI-uppgifter eller synka från molnet enligt v2.3.0-dokumentationen

Shuffle jämfört med andra SOAR- och automationsverktyg

Shuffle är inte det enda verktyget i den här kategorin, och det är värt att förstå var det passar bäst innan du bygger hela er incidentprocess runt det. Tines och Torq är etablerade kommersiella SOAR-plattformar riktade mot större säkerhetsorganisationer, med fokus på molndrift och support. n8n är i grunden ett generellt automationsverktyg, inte byggt specifikt för säkerhet, men används ändå ibland för enklare säkerhetsautomation tack vare sitt breda utbud av kopplingar.

Verktyg	Licensmodell	Primär målgrupp	Driftmodell
Shuffle	Öppen källkod, gratis självhostad	Säkerhetsteam som vill äga sin data	Självhostad (Docker/Swarm) eller moln
Tines	Kommersiell, prissättning ej öppet publicerad	Större säkerhetsorganisationer	Molnbaserad SaaS
Torq	Kommersiell, prissättning ej öppet publicerad	Enterprise-SOC och MSSP:er	Molnbaserad SaaS
n8n	Öppen källkod/kommersiell hybrid	Generell IT- och affärsautomation	Självhostad eller moln

Ingen av de kommersiella konkurrenterna hade en öppet publicerad prislista att jämföra mot vid research till denna artikel, vilket i sig säger något om hur de riktar sig mot enterprise-kunder med individuella avtal snarare än självbetjäning. Shuffles största fördel för mindre och medelstora nordiska team är just att du kan sätta upp en fullständig testmiljö på en virtuell maskin samma dag, utan att behöva gå igenom en säljprocess först.

Valet handlar i slutändan sällan om vilket verktyg som har flest funktioner på papper, och mer om vilken driftmodell organisationen redan är bekväm med. Ett team som redan kör allt annat i containrar och har en DevOps-kultur kommer att hitta sig hemma i Shuffles Docker-baserade värld nästan direkt. Ett team utan den vanan kan uppleva att den initiala inlärningskurvan, särskilt kring felsökning av containrar, tar längre tid än själva byggandet av arbetsflödena. Det är värt att räkna in den kostnaden, inte bara serverräkningen, när ni jämför “gratis” mot en betald SaaS-lösning.

Självhostad eller molnversion: vilket passar ditt team

Shuffle erbjuder tre varianter av drift: helt öppen källkod och självhostad (det du byggt i den här guiden), en licensierad självhostad variant med extra enterprise-funktioner, och en fullständig molnversion där Shuffle sköter infrastrukturen. Vilken som passar bäst beror mindre på teamets storlek och mer på var ni redan har er data och vilka krav ni har på var den får bearbetas.

Självhostad öppen källkod är rätt val när säkerhetsdata av policyskäl inte får lämna er egen infrastruktur, när ni redan har ett team som är vant att drifta containerbaserade tjänster, eller när ni vill undvika återkommande licenskostnader helt och hållet. Nackdelen är att ni själva ansvarar för uppgraderingar, säkerhetshärdning och drift dygnet runt, vilket kan bli en belastning för ett litet team som redan är pressat på tid.

Molnversionen passar team som vill komma igång snabbare och inte har kapacitet att äga infrastrukturen, men den innebär per definition att säkerhetslarm och de API-nycklar som kopplar till era interna system passerar genom en tredje parts molnmiljö. För organisationer med strikta krav på datalokalisering, vanligt inom offentlig sektor och finansiella tjänster i Sverige, är det en avgörande skillnad som bör klaras ut innan ni väljer driftmodell, inte efteråt.

Avancerade tips för produktionsdrift

När grundarbetsflödet fungerar är nästa steg att göra driften robust nog att lita på i skarpt läge. Bygg en biblioteksstruktur av återanvändbara delarbetsflöden, exempelvis ett separat flöde bara för IP-berikning som andra flöden anropar, i stället för att duplicera samma logik i varje enskilt arbetsflöde. Det gör underhåll enklare: en ändring av berikningslogiken på ett ställe uppdateras automatiskt överallt den används.

Använd versionering flitigt. Shuffle sparar historik för arbetsflödesändringar, men exportera ändå dina viktigaste flöden som JSON och checka in dem i ett git-repo, så har du en oberoende backup och kan köra kodgranskning på ändringar precis som för vanlig applikationskod. Sätt också upp separata organisationer (tenants i den nya terminologin) för test och produktion, så att ett experimentellt arbetsflöde i testmiljön aldrig av misstag kan trigga en riktig notis till jourhavande.

Slutligen, mät din automation. Shuffles exekveringslogg ger dig rådata, men exportera nyckeltal som antal automatiskt stängda ärenden, genomsnittlig tid från larm till åtgärd, och andel falska positiva till en instrumentpanel ni redan använder. Utan mätning vet ni aldrig om SOAR-satsningen faktiskt kortar incidenttiden eller bara flyttar runt samma flaskhals till ett nytt ställe.

Ett sista tips som ofta underskattas: dokumentera ägarskap per arbetsflöde. Lägg till namn, team och en kort beskrivning av syftet direkt i arbetsflödets metadata, inte bara i ett separat Confluence-dokument som glöms bort. Sex månader efter att ett arbetsflöde byggdes har ofta ingen i teamet minnet kvar av exakt varför ett visst villkor sattes till just det värdet, och utan ägarskap blir rädslan för att ändra något gammalt större än nyttan av att förbättra det.

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

Sätt ihop allt du byggt i stegen ovan till ett komplett, fungerande projekt. Nedan är den fullständiga docker-compose-konfigurationen i sin kärna (förenklad från standardmallen) och ett exempel på hur arbetsflödet exporteras som JSON för versionering i git.

version: "3.8"
services:
  shuffle-frontend:
    image: ghcr.io/shuffle/shuffle-frontend:v2.3.0
    ports:
      - "3001:80"
    restart: unless-stopped

  shuffle-backend:
    image: ghcr.io/shuffle/shuffle-backend:v2.3.0
    ports:
      - "5001:5001"
    environment:
      - SHUFFLE_HOSTNAME=${SHUFFLE_HOSTNAME}
      - BASE_URL=${BASE_URL}
    volumes:
      - shuffle-database:/var/lib/shuffle
    restart: unless-stopped

  shuffle-orborus:
    image: ghcr.io/shuffle/shuffle-orborus:v2.3.0
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - BASE_URL=${BASE_URL}
    restart: unless-stopped

volumes:
  shuffle-database:

Det kompletta projektet, exporterat som arbetsflödesfil, ser i grova drag ut som nedan när du hämtar ner det via “Export” i editorn. Spara filen i ett git-repo tillsammans med en kort README som beskriver vilket larm den hanterar och vem som äger arbetsflödet.

{
  "name": "IP-berikning och biljett",
  "triggers": [{"type": "webhook", "name": "firewall_alert"}],
  "actions": [
    {"app": "threatintel", "action": "ip_lookup"},
    {"app": "condition", "action": "evaluate", "rule": "risk_score > 70"},
    {"app": "ticketing", "action": "create_case"},
    {"app": "slack", "action": "send_message"}
  ],
  "version": "1.0",
  "owner": "soc-team"
}

Med den här filen i git kan vem som helst i teamet återskapa exakt samma arbetsflöde på en ny Shuffle-instans genom att importera filen via “Import Workflow” i gränssnittet, vilket gör katastrofåterställning till en femminutersuppgift i stället för att bygga om allt från minnet.

SOAR och regelefterlevnad: NIS2, GDPR och API-säkerhet

Automation är inte bara en bekvämlighet för svenska säkerhetsteam just nu, det börjar bli en regelmässig nödvändighet. NIS2-direktivet, som redan omfattar tusentals svenska företag inom kritisk infrastruktur och viktiga sektorer, ställer krav på att organisationer kan upptäcka och hantera incidenter inom strikta tidsramar. Ett team som förlitar sig helt på manuell triagering har svårt att hålla den typen av deadlines när larmvolymen växer, vilket är precis det scenario SOAR är byggt för att lösa. ENISA, EU:s cybersäkerhetsbyrå, publicerar löpande vägledning om hur organisationer bör strukturera sin incidenthanteringsförmåga, och mycket av den vägledningen förutsätter någon grad av automatiserad detektering och respons för att vara realistisk att uppnå i praktiken.

Eftersom Shuffle integrerar mot externa system via API:er, ärver din installation också de generella riskerna som finns beskrivna i OWASP Top Ten, särskilt kring felaktig autentisering och osäker hantering av autentiseringsuppgifter. Om du bygger arbetsflöden som anropar interna API:er, applicera samma härdningsprinciper du skulle använda för en vanlig webbapplikation: minsta möjliga behörighet för varje nyckel, kort livstid på tokens där det är möjligt, och loggning av varje anrop som går ut från plattformen. En SOAR-installation som i sig blir en osäker genväg in i resten av infrastrukturen har gjort mer skada än nytta.

Ett praktiskt sätt att visa regelefterlevnad är att låta Shuffle själv producera revisionsspår. Varje exekvering loggas med tidsstämpel, indata och utdata, vilket ger dig ett konkret bevis på att en viss typ av incident faktiskt hanterades inom en given tidsram, snarare än att behöva lita på en analytikers minnesanteckningar efteråt. Det är den typen av spårbarhet en revisor eller tillsynsmyndighet som IMY ofta frågar efter när ett företag ska visa att det har en fungerande process, inte bara en policy på papper.

Så underhåller du Shuffle-installationen över tid

Precis som alla internetexponerade säkerhetsverktyg behöver Shuffle löpande underhåll. Följ projektets releaser på GitHub och planera uppgraderingar till nya versioner inom rimlig tid efter att de publiceras, särskilt när release-anteckningarna nämner säkerhetsrelaterade buggfixar som den som åtgärdades i v2.3.0 kring sessionshantering vid inloggning med API-nyckel.

Sätt upp en enkel rutin: kontrollera releaser varje månad, läs igenom ändringsloggen, testa uppgraderingen i er testmiljö innan ni rullar den till produktion. Shuffles arkitektur med separata containrar för frontend, backend och Orborus gör att en uppgradering oftast bara innebär att dra ner nya avbilder och köra docker compose up -d igen, men backup av databasvolymen innan uppgraderingen är en självklarhet som ändå ofta glöms bort i stressen att få fixen på plats snabbt.

Testa hela kedjan end-to-end innan ni går live

Innan ni kopplar in riktiga produktionslarm, köra en fullständig genomgång av hela kedjan från start till slut minst tio gånger med varierande indata. Skicka in en IP-adress ni vet är ren, en ni vet har dålig anseende, och några fall som ligger precis i gränslandet kring ert tröskelvärde. Syftet är inte att hitta buggar i Shuffle, utan att hitta hål i er egen logik, till exempel fält som saknar värde i vissa larmkällor men inte andra.

Dokumentera varje testkörning i en enkel tabell: indata, förväntat utfall, faktiskt utfall. Avvikelser här, även små, är precis det som annars dyker upp som ett missat larm klockan tre på natten sex veckor senare. Lägg särskilt vikt vid vad som händer om en nod i kedjan returnerar ett oväntat dataformat, exempelvis om hotunderrättelse-API:et byter ut ett fältnamn i en uppdatering, något som har hänt för flera välkända API:er under 2025 och 2026 utan större förvarning till användarna.

När testerna är godkända, aktivera arbetsflödet mot en begränsad delmängd av verklig trafik först, till exempel bara larm från en enskild brandvägg eller ett enskilt kontor, innan ni rullar ut det mot hela organisationens larmflöde. Den stegvisa utrullningen gör att om något ändå går fel, påverkas en liten, avgränsad del av verksamheten snarare än hela SOC:en samtidigt. Det är samma princip som gäller för all förändringshantering i produktionsmiljöer, och SOAR-arbetsflöden är inget undantag bara för att de körs i en separat plattform.

Vanliga frågor om Shuffle och SOAR

Är Shuffle verkligen helt gratis att använda?
Själva mjukvaran är öppen källkod och kostnadsfri att självhosta, enligt både GitHub-repot och Shuffles produktlistning på AWS Marketplace. Du betalar bara för din egen infrastruktur, som servertid, lagring och nätverk. Det finns även en molnversion och en licensierad självhostad variant med extra funktioner, där prissättning sätts separat.

Behöver jag kunna programmera för att använda Shuffle?
Nej, grundprincipen är ett visuellt, lågkodat gränssnitt där du kopplar ihop färdiga noder. Du kan komma långt utan att skriva en rad kod. Vill du bygga egna appar eller mer avancerad logik hjälper det att känna till Python, eftersom Shuffles app-SDK är byggt kring det.

Kan Shuffle ersätta mitt SIEM?
Nej. Shuffle är inte en detekteringsplattform som samlar in och korrelerar loggar, det är ett orkestrerings- och automationslager som agerar på larm som redan genererats av ett SIEM, en EDR eller en brandvägg. Många team kör Shuffle tillsammans med en SIEM-lösning som Wazuh snarare än i stället för den.

Hur skiljer sig Shuffle från TheHive och MISP?
TheHive är ett ärendehanteringssystem fokuserat på att strukturera och spåra incidentutredningar, medan MISP är en plattform för att dela och korrelera hotunderrättelser mellan organisationer. Shuffle kompletterar båda genom att automatisera flödet mellan dem, till exempel genom att automatiskt skapa ett TheHive-ärende baserat på en MISP-träff.

Är det säkert att låta Shuffle agera helt autonomt utan mänsklig granskning?
Det beror på åtgärdens konsekvens. Att automatiskt berika data, skapa biljetter och skicka notiser är lågrisk. Att automatiskt blockera IP-adresser, inaktivera konton eller isolera maskiner bör ha ett mänskligt godkännandesteg inbyggt i arbetsflödet för de fall där riskpoängen ligger i en gråzon, för att undvika att en felaktig signal stänger av legitima användare eller system.

Fungerar Shuffle med molnleverantörer som AWS?
Ja, Shuffle finns tillgängligt som en färdig AMI på AWS Marketplace, där du betalar för instanstid i stället för mjukvarulicens enligt listningen. Det gör det enkelt att testa plattformen utan att sätta upp egen hårdvara, även om många svenska team av dataskyddsskäl väljer att självhosta on-premise eller i en EU-baserad molnregion.

Vad händer om den externa tjänsten ett arbetsflöde anropar är nere?
Arbetsflödet pausar den exekveringen och, om du har konfigurerat en timeout-gräns via SHUFFLE_APP_SDK_TIMEOUT, markeras den som misslyckad efter en viss tid i stället för att hänga permanent. Bygg alltid en felhanteringsgren som fångar detta och eskalerar manuellt om den automatiska vägen inte kan slutföras.

Kan jag migrera arbetsflöden mellan en testmiljö och produktion?
Ja, exportera arbetsflödet som JSON från testorganisationen och importera det i produktionsorganisationen. Kom ihåg att autentiseringsuppgifter inte följer med i exporten av säkerhetsskäl, så du måste konfigurera om API-nycklarna separat i den nya miljön.