När jag arbetar med Sysmon försöker jag börja i den faktiska tillgången, datan och förändringen som ska skyddas. Sysmon kan ge betydligt rikare Windows-telemetri om processer, nätverk och filhändelser, men konfigurationen måste balansera analytiskt värde mot volym.
Sysmon i praktiken
Första byggstenen: Process Create med parent, command line och hashes kan ge stark kontext. 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: Network Connect kan koppla process till destination men blir snabbt volymrik. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det tekniska ankaret: Image Load och File Create kan vara värdefulla selektivt. 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: Config bör versionshanteras och testas mot normal programvara. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Från nuläge till verifierad kontroll
- Börja med process- och nätverkshändelser som stöder era detektioner.
- Mät eventvolym per endpointtyp.
- Lägg inkluderings- och exkluderingsregler på konkreta grunder.
- Skicka loggen centralt.
- Retesta detektionsregler efter configändring.
För Sysmon 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.
Exempel från ett driftperspektiv
Jag skapar gärna en kontrollerad PowerShell-process som startar ett känt barnprogram och gör ett nätverksanrop. Då kan jag se om processkedjan och connection-event faktiskt går att korrelera.
Fallgropar jag försöker undvika
- Att kopiera en jättestor communityconfig utan att förstå datavolymen.
- Att exkludera breda paths för att tysta ett enda program.
- Att uppdatera Sysmonconfig utan att kontrollera event coverage.
Kontrollpunkter
För Sysmon 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:
- Förväntad testprocess syns med parent och command line.
- Nätverkstest kan kopplas till rätt process.
- Loggvolym håller sig inom planerad kapacitet.
Ett negativt test hör också till Sysmon: 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
Sysmon – rikare Windows-telemetri när standardloggar inte räcker 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.