Skriva SIEM-regler och aviseringar för detektering

Varje detektionsregel balanserar känslighet (att fånga alla sanna positiva) mot specificitet (att undvika falska positiva). En regel med mycket hög känslighet fångar alla attackvarianter men genererar ett enormt brus av aviseringar. En regel med mycket hög specificitet utlöses sällan men kan missa nya attackvarianter. Bra detection engineering börjar med hög specificitet för att skapa analytikernas förtroende och breddar sedan gradvis omfattningen när justeringar minskar antalet falska positiva och förtroendet för regeln ökar.

Tröskelbaserade regler utlöses när antalet händelser överskrider en gräns inom ett tidsfönster. De passar utmärkt för att upptäcka volymbaserade attacker som brute force, portskanning och DDoS. Viktiga parametrar är: antalströskel (hur många händelser), tidsfönster (inom hur många minuter) och grupperingsfält (per käll-IP, per användare eller per värd). Felaktiga tröskelvärden orsakar aviseringsbrus eller missade detektioner — justera dem noggrant med hjälp av historiska baslinjedata.

Sekvensbaserade regler letar efter en specifik kedja av händelser i en viss ordning, vilket passar bra för att upptäcka attackmönster i flera steg. Exempel: nätfiske-e-post tas emot DÄREFTER öppnas en skadlig bilaga DÄREFTER startas PowerShell av ett Office-program. Varje händelse kan vara godartad var för sig, men sekvensen visar att ett intrång kan ha skett. De flesta moderna SIEM-system (Splunk, Sentinel, Elastic) har stöd för sekvensmatchning med tidskorrelation över händelsekedjor.

Sigma är ett öppet, leverantörsoberoende format för att skriva detektionsregler som kan konverteras till SIEM-specifika frågespråk (SPL för Splunk, KQL för Sentinel och Lucene för Elastic). Säkerhetscommunityn delar tusentals Sigma-regler på GitHub, med täckning av vanliga ATT&CK-tekniker. Med Sigma kan organisationer använda detektioner från communityn utan att manuellt skriva om dem för sin specifika SIEM-plattform, vilket avsevärt påskyndar detektionstäckningen.

Detektionsregler måste testas innan de tas i produktion. God praxis omfattar: enhetstestning med syntetiska händelser som representerar både scenarier med sanna positiva och falska positiva, replay-testning med inspelad godartad trafik för att mäta andelen falska positiva samt red team-övningar där regeln förväntas utlösas av kontrollerade attacksimuleringar. Verktyg som Atomic Red Team tillhandahåller små testskript som på ett säkert sätt simulerar specifika ATT&CK-tekniker.

När en regel har distribuerats krävs kontinuerlig justering. Vanliga justeringstekniker är: undantagslistor för kända legitima processer eller konton som på ett korrekt sätt utlöser regeln, allowlisting av specifika käll-IP-adresser (skannrar och övervakningsverktyg), justering av tröskelvärden utifrån observerade baslinjenivåer samt tillägg av kontextvillkor (avisera endast om värden också är åtkomlig utifrån). Dokumentera varje undantag med en motivering så att framtida analytiker förstår varför det finns.

Detektionsregler bör ha allvarlighetsgrader som vägleder analytikernas prioritering. Vanliga nivåer är: Critical — aktiv exploatering, ransomware och intrång i domänkontrollant. High — lateral förflyttning, credential dumping och C2-kommunikation. Medium — misstänkt rekognosering och policyöverträdelser. Low/Informational — ovanliga men inte omedelbart farliga händelser som är värda att följa upp. Allvarlighetsgraden bör återspegla verksamhetspåverkan, inte bara teknisk allvarlighetsgrad.

Detektionsregler har en livscykel som måste hanteras aktivt. Regler blir inaktuella när miljön förändras (ny programvara distribueras eller IP-intervall ändras) och genererar då falska positiva. Regler missar nya attacktekniker när angripare utvecklar sina metoder. God praxis är att underhålla regler i versionshantering (git), granska och uppdatera dem kvartalsvis, mappa varje regel till minst en ATT&CK-teknik och mäta reglernas effektivitet (utlösningar per vecka och andel sanna positiva) för att avveckla eller förbättra regler som presterar dåligt.

En karta över detektionstäckningen lägger befintliga detektionsregler ovanpå MITRE ATT&CK-matrisen för att synliggöra täckningsluckor. Varje teknik som täcks av minst en regel markeras med grönt, medan tekniker utan täckning markeras med rött. Denna visualisering visar vilka angreppsfaser (till exempel Persistence och Exfiltration) som saknar detektionstäckning och hjälper team att prioritera utvecklingen av nya regler. Regelbundna granskningar av täckningen säkerställer att detektionsprogrammet håller jämna steg med angriparnas föränderliga tekniker.

I den här lektionen lärde ni er att detektionsregler kodar specifika angriparbeteenden som aviseringsvillkor i SIEM-systemet, att tröskel- och sekvensbaserade regler hanterar olika typer av attackmönster samt att Sigma tillhandahåller ett portabelt format för att dela detektioner inom säkerhetscommunityn. Härnäst utforskar vi UEBA och beteendeanalys för att upptäcka insiderhot och komprometterade konton.