4 MIN READ
Picture the EDR stack. The dashboard shows every alert, every detection rule, every signature match. It also shows almost nothing about what the endpoint is actually doing between alerts. The process that started at 3:14am, the socket that opened to an IP nobody recognised, the scheduled task the contractor dropped in last week, all of it sits unobserved.
osquery sits underneath that layer and sees everything. The agent on the endpoint exposes the operating system as a relational database. Processes, network connections, kernel modules, loaded libraries, scheduled tasks, browser extensions, installed software, logged in users, hardware events, queryable in plain SQL. Kolide, Fleet, and Uptycs ship the agent inside most EDR consoles. So does the platform org at most Fortune 500s. The platform org paid for the licence. The platform org never paid anyone to actually run the queries.
The three tables that actually answer questions
The processes table serves as the starting point for most investigations. Path, hash, parent process, command line, user, on every running process, all of it queryable. The process_open_sockets table answers the network questions. Local address, remote address, state, owning process, on every open socket. The persistence tables sit across the three operating systems. Launchd on macOS, scheduled_tasks on Windows, cron on Linux, kernel_extensions on the Macs that still load them. Those three cover most of the questions a real incident asks, from the obvious “what process started” to the harder “which scheduled task survived the reboot.”
What the typical enterprise gets wrong
Most postmortems that trace back to an endpoint the EDR was sitting on share the same shape. The tables sit inside the console, nobody writes the query, the analyst waits for the alert. The EDR does not fire on raw osquery state changes either, so the analyst has to know what to look for in advance, and most do not. The tables return raw rows, no context, no baseline, no explanation of what a row means in the environment, and the analyst gets the data without the means to act on it. The three failure modes stack. By the time someone notices, the EDR has been logging everything and answering nothing.
How to actually use it
Start with the query library. The suspicious process pattern, the unexpected outbound socket, the new persistence entry, all of them get written once, reviewed by a peer, and reused. Without the library, every investigation starts from blank SQL and the same three queries get typed in from memory.
Then the alert rules. A new process launched from a temp directory, a new socket to a non corporate IP, a new cron entry on the build server, all of them get expressed as scheduled osquery queries. The EDR alerts catch the known signatures. The osquery alerts catch the unknown behaviour that the signatures miss.
Then the training. The analyst who has not memorised the schema cannot use the tables. A two day workshop on the osquery schema plus a notebook of the top fifty queries covers more ground than another vendor demo.
The bottom line
Build the query library, write the alert rules, train the analyst. The platform org that does those three gets the value out of the osquery tables. The one that just enabled the agent pays for the licence twice.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
