Why osquery?

It is a known fact that every organization should work on maximizing its endpoint visibility. Network traffic visibility is, of course, equally important but modern enterprise networks can pose multiple obstacles to effective traffic capturing and analysis.

As we already know, endpoint visibility can be achieved to a certain degree by deploying Sysmon, but the addition of a specialized agent that can efficiently interrogate endpoints can prove useful during incident response activities. In addition, a specialized agent is great for gaining visibility into Linux endpoints and servers, where Sysmon is not applicable.

Enter osquery…

Osquery is an open source solution that can extend a Blue team’s endpoint visibility in an efficient and centralized manner. It does so by exposing operating system configuration data in the form of relational database tables. All Blue team members have to do is submit (or schedule) queries against these tables to collect valuable data about the current state of an endpoint/server as well as changes performed on it over time.

The great thing about osquery (especially when deployed on a Windows environment) is that it provides detailed insight into the registry, WMI, hardware events and many other areas that were previously disregarded by other endpoint monitoring agents or could not be interrogated though a single endpoint monitoring solution.

That being said, osquery wouldn’t be a great endpoint monitoring solution if it couldn’t easily scale don’t you think?

Imagine being able to execute the same query across all your endpoints and not only that, but also being able to receive an alert in case of a deviation from the normal endpoint state. Well, you can actually do that by enrolling every osquery agent to a Kolide Fleet. Kolide Fleet is essentially an open source osquery manager that enables you to track, manage, and monitor your entire infrastructure from a single user interface

Most of osquery’s virtual tables are generated when an SQL statement requests data. This is not the optimum approach from a data gathering perspective though.

Consider the processes table: if a process like ps runs for a fraction of a moment there’s no way SELECT * FROM processes; will ever include all the details. To solve this osquery exposes a publish-subscribe framework for aggregating operating system information asynchronously at event time, storing related event details in the osquery backing store, and performing a lookup to report stored rows at query time.

Let’s take for example the need for file integrity monitoring (FMI). A query scheduled to run every 5 minutes to identify editing/injection attempts against important files on a system may miss an interval where an attacker tampered with a file. In such cases, where continuous visibility is required, we can leverage the aforementioned publish-subscribe framework. Specifically, we can work with event-based queries and evented tables that track time or action changes to files specified in configuration data. Technical details on how to work with evented tables are provided on the video that follows…

Osquery is full of useful capabilities and integrations. I strongly suggest you go through the official documentation to learn about them. https://osquery.readthedocs.io/en/stable/