Här går jag igenom området ur ett SOC-perspektiv, med fokus på evidens, kontext, analysthypoteser och hur man går från en signal till en tekniskt motiverad slutsats.
Varför detta spelar roll
SIEM är mer än en produkt. Det är ett data- och analystflöde där loggar samlas, normaliseras, söks, används i detections och kopplas till incidenthantering.
Teknisk modell
Sentinel, Splunk, Wazuh och Elastic har olika implementationer men analytikern behöver fortfarande förstå schema, tidsfält, entiteter och hur en query motsvarar ett beteende.
Ingestion och normalisering
Det här avgränsar vilken tillgång, datakälla eller konfiguration som ska undersökas först. Med ett tydligt scope blir det lättare att skilja relevant evidens från närliggande brus.
Queries/detections
Nästa fråga är vilken påverkan observationen har på miljön och vilka beroenden som berörs. Innan en förändring görs behöver man förstå blast radius och vilken ytterligare evidens som krävs.
Investigation och response
Här kopplas observationen till ett konkret tekniskt arbetsmoment. Beroende på miljö kan det innebära en portal, query, API, CLI eller loggkälla, men steget ska vara reproducerbart och möjligt att granska.
Praktiskt arbetsflöde
- Kontrollera ingestion och tidsstämplar.
- Förstå normalisering/schema.
- Bygg query från en analystfråga.
- Validera mot känd data.
- Skapa detection med tydlig context.
- Följ upp alert till incident och response.
Konkret exempel
En första KQL-sökning bör vara enkel och lätt att verifiera. För en identitetsfråga kan man exempelvis börja med ett snävt tidsfönster och därefter lägga på fler villkor:
SigninLogs
| where TimeGenerated > ago(24h)
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, ResultType
| order by TimeGenerated desc
Poängen är inte att queryn i sig är avancerad. Den skapar ett kontrollerbart utgångsläge. Därefter kan man pivota på identitet, IP, applikation och resultatkod och kontrollera om samma tidslinje stöds av andra datakällor.
Vad jag vill kunna verifiera
Jag vill testa att en datakälla verkligen levererar de fält som en detection förutsätter. En regel som är korrekt syntaktiskt men saknar data är funktionellt värdelös.
Man kan använda följande kontrollfrågor:
- Vilken rådata eller konfiguration stödjer slutsatsen?
- Vilket resultat förväntas efter en förändring?
- Finns ett negativt test som visar att en förbjuden väg verkligen är stängd?
- Kan man återgå säkert om förändringen ger en oväntad sidoeffekt?
Vanliga fallgropar
- Samla allt utan use case.
- Fältantaganden utan kontroll.
- Ingen retentionstrategi.
- Dashboards som ersätter investigation.
Koppling till yrkesrollen
För mig är värdet i ämnet att det går att koppla till ett verkligt analyst- eller engineeringflöde. Man behöver kunna förklara varför kontrollen finns, vad som ska mätas och hur resultatet verifieras.
Om central endpointhantering
Wazuhs API kan användas för agenthantering och Active Response, medan system inventory kan ge central information om bland annat programvara, nätverk, portar, processer och tjänster. I mina egna koncept vill jag lägga skyddsräcken runt response: rätt agent-ID, minsta privilegium, allow-listad action, audit, verifiering och tydlig receipt.
Frågor jag tar med till en verklig miljö
När jag lämnar labbet och tänker på en riktig verksamhet försöker jag alltid ställa några kontrollfrågor innan samma metod används skarpt:
- Vilken tillgång eller affärsprocess påverkas om kontrollen fungerar fel?
- Vilken person eller funktion äger systemet och kan bekräfta legitimt beteende?
- Vilken telemetry finns redan, och vilken datakälla saknas för att slutsatsen ska bli tillräckligt stark?
- Vilken del kan testas i begränsad scope innan förändringen breddas?
- Hur dokumenteras expected result, efterkontroll och rollback så att nästa tekniker kan förstå vad som gjordes?
Sammanfattning
SIEM är ett arbetssätt, inte en produkt – Sentinel, Splunk, Wazuh och Elastic handlar för mig ytterst om att göra säkerhetsarbetet begripligt och verifierbart. Man får ett bättre resultat när analysten kan gå från observation till evidens, från evidens till avgränsad åtgärd och från åtgärd till ett kontrollerat eftertest.