Jag ser Sigma som en praktisk säkerhetsfråga där tekniken behöver kunna verifieras, inte bara beskrivas. Sigma beskriver loggdetektion på ett portabelt sätt så att samma analytiska idé kan översättas till olika SIEM-språk och datamodeller.
Sigma i praktiken
Första byggstenen: Logsource anger vilken typ av telemetry regeln förväntar sig. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
En annan viktig del: Selection beskriver mönster medan condition uttrycker logiken. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det tekniska ankaret: Field mapping är ofta den svåraste delen mellan produkter. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det som ofta avgör kvaliteten: En regel behöver testdata och kända begränsningar för att vara användbar. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Ett arbetsflöde jag skulle använda
- Definiera först det attackerbeteende som ska synas.
- Säkerställ att rätt loggkälla faktiskt finns.
- Skriv en enkel selection med så få fält som möjligt.
- Översätt regeln till målplattform och testa mot sample events.
- Lägg tuning separat från grundlogiken när det går.
För Sigma håller jag därför införandet i små steg. Då går det att skilja ett säkerhetsproblem från ett rent driftfel och att rulla tillbaka just den ändring som gav ett oväntat resultat.
Ett konkret scenario
En bra Sigmaregel kan vara startpunkten för Sentinel, Splunk eller Elastic, men jag kontrollerar alltid det genererade queryspråket. Portabilitet betyder inte att datan automatiskt är identisk.
Vanliga sätt att göra kontrollen svagare
- Att kopiera communityregler utan att ha motsvarande telemetry.
- Att anta att fältnamn betyder samma sak i alla backends.
- Att lägga in miljöspecifika undantag tills regeln inte längre är begriplig.
Vad som måste gå att bevisa
För Sigma vill jag avsluta med mätbara efterkontroller i stället för att nöja mig med att en statusruta visar ”enabled”. De viktigaste kontrollerna här är:
- Positivt testevent ger träff.
- Normaldata ger förväntad signalnivå.
- Backend-queryn motsvarar Sigma-logiken efter översättning.
Ett negativt test hör också till Sigma: den väg, identitet eller operation som inte ska vara tillåten ska misslyckas på ett förutsägbart sätt. Då kan nästa tekniker upprepa kontrollen och förstå både avsikten och gränsen.
Slutsats
Sigma – portabla detektionsregler för loggbaserad jakt handlar därför inte om att samla fler säkerhetsinställningar. Det handlar om att minska en konkret risk med en kontroll som har tydligt scope, tydlig ägare och ett verifierbart resultat. När före-läge, förändring och eftertest dokumenteras blir säkerhetsarbetet både säkrare och lättare att förvalta.