osquery — SQL Lens on System State
Why It Matters
Admins spend time piecing together info: ps, netstat, digging through /var/log. Every system looks a bit different, and scripts pile up fast. osquery flips it around. It treats the OS as a database. System info becomes rows and tables you can query with SQL. Instead of custom scripts per host, you get one language to ask questions across Linux, macOS, and Windows.
How It Works
The agent runs in the background and maps internals — processes, users, sockets, kernel modules, file hashes, startup items. You can poke it interactively with osqueryi, or let the daemon (osqueryd) collect on schedule. Data can be logged locally or shipped to a SIEM. Query packs make it easy to repeat checks fleet-wide: compliance audits, persistence lookups, or suspicious binaries. Same SQL runs on all supported OSes, so scaling is straightforward.
Technical Notes
Area | Notes |
Platforms | Linux, Windows, macOS |
Purpose | Unified system visibility via SQL tables |
Data scope | Processes, users, sockets, configs, kernel modules, file integrity |
Modes | osqueryi (interactive), osqueryd (daemon) |
Output | JSON, local logs, SIEM feeds |
License | Apache 2.0, open source (originated at Facebook) |
Deployment Notes
– Install via repo or vendor binary.
– Use osqueryi for ad-hoc queries like SELECT * FROM listening_ports;.
– Deploy osqueryd with packs for scheduled checks.
– Pipe results into ELK, Splunk, or any log shipper.
– Tune packs to avoid noise and CPU load.
Where It Fits
– Incident response: snapshot of processes, sockets, persistence.
– Compliance: standardized checks for PCI, HIPAA, CIS.
– Fleet ops: one query language across thousands of machines.
– Forensics: structured evidence collection.
Caveats
– Needs SQL literacy — not everyone is fluent.
– No prevention, visibility only.
– Badly written queries can spike CPU.
– For large rollouts, extra tooling like Fleet or Kolide is almost required.