Sysmon och Sigma: Bygg Gratis EDR i 14 Steg [2026]

De flesta mindre och medelstora organisationer i Sverige har inte råd med en fullskalig EDR-lösning för alla sina Windows-maskiner. Licenser för kommersiell “endpoint detection and response” kostar ofta mer per enhet och år än hela IT-säkerhetsbudgeten tillåter. Samtidigt kräver NIS2 att fler verksamheter kan upptäcka och hantera säkerhetsincidenter, inte bara skydda sig mot dem. Lösningen många SOC-team redan använder är en kombination av två kostnadsfria verktyg: Microsofts processövervakare Sysmon och det öppna regelformatet Sigma. Tillsammans ger de en stor del av den synlighet som en kommersiell EDR-produkt säljer, utan licensavgift.

Den här guiden går igenom hur du installerar Sysmon, samlar in loggarna i en SIEM, konverterar Sigma-regler till din plattform och testar att larmen faktiskt triggas. Du får 14 konkreta steg, kodexempel du kan kopiera rakt av, och en lista över de fallgropar som gör att nya installationer antingen tystnar eller dränker SOC-teamet i falska larm. Målet är ett fungerande detekteringsflöde du kan driftsätta samma vecka, inte en teoretisk översikt.

Upplägget passar särskilt bra för organisationer som redan loggar till en SIEM men saknar skarp detekteringslogik ovanpå loggarna, och för team som behöver visa att de har proportionerlig övervakning på plats inför en NIS2-granskning utan att först behöva förhandla fram en ny budgetpost. Du behöver ingen tidigare erfarenhet av Sigma, men grundläggande vana vid Windows händelselogg och ett SIEM-gränssnitt gör de senare stegen betydligt smidigare.

Vad är Sysmon och varför behöver du det

Sysmon, kort för System Monitor, är en del av Microsofts Sysinternals-svit och loggar detaljerad systemaktivitet direkt till Windows händelselogg. Verktyget är gratis, körs som en tjänst och skriver händelser som processkapning, nätverksanslutningar, registerändringar och filskapande till kanalen Microsoft-Windows-Sysmon/Operational. Den senaste versionen är Sysmon v15.22, släppt i september 2026, och stöder Windows 10 och senare samt Windows Server 2016 och senare. Sedan februari 2026 finns Sysmon dessutom som en inbyggd, valbar funktion direkt i Windows 11, vilket gör utrullningen enklare än när admins tidigare behövde distribuera en separat .exe-fil till varje dator.

Skillnaden mot standardloggningen i Windows är detaljnivån. Windows Security-loggen fångar till exempel att en process startades, men sällan kommandoradsargumenten, föräldraprocessen eller filens hash. Sysmon fångar allt detta, vilket gör skillnaden mellan “något startade PowerShell” och “explorer.exe startade ett dolt PowerShell-fönster med en base64-kodad nedladdningskommandorad” – precis den typen av detalj en SOC-analytiker behöver för att skilja ett legitimt skriptjobb från ett intrång.

Mark Russinovich, som skapade Sysinternals-sviten och i dag är teknisk chef för Microsoft Azure, är tydlig med verktygets begränsning: “Sysmon does not provide analysis of the events it generates, nor does it attempt to hide itself from attackers.” Det är precis här Sigma kommer in. Sysmon samlar in rådata. Sigma ger dig en standard för att skriva regler som tolkar datan och slår larm.

Värdet märks tydligast vid utredningar av ransomware-förberedelser och sidledsrörelse i nätverket, de två faserna där angripare oftast agerar innan de slår till på bred front. Event ID 1 avslöjar om en angripare kör verktyg som används för att dumpa autentiseringsuppgifter, Event ID 10 visar om en process öppnar lsass.exe på ett sätt som pekar mot credential dumping, och Event ID 3 kan fånga ovanliga utgående anslutningar mot en kommando- och kontrollserver innan krypteringen av filer börjar. Utan den här telemetrin ser många av dessa tidiga signaler identiska ut med normal administrativ aktivitet, och det är just den skillnaden Sysmon gör synlig.

Vad är Sigma-regler och SigmaHQ-biblioteket

Sigma är ett plattformsoberoende regelformat i YAML för att beskriva detekteringslogik mot loggdata, oavsett vilken SIEM eller loggplattform du använder. Du skriver regeln en gång och konverterar den sedan till frågespråket för Splunk, Elastic, Microsoft Sentinel, QRadar eller vilken backend du kör. Florian Roth, som skapade formatet och i dag är teknisk chef på Nextron Systems, beskriver det träffande: “Sigma is for log data what YARA is for files and Snort is for network traffic.” Sigma är alltså inte ett verktyg i sig utan ett gemensamt språk för detekteringsidéer.

Community-repot SigmaHQ på GitHub beskriver själva att samlingen “offers more than 3000 detection rules” och gör dem fritt tillgängliga. Oberoende katalogtjänster som synkroniserar mot repot dagligen räknade i oktober 2026 omkring 3 800 regler fördelat på runt 30 produkter och plattformar. Siffran varierar lite beroende på hur man räknar undertyper och dubbletter, men kärnan är densamma: det är ett stort, aktivt underhållet bibliotek som uppdateras flera gånger i veckan med nya detekteringar, bland annat för BPFDoor-aktivitet, misstänkt schtasks-körning och onion-DNS-uppslag mot Tor.

Roth har själv svarat på frågan om Sigma fungerar som hotjaktsverktyg: “Yes. As we encourage people to write Sigma rules to detect generic malicious behavior, it can help you to detect threats that your Antivirus or other solutions miss.” Han tillägger att fördelen är ekonomisk också: “With Sigma, you can supercharge your existing log management solution and apply detection methods provided by the community at no extra costs.” Det är precis den kombinationen svenska SOC-team med begränsad budget letar efter – mer täckning utan mer licenskostnad.

En annan fördel som ofta glöms bort är att Sigma-regler går att versionshantera precis som vanlig kod. Eftersom varje regel är en ren YAML-fil kan den läggas i ett eget git-repo, granskas via pull request av en kollega innan den aktiveras, och rullas tillbaka om den visar sig skapa för mycket brus. Det gör detekteringsarbetet till en del av samma ingenjörsprocess som resten av IT-driften använder, i stället för en separat, odokumenterad samling regler som bara en person i teamet förstår.

Sysmon och Sigma jämfört med kommersiell EDR

Det är viktigt att vara ärlig om vad kombinationen faktiskt ersätter. Sysmon och Sigma ger dig telemetri och detekteringslogik, men ingen inbyggd respons. En kommersiell EDR-plattform isolerar en komprometterad dator, dödar en skadlig process automatiskt och korrelerar signaler från moln, identitet och nätverk i samma konsol. Sysmon gör inget av detta på egen hand. Du bygger själv rörledningen: insamling, lagring, regelkonvertering och larmhantering.

Den distinktionen är inte bara teoretisk. Om ett larm triggar klockan tre på natten och ingen är vaken för att agera, spelar det ingen roll hur bra själva detekteringsregeln var. En kommersiell EDR kan i det läget isolera maskinen från nätverket automatiskt och vänta på att en människa loggar in på morgonen. Sysmon och Sigma kräver att någon faktiskt ser larmet och agerar, antingen manuellt eller via en kopplad SOAR-plattform som Shuffle eller TheHive som automatiserar själva svarsprocessen ovanpå detekteringen.

Det gör kombinationen bäst lämpad som ett komplement, inte en fullständig ersättning. Många organisationer som redan har en EDR-produkt lägger till Sysmon-telemetri som extra källa in i sin SIEM, för att få djupare synlighet än vad EDR-agenten exponerar via sitt eget API. Andra, särskilt mindre verksamheter som ännu inte har råd med en EDR-licens för alla enheter, använder Sysmon och Sigma som en fungerande baslinje tills budgeten tillåter mer. Tabellen nedan sammanfattar de viktigaste skillnaderna.

Egenskap	Sysmon + Sigma	Kommersiell EDR
Licenskostnad	Gratis (Sysinternals + öppen källkod)	Licensavgift per slutpunkt och år
Primär funktion	Detaljerad telemetri och regelbaserad detektering	Detektering, utredning och automatisk respons
Analys	Kräver egen SIEM, regelmotor och tolkning	Inbyggd analysmotor och leverantörens hotunderrättelser
Respons	Ingen inbyggd isolering eller sanering	Automatisk isolering, processavslut och återställning
Datakälla	Primärt Windows-värdaktivitet via konfiguration	Ofta slutpunkt, identitet, moln och nätverk samlat
Driftsättning	Kräver eget konfigurations- och insamlingsarbete	Agent plus leverantörens hanteringsplattform
Bäst för	Kostnadseffektiv telemetri och detekteringsutveckling	Hanterad eller integrerad prevention och incidenthantering

Under NIS2 ställs i grunden riskbaserade krav på att verksamheter ska kunna upptäcka och hantera incidenter proportionerligt mot sin risknivå. Regelverket pekar inte ut Sysmon, Sigma eller någon specifik EDR-produkt som obligatorisk. Det du som svensk eller nordisk organisation behöver visa är att loggningen är tillräcklig för att upptäcka avvikande beteende, skyddad mot manipulation, och sparas tillräckligt länge för att stödja en utredning. Sysmon och Sigma kan vara en fullt giltig del av den lösningen, så länge insamlingen är robust och regelbundet granskad.

Förutsättningar: verktyg, versioner och behörigheter

Innan du börjar behöver du ha följande på plats. Listan är medvetet konkret så att du kan bocka av varje punkt innan steg ett.

Windows 10/11 eller Windows Server 2016 eller senare på minst en testmaskin, administratörsbehörighet krävs för installation
Sysmon v15.22 (senaste version från Microsoft Sysinternals) nedladdad från den officiella sidan
En startkonfiguration, till exempel SwiftOnSecurity-mallen, som utgångspunkt i stället för standardinställningarna
En SIEM eller loggplattform att skicka data till – Wazuh, Elastic Stack, Microsoft Sentinel eller motsvarande fungerar alla
Python 3.10 eller senare för att installera sigma-cli och pySigma, verktygen som konverterar Sigma-regler till din backend
Git installerat för att klona SigmaHQ-repot lokalt
Atomic Red Team eller motsvarande testramverk för att simulera attacktekniker och verifiera att larmen triggas
Minst en testmiljö som är isolerad från produktion, så att du kan köra attacksimuleringar utan risk

Räkna med ungefär 60–90 minuter för grundinstallationen på en enskild maskin, och ytterligare en till två arbetsdagar för att få hela kedjan – insamling, konvertering och testning – att fungera stabilt över en handfull maskiner. Det är tid värd att investera innan du rullar ut till hela flotten.

Tänk också igenom vem i organisationen som äger pipelinen efter lanseringen. Det kan vara en IT-säkerhetsansvarig som redan sköter SIEM-plattformen, eller en extern konsult som sätter upp grunden och lämnar över underhållet till en intern administratör. Utan en tydlig ägare hamnar regeluppdateringar och tuning ofta längst ner på att-göra-listan, och då tappar hela upplägget sitt värde redan efter några månader.

Fas 1: Installera och konfigurera Sysmon

Den första fasen handlar enbart om att få korrekt, filtrerad telemetri att flöda lokalt på en enskild testmaskin innan du ens börjar tänka på insamling eller regler. Hoppa inte över den här fasen för snabbt bara för att den känns enkel, eftersom en felkonfigurerad startpunkt följer med genom hela resten av pipelinen.

Steg 1: Ladda ner Sysmon och en härdad startkonfiguration

Ladda ner Sysmon från Sysinternals och en etablerad konfigurationsmall i stället för att skriva din egen från grunden. SwiftOnSecurity-konfigurationen är den mest använda utgångspunkten i communityn och filtrerar bort det mesta av bruset från normal systemaktivitet medan den behåller de händelser som faktiskt är intressanta ur ett detekteringsperspektiv.

mkdir C:\Tools\Sysmon
cd C:\Tools\Sysmon
# Ladda ner Sysmon-paketet och packa upp i mappen
# Ladda ner sysmonconfig.xml från SwiftOnSecurity/sysmon-config

Steg 2: Installera Sysmon som tjänst

Installera med administratörsbehörighet och peka direkt på konfigurationsfilen, så att tjänsten startar med rätt filter från första start i stället för att först köra med standardinställningar.

Sysmon64.exe -accepteula -i sysmonconfig.xml
sc query Sysmon64
Get-Service Sysmon64

Förväntat resultat: sc query ska visa STATE som RUNNING, och tjänsten ska dyka upp i Tjänster-panelen med namnet “Sysmon64”.

Steg 3: Verifiera att loggning fungerar

Öppna Händelsevisaren och navigera till Program- och tjänstloggar → Microsoft → Windows → Sysmon → Operational. Du bör se en ström av händelser med ID 1 (processkapning), 3 (nätverksanslutning), 11 (filskapande) och liknande, nästan direkt efter installation. Om kanalen är tom efter några minuter är något fel i konfigurationen eller behörigheterna, se felsökningsavsnittet längre ner.

Steg 4: Finjustera konfigurationen för din miljö

Standardmallen är en bra start men ska alltid justeras. Lägg till undantag för era legitima administrationsverktyg, backup-agenter och interna skript som annars genererar onödigt brus, och uppdatera konfigurationen med samma installationskommando men flaggan -c i stället för -i för att ladda om utan att avinstallera tjänsten.

Sysmon64.exe -c sysmonconfig-uppdaterad.xml

Fas 2: Samla in och vidarebefordra loggarna centralt

Nu flyttar fokus från den enskilda maskinen till hur loggarna når en central plats där de både är säkra mot manipulation och tillgängliga för analys. Det här är fasen som avgör om detekteringen faktiskt skalar bortom en testmaskin till resten av flottan.

Steg 5: Välj insamlingsmetod

Lokala loggar hjälper inte om angriparen raderar dem efter intrånget, så nästa steg är att skicka händelserna någon annanstans direkt vid genereringen. De två vanligaste vägarna är Windows Event Forwarding (WEF), som är inbyggt i Windows och använder WinRM för att skicka valda kanaler till en central insamlare, eller en agent som Winlogbeat eller Wazuh-agenten som skickar direkt till din SIEM. WEF kräver ingen extra programvara på klienterna men mer konfigurationsarbete i Active Directory. En agentbaserad lösning är ofta snabbare att komma igång med i mindre miljöer.

Steg 6: Konfigurera vidarebefordran till din SIEM

Om du använder Wazuh, som är ett vanligt kostnadsfritt SIEM-val bland svenska SOC-team, pekar du agentens ossec.conf mot kanalen Microsoft-Windows-Sysmon/Operational.

<localfile>
  <location>Microsoft-Windows-Sysmon/Operational</location>
  <log_format>eventchannel</log_format>
</localfile>

Starta om agenten och kontrollera i SIEM-gränssnittet att nya Sysmon-händelser dyker upp inom en minut eller två efter att du genererat testaktivitet, till exempel genom att starta ett nytt program på klienten.

Steg 7: Verifiera volym och fältmappning

Kontrollera att centrala fält som CommandLine, ParentImage och Hashes faktiskt kommer med i den parsade händelsen i SIEM, inte bara en råtextblob. Det är dessa fält Sigma-reglerna i nästa fas matchar mot, och om parsningen inte mappar dem korrekt kommer reglerna att konverteras felfritt men aldrig slå larm.

Det enklaste sättet att verifiera detta är att öppna en enskild rå händelse i SIEM:s utvecklarvy eller JSON-vy, inte bara den sammanfattade listvyn, och jämföra fältnamnen mot vad dokumentationen för er valda Sigma-bakände förväntar sig. Många plattformar normaliserar exempelvis CommandLine till antingen “process.command_line” eller “CommandLine” beroende på vilken parser-pipeline som används, och en felaktig gissning här är den enskilt vanligaste orsaken till att hela nästa fas känns som att den “inte fungerar” trots att varje enskilt steg tekniskt gått rätt till.

Fas 3: Implementera Sigma-regler mot din loggdata

Med loggarna på plats i SIEM går nästa fas åt till att omsätta Sigma-regelbiblioteket till faktisk detekteringslogik för just er plattform. Det här är arbetet som gör skillnaden mellan att bara samla loggar och att faktiskt kunna upptäcka något i dem.

Steg 8: Klona SigmaHQ-regelbiblioteket

git clone https://github.com/SigmaHQ/sigma.git
cd sigma/rules/windows/process_creation
ls *.yml | wc -l

Steg 9: Installera konverteringsverktygen

Det äldre sigmac-verktyget har ersatts av sigma-cli tillsammans med pySigma-biblioteket, som har stöd för betydligt fler bakändar.

python3 -m venv sigma-env
source sigma-env/bin/activate
pip install sigma-cli
sigma plugin install elasticsearch
sigma plugin list

Steg 10: Konvertera regler till din plattforms frågespråk

Börja i liten skala med en specifik undermapp innan du konverterar hela biblioteket på en gång, så att du kan granska varje regel manuellt innan den går live.

sigma convert -t es_qs -p sysmon \
  rules/windows/process_creation/proc_creation_win_susp_powershell_encoded.yml

Förväntad utskrift är en giltig frågesträng för din valda bakände, till exempel en Elasticsearch-sökfråga som letar efter EventID 1 i kombination med nyckelord som -EncodedCommand i fältet CommandLine. Om kommandot istället returnerar ett felmeddelande om okänt fält, se felsökningsavsnittet nedan.

Steg 11: Ladda upp och aktivera reglerna

Importera de konverterade frågorna som sparade sökningar eller detekteringsregler i din SIEM, sätt en rimlig allvarlighetsgrad för varje regel, och aktivera dem i “endast loggning”-läge innan du kopplar på automatiska notiser. Det ger dig en period att se volymen innan SOC-teamet börjar få larm mitt i natten.

Fas 4: Testa, validera och dokumentera detekteringen

En regel som aldrig testats mot ett verkligt beteende är bara ett antagande. Den sista fasen bevisar att hela kedjan faktiskt fungerar, från att en attackteknik körs till att ett larm landar hos en analytiker, och ger er samtidigt ett dokumenterat facit att visa upp vid en revision.

Steg 12: Simulera en attackteknik

Använd Atomic Red Team för att trigga exakt det beteende regeln är skriven för att upptäcka. Nedan ett exempel som simulerar kodad PowerShell-körning, en klassisk teknik för att dölja kommandon från enkel textbaserad loggning.

Invoke-AtomicTest T1059.001 -TestNumbers 1

Steg 13: Verifiera att larmet triggas inom rimlig tid

Gå till SIEM-gränssnittet och kontrollera att Sysmon-händelsen genererades, att den matchar den konverterade Sigma-frågan, och att larmet syns i dashboarden inom ett par minuter. Om händelsen finns i loggarna men larmet aldrig triggas ligger felet nästan alltid i fältmappningen eller i hur villkoret i regeln är skrivet, inte i Sysmon-konfigurationen.

Steg 14: Dokumentera falska positiva och justera

Kör varje ny regel i minst en vecka i loggningsläge innan den går till aktiv larmning, och anteckna vilka legitima processer som triggar den i onödan. Lägg till undantag i regeln eller i Sysmon-konfigurationen för dessa, dokumentera varför undantaget finns, och först därefter aktivera notiser.

Exempel: en komplett Sigma-regel steg för steg

Så här ser en färdig regel ut i praktiken. Den fångar misstänkt PowerShell som körs med en base64-kodad kommandorad, ett av de vanligaste sätten skadlig kod döljer sin första körning.

title: Misstänkt kodad PowerShell-körning
id: 8f4e2c91-aa21-4b7d-9c3e-example0001
status: test
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        Image|endswith: '\powershell.exe'
        CommandLine|contains:
            - '-EncodedCommand'
            - '-enc '
            - '-e '
    condition: selection
level: high
tags:
    - attack.execution
    - attack.t1059.001

Logsource-fältet talar om för konverteraren vilken Sysmon-mappning som ska användas, selection-blocket beskriver vad som räknas som en träff, och tags kopplar regeln till en specifik MITRE ATT&CK-teknik, i detta fall T1059.001 för kommandoradstolkare. Det är den här taggningen som gör det möjligt att senare rapportera vilken andel av ramverket er detektering faktiskt täcker.

Så ser flödet ut i praktiken, från händelse till larm

Det är lätt att tappa bort helheten bland alla enskilda steg, så här är hela kedjan i ett sammanhängande exempel. En anställd öppnar av misstag en bifogad fil i ett nätfiskemejl. Filen startar powershell.exe med en lång, base64-kodad kommandorad som i sin tur försöker ladda ner ytterligare skadlig kod från en extern server.

Sysmon fångar det här som en Event ID 1-post inom loggningsögonblicket, med hela kommandoraden, föräldraprocessen (ofta outlook.exe eller winword.exe) och en hash av powershell.exe sparad i händelsen. Eftersom agenten vidarebefordrar Operational-kanalen i realtid når händelsen SIEM-plattformen inom några sekunder, långt innan den eventuella nedladdningen hinner slutföras. Den konverterade Sigma-regeln från steg tio matchar omedelbart mot CommandLine-fältet och skapar ett larm med allvarlighetsgrad “hög”, taggat med T1059.001.

SOC-analytikern som tar emot larmet ser direkt vilken användare, vilken maskin, vilken fullständig kommandorad och vilken förälderprocess som var inblandad, utan att behöva logga in på klienten och gräva manuellt i händelseloggen. Den detaljnivån är skillnaden mellan en utredning som tar fem minuter och en som tar en halv dag. Om samma miljö även har Event ID 3 aktiverat för den specifika processen syns dessutom vilken extern adress PowerShell försökte kontakta, vilket ofta räcker för att blockera domänen i brandväggen innan något mer hinner hända.

Sysmon-händelser du bör prioritera för detektering

Sysmon genererar fler än 25 olika händelsetyper, men du behöver inte aktivera alla för att få ett bra detekteringsunderlag. Tabellen nedan listar de händelser erfarna SOC-team konsekvent prioriterar.

Event ID	Namn	Vad den fångar
1	Process Create	Ny process, kommandorad, förälder och hash
3	Network Connection	TCP/UDP-anslutningar från en process, inkl. destination
6	Driver Loaded	Laddade kärndrivrutiner, hjälper upptäcka osignerade/ovanliga drivrutiner
7	Image Loaded	DLL- och binärladdning, användbart mot DLL-kapning
8	CreateRemoteThread	Fjärrtrådsinjektion mellan processer
10	ProcessAccess	En process öppnar en annan, vanligt vid credential dumping
11	FileCreate	Filer som skapas eller skrivs över
12–14	Registry Event	Skapande, ändring och borttagning i registret, ofta persistens
22	DNSEvent	DNS-uppslag gjorda av en process

Event ID 3 (nätverksanslutning) och Event ID 7 (bildladdning) är avstängda i många standardkonfigurationer eftersom de genererar stora volymer. Aktivera dem selektivt, med filter mot specifika processer eller portar, snarare än globalt, om du vill undvika att dränka din insamlingspipeline.

Volymskillnaden mellan dessa händelsetyper är stor i praktiken. En vanlig kontorsdator genererar normalt några hundra Event ID 1-poster per dag, medan samma maskin med Event ID 7 fullt aktiverat utan filter kan generera tiotusentals poster, eftersom varje DLL som laddas av varje process räknas som en egen händelse. Den skillnaden slår direkt mot lagringskostnaden i er SIEM, vilket är ett starkt skäl att aktivera de bullrigaste händelsetyperna selektivt snarare än att slå på allt och hoppas att indexeringen håller.

Vanliga fallgropar när du bygger Sysmon- och Sigma-detektering

Dessa misstag dyker upp om och om igen hos team som bygger sin första Sysmon/Sigma-pipeline, och de går nästan alltid att undvika med lite förarbete. Gemensamt för de flesta är att de uppstår av iver att komma igång snabbt, snarare än av bristande teknisk kompetens i teamet.

Köra med standardkonfigurationen rakt av. Utan filtrering genererar Sysmon enorma volymer som dränker lagring och gör det svårt att hitta det som faktiskt betyder något. Börja alltid med en etablerad, filtrerad mall.
Bara spara loggarna lokalt. En angripare som får administratörsrättigheter kan radera eller manipulera lokala Sysmon-loggar innan de upptäcks. Vidarebefordra alltid till en central plats utanför värdens kontroll.
Importera alla 3 800 Sigma-regler på en gång. Det ger en flodvåg av falska positiva som drunknar SOC-teamet och får hela initiativet att avskrivas som opraktiskt. Börja med en liten, relevant delmängd och bygg ut gradvis.
Hoppa över testfasen. En regel som konverteras utan felmeddelande är inte samma sak som en regel som faktiskt matchar riktig data. Testa alltid mot en simulerad attack innan regeln går till produktion.
Behandla Sysmon och Sigma som en komplett EDR-ersättning. Kombinationen ger telemetri och detektering, inte automatisk isolering eller sanering. Ha en plan för vem som agerar manuellt när larmet går.
Glömma underhållet. SigmaHQ uppdateras flera gånger i veckan. Regler som aldrig uppdateras blir snabbt irrelevanta mot nya tekniker.

Felsökning: när Sysmon- eller Sigma-pipelinen inte fungerar

De här problemen täcker de absolut vanligaste orsakerna till att en installation ser korrekt ut men inte levererar larm. Gå igenom dem i ordning första gången något krånglar, eftersom de är sorterade ungefär efter var i kedjan felet oftast sitter, från installation på klienten till korrelation i utredningsfasen.

Sysmon-tjänsten startar inte och ger “Access is denied”. Kör installationskommandot från en upphöjd kommandotolk (Run as administrator), inte en vanlig användarsession.
Inga händelser syns i Operational-kanalen. Kontrollera att konfigurationsfilen faktiskt laddades vid installation med Sysmon64.exe -c och jämför utskriften mot den fil du avsåg att använda.
Händelserna finns lokalt men syns aldrig i SIEM. Verifiera att agentens kanalnamn stämmer exakt, inklusive skiftläge, mot Microsoft-Windows-Sysmon/Operational, och att tjänsten som läser kanalen har behörighet.
sigma-cli hittar inte plugin för din bakände. Kör sigma plugin list för att se installerade bakändar, och installera saknad backend explicit med sigma plugin install innan du konverterar.
Konverteringen lyckas men regeln matchar aldrig något. Jämför fältnamnen i din parsade logg mot fältnamnen Sigma-regeln förväntar sig. Olika SIEM-parsers normaliserar Sysmon-fält olika, och en mismatch i fältnamn ger en giltig men tom fråga.
Enorm mängd falska positiva direkt efter aktivering. Kör regeln i loggningsläge i minst en vecka innan notiser kopplas på, och lägg till undantag för era kända administrationsverktyg.
WEF-prenumerationen visar “source not responding”. Kontrollera WinRM-konfigurationen på källmaskinen och att brandväggsregler tillåter trafik mellan klient och insamlare på rätt port.
YAML-fel vid konvertering av egna regler. Sigma är strikt med indragsnivåer. Kör filen genom en YAML-validerare innan du konverterar, särskilt om du redigerat en regel manuellt i en vanlig textredigerare.
Insamlingspipen hänger vid hög händelsevolym. Aktivera inte Event ID 3 och 7 globalt på servrar med hög trafik. Filtrera på specifika processer eller nätverksintervall i stället för att samla in allt.
Tidsstämplar matchar inte mellan källor vid korrelation. Säkerställ att alla maskiner synkar klockan mot samma NTP-källa, annars blir tidslinjen i en utredning missvisande även om själva händelserna är korrekta.

Avancerade tips för att skala upp detekteringen

När grundflödet fungerar stabilt på en handfull maskiner finns flera sätt att ta pipelinen vidare. Sysmon-modular är ett community-projekt som delar upp konfigurationen i moduler per teknik snarare än en enda monolitisk fil, vilket gör det enklare att slå på eller av specifika detekteringsområden utan att röra hela konfigurationen.

På Sigma-sidan kan du använda MITRE ATT&CK-taggningen för att bygga en täckningskarta: exportera vilka tekniker era aktiva regler faktiskt pekar mot, och jämför det mot ramverkets fulla lista för att identifiera luckor. Aktuella Sigma-kataloger taggar omkring 171 av de 222 teknikerna i Enterprise-matrisen version 19.2, men det är taggtäckning, inte bevis på att varje teknik upptäcks tillförlitligt i praktiken – en regel per teknik räcker sällan för robust detektering.

Överväg också att komplettera med ett verktyg som Velociraptor eller Wazuh för själva utredningsarbetet när ett larm väl triggas, snarare än att bara stanna vid “larm skickat”. Sysmon och Sigma talar om att något hände, men ett separat forensikverktyg hjälper er svara snabbt på vad angriparen faktiskt gjorde efter den initiala händelsen.

Sigma-specifikationen har också utökats med ett eget korrelationsformat, som låter en regel referera till flera underliggande detekteringar och slå larm först när de inträffar i en viss ordning eller inom ett visst tidsfönster. Det är användbart för att fånga mönster som en enskild regel missar, till exempel en inloggning från en ovanlig plats direkt följt av en misslyckad autentisering mot flera konton i rad. I stället för tre separata, lågprioriterade larm får analytikern ett sammanhängande, högprioriterat larm som faktiskt beskriver vad som händer.

Ett sista tips handlar om prestanda snarare än detektering. Om insamlingspipelinen börjar släpa efter vid hög händelsevolym, testa att flytta den tyngsta filtreringslogiken till Sysmon-konfigurationen själv i stället för att skicka allt obehandlat till SIEM och filtrera där. Att exkludera kända, högfrekventa processer redan vid källan minskar nätverkstrafiken, lagringsbehovet och indexeringstiden samtidigt, vilket ofta är den enklaste vinsten när en miljö växer från en pilotgrupp till hela organisationen.

Slutligen, bygg in regelbunden granskning i rutinerna. Boka in en återkommande genomgång, till exempel månadsvis, där teamet går igenom nya Sigma-releaser, inaktiverar regler som gett för många falska positiva, och lägger till nya baserat på aktuella hotrapporter. Ett detekteringsprogram som aldrig uppdateras förfaller snabbt i takt med att angripartekniker förändras.

Kostnad och tidsåtgång jämfört med kommersiell EDR

Den uppenbara fördelen med Sysmon och Sigma är licenskostnaden, men det är inte samma sak som noll totalkostnad. Tabellen nedan sammanfattar var kostnaden faktiskt ligger i respektive modell.

Kostnadspost	Sysmon + Sigma (DIY)	Kommersiell EDR
Programvarulicens	0 kr	Licensavgift per slutpunkt och år
Initial driftsättning	1–2 arbetsdagar för pilotgrupp	Timmar till en dag med leverantörsagent
Löpande regelunderhåll	Kräver dedikerad tid varje månad	Sköts till stor del av leverantören
Respons vid larm	Manuell, kräver eget SOC-arbetsflöde	Ofta automatiserad isolering inbyggd
Krav på intern kompetens	Hög – detekteringsingenjörskap i huset	Lägre – leverantören sköter analysmotorn

Den verkliga kostnaden i DIY-modellen är personaltid, inte programvara. En organisation utan någon som kan äga detekteringsarbetet löpande får sällan ut värdet av en gratis lösning, oavsett hur bra verktygen i sig är. Väg därför alltid in om ni faktiskt har kapaciteten att underhålla pipelinen innan ni väljer bort en kommersiell produkt helt.

I praktiken ser vi tre vanliga upplägg hos svenska organisationer. Det första är en ren DIY-modell för verksamheter som redan har ett kompetent IT-säkerhetsteam men begränsad licensbudget. Det andra är ett hybridupplägg där en kommersiell EDR täcker kritiska servrar och ledningsgruppens enheter, medan Sysmon och Sigma täcker resten av flottan till lägre kostnad. Det tredje är att använda Sysmon och Sigma som en tillfällig lösning under en upphandlingsprocess, för att inte stå utan synlighet medan budgeten för en permanent EDR-licens godkänns. Alla tre är rimliga, så länge valet är medvetet och inte bara ett resultat av att ingen tog ställning.

Så håller du Sigma-reglerna uppdaterade över tid

SigmaHQ-repot förändras kontinuerligt, med nya och justerade regler flera gånger i veckan. Sätt upp en enkel rutin för att hålla jämna steg: synka repot regelbundet mot en fast gren, diffa mot er senaste importerade version, och granska enbart de nya eller ändrade reglerna i stället för att konvertera om hela biblioteket varje gång.

Det är också värt att separera regler efter status-fältet i varje Sigma-fil. Nya regler taggade “test” eller “experimental” bör gå genom samma loggningsperiod som beskrivs i steg 14 innan de får larma på riktigt, medan regler taggade “stable” från etablerade bidragsgivare normalt är säkrare att aktivera snabbare. Att hålla koll på denna skillnad sparar mycket onödig tuning längre fram.

cd sigma
git pull origin master
git log --since="2 weeks ago" --oneline -- rules/windows/

Det ger er en lista över exakt vilka filer som ändrats de senaste veckorna, vilket gör granskningsarbetet hanterbart även för ett litet team. Prioritera alltid regler taggade med tekniker ni vet är relevanta för er hotbild, snarare än att försöka hålla jämna steg med hela biblioteket på en gång.

Vanliga frågor om Sysmon och Sigma

Är Sysmon helt gratis att använda i ett företag?
Ja. Sysmon är en del av Microsofts Sysinternals-svit och kostar ingenting att ladda ner, installera eller använda, oavsett organisationens storlek.

Kan Sysmon och Sigma helt ersätta en kommersiell EDR-produkt?
Nej. Kombinationen ger telemetri och regelbaserad detektering, men ingen inbyggd automatisk respons, isolering eller sanering. Den fungerar bäst som ett komplement eller som en budgetvänlig baslinje innan en EDR-licens är möjlig.

Hur många Sigma-regler bör vi aktivera från start?
Börja med en liten, relevant delmängd, till exempel 20–30 regler som matchar er faktiska hotbild, i stället för att importera hela biblioteket på flera tusen regler direkt. Utöka gradvis efter att varje regel testats och tunats.

Fungerar Sigma-regler mot alla SIEM-plattformar?
Sigma är plattformsoberoende i formatet, men varje regel måste konverteras till målbakändens frågespråk med sigma-cli eller pySigma. De flesta stora plattformar som Elastic, Splunk och Microsoft Sentinel har stöd via en officiell eller community-underhållen backend.

Räcker Sysmon och Sigma för att uppfylla NIS2-krav på loggning?
NIS2 kräver riskbaserad, proportionerlig loggning och förmåga att upptäcka incidenter, men pekar inte ut specifika verktyg. Sysmon och Sigma kan vara en giltig del av lösningen om insamlingen är robust, skyddad mot manipulation och regelbundet granskad, men varje organisation måste bedöma detta mot sin egen riskprofil och sektorsspecifika vägledning.

Varför triggar inte larmet trots att händelsen syns i loggarna?
Den vanligaste orsaken är en mismatch mellan fältnamnen i er parsade logg och fältnamnen Sigma-regeln förväntar sig. Olika SIEM-parsers normaliserar Sysmon-fält olika, vilket kan ge en giltig men tom fråga efter konvertering.

Hur ofta bör vi uppdatera vårt Sigma-regelbibliotek?
SigmaHQ publicerar ändringar flera gånger i veckan. En månadsvis granskningsrutin, där ni diffar mot senaste synk och enbart granskar nya eller ändrade regler, är ett realistiskt tempo för de flesta mindre SOC-team.

Kan Sysmon installeras på Linux-servrar också?
Ja, Microsoft underhåller en separat version kallad Sysmon for Linux, som fick en uppdatering i oktober 2026. Konfigurationsformatet skiljer sig delvis från Windows-versionen, men principen med detaljerad processtelemetri är densamma.

Sysmon och Sigma: Bygg Gratis EDR-Larm i 14 Steg [2026]