Det intressanta med Windows Event Logs är hur snabbt teori möter drift: en kontroll måste fungera även när systemet uppdateras, felsöks och utsätts för fel. Windows Event Logs innehåller både säkerhets- och driftspår, och effektiv incidentanalys börjar med rätt kanal snarare än med att exportera allt.
Windows Event Logs i praktiken
Första byggstenen: Security-loggen fångar bland annat logon- och policyhändelser beroende på audit policy. 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: System kan visa service- och drivrutinsproblem. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det tekniska ankaret: PowerShell Operational ger annan kontext än Security. 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: Produktloggar för Defender, Task Scheduler och andra komponenter kan vara avgörande. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Så skulle jag testa det i en riktig miljö
- Definiera incidentfrågan och tidsfönstret.
- Börja med identitet och host som ankare.
- Exportera relevanta EVTX utan att ändra original.
- Normalisera timestamps.
- Korrelera event-id med process, användare och nätverk från andra källor.
För Windows Event Logs 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.
Praktiskt exempel
Vid en misstänkt fjärrinloggning tittar jag inte bara på ett logon-event. Jag jämför logon type, source address, process- eller servicekontext och vad som händer direkt efter autentiseringen.
Misstag som skapar falsk trygghet
- Att tolka event-id utan att läsa fälten och logon type.
- Att anta att frånvaro av event betyder frånvaro av aktivitet när auditing var avstängd.
- Att blanda lokal och UTC-tid i tidslinjen.
Verifiering före stängning
För Windows Event Logs 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:
- Testlogon ger förväntat event.
- Kanalerna har tillräcklig retention.
- Central insamling bevarar host- och record-id.
Ett negativt test hör också till Windows Event Logs: 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
Windows Event Logs – vilka kanaler jag börjar med i en incident 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.