There are two reputations(at least) that your faithful writer is hoping to shake: #1, I do not work for Google. #2, I am not the ‘osquery guy’. I don’t even know any C++! (I’m going to make time for this eventually, though.) However, for three events over the course of three months earlier this year I was invited to talk about osquery on the Mac. For the U of Utah, while illustrating how I approached my security team with this (among other FOSS tools), I used a chestnut by a certain AFP548 alumni about the concept of ‘fences, not walls’. Don’t lock a machine down until it loses any chance of actual productivity or creative use, which ignores the fact that physical access is total access, anyway. Instead, think of your management enforcement attempts as a fence that end users will jump – and make sure those instances can be logged so that one of three things can happen: ‘compliance’ folks can remediate, HR can… do their work, and/or policies can be altered as needed.
Back when dtrace came to OS X (back when it wasn’t yet macOS…) sysadmins rejoiced! For the first time they could do truly mind-expanding tasks with unprecedented low system impact: A firehose of info was now available to us, covering everything from cpu operation specifics to filesystem activity. FSEventer(temporarily offline for over a year now 😢) became an invaluable part of our toolset, helping us trace the behavior of things like cfprefsd when trying to track down settings. We got spoiled by this low-level access and high-performance. In the linux server world, new security-focused features came on the scene as well, like auditd. The trend has turned to using these performant interfaces to the system in lieu of heavier, inflexible host-based intrusion detection tools.
Individuals may be fine with friendlier tools like Little Snitch and osxlockdown, but organizations that need to set up policies and collect metrics would want to start by gathering standardized information from across their environment. Written in C++, osquery runs on many operating systems, but is specifically tailored towards each platforms attack vectors. Facebook, in conjunction with dozens of contributors around the world, has a secure release process and is continually adding features based on the criteria admins need to collect. The user interface to the information it can access is via the sql language, and therefore collections of OS details can be mashed together and sliced and diced as needed.
Where exactly does this intersect with security? How does it ‘do it better’ than similar products like Puppet’s Facter, or certain management tools with ‘throw a script at a machine’ inventory systems that use peer-to-peer communication and advanced threat modelling to efficiently circuvent firewalls and conveniently makes you write all the products logic?
osquery does not need to know everything about a system. You can disable tables (collections of data in sql parlance,) from being accessed to ensure you aren’t collecting information you don’t want, like environment variables a developer might leak credentials into. And the product doesn’t even collect browser histories, which incident response will need to pull an image of the affected drive to access. That being said, what it can access are the most common indications of compromise: browser extensions, launchd jobs, applications stuffed out of sight, and other ways badware tries to get persistence on a Mac. It can also overcome a blind spot in the ‘periodic run’ inventory tools: what happens if an event occurs in between the interval that it’s scheduled to collect this data? osquery overcomes this with tables whose names end in ‘_events’, which leverage system frameworks for high-priority data types. These have the capability of essentially ‘streaming’ the actions it’s configured to pick up on in real-time when using the osqueryd daemon.
Another way it can be less naïve than other systems like xprotect is its support for file integrity monitoring(FIM) – other tools that are based on the presence of definitions must find an exact match to be ‘known-bad’. FIM can help you work in reverse by reporting on known good files at certain paths, so you don’t have to trust file names at certain paths in order to tell everything is as you’d expect it to be. Many pieces of malware hide in plain sight by choosing names that will be overlooked by casual inspection. Being able to collect fingerprints on files you don’t recognize or DON’T match as-of-yet known-bad files means you can do your own research without actually pulling the artifact off the affected machine. Apple’s future push towards adopting xip files and DMG signing instead of zip’s will help extend this chain of trust to the distribution step as well. osquery can also stream DMG mount events so you can trace the path from a benign-looking filedropper to the actual infected application.
In this way osquery can watch the fence-jumping and give you the historical play-by-play of what is occuring – if a new launchd shows up after a DMG mount event, your chain of cause and effect is captured way before VirusTotal can scrape up enough strikes for the AV vendors to wake up about that particular strain of an infection.
Finally, one of the built-into-the-core features of osquery is the ability for it to both receive configs over https and send the results of queries over the wire as well. And a newer table (this is going to BLOW YOUR MIND) can parse Apple System Log – perhaps obviating the need for most log aggregation and shipping. Not only can osquery gather its own criteria, but it can also send scraped data from other logs! I hope this dipping-of-a-toe into osquery has piqued your interest. In addition to the U of Utah presentation above, I gave talks on leveraging osquery from python for Philly Mac Admins, and a more… ‘entertaining’ intro at MacDevOps YVR.