These are the slides for a recent talk on osquery I gave at a DevOpsCT meetup.
osquery is an instrumentation framework that exposes an operating system as a high-performance relational database. This allows you to write SQL queries to explore operating system data.
This query returns any process whose original binary has been deleted or modified.
This query returns hosts whose primary disk is currently unencrypted.
This query allows us to see where specific logins have occurred within your infrastructure.
With osquery, SQL tables represent abstract concepts such as running processes, loaded kernel modules, open network connections, browser plugins, hardware events or file hashes.
File integrity monitoring is available for Linux and Darwin using inotify and FSEvents. The daemon reads a list of files/directories from the osquery configuration. The actions to those selected files populate the file_events table.
As file changes happen, events will appear in the file_events table. During a file change event, the md5, sha1, and sha256 for the file will be calculated if possible. A sample event looks like this…
The osquery daemon uses a default filesystem logger plugin. Like the config, output from the filesystem plugin is written as JSON. There are two types of logs: Status logs and Query schedule results logs, including logs from snapshot queries. osquery includes logger plugins that support configurable logging to a variety of interfaces. The built in logger plugins are filesystem (default), tls, syslog (for POSIX), windows_event_log (for Windows), kinesis, firehose, and kafka.
The results of your scheduled queries are logged to the “results log”. These are differential changes between the last (most recent) query execution and the current execution. Each log line is a JSON string that indicates what data has been added/removed by which query. The first time the query is executed (there is no “last” run), the last run is treated as having null results, so the differential consists entirely of log lines with the added indication.
Snapshot logs are an alternate form of query result logging. A snapshot is an ‘exact point in time’ set of results, no differentials. If you always want a list of mounts, not the added and removed mounts, use a snapshot. In the mounts case, where differential results are seldom emitted (assuming hosts do not often mount and unmount), a complete snapshot will log after every query execution. This will be a lot of data amortized across your fleet.
Query packs help you group queries by function or problem domain into files that are easy to download, distribute, and update. There are some query packs distributed by default…
An equivalent of the OSSEC rootkit database.
An incident response query pack to help you detect and respond to breaches
