För mig blir PowerShell-loggning värdefullt först när resultatet går att testa med både positiva och negativa kontrollfall. PowerShell är ett legitimt administrationsverktyg och därför också intressant för angripare; bra loggning ska göra beteendet granskningsbart utan att blockera normal drift blint.
PowerShell-loggning i praktiken
Första byggstenen: Script Block Logging kan visa scriptinnehåll som faktiskt exekveras. 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: Module Logging kan ge modul- och pipelinekontext. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det tekniska ankaret: Transcription kan vara användbart men kräver känslig hantering av output. 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: AMSI ger säkerhetsprodukter möjlighet att inspektera scriptinnehåll i körflödet. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Arbetsgång utan genvägar
- Aktivera relevanta loggfunktioner via central policy.
- Skicka Operational-loggar till central lagring.
- Skapa testscript med känd unik markör.
- Kontrollera att markören syns i rätt event.
- Bygg detektion på beteende och kontext snarare än ordet powershell.
För PowerShell-loggning 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 testbart exempel
Jag använder ett harmlöst script med en unik sträng och ett enkelt nätverks- eller filsteg. Om den kedjan syns i loggarna vet jag vilka fält som finns innan jag skriver en detektionsregel.
När en bra idé blir fel i drift
- Att logga känsliga hemligheter utan åtkomstkontroll på loggplattformen.
- Att blockera PowerShell generellt och driva administration till mindre synliga verktyg.
- Att larma på varje encoded command utan ytterligare kontext.
Efterkontroll
För PowerShell-loggning 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:
- Testscript kan hittas centralt.
- Loggarna går att koppla till användare och host.
- Legitim automation skapar hanterbar signalnivå.
Ett negativt test hör också till PowerShell-loggning: 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
PowerShell-loggning – gör administration och missbruk synligare 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.