osquery är ett område där små designval ofta avgör om kontrollen blir robust eller bara ser bra ut på papper. osquery gör endpointinventering och jakt frågebart med SQL-liknande syntax och är särskilt användbart för frågor som behöver besvaras likadant över många system.
osquery i praktiken
Första byggstenen: Tables representerar processer, users, packages, sockets och annan lokal state. 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: Scheduled queries kan skapa jämförbar telemetry över tid. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det tekniska ankaret: Evented tables ger förändringsdata där plattformen stöder det. 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: Distributed query bör begränsas så att central jakt inte överbelastar endpoints. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Praktisk införandeordning
- Börja med inventoryfrågor som har tydligt schema.
- Testa queryns kostnad lokalt.
- Schemalägg endast fält som behövs.
- Skicka resultat med hostidentitet och timestamp.
- Använd ad hoc-frågor för avgränsad incidentjakt.
För osquery 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.
Så kan det se ut
En enkel fråga efter lyssnande sockets och processnamn kan snabbt svara på om en oväntad tjänst finns på hundra endpoints. Jag behöver inte vänta på att varje maskin manuellt granskas.
Tre risker i implementationen
- Att köra dyra globmönster eller processfrågor för ofta.
- Att använda osquery som ersättning för all EDR-telemetri.
- Att samla stora mängder inventory utan retention- eller användningsplan.
När jag anser ändringen färdig
För osquery 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:
- Query ger samma typer av kolumner på målplattformarna.
- Schemat orsakar acceptabel CPU- och I/O-belastning.
- Resultat kan kopplas till en unik endpoint.
Ett negativt test hör också till osquery: 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
osquery – ställ SQL-liknande frågor till endpoints och bygg verifierbar inventory 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.